Size: 2019
Comment: add more cons to automatic evolve
|
Size: 6026
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 7: | Line 7: |
== Glossary == Which language should we use for Evolve? Remember that once this goes into core, this language gets frozen forever. === Command names === * `evolve`: Automatically solve troubled commits. Get rid of `stabilize` and `solve` aliases? * `previous` and `next`: Move up and down the DAG. No more `gup` and `gdown` aliases? * I'm in favor of removing gup and gdown. I never liked gup because it has "up" in its name and could be confused for "update." -- indygreg * `touch`: Create a new identical commit but identical to obsolete commit. Rename to `restore` and limit source to obsolete commits? * +1 for restore. "touch" never made much sense to me. "touch" is also overloaded in UNIX speak to draw up associations with files. --indygreg * `prune`: Mark a commit as obsolete, optionally as replacing one. Remove `kill` and `obsolete` aliases. * `fold`: Fold various commits into one. Add a `squash` alias? Ok since git doesn't have a squash command. * `reorder`: Proposed command that permutes commits. With this proposed command, the Evolve UI completely replaces all uses of the histedit UI. === Concepts === * '''Successor/precursor''': An obsolescence marker can indicate the commit that replaces the obsolete commit. The replacement is a successor, and the obsoleted commit is a precursor. These names are a bit ambiguous, because they sort of are synonyms for descendants and ancestors. Possible alternative language: '''replacement''' commit and '''original''' commit, with corresponding revset functions. * '''Troubled commits''': Commits that `hg evolve` will have to fix. There are three kinds of troubled commits: * '''Unstable''' commits: non-obsolete commits based on obsolete commits. If the obsolete commits have a replacement, `hg evolve` rebases unstable commits to the replacemnt. If there is no replacement, `hg evolve` rebases unstable commits to the root of their obsolete ancestors. * '''Bumped''' commits: replacement commits whose original commit got turned into the public phase by a pull. Better terminology: '''invalidated''' replacements? Since it is no longer valid to edit a now-public commit, the best that can be done for invalidated replacements is to create a diff between the replacement and the original and add that as a new commit. * '''Divergent''' commits: Two conflicting replacement commits for the same original commit. What should `hg evolve` do here? === Terminology Opinions === Ideally we're searching for a grammar where everything is related. If we have words that are closely associated in the English language, users will associate them with related version control tasks. It reduces the potential for confusion and increases the probability for knowledge recall. With that in mind, I'm not sure words like "evolve" and "troubled" go together well. You wouldn't think "this thing is troubled, therefore I'm going to evolve it." I would think "stablize" or "solve" would be much better verbs to complement "troubled." "This thing is troubled, therefore I'm going to stablize it" makes more sense, IMO. But I think there's still room for improvement in the grammar. --indygreg |
|
Line 8: | Line 40: |
Line 12: | Line 43: |
Line 17: | Line 47: |
* 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. /!\ Agreed, we should absolutely not do this by default, nor have a config option. I'm ok with an hg commit --amend flag that does this for you automatically though. -- sid0 |
|
Line 18: | Line 50: |
* 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. |
|
Line 21: | Line 51: |
. /!\ This is also concerning. This is O(N^2) work rather than O(N) that incremental hg evolve runs allow. -- sid0 |
|
Line 25: | Line 57: |
I think auto evolve makes sense in some cases. For example, say you amend a commit with descendants and only change the commit message. Why wouldn't you want auto evolve in that scenario? -- indygreg I think the "there are now troubled commits message" should be actionable. Currently it just prints the count of troubled commits. I'd really like to see a "run hg evolve to stablize" message. If we don't auto evolve, at least we can tell the user what they should probably be doing next. -- indygreg |
|
Line 26: | Line 62: |
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.
Contents
Glossary
Which language should we use for Evolve? Remember that once this goes into core, this language gets frozen forever.
1. Command names
evolve: Automatically solve troubled commits. Get rid of stabilize and solve aliases?
previous and next: Move up and down the DAG. No more gup and gdown aliases?
- I'm in favor of removing gup and gdown. I never liked gup because it has "up" in its name and could be confused for "update." -- indygreg
touch: Create a new identical commit but identical to obsolete commit. Rename to restore and limit source to obsolete commits?
- +1 for restore. "touch" never made much sense to me. "touch" is also overloaded in UNIX speak to draw up associations with files. --indygreg
prune: Mark a commit as obsolete, optionally as replacing one. Remove kill and obsolete aliases.
fold: Fold various commits into one. Add a squash alias? Ok since git doesn't have a squash command.
reorder: Proposed command that permutes commits. With this proposed command, the Evolve UI completely replaces all uses of the histedit UI.
2. Concepts
Successor/precursor: An obsolescence marker can indicate the commit that replaces the obsolete commit. The replacement is a successor, and the obsoleted commit is a precursor. These names are a bit ambiguous, because they sort of are synonyms for descendants and ancestors. Possible alternative language: replacement commit and original commit, with corresponding revset functions.
Troubled commits: Commits that hg evolve will have to fix. There are three kinds of troubled commits:
Unstable commits: non-obsolete commits based on obsolete commits.
If the obsolete commits have a replacement, hg evolve rebases unstable commits to the replacemnt. If there is no replacement, hg evolve rebases unstable commits to the root of their obsolete ancestors.
Bumped commits: replacement commits whose original commit got turned into the public phase by a pull. Better terminology: invalidated replacements?
- Since it is no longer valid to edit a now-public commit, the best that can be done for invalidated replacements is to create a diff between the replacement and the original and add that as a new commit.
Divergent commits: Two conflicting replacement commits for the same original commit.
What should hg evolve do here?
3. Terminology Opinions
Ideally we're searching for a grammar where everything is related. If we have words that are closely associated in the English language, users will associate them with related version control tasks. It reduces the potential for confusion and increases the probability for knowledge recall. With that in mind, I'm not sure words like "evolve" and "troubled" go together well. You wouldn't think "this thing is troubled, therefore I'm going to evolve it." I would think "stablize" or "solve" would be much better verbs to complement "troubled." "This thing is troubled, therefore I'm going to stablize it" makes more sense, IMO. But I think there's still room for improvement in the grammar. --indygreg
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.
Agreed, we should absolutely not do this by default, nor have a config option. I'm ok with an hg commit --amend flag that does this for you automatically though. -- sid0
- If you need to amend multiple changeset, you'd be stuck having to do multiple back-and-forth updates.
This is also concerning. This is O(N^2) work rather than O(N) that incremental hg evolve runs allow. -- sid0
- 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?
I think auto evolve makes sense in some cases. For example, say you amend a commit with descendants and only change the commit message. Why wouldn't you want auto evolve in that scenario? -- indygreg
I think the "there are now troubled commits message" should be actionable. Currently it just prints the count of troubled commits. I'd really like to see a "run hg evolve to stablize" message. If we don't auto evolve, at least we can tell the user what they should probably be doing next. -- indygreg
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?