Karl Hasselström <kha@xxxxxxxxxxx> writes:
> On 2007-01-17 00:30:18 +0100, Jakub Narebski wrote:
>
>> Yann Dirson wrote:
>>
>> > My example is quite similar to the one given by Guilhem: I had a
>> > git branch coming from git-cvsimport, and my stgit stack forked
>> > atop that branch. At some point git-cvsimport fucked something,
>> > and I regenerated a new mirror branch using it in a fresh repo.
>> > Then I wanted to rebase my stack on that new branch.
>>
>> I'm all for calling this command "stg rebase". Currently you can do
>> "stg push -a; stg commit -a; git rebase; stg uncommit -n <n>"...
>
> Or simpler,
>
> stg pop -a
> git reset --hard <new_base>
> stg push -n <n>
>
> This uses stgit for all operations that can conflict.
>
> (BTW, I've never seriously tried git rebase; does anyone have an
> opinion of how convenient its conflict handling is, compared to
> stgit's?)
I have used it a little (together with git-svn), and one thing that
confused me was that when I got a conflict to resolve, it looked like
this:
...
<<<<<<
base version
======
my version
>>>>>>
...
Where "my version" is the code in the branch I'm rebasing, and
"base version" is the code in the branch I'm rebasing on.
This is kind of opposite of how e.g. "git pull" works, where the first
alternative is "my version". I guess it is an effect of the fact that
you are actually merging your branch into another, instead of the
other way around.
--
David Kågedal
-
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