Differences between revisions 2 and 3
Revision 2 as of 2014-04-14 23:14:19
Size: 1736
Editor: JordiGH
Comment:
Revision 3 as of 2014-04-14 23:38:29
Size: 2019
Editor: Sean Farley
Comment: add more cons to automatic evolve
Deletions are marked like this. Additions are marked like this.
Line 19: Line 19:
  /!\ This is a very serious downside. Currently, there is no way at all to cancel a merge conflict. Once you are in this state, you are stuck and have to do a serious biopsy.
 * If you need to amend multiple changeset, you'd be stuck having to do multiple back-and-forth updates.

/!\ This page is primarily intended for Mercurial developers

There are a number of things that have to be discussed about how the Evolve UI works.

Automatic "hg evolve" call

Many evolve commands produce unstable changesets. Should they immediately call hg evolve by default?

1. pros

  • Most (?) of the time, hg evolve will work without problems.
  • Nicer for the user for the magic to happen automatically by default

2. cons

  • Makes the user immediately handle instability
    • /!\ This is a very serious downside. Currently, there is no way at all to cancel a merge conflict. Once you are in this state, you are stuck and have to do a serious biopsy.

  • If you need to amend multiple changeset, you'd be stuck having to do multiple back-and-forth updates.
  • Letting the user decide when to deal with rebases and merge conflicts might be nicer.

Perhaps ui.autoevolve option? On by default? Off by default?

hg fold

Currently fold can work in two modes: folding between a target revision and ".", or given an explicit set of revisions, fold this set into a single revision. The current UI for this is weird: for the first mode you specify revisions without --rev and the second mode you specify them with --rev. This UI is inconsistent with the rest of Mercurial. We have several examples of commands that take revisions with or without a --rev argument, and in all these cases, the behaviour is the same, and the --rev specifier is just optional:

  • strip
  • update
  • export

Jordi has proposed patch to address this that treats revisions with and without --rev the same way and obtains both kinds of behaviours depending on whether a single or multiple revisions are specified. However, this has other problems. With certain revsets, it may not be easy to know in advance how many revisions are actually in the revset, so it would be surprising to get different behaviour depending on the number of revisions.

How to solve this?

CEDUserInterface (last edited 2021-10-20 08:05:10 by Pierre-YvesDavid)