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

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?

On Sat, Jan 10, 2009 at 6:11 AM, Junichi Uekawa wrote:

...

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.

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

On 2009-01-10, Peter Harris <git@peter.is-a-geek.org> wrote:

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 ;-)

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.

2009/1/10 Junichi Uekawa <dancer@netfort.gr.jp>:

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

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

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

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:

    use "git pull --rebase xxxx" instead of plain pull;
    resolve conflicts if needed

    (I'm assuming there's a long gap between the pull above
    and the add below)

    git fetch       # update from origin
    git rebase origin/master
    (they may have to resolve conflicts, but it's easiest
    when done at this point)

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 ;-)