2009/1/10 Junichi Uekawa <dancer@xxxxxxxxxxxxx>:
> 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
--
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
