GIT workflow

GIT workflow

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

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?
- Which commits should we sign? All? Some? Official releases?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

Re: GIT workflow

[Mikko Rantalainen]

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

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

-- 
Mikko

Re: GIT workflow

[Andrey Borzenkov]

В 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"?

Re: GIT workflow

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 3317 bytes --]

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" <arvidjaar@gmail.com> wrote:

> В 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"?
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 4347 bytes --]

Re: GIT workflow

[Andrey Borzenkov]

В Thu, 28 Nov 2013 07:45:00 +0100
"Vladimir 'phcoder' Serbinenko" <phcoder@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" <arvidjaar@gmail.com> wrote:
> 
> > В 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"?
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >

Re: GIT workflow

[Colin Watson]

On Thu, Nov 28, 2013 at 09:26:36PM +0400, Andrey Borzenkov wrote:
> В Thu, 28 Nov 2013 07:45:00 +0100
> "Vladimir 'phcoder' Serbinenko" <phcoder@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.

gnulib (which we're already using elsewhere) has a "gitlog-to-changelog"
module that allows you to autogenerate ChangeLog; basically we'd move
ChangeLog to ChangeLog-2013 and then add a dist-hook that autogenerates
everything after that.  I quite like that approach, and it's used by
major GNU projects such as coreutils and diffutils.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]