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. 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
