|
Size: 1530
Comment:
|
Size: 2080
Comment: Mentioning explicit destination is not required as now update will tell you the commit you updated to in case of multiple heads.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| Line 9: | Line 8: |
| == Proposed Name == {{{ [ui] modernize = yes }}} Rejected alternatives: `friendly`, `progressive`: These have negative implications we don't particularly like. |
|
| Line 10: | Line 19: |
* [[https://bitbucket.org/sr105/terse-status|terse status]] |
|
| Line 15: | Line 22: |
| * progress | |
| Line 17: | Line 23: |
| * diff.git=1 * needs an easy way to disable when it breaks something * diff.showfunc=1 * needs an easy way to disable when it breaks something * eradicate all instances of the word `tip` (`tip` command, `tip` pseudo-tag) * change default `ui.interface` to curses * `hg log` gains a default of `--follow` == Ideas for later == * `hg update` gains a default of `--check` * disallow bare `hg push` * [[https://bitbucket.org/sr105/terse-status|terse status]] * not ready yet: has weird bugs, needs more discussion. |
|
| Line 18: | Line 37: |
| * diff.git=1 * diff.showfunc=1 * eradicate all instances of the word tip (tip command, tip pseudo-tag) * pager? (durin42,mpm not a fan) * disallow bare `hg push` |
* Risky on some non-English systems |
| Line 24: | Line 39: |
| == Naming == The best proposal I've heard for the name for this config knob is `ui.progressive`. We want something that suggests the moving-target nature of the knob, but also doesn't imply that we think hg without this is bad, just that we think this is better. |
|
| Line 29: | Line 42: |
Jun: since the config is likely to be a set of individual configs. It may be better to be implemented as a rc file. So `%include friendly` is the way to use it. The rc could also enable pager, color, rebase, histedit extensions etc. Augie: I'm strongly opposed to this approach. ---- CategoryNewFeatures |
Note:
This page is primarily intended for developers of Mercurial.
![/!\](/moin-static/modernized/img/alert.png "/!\"){kind=small}
This is still only an idea from durin42. It does NOT yet represent a plan of record.
Rationale
We've been accumulating functionality that the average user probably wants on by default, but can't always turn on by default due to our compatibility rules. The idea of "Friendly HG" is to give us an opt-in way for users to request our best features as they become polished and ready, even in cases where that violates some of our compatibility rules.
Proposed Name
[ui] modernize = yes
Rejected alternatives: friendly, progressive: These have negative implications we don't particularly like.
Proposed Items
- grep should search working copy by default
- show renames and copies in status
- color
- completely remove all traces of the rollback command
- diff.git=1
- needs an easy way to disable when it breaks something
- diff.showfunc=1
- needs an easy way to disable when it breaks something
eradicate all instances of the word tip (tip command, tip pseudo-tag)
change default ui.interface to curses
hg log gains a default of --follow
Ideas for later
hg update gains a default of --check
disallow bare hg push
- not ready yet: has weird bugs, needs more discussion.
- mergemarkers.detailed
- Risky on some non-English systems
Implementation
This would change some defaults, but users can still override things (for example, if we include pager, durin42 and mpm can put [extensions] pager = ! in their hgrc.) HGPLAIN would disable all default-changes from friendlyhg, so automation tooling still works as expected.
Jun: since the config is likely to be a set of individual configs. It may be better to be implemented as a rc file. So %include friendly is the way to use it. The rc could also enable pager, color, rebase, histedit extensions etc. Augie: I'm strongly opposed to this approach.