[PATCH 0 of 3 RFC] Hidden changesets and usability

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Aug 15 23:24:31 UTC 2013


On 8 août 2013, at 09:48, Dan Villiom Podlaski Christiansen wrote:

> Hi,
> 
> This series is probably incomplete and needs a bit of discussion;
> hence the RFC tag.
> 
> From my perspective, one of the annoying parts of working with the
> evolve extension and histedit compared to MQ is the lack of consistent
> identifiers for in-progress changesets, similar to MQ's patch
> names.

Yes, this is something we lack. some volatile label would do but I've not convincing idea about how to do that (bookmark are poor candidate as they move by themselves).

> Typically, I'll work on something, do a histedit or evolve, and
> want to return. If I want to return to where I was, I then have to
> enter either the new hash or revision somehow; I can't just search my
> shell history or reuse any info I could obtain *before* doing the edit
> round.

Well you could used revset predicate to find successors but that's not very friendly

> Currently, when a user enter an identifier -- whether hash or revision
> -- that refers to a hidden changeset, they're told that such a
> revision doesn't exist. This isn't terribly helpful, and even
> misleading in a sense: the revision plainly exists; it's merely
> hidden. If the user really wants to, they can often recover it.

Yes, the current state clearly unfriendly and unpolished.

> So, the first step is it tell the user that something is hidden; the
> first patch in this series does that.

I totally agree with that. It's planned for the beginning to have a smarter message.

> Then, how do we identify revisions? It's worth noting that obsolete
> changesets may exist in one of three states:
> 
> 1) The changeset has no successors; it was killed.
> 2) The changeset has one and only one live successor.
> 3) The changeset has more than one successor.
> 
> #1 and #3 should be presented to the user as an error. #3 preferably
> with a list of choices they might refer to.

The situation is a bit more complex

1)   no successors (pruned)
2.1) single successors-set of a single changeset (amended ?)
2.2) single successors-set of multiple sequential changeset (split)
2.3) single successors-set with multiple changeset on multiple branch (split + dispatch)
3)   multiple successors-set (divergent)

In 2.2 the latest of the successors can probably be used. 2.3 is more similar to (3) except the is no "Evolution trouble"

> The idea is to redirect a hidden changeset to refer to its one
> successor, if possible; the third patch implements a proof-of-concept
> of that.

I've to start disagreeing default automatic redirection from a changeset -hash- to its successors seems a bad idea to me. A changeset hash is it very unique and own identifier! asking for xxxx and getting yyyy is a very confusing situation (you have to first realize it is happening). We had branch name matching changeset hash in a Logilab's repository and it took us some time to understand what was going on.

I really feel like you are burning step here. I would first focus on having a better error messages before thinking about more advanced behavior changes.

> I mainly wanted to send the patch here for feedback on the concept. Is
> this something suitable for Mercurial core? I'll probably change the
> HTTP status codes and web error messages; they're not set in stone,
> but mainly prove that we can distinguish between the different
> cases.
> 
> (I imagine the CLI equivalent is better suited to the evolve
> extension.)

Having better exception and error message suits core in my opinion.




More information about the Mercurial-devel mailing list