On 6/10/07, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Adding git & gitweb support to traq, bugzilla, mantis, gforge, etc is > what is going to make the difference. Most of those have already the > ability to "link" to one or more commits -- after the commits are done > and in GIT. You are a brave person to say this (no sarcasm --- I wish I were, too). On one hand, I very much applaud and appreciate your comment for injecting sanity to the discussion. On the other hand, if Linus had such an attitude, we might not be hacking on git right now.
Thanks for the reply - sorry for being a bit of a stirrer ;-) Yes, I do appreciate the irony and I'd have never started git. If anyone really wants to do their own bugtracker... be like Linus not like me (a mere follower) ;-)
After looking at the above existing alternatives, some brave soul might decide and say, "Hey, I can write something better in 2 weeks" ;-).
Definitely. But that takes a deeper look into the above alternatives, and probably a good perspective. I hope noone takes offence if I say that -- as a user of several bugtrackers over ~10 years -- I haven't yet read anything in this thread that is exciting. And "it's closely integrated with git" can actually be a misfeature. Cool if it's what gets you going, but not enough for world domination ;-)
All of your examples are going from a single bug to commits, but from a release person's point of view, you are never interested in a single bug, just like a top-level maintainer is never interested in a single file. A release person would want to go in the reverse direction: from a commit range to a set of bugs.
That's right. It's not that hard to correlate commits-in-the-changelog and ask the bugtracker to produce a "tracker changelog" showing all the bugs/tasks that link to the commits (with that liberal view of "links to" discussed before). Formatting of the tracker changelog _is_ tricky but that's due to the ambiguities in those relationships. (In Moodle I use JIRA, a non-FOSS tracker, and it does exactly that. I think it has some notion of CVS branches, and where tags sit, so you can ask for a report of which bugs are fixed in the release you are preparing on branch X).
What bugs were fixed and what regressions were introduced during this release cycle. While embedded ticket numbers in commit log messages would certainly help, a change made to fix a particular bug may fix another as its side effect, and the develeoper who did the change may not know about the latter when the commit log message is written.
I agree it's useful, but I don't think it has any benefit having it in the SCM _at all_. Having them in the BT is a lot more flexible -- and the fact that git has stable commit IDs makes it easier to integrate in a BT; as the BT can spot that the commit fixing bug 123 is now merged into head ZZ as well as head YYY. So the BT holds "external tags" to your commits. Lots of them. With a ton of data. And that's great -- in fact there's no stopping it -- the stability of SHA1s means that the whole internet holds tags to your repo. Every time a SHA1 (or output of git-describe) is mentioned in a mailing list, wiki or forum, there's a tag. Now, to rule the world, BTs gain a lot more from being able to integrate with different SCMs, automated test systems (like tinderbox), MTAs (debbugs), wikis (traq), stats tracking for PHBs (bugzilla), etc. So loose coupling wins here, and git's SHA1s are great for that. And at git's end we can get the smooth integration using/abusing that loose coupling strategy. So if git-log/gitk/qgit grow some hooks that can be used to perform a lookup... I can think of a perl script that gets events for each SHA1 that git-rev-list produces and returns one bug number, url and title (or more than one) that then git-log / gitk / qgit / annotate can use to further "decorate" the commit info in a similar style to what gitk is doing now with head names in each commit. Would that fit your vision of a nicely integrated tracker? martin (who's now thinking how to craft a proof of concept) - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
