Re: GIT workflow

[Andrey Borzenkov]

В Thu, 28 Nov 2013 07:45:00 +0100
"Vladimir 'phcoder' Serbinenko" <address@hidden> пишет:

> 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" <address@hidden> wrote:
> 
> > В Thu, 14 Nov 2013 15:20:10 +0200
> > Mikko Rantalainen <address@hidden> пишет:
> >
> > > 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 <address@hidden>
> > >
> > > 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
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >