rebase usability

[anatoly techtonik]

On Tue, Nov 25, 2014 at 9:50 AM, Ben Schmidt
<mail_ben_schmidt at yahoo.com.au> 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.
>>
>> 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.

Yes, I am using Evolve extension and non-publishing repository to keep
rebase soft and fluffy. In real world it is nearly impossible to get proper
review of your code from the first try, so you will have to update it sooner
or later, and as a reviewer I hate merges. Repeated and interwined
merges is the point where version control fails to be something better
than just a backup of source code mess. Just my IMHO.

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

Thanks for advice. I somehow handled the problem this time by applying
my version file on top of destination revision. This was manual process so
HG didn't help much. It seems that there was a bug with HG that after the
first cancelled rebase to the wrong branch, some change from this branch
still creeped into the file and played a role with conflicting later, but I
unlikely to be able to reproduce that.

-- 
anatoly t.