rebase usability

[Ben Schmidt]

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.
>
> 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.

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.

Some ideas:

- Rebasing doesn't remove the old changeset from the repo until it's
   finished, so they're all still there.
- Using something like graphlog, you can see visually what's going on.
- 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
- 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.