Re: Main branch being maintained with 'git am', how do mere mortals interact without too much conflicts?
- From
Sitaram Chamarty <sitaramc@gmail.com>
- Date
- Jan 10, 2009, 16:18 UTC
- Message-ID
- <slrngmhijb.3u7.sitaramc@sitaramc.homelinux.net>
- In-Reply-To
- <87vdsntnyd.dancerj%dancer@netfort.gr.jp>
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 sendThat'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^
Show 5 quoted lines
> 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 ;-)