rebase usability

[anatoly techtonik]

On Tue, Nov 25, 2014 at 9:18 PM, Benjamin Fritz <fritzophrenic at gmail.com> wrote:
>
> On Mon, Nov 24, 2014 at 9:33 AM, anatoly techtonik <techtonik at gmail.com>
> 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?
>
> Forgive me if this is too obvious a question, but maybe the changes between
> when you started working, and the current changeset you're rebasing to,
> modified a line you deleted? That's a real conflict you'd need to resolve.

Right. This is too obvious idea, but.. only if you know how merge work and how
conflicts are detected. I found that people don't need to know about that when
they merge, but that's a different topic. So, to prove that idea I had to:

1. clone repository anew (because inside of merge and can't switch to
different branch to inspect if file was modified)
2. switch to branch which is being merged in (unknown to me)
3. blame file
4. find lines that were modified after branches diverged (it would
help if non-modified lines had blank labels)
5. compare if these are the same lines that were modified in my branch
6. find commits in both branches that made conflicting edits
    (remove in my branch and modification of the same lines in the other)

After that:

7. copy/paste edits to original clone with conflict and ensure that
both conflicting changes are working
8. continue rebase

There are not the steps that I have in mind when a conflict appears. I
wrote this algorithm just now after sleeping over this problem.
Ideally, every step should somehow pass you to the next stage, maybe
even automatically. This is something about user experience.