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]

Git workflow

[Peter Gordon]

Hi.

There are a number of us working on a project. We each have a HEAD, and
work on branches, using git-checkout -b MyPatch. When we have finished
working on the branch, we move back to the HEAD, with 
git-checkout master, do a 
git-pull
and then git-cherry-pick sha1.....

I have two questions. 

1) Is this the normal way to work with git.

2) Also, we sometimes get a log of 
Merge branch 'master' of git://sgit/MyProject which has no commits. Why
does this happen?

Thanks,

Peter

Re: Git workflow

[Thomas Harning]

On Mon, 10 Mar 2008 14:37:43 +0200
Peter Gordon <peter@pg-consultants.com> wrote:

> Hi.
> 
> There are a number of us working on a project. We each have a HEAD,
> and work on branches, using git-checkout -b MyPatch. When we have
> finished working on the branch, we move back to the HEAD, with 
> git-checkout master, do a 
> git-pull
> and then git-cherry-pick sha1.....
> 
> I have two questions. 
> 
> 1) Is this the normal way to work with git.
Since you always work on your own 'branch', you have no need to check
out a new branch to be independent of others.
If you 'do' work on your own branch, the easier way would be to do one
of the following:
a) git pull
b) Separate branches for separation..
  git checkout master
  git pull -- may cause a merge
  git merge <your branch> -- if you worked on your own branch..git pull
c) Get the latest changes and linearize history
  git fetch
  git rebase origin/master

a - Easiest and more sane
	If you want to work on your own branches you can always
	work on that branch and pull updates from the master
b - Might keep workflow simpler and follows your workflow without
cherry-picks
c - Might be good if you create a simple patch and don't care about the
history and haven't published the branch
> 
> 2) Also, we sometimes get a log of 
> Merge branch 'master' of git://sgit/MyProject which has no commits.
> Why does this happen?
git pull performs explicit merges if your repository is not at the
exact same point as another.  Depending on what has happened, there
might be no code changes, but the history is different (perhaps
out-of-order 'cherry-picks')

Re: Git workflow

[Junio C Hamano]

Peter Gordon <peter@pg-consultants.com> writes:

> ... When we have finished
> working on the branch, we move back to the HEAD, with 
> git-checkout master, do a 
> git-pull
> and then git-cherry-pick sha1.....
> ...
> 1) Is this the normal way to work with git.

It does not look "normal" in that I do not see anything that pushes
your change back so others can build on top of it.  Also cherry-pick is
valid but it probably is easier to use "git rebase" frontend.

You need to answer one policy question at the project level.  Do you want
the shared central repository to be a place for your developers to also
share their not-quite-ready-for-master-work-in-progress? 

Assuming you don't, for the sake of simplicity for now, you can simplify
the workflow by dividing it conceptually into two levels:

 * shared repository 'master' branch is where everybody meets.  Birds-eye
   view of what you do is:

   (0) git clone;

   (1) work locally to advance your 'master';

   (2) "git fetch origin", followed by "git rebase remotes/origin" to make
       sure your changes come on top of whatever others have done while
       you were working in step (1);

   (3) "git push origin master", which pushes back your 'master', so that
       others can build on what you did in step (1);

   (4) go back to (1) to work further.

 * because you always push your 'master' in step (3) above, as long as you
   have what you want in your 'master' at that point, it does not matter
   _how_ you work towards that state in step (1) above.

   You can employ local topic branches (or you can use guilt patch stack),
   and nobody else needs to know about it.  If you have a long-running
   work that won't be ready for the shared 'master', you may locally:

   (a) "git checkout -b my-topic master";

   (b) work locally whenever you find time;

   (c) "git checkout master" if you get interrupted and have more urgent
       things to do;

   (d) "git checkout my-topic" to continue, but from time to time, it
       would be a good idea to "git rebase remotes/origin" while on that
       branch, and when you are finally done with my-topic, then

   (e) after making sure with (2) above that your 'master' is up-to-date,
      "git checkout master", "git merge my-topic".

   (f) then finally "git push origin master".

   But you can consider these steps (a)-(e) merely "implementation
   details" of how you would perform (1) above.

Once you got comfortable with the workflow without topics, more advanced
developers among you would find local topic branches handy way to organize
their work.  But you do not have to.  And if you do not use local topics,
there is no reason to avoid working directly on 'master'.