Tom Clarke wrote:
quoted text
> Hi,
> 
> I'm in the process of setting up a git environment with a number of
> shared branches. To avoid putting unnecessary merges into the trunk,
> we'd like to normally use rebase when updating private branches. I
> wondered if it would be possible to automatically determine the
> correct remote branch to rebase against.
> 
> The most logical place to do this seemed to be in git-pull, so I
> experimented with adding a '--rebase' option, per the (rough) diff
> below.
> 
> I'm quite new to git, so is this a good strategy?
> 

If I read the patch correctly (which I may not, ofcourse), you're
rebasing the upstream changes to on top of your own work. That's
not something you can readily do, since the parentage chain in
git is supposed to be immutable, so mutating the one you get from
an already published source would be a horribly bad idea indeed.

You need to do it the other way around, so that you rebase your
local changes onto the upstream HEAD prior to pushing.

If that's what the patch does, then I guess all is fine and dandy,
although I think it'd be better to add the merge-strategy rebase
or possibly rebase-ours or rebase-theirs, which can be given as
arguments to git-pull.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html