В Thu, 28 Nov 2013 07:45:00 +0100 "Vladimir 'phcoder' Serbinenko" <phco...@gmail.com> пишет:
> I don't like the idea of double work to essentially have 2 commit messages. > But it's possible to remove Changelog file. I'd like to know if any other > major gnu projects made the move. Oh, I did not dare to ask but if you mention it :) Yes, ChangeLog is the major source of merge conflicts and makes it impossible to cleanly cherry-pick patches for package maintenance. So please ... > On Nov 25, 2013 7:27 PM, "Andrey Borzenkov" <arvidj...@gmail.com> wrote: > > > В Thu, 14 Nov 2013 15:20:10 +0200 > > Mikko Rantalainen <mikko.rantalai...@peda.net> пишет: > > > > > Vladimir 'φ-coder/phcoder' Serbinenko, 2013-11-10 19:01 > > (Europe/Helsinki): > > > > Hello, all. We've switched to git some time ago, now we should have > > some > > > > kind of workflow documents. In particular I think of following points: > > > > - Developpers with commit access can create branches as they see fit as > > > > long as it's prefixed by their name and they don't do sth nasty like > > > > storing binary or unrelated files. > > > > - When committing bigger work should we merge or squash? I think that > > > > squash should be possible if developper desires. Is there any reason to > > > > use merges? > > > > > > Squashed merge is identical to rebase && merge --no-ff except for the > > > detail that squashing loses any meaningful history for the patch series. > > > I'd seriously suggest rebase followed by merge --no-ff over squashed > > > merges. The only exception is the case where commits in the original > > > work are not logical patches but instead random snapshots of the > > > directory tree during development of the patch. In that case, squashing > > > the patch series loses no valuable information. > > > > > > The reason to keep patch series: git bisect > > > > > > > Also squash is losing individual contribution. > > > > I think it really depends. For simple patches that are self-contained > > squash is actually better; that is basically what TopGIT does to > > maintain patches. For anything developed over long time history should > > be preserved (a.k.a. merge). > > > > > > - Which commits should we sign? All? Some? Official releases? > > > > > > Depends on what you mean by "sign". If you mean > > > > > > Signed-off-by: A U Thor <a.u.t...@example.com> > > > > > > that's the "Developer Certificate Of Origin": > > > http://elinux.org/Developer_Certificate_Of_Origin > > > > > > Other projects (e.g Grub) can decide their own policy for such metadata. > > > Additional info is available at > > > > > http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for > > > > > > If you mean digitally signed, the correct method is to use signed tags > > > for all the releases meant for non-developers. See "git help tag" and > > > look for "--sign". > > > > > > > Release tags should better be signed; is there official key to be used > > in this case? > > > > I have additional topic > > > > - format of commit message > > > > Established GIT commit message is single summary line followed by more > > extensive description if necessary. Quite a number of git commands and > > wrappers around git assume that the summary line is present. Currently > > commit message format is near to useless. Half of the first line is > > lost for file name; the second half is partial sentence, often > > meaningless. > > > > Could we break with tradition "commit message" == "ChangeLog entry"? > > > > _______________________________________________ > > Grub-devel mailing list > > Grub-devel@gnu.org > > https://lists.gnu.org/mailman/listinfo/grub-devel > > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
