On 2009-01-10, Junichi Uekawa <dancer@xxxxxxxxxxxxx> 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
;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
