[PATCH v2] rebase: add potential divergent commit hashes to error message (issue5086)

[Sean Farley]

Augie Fackler <raf at durin42.com> writes:

>> On Feb 22, 2016, at 6:41 PM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
>> 
>> Yes, long hash is un-necessary/unusual here. We should stick to a short version,
>> 
>> Rebase complain because you are about to rewrite (here rebase), an absolete changeset that already have a sucessors. Creating a second successor will create divergence.
>
> I know that, but the error output is still useless to me, as it offers no suggestions on how I might avoid the divergence or why it’s bad.

I definitely think it's an improvement over the current error output:
"abort: this rebase will cause divergence".

> (Note: **I** know why divergence is bad, but I don’t actually know what I’m doing wrong that would result in divergence. The above sentence is partially me pretending to be a novice user of rebase.)

For the user that knows about divergence, then they can investigate the
precursor / other divergent head with the given hash (bikeshedding on
short hash).

For the user that doesn't, then it's even more confusing.

>> There is a couple thing we could improve here:
>> 
>> a) finish Laurent work on skipping changeset already in destination, that should remove most of it.
>> 
>> b) suggest/tell/explain-how the user could exclude that changesets from its rebase.
>> 
>> c) points at that already existing successors,
>> 
>> d) improvement d.
>> 
>> that said, this message is already some improvement compared to the new one. I've pushed to the clowncopter a version using short hash.
>
> I disagree that this is a measurable improvement over the status quo. Option B would be a significant improvement, and C is probably a small improvement.

Eek. This is all under the umbrella of 'improve evolve UI'. I honestly
don't know how to do small (experimental) improvements there within the
constraints of BC.

> Option A is somewhat orthogonal - it’s important, but it doesn’t move the needle when users are actually about to burn themselves.

Yeah, I would say that too.