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

Augie Fackler raf at durin42.com
Mon Feb 22 19:28:09 EST 2016



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

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

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

Option A is somewhat orthogonal - it’s important, but it doesn’t move the needle when users are actually about to burn themselves.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160222/5a415c94/attachment.sig>


More information about the Mercurial-devel mailing list