Main branch being maintained with 'git am', how do mere mortals interact without too much conflicts?

Main branch being maintained with 'git am', how do mere mortals interact without too much conflicts?

[Junichi Uekawa]

Hi,

I've been maintaining my Git repository (monthlyreport.git) where most
people do not have push access, and I'm taking patches through e-mail
with 'git am'.

It often happens that I'm receiving patches which won't apply without
a merge ('git am -3') and happen to be conflict-resolving often,
because people work off a branch a few days before, and try to send
patches nearer the deadline (This is a monthly meeting resume, which
people are expected to submit their material, so this is kind of
normal).


One thing I'm worried is that users apparently have to throw away
their own change or do some conflict resolution.


User does 
  git pull xxxx
  edit ...
  git add 
  git commit 
  git format-patch -o ... HEAD^


I do bunch of 
    git am -3 (which usually has a conflict of some way or other)
    git add XXXX
    git am -3 --resolve
    git push


User then find that when doing

  git pull

again, a conflict will occur. 



I am thinking of recommending the users to create a branch

  git checkout -b my-work-for-2009-01 origin
  edit ...
  git add
  git commit
  git format-patch -o ... HEAD^
  send the email

and do

  git checkout master 
  git pull

and throw away their branches when they are included upstream.



Something tells me the problem is that I'm probably using a workflow
that resembles SVN too much, and users aren't used to branches yet.
Has anybody found this to be a problem, or better yet, is there a 
better workflow?



-- 
dancer@{netfort.gr.jp,debian.org}

Re: Main branch being maintained with 'git am', how do mere mortals interact without too much conflicts?

[Peter Harris]

On Sat, Jan 10, 2009 at 6:11 AM, Junichi Uekawa wrote:
> I am thinking of recommending the users to create a branch
...
> and throw away their branches when they are included upstream.

Yes, with a patch based workflow, this is almost required; all of the
commits will at least have different committer information.

There's nothing wrong with this approach.

> Something tells me the problem is that I'm probably using a workflow
> that resembles SVN too much, and users aren't used to branches yet.
> Has anybody found this to be a problem, or better yet, is there a
> better workflow?

If you need the commits to be identical, and you don't mind your email
consisting of a binary blob attachment, you can ask your contributors
to send you a bundle instead of a series of patches. "git help bundle"
for details.

Peter Harris

Re: Main branch being maintained with 'git am', how do mere mortals interact without too much conflicts?

[Santi Béjar]

2009/1/10 Junichi Uekawa <dancer@netfort.gr.jp>:
> Hi,
>
> I've been maintaining my Git repository (monthlyreport.git) where most
> people do not have push access, and I'm taking patches through e-mail
> with 'git am'.
>
> It often happens that I'm receiving patches which won't apply without
> a merge ('git am -3') and happen to be conflict-resolving often,
> because people work off a branch a few days before, and try to send
> patches nearer the deadline (This is a monthly meeting resume, which
> people are expected to submit their material, so this is kind of
> normal).
>
>
> One thing I'm worried is that users apparently have to throw away
> their own change or do some conflict resolution.
>
>
> User does
>  git pull xxxx
>  edit ...
>  git add
>  git commit
>  git format-patch -o ... HEAD^
>
>
> I do bunch of
>    git am -3 (which usually has a conflict of some way or other)
>    git add XXXX
>    git am -3 --resolve
>    git push
>
>
> User then find that when doing
>
>  git pull
>
> again, a conflict will occur.
>
>
>
> I am thinking of recommending the users to create a branch
>
>  git checkout -b my-work-for-2009-01 origin
>  edit ...
>  git add
>  git commit
>  git format-patch -o ... HEAD^
>  send the email
>
> and do
>
>  git checkout master
>  git pull
>
> and throw away their branches when they are included upstream.
>
>
>
> Something tells me the problem is that I'm probably using a workflow
> that resembles SVN too much, and users aren't used to branches yet.
> Has anybody found this to be a problem, or better yet, is there a
> better workflow?

I think your workflow is fine. When someone sends a patch s/he has to
know that their branch is a throw away branch to create the patch.
Another thing is if you send it as a public repository or as a bundle,
and even then the maintainer can decide to apply it merging or
cherry-picking.

There is a doc explaining " An overview of recommended workflows with
git" in git:

http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

HTH,
Santi

Re: Main branch being maintained with 'git am', how do mere mortals interact without too much conflicts?

[Sitaram Chamarty]

On 2009-01-10, Junichi Uekawa <dancer@netfort.gr.jp> wrote:

> I've been maintaining my Git repository (monthlyreport.git) where most
> people do not have push access, and I'm taking patches through e-mail
> with 'git am'.

In general, if inputs are bunched up and arrive all
together, there's bound to be conflicts.

> It often happens that I'm receiving patches which won't apply without
> a merge ('git am -3') and happen to be conflict-resolving often,
> because people work off a branch a few days before, and try to send

That's the key phrase, the delay between when they pulled
and when they committed.  I'm not sure of the nature of the
data, and how close it is to "source code" but normally this
is a case for a rebase.

If you don't want them to use branches, you can sort of get
away with these changes to your current flow:

> User does 
>   git pull xxxx
    use "git pull --rebase xxxx" instead of plain pull;
    resolve conflicts if needed
>   edit ...
    (I'm assuming there's a long gap between the pull above
    and the add below)
>   git add 
>   git commit 
    git fetch       # update from origin
    git rebase origin/master
    (they may have to resolve conflicts, but it's easiest
    when done at this point)
>   git format-patch -o ... HEAD^

> I do bunch of 
>     git am -3 (which usually has a conflict of some way or other)
>     git add XXXX
>     git am -3 --resolve
>     git push

The less the time gap between their "git format-patch" and
your "git am", the less conflicts you will have.  If you're
working almost in "real time", the next user gets the latest
tree when he does his "git rebase origin/master" -- and in
fact that becomes pretty much the only point at which any
conflicts even happen.

...and you don't usually have to resolve a single conflict
;-)

Re: Main branch being maintained with 'git am', how do mere mortals interact without too much conflicts?

[Sitaram Chamarty]

On 2009-01-10, Peter Harris <git@peter.is-a-geek.org> wrote:
> On Sat, Jan 10, 2009 at 6:11 AM, Junichi Uekawa wrote:
>> I am thinking of recommending the users to create a branch
> ...
>> and throw away their branches when they are included upstream.
>
> Yes, with a patch based workflow, this is almost required; all of the
> commits will at least have different committer information.
>
> There's nothing wrong with this approach.

That is almost exactly what a rebase does.  Each patch on
your local "master" that eventually made it upstream gets
discarded during the rebase (which is a pretty cool thing!),
and what remains are commits that did not make it upstream
-- their current "work in progress".

The difference between "origin/master" and "master", after
each rebase, is their "private branch".

Except you don't have to confuse them by saying so ;-)

>> Something tells me the problem is that I'm probably using a workflow
>> that resembles SVN too much, and users aren't used to branches yet.
>> Has anybody found this to be a problem, or better yet, is there a
>> better workflow?
>
> If you need the commits to be identical, and you don't mind your email
> consisting of a binary blob attachment, you can ask your contributors
> to send you a bundle instead of a series of patches. "git help bundle"
> for details.

Excellent idea.  But it only works for the first user who
sends him a bundle.  The next one that he gets, assuming
that user also started from the same "upstream" commit as
the starting point, will be a merge, and he has to resolve
conflicts anyway.

Essentially, two things have to happen to reduce conflict
resolution overall.  The users must rebase against the
latest upstream before sending the patch, and the supervisor
must process and push received patches asap.