Re: GIT workflow

[Andrey Borzenkov <arvidjaar@gmail.com>]

В Thu, 14 Nov 2013 15:20:10 +0200
Mikko Rantalainen <mikko.rantalainen@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.thor@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"?