Tom Clarke wrote:
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@xxxxxx 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
