On 30.09.2013 20:55, Jonathan Nieder wrote: > Hi, > > Marc Strapetz wrote: >>> On Wed, Jul 17, 2013 at 03:03:14PM +0200, Marc Strapetz wrote: > >>>> I'm looking for a specification or guidelines on how a Git client should >>>> integrate with bug tracking systems. > [...] >> Finally, I've created a minimal spec which is sufficient to parse and >> display issue IDs: >> >> https://github.com/mstrap/bugtraq/blob/master/specification.txt > > Neat. :) > > It reminds me a little of Gerrit's commentlink functionality, though > that tries to solve a different / more generic problem (automatic > linking in commit messages in general, not just to bug trackers): > https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#_a_id_commentlink_a_section_commentlink Thanks, that's an interesting pointer. I have included some of the ideas in this new draft (section 2 and new section 3): https://github.com/mstrap/bugtraq/blob/wip/specification.txt > Some projects use more than one bug tracker. For example, a distro > might have its own bug tracking system and also sometimes make commits > that refer to the upstream bug tracker. I don't think that's > important to necessarily address in the first version of a project > like this, but thought I should mention it to help plans for the > future. I'd even say it's a good idea to prepare for multiple configurations right from the beginning :) I've changed that in the draft as well. > Gerrit keeps its configuration in a file named "project.config" in the > tree associated to the refs/meta/config commit so a single > configuration can be applied to the entire repository. Which > .gitbugtraq file should take effect in a repository with multiple > branches? Actually, if the configuration changes over time, .gitbugtraq does not work well, at least when working with older commits. However, the advantage of this regular file is that users will get it automatically when cloning a repository for the first time and they will get updates to this file on Pull as well. So the Bugtraq configuration works out of the box. To set up refs/meta/config, you have to be a Git expert, IMO. And -- more important -- a user (or the client) needs to invoke additional commands to receive the configuration (or updates of the configuration). Nevertheless I see the advantages of this singular file as well. So I'm not sure, how to proceed here. -Marc -- 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