Differences between revisions 8 and 19 (spanning 11 versions)
Revision 8 as of 2015-12-15 19:14:29
Size: 1719
Editor: GregorySzorc
Comment: add category
Revision 19 as of 2017-12-06 21:53:09
Size: 2132
Editor: PulkitGoyal
Comment: update about tersestatus
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
/!\ '''This is still only an idea from [[AugieFackler|durin42]]. It does NOT yet represent a plan of record.''' This is done.
Line 8: Line 9:
== Name ==
{{{
[ui]
tweakdefaults = yes
}}}

Rejected alternatives:
`friendly`, `progressive`: These have negative implications we don't particularly like.

`modernize`: nobody liked this.

Line 9: Line 22:
 * 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
 * grep should search working copy by default (obsoleted by GrepPlan)
 * show renames and copies in status (done)
 * color (on by default globally)

 * completely remove all traces of the rollback command (done)
 * diff.git=1 (done)
   * needs an easy way to disable when it breaks something
Line 15: Line 29:
 * eradicate all instances of the word tip (tip command, tip pseudo-tag)    * 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`
Line 18: Line 35:
 * `hg update` gains a default of `--check`  * `hg update` gains a default of `--check` (done)
Line 20: Line 37:
 * [[https://bitbucket.org/sr105/terse-status|terse status]]
  * not ready yet: has weird bugs, needs more discussion.
 * pager
  * durin42,mpm,marmoute not a fan
 * terse status (done as `-t/--terse` flag to `hg status`)
  * marked as experimental because of [[https://bz.mercurial-scm.org/show_bug.cgi?id=5724| bug5724]]
Line 27: Line 42:
== 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 32: Line 45:

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.
Line 33: Line 50:
CategoryNewFeatures CategoryOldFeatures

Note:

This page is primarily intended for developers of Mercurial.

This is done.

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.

Name

[ui]
tweakdefaults = yes

Rejected alternatives: friendly, progressive: These have negative implications we don't particularly like.

modernize: nobody liked this.

Proposed Items

  • grep should search working copy by default (obsoleted by GrepPlan)

  • show renames and copies in status (done)
  • color (on by default globally)
  • completely remove all traces of the rollback command (done)
  • diff.git=1 (done)
    • 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 (done)

  • disallow bare hg push

  • terse status (done as -t/--terse flag to hg status)

    • marked as experimental because of bug5724

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


CategoryOldFeatures

FriendlyHGPlan (last edited 2017-12-06 21:53:09 by PulkitGoyal)