rebase usability

[Pierre-Yves David]

On 11/24/2014 10:50 PM, Ben Schmidt wrote:
> On 25/11/14 2:33 AM, anatoly techtonik wrote:
>> I realize that I removed these lines, but I don't get where and why
>> there is conflict? Somebody added them or what? How to see the exact
>> changes that cause the conflict from each side?
>>
>> I'd like to see at clashing edits or at least revisions that are
>> clashing, but there is no such info. It is also quite hard to
>> understand what is dest and source - a more detailed explanation
>> `<<<<< common lines changed in destination revision XXX`, `>>>>>
>> common lines changed in revision YYY that is being rebased` would be
>> better.

You should have a look at the `ui.mergemarkers` option (set it to detailed)

IF you use rebase a lot I recommand using three way markers (or a 
graphical tool).

>> Right now I don't see other way than to cloning repo once more, switch
>> to dest branch, and run `hg blame` to see where these lines were
>> changes. Feel very ugly to me. Is there a better way?
>
> You definitely don't need to clone the repo again.

+1 for "no need to re-clone" just run your command in the existing one.

> But yeah, I think it's a little involved getting the info you want (and
> I also have found myself in similar situations from time to time).
>
> DISCLAIMER: rebasing is evil. I recommend against it most of the time. I
> think it's best suited to reorganising your own work (much like
> histedit) not to collaboration. I wouldn't recommend rebasing on top of
> someone else's work. You essentially lose the record of your originally
> working code.

I disagree here, rebase is useful in multiple situation and the 
resulting history (that must be properly tested) can be much easier to read.

> Some ideas:
>
> - Rebasing doesn't remove the old changeset from the repo until it's
>    finished, so they're all still there.

This is already what currently happens.

> - Using something like graphlog, you can see visually what's going on.

Visual tool like Tortoise HG are good too.

> - Rebasing works one changeset at a time in order, and you can see them
>    in the repository; so look at the tip changeset and identify the
>    original un-rebased changeset a little 'lower' in the repo; the
>    changeset after that is the one currently being rebased

I do not get this?

> - You can use hg cat or hg blame or hg diff with an -r argument (or two,
>    or a -c argument in the case of diff) to get info about the changesets
>    involved.
>
> Hope this helps at least a little!
>
> Ben.
>
>
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial

-- 
Pierre-Yves David