Re: git svn rebase problem
- From
Miles Bader <miles@gnu.org>
- Date
- May 19, 2009, 00:56 UTC
- Message-ID
- <buobpppq5av.fsf@dhlpc061.dev.necel.com>
- In-Reply-To
- <32541b130905181000v34d5fd6arcb662bff232cb81c@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
>> Branches and git-svn don't mix. > > That's not exactly true: merging and git-svn don't mix. But rebasing > works fine.
I've given up on trying to maintain rigid consistency with svn -- git-svn's constant rebasing is just too painful -- and just cherry-pick everything between my "svn" branch and master, and use master in conjunction with better-behaved git-only branches. I often end up with the same commits in a different order on the two branches, but oh well, not much to do about that I suppose.
This means I often end up cherry-picking long sequences of commits, and need to deal with conflicts in these cp-sequences. For this reason, I often wish cherry-pick supported all the fancy features of rebase (multiple commits, nice handling of conflicts, -i, etc) -- after all rebasing is really just a special case of cherry-picking.
[I've tried on a shell-script implementation of such an extended cherry-pick, but soooo many little corner cases to deal with... maybe it'd be easier to try and generalize git-rebase...?]
-Miles
-- Conservative, n. A statesman enamored of existing evils, as opposed to a Liberal, who wants to replace them with new ones.