Hi, > Oh, wait, do you mean that when you commit a fix to your code, you > would add a second parent to that commit which refers to the issue > that's fixed? So instead of having a special marker (says "Fixes: > issue#<foo>") in your commit message, you refer to the issue as a > parent? Yep.
> Hmm... that sounds interesting. I wonder what that allows you to do > that the "Fixes: issue#<foo>" doesn't, tho. I can see that it makes > sure your issues-history is always preserved in the code-history, but > I'm not sure if that's a feature. It's a question of what's your use-case or work-flow. Especially for patch-sets, it often makes sense to have some sort of description preserved for future reference. Kernel-devs, for example, post a patch-set with a cover letter. For bug-reports, conserving at least some of the discussion may also be important. Anyway, we might as well introduce other ways of (weak) references through trailers, for more flexibility. > > For example bugs can be files on a certain commit > > I don't understand what you mean by that. Neither do I. > [ The main problem of BuGit (other than lack of manpower) is that it > needs to be rewritten from scratch since it's currently just an sh > script. ] Well, if you look at git-dit's history you'll discover that it was developed as a collection of bash scripts as well. > One more thing, in > https://github.com/neithernut/git-dit/blob/master/doc/datamodel.md you > say that message metadata is kept in the form of "git-tags". Do you > mean the same tags as those managed by "git tag"? How does that work? "git-tag" is a bit ambiguous. By "git-tag" we mean trailers. Maybe we should be more explicit on that front. Regards, jule _______________________________________________ dist-bugs mailing list [email protected] https://kitenet.net/cgi-bin/mailman/listinfo/dist-bugs
