hg 4.2 sprint notes
Taken from: https://public.etherpad-mozilla.org/p/sprint-hg4.2-NOSPAMREMOVETHATLASTPART (drop the anti spam part)
Steering committee is nearly set up with Conservancy to take donations.
Has a Pay Pal link for personal donations - not yet fully set up for Purchase Orders etc for corporation donations, but can do it if needed (sprint sponsorship etc). Trying to get to a better place. Funding only really needed to a few hundred dollars per year - beyond that, mostly spent on sprint sponsorship, but could spend more if they had it via a bid process. Would like to spend some on finishing off evolve - Pierre-Yves now has a consulting company around Mercurial, so you can pay PYD to fix things. Generally quicker/better to hire consultants directly if you have a planned spend (e.g. want a feature implemented).
Augie would like someone to fix release scripts - please go speak to him if you enjoy fixing mpm's artisanal bash scripts.
We now have a current Patchwork release - Kevin is working on a modern Patchwork instance, too, which is growing support for series of patches - playground site at https://patchwork-demo.mercurial-scm.org/ - goal is to replace main patchwork with demo site when people agree it's better.
Information discussed at the Sprint are "Public Domain by Default" -- be aware that there are 40 people here and anyone of them may intentionally or unintentionally leak data, so don't share anything you don't want public at some point. That being said, "use discretion and don't be a jerk". If you want to mention something but not have it recorded in the etherpad, try to mention that beforehand so the notetakaer doesn't write it down.
Google rules: no photos or videos outside of the meeting room. It's easy to lock yourself out. Four google employees here, ask them if you have any questions. Google tours optionally available later. Maybe a small field trip to Computer History Museum.
Introductions: bunch of people from FB, 4 from GOOG, 4 from Atlassian, and a handful of people across a bunch of other companies
FB Update: We're attempting to do daily deployment but run into lots of problems, especially after a freeze ends and a bunch of patches come in -- that breaks everything. Macs are particularly broken, and we want to get windows onto this continuous deployment as well.
FB has an enormous data set internally -- every command run we collect metrics. We're actively looking at that dataset to find issues that we can fixed. Some outliers have consistently bad experiences. Performance is a big focus right now. Looking at both current commands but also future workflows (like automatic rebasing). Simon can present on the information we are collecting.
Restack concept has shipped at FB -- same end goals as evolve and uses the evolve infrastructure, but a different take on UI.
Kostia is working on Windows support and can talk about pain points.
David SP can talk about issues with huge files in game development workflows.
FB also collects a random set of commands with profiling enabled, want to be able to get to a point where every command is profiled and any unexpectedly slow things have their profiles saved for later analysis. Have made sure profiling interacts well with chg.
FB has a wrapper that does a few useful things: collects timings, turns of profiling randomly, and implements some basic commands that can run "instantaneously".
FB is automatically uploading all commits from laptops. Lightweight backups, cheap synchronization, static and security analysis, etc. Called "Infinite Push" in Facebook extensions repo.
Google is starting to collect timings as well, is going to use "time blocked" stuff that Simon made so data can be clean.
Google is still slowly rolling out hg to users. It's entirely opt-in. We hope experience is better than what they currently have -- no forcing over to hg. Approximately 1% of all commits are coming from hg, X hundreds of users.
Trying to get it to work on top of CITC ("Client in the Cloud")
Working on getting "Critical User Journeys" written -- may create new commands to make these Journeys easier.
Pain points: diff has a big variance in speed, evolve is still really confusing for people. Adding tags to mark exported commits, so otherwise obsoleted things are still visible. Divergence is confusing.
Follow-up: Evolve UX session added to board
Some complaints about slowness, but often it's just unfamiliarity with hg best practices (like avoiding 500 command startups)
Google has a handful of extensions enabled -- maybe a half dozen (FB has ~70 right now)
Google repo size numbers from Rachel Potvin's monorepo paper (mid 2016): 1B files, 9M source files, 2B LOC, 35M commits, 86TB, 40k commits per workday
Rachel gave a presentation at @scale conference where she went over some of these numbers -- video is on YouTube.
Why python 3? In 3 years, python 2 will be ruthlessly exterminated. 3.6 is 10% faster than 3.5. Bringing hg to python 3 is also about having a say is how future pythons are built.
Python 3 breakout
bytes vs unicode before python 3.5 made it very difficult to port mercurial to python3
bytes/unicode differences still makes it very difficult to port, even in python3.5 or python3.6
mercurial: everything is bytestrings, python3: everything is unicode by default
Moving to python3 so far has been somewhat of a fringe effort (e.g. GSOC projects).
One possible path forward: add type hinting to mercurial, keep type hints in separate stub files, write script that re-applies stubs to mercurial codebase to work around mypy limitations
The wiki page for Python 3 is updated and it explains the current state and everything related to contributing on this. ( https://www.mercurial-scm.org/wiki/Python3 )
Should set up a python3 builder on buildbot to avoid regressions
Right now entire codebase imports cleanly (except extensions)
Need to think about features we want in python3.7 and python3.8 to make porting easier, mercurial run faster
python3.7 might pickle modules, which will obviate need for demandimport, make imports in general much faster
hg version and hg debuginstall works with all the out of core extensions disabled.
--debugger also works
Python 3 mercurial runs in pure mode at the moment
Generally positive reaction to including type hints in mercurial, discussion about whether or not it makes sense to include as comments, stub files
One issue: our custom importer is not going to be run for mypy (e.g. from __past__ import byte_literals)
We could get rid of the custom importer and eliminate issues with blame being ruined by adding a new revset that ignores some revisions (e.g. the series that replaces all instances of '' with b'')
GSOC Ideas
==========
Link : https://www.mercurial-scm.org/wiki/SummerOfCode/Ideas2017
Kevin and Pulkit are two who will be mentoring, we can add more mentors though
Magic new revset operator
`hg config --set` implementation (bigger?)
Maybe specific python3 work pending this weekend's results
(mostly-js project): improve graph view in hgweb
<ideas from spectral>
<ideas from smf/erik>
<ideas from durham>
<ideas from danek>
<ideas from indygreg>
merge diffs
Maybe CommitCustodyPlan? Big, not fully defined.
Lightning talks
===========
Jun: Enhanced repoview - http://files.lihdd.net/repoview.pdf
Sean: Magit for hg -- demo works, need more developers
In-memory merge breakout
====================
durham: merges use the working copy today. Can't do in-memory merges today.
Interferes with many use cases: drag and drop commits in an IDE. Optimistic rebases. Merges in the cloud. Performance (not touching files = faster).
Erik: Bitbucket does in-memory merges today via a hacky hg extension: use merge.py:manifestmerge and implement all the other logic on top. Ideally use changectx instead so that stuff can be done on top, etc.
Danek: Want to maintain two parallel branches with small divergence. Auto-graft uses working copy today -- would ideally do it in-memory.
dsop: web UI can simulate cherry-picks, see if a conflict will happen
marmoute: (basically wants a git staging area to apply/unapply patches)
durham: Phil Cohen might make this happen.
Current state:
filectx and memctx have a file data attribute
(1) biggest hurdle by far (grunt work) -- merge.py:manifestmerge -> -> -> simplemerge accepts 3 paths. It should accept 3 filectxs instead with write methods. Then could pass in a memfilectx instead of a filectx.
(2) merge.py:recordupdates touches the dirstate -- it shouldn't with in-memory merges
mpm wanted a rollback: if it's too big for memory write to disk instead.
Durham: user experience?
sid0 + TheMystic: must use working copy if a file conflict happens
TheMystic: can iterate towards allowing rebases with file conflicts even if the working copy is dirty
Does any in-progress, unlanded code exist?
smf: have an unlanded branch, can work during the weekend
kiilerix: partial merge? mergestate in repo -- transmit merge state over the wire?
smf: serialize commit objects. mpm suggested
durham: general idea would be to transmit all repo state over the wire. Useful for backups, "time machine" etc.
TLS Breakout
==========
/usr/bin/python on OS X links against ancient openssl. Options:
* Ship our own Python
* Ship our own OpenSSL with bindings...somehow
* Move to Python 3.6 and get a hard dep on the Python.org Python
* Use pyOpenSSL and cryptography and have users install it themselves?
This last one seems the most manageable: we add support for using pyOpenSSL if it's present, and then if we spot a broken ssl library in the stdlib we give the user a hint to update their Python or `pip install pyOpenSSL`. That's our proposal for the time being. As far as we can tell, this is really only a major problem on Windows and OS X - on other platforms we're pretty well served by the base OS setup.
Another option: https://github.com/shazow/urllib3/pull/1122
Diff Annotate breakout
=================
Annotate of a diff between two points. Trivial for a diff of a single rev (it's always the rev).
Imagine a three commit repo:
A
|
|
B
|
|
init
Diff B->init is easy to annotate - each change is B. Diff A->B is easy, too. Diff A->init needs you to determine if each change was A or B to annotate the change.
Background: is easier to work on BB top-levels, parsing text diffs, than to work on Mercurial at Atlassian. But Mercurial is fast - so do the diffannotate by walking the DAG for single plain diffs, then combine the diffs into a single annotated diff.
Difficult to come up with bug-free test cases, let alone fix it.
Motivation is to allow you to comment on a pull request as a whole, and have the comments attach to the individual diffs instead.
Example:
Diff A is:
one
- two
+ TWO
three
Algorithm makes it:
?:1 one
A:2- two
A:2+ TWO
?:3 three
telling you that the context lines are from unknown commits, and the -/+ pair is from diff A. The numbers are the line number at the time of the change.
Diff B is:
TWO
- three
+ THREE
four
Algorithm makes it:
?:2 TWO
B:3- three
B:3+ THREE
?:4 four
Merge together:
?:1 one
A:2- two
A:2+ TWO
B:3- three
B:3+ THREE
?:4 four
Order into a human-expected diff (this is the hard bit):
?:1 one
A:2- two
B:3- three
A:2+ TWO
B:3+ THREE
?:4 four
Let's add changeset C on top of the pile, to get diff C:
one
- TWO
+ Two
THREE
Result ends up being:
?:1 one
A:2- two
B:3- three
C:2+ Two
B:3+ THREE
?:4 four
Disambiguation is "choose your favourite commit"
Can we use Denis's line range work to make this easier to get in Mercurial?
What does it look like if your diffannotate revset is not a continuous linear set? Broken DAG == broken output - you must not have missing changesets in the middle, otherwise the algorithm can get lost.
- Algorithm usually just depends on line numbers from adjacent diffs, but uses content when it gets hard
Order is done bottom to top as empirically faster - but outcome doesn't depend on order.
Diff minimization (turn -, +, -, + lines into -, -, +, +) is done by difflib
Jun: Each line could have a birth cset introducing the line, and a death cset removing the line. A traditional blame algorithm will only be confident about birth cset information, and it's very tricky to get the death csets right running the traditional algorithm. The problem will be simpler if death information is not needed. However if it's needed, we can reverse the DAG (reverse every edge), and the traditional algorithm outputing the birth csets is the death csets for the original DAG. Since the most expensive operation is diff, and diff result could be reused for both DAGs, the performance can be reasonably good and the result is correct in theory - no headcache with pathological merge csets. Note that given the diff outputs between revisions with line numbers, a traditional blame algorithm only relies on line numbers. The key (Jun believes) is to track the file content of the normal DAG travelsal and the file content of the reversed DAG travelsal SEPARATELY so only line numbers are enough. Trying to mix both contents together as a single content during the DAG travesal is likely to have (merge-related) issues about the ordering of the alive and dead lines. The "diff minification" is an unnecessary step if done this way.
SHA1 replacements
===============
Blake2 is generally considered good - only reason that it lost to Keccak for SHA3 is that it is challenging in ASIC.
Augie proposal: can we come up with a good way to use the 32 byte "hash" field to allow us to replace hashes live (use the last byte as a "format" byte - so format 0 is SHA1).
Do we want to do multiple hash storage so that a server can serve both SHA1 and SHA2 clients? Issue is revlog format has a 32 byte hole for caches. Augie not comfortable tying hash agility to a format change.
Default to SHA3 instead of blake2 for FIPS type compliance issues? No - FIPS mandates some bad requirements, so we should wait for someone who cares to ask. Blake2b lets us choose hash size.
General goal of hash agility is to let you choose a setup you care about.
Migration plan is to continue with SHA1 as default for a year, then flip the default to new hash. Server config option to choose acceptable hashes.
Config options:
* Which hash to use for new commits
* Which hash to accept in a push - possibly just a consequence of the server accepting a new hash commit.
Amounts to a flag day for all users
If you have old commits to keep, you need to rehash the repo to move over to the new hash for old commits - but we expect to support a setup where old commits are on the old hash, new commits are on the new hash. Means that each hash becomes a repo requirement.
Will also need to change wireproto.
Would be nice to be bale to rehash a repo to newhash, but maintain a mapping of SHA1 foo to newhash bar, so that old hashes still work. When we rehash, perhaps store the old SHA1 in extra, and index separately?
We'd also like an opt-in way to forward from old SHA-1 to newhashed nodes if you've rehashed - but need to think about making sure that you know whether a hash is short SHA1, or short newhash. Do we want a way for servers to enable "old client" compatibility (opt-in) after rehashing? If so, is this read-only, or push supported too?
Windows
=======
Testing?
Maybe teach run-tests.py to run in powershell?
Maybe use WSL bash to drive native win32 hg
WSL may not work well with CI systems
AV concerns?
Error messages are not great. In particular, when it comes to Windows fs errors, we don't print very clear messages and it also looks like we don't check Windows name validity every time: we only check on file creation, and we sometimes try to delete non-existing files, which involves trying to create file with the same name, but that name is AUX or CON or something like this, and so Mercurial crashes.
Facebook's extensions use C++11, which means they have to build a custom Python using VS2015, so anyone depending on those extensions will need a custom Python.
Python3 is much faster when it comes to IO on Windows, thus porting Mercurial to run on it is likely going to improve Windows perf. Also, Python3 is natively compiled with MSVC2015, which means we can compile C++11 extensions without extra efforts.
Question: do we want to make MSIs available that are built using VS2015?
Hackable Mercurial is important to support non-python.org Python and will allow us to eventually bundle >VS2015 Python.
We need proper Windows testing on Mercurial test infra
Archived Phase
============
"Computing hidden changesets from obsstore is stupid" -- Jun
Reasons might not be a phase: while the phase boundary is good for "what to exchange" it doesn't perserve the previous boundary. Also, archived cannot archive public changesets. It seems we all agreed that this is a "hidden-map-based-on-roots" (check with Jun, Pierre-Yves, et al)
Rebase with Instability Breakout
========================
Background: https://www.mercurial-scm.org/wiki/CEDRebase
If you rebase a tree that has obsmarkers in it, we currently abort to avoid creating divergence. What should we be doing?
Three options:
0. Abort with message about ways to proceed
1. Implicitly ignore anything after an obsolete commit, with message
2. Stabilize unstable commits above obsolete commits
3. Rebase full subtree, including "duplicate" commits
Big discussion about different reasonable options, etc
People mostly seem onboard with option 1
Friendly HG Breakout
================
Background: https://www.mercurial-scm.org/wiki/FriendlyHGPlan
Everyone agreed that we should do it
The gist of it is to add a new config option to hg that changes default behaviors
Augie: extensions will not be in the surface area of friendly hg (options only)
Durham: What about rebase? Augie: Nope, it should be moved to core with evolve, not be an extension
Mads: Actually we just need safe strip
Ryan: Agree, but that's not what Augie said
Durham: Disagree that rebase should be excluded even in the current state, but don't want to hold up discussion so lets move on
Augie: remotenames for example changes things so fundamentally that it couldn't really be used with both workflows at the same time without massive confusion
Greg: If a user downloads hg after hearing "it's usable now" but then the out of the box experience still sucks
Augie: packagers should be encouraged to enable this by default
Greg: What would it take to relax the BC consraints in the future?
Kyle: If the default packages come with this turned on, then what's the difference between turning it on in core?
Augie: we don't want to alienate current users
Ryan: I think the lack of friendliness by default alienates more current users than breaking BC would
Augie: Baby steps people! We're not going to change everything all at once!
Durham: What about a notion of "levels": unobjectionable stuff on a level one, more BC breaking stuff in level two, etc?
Augie: Possible
Greg: What about having a per-feature BC opt-in?
Augie: I've been assuming that anything that's in friendly hg would have it's own config knob already
Kostia: It seems weird that BC on would disable rebase
PYD: Use the "plain" vocabulary
Andras: What about a compatibility level like compilers have?
Augie: Now that's an interesting idea
Andras: And then in 10-20 years we can maybe finally remove a feature!
Augie: Really important to me to have a way to have commands scriptable and work forever
Greg: This is leading towards a config registry (mostly people agree that we need something like this)
Augie: I've gone back and forth on this. How do you handle third-party configs?
Greg: This can solve that problem too -- hg help can list config options for enabled extensions too!
This is a goddamn trainwreck. <-- smf.io
Kyle: With compatibility levels, this lets distributions take newer hg builds with security fixes but pin the UX to the initial release
Augie: is skeptical
Greg: We can fight about this in two years
SMF: What is changing here? Why not just use HGPLAIN here?
Ryan: This gives us a path so that in 5 years we don't have to have this conversation again
DSOP: Compat layers might be too complicated to have people work on at the moment, so we might risk being here next year again without a friendlyhg, while the current proposal is easier.
Augie: I need to think about it more, but I think that if we have compatibility modes, I might feel more comfortable with bigger changes in the future
Kyle: HGPLAIN already changes more behavior than what we're discussing here
SMF: I'm concerned about HGPLAIN changes
Kyle: Nobody is suggesting changing the output of HGPLAIN
Greg: Maybe large parts of compatibility mode could be implemented as templates?
Danek: In Oracle admin tools, we force users to pass fields they want in programtic output mode, maybe we can do the same with hg?
Ryan: I'd love that for JSON
Discussion about issues around JSON and fields and templates and fields and so forth
Augie: Wrapping up: we'll have a BC flag that defaults to true; setting it to false will give you future things?
Ryan: I'd really like compat levels from the get-go for future-proofness
Kyle: If we have to special flags, LATEST and COMPAT which means we don't need to get versioned levels yet
Ryan: Agree, that sounds even better
Greg: I want to have a way to turn this on by default
Augie: It has always been safe to tell people to upgrade their mercurial, are you going to stop that?
Greg: I think we have earned the right to shoot this gun
Augie: FB needs to start upstreaming their tweakdefaults changes as settings
Ryan: Yeah, but Martin is doing it for us
Augie: So did I
David, Ryan: But yeah, you're right
Augie: Story about SVN screwing over users by relaxing constraints, that's why concerns about on by default
Augie: First step is getting tweakdefaults changes upstream
Augie: Show me some code!
Augie: Take extra care to think about flags that interact with defaults like --check, --git
Greg:
Offlinestorage
==========
Remotefilelog pack format (Durham)
------------------------------
Remotefilelog is changing its fileblob storage. It's splitting the data up into histpacks and datapacks.
Packs consist of two parts, a data part and an index part.
The histpack data roughly maps files to changesets that modified it. This allows us to quickly do hg log <file> et al in a remotefilelog world.
The datapack data deltas the actual file contents.
Pack's index is a fanout table that allow us to efficiently find entries in the data file.
Comes with a storage abstraction. It implements an interface. This is the most interesting part for core. It would allow moving to different storage implementations transparently.
Benefits over old storage format:
- Separation of history and contents
- Way more space efficient due to delta compression (before, fileblobs didn't compress anything)
Benefits over revlog:
- Allows arbitrary insertion (no need to append in order)
- Less inodes
Making revlogs more performant (Gregory)
--------------------------------------
Include compression bit in revlog so we don't have to read data file.
Revlog bit saying this is zstd (better compression with Zstandard, see http://gregoryszorc.com/blog/2017/03/07/better-compression-with-zstandard/)
New revlog format for changelog.
- Hash field is 32 byte. Should be variable length with a field identifying the size of the hash.
- Caching arbitrary information inside of the revlog
Rewrite revisions API to get revisions from C to avoid back and forth between C and Python
"Experimental as a Tag instead of a Name" Breakout
=======================================
The problems:
* experimental stuff tends not to be documented
* config rename when thing becomes non-experimental breaks early adopters
* On the plus side, we can change this stuff easily
Proposed solution from Ryan:
* Name things what you think they will be named long term (even though you might be wrong)
* Write the word EXPERIMENTAL in the required help
* Document the meaning of EXPERIMENTAL
Proposed solution from PYD:
* Make a config registry
* Config registry can forward configs to deal with rename breakage
* Turn off "experimental stuff doesn't need to be documented" flag
Other items discussed:
smf: Facebook seems to be pushing really hard for a bunch of things, but they're not stepping up to do the work that has been laid out for years (color, pager)
Ryan: I wasn't even aware of this "work laid out for years" -- visibility/communication problem? Also, I considered color and pager basically solved problems -- just swapping configs isn't the issue here
Kevin: We can raise visibility of some of these plans on the wiki. At a minimum there is Category:Plan on the wiki, but it would be better to have a page that lists community priorities
Simon: Part of why Facebook appears to be pushing in part because we're doing a lot of work -- half the people at sprint are from FB
Kevin: If we have a discussion about common priorities, we can make a lot quicker progress
pyd: Being half the workforce on hg is a double edged sword: less than 25% of the commits in hg core are coming from FB -- that seems like a problem
Kostia: FB is incentivized to fix 2 problems for FB engineers by doing our own extensions over fixing 1 problem upstream.
Simon: A community priority list would help us align work better
Greg: Observation about large companies (GOOG and FB): there are thousands of engineers and they hang out with other eng and socialize about mercurial, monorepo, etc. It's in the community's interest to have a good experience so people who try it out after these conversations don't say "wow this is terrible" when they first try it.
Simon: Sean, can you write up a quick outline of community priorities?
Sean: Uh, um, okay, I guess?
Simon: If Sean writes up a priority outline, I'll push it inside Facebook to try to keep us aligned with the community
"Evolve vocabulary"
================
Names to analyze:
- troubles
- unstable (child of an obsolete changeset)
- bumped
- divergent (two changesets claiming to be successor to the same changeset)
- successor
- precursor
- obsolete
Possible names:
- drift(ed)
- volatile
- tardy (bumped)
- bifurcated
- competing
Bumped and diverged are more closely related, could share some terminology: diverged and draft-diverged? But you can have both going on at the same time.
Currently, evolve solves a divergence where one is public ends you up with a bumped situation. Not the long-term path.
We need both adjectives and nouns.
*IRC logging*
Time limited please - logs public for as long as a week or so. robots.txt etc to hide from search engines.
*Release notes*
Tag individual commits with a "release notes" area - have ability to tag commits with an admonition to tell the release notes system to extract some text as a release note (tagged as BC, perf etc). Greg has hacked up a releasenotes extension that syncs up commit admonitions to an RST release notes file so that you can do things like correct a bad release note from the commit message, and have it tie up with the original. Consensus from release note writers was to put the extension in contrib to get going, then if it turns out generally useful, it can be migrated to hgext.
We need to be able to spit out wiki markup, too, from release notes. Existing RST parser in use is designed to just parse help files - could limit to the common subset of RST that maps to wiki markup, and script that output. Would also be nice if commits could link back to Mercurial hgweb to allow people to go from release note to commit that changed things.
Could also develop a MOTD from `hg pull` based on the release notes for the commits that you've pulled.
Potential GSoC project!
*Sprint Locations*
Kyle suggested Japan. Visa situation at https://en.wikipedia.org/wiki/Visa_policy_of_Japan#Visa_exempt_countries Tabled for now while Kyle does research
Next time round, Europe somewhere. Mads volunteered to look into hosting in Copenhagen.
Augie suggested Iceland if we can organise somewhere.
Could we volunteer Gábor Stefanik to host us in Hungary? Could Mathias De Mare get us hosted by Nokia
Google could host us in Zurich/Dublin/London/Hamburg. Maybe even Australia/New Zealand?
Mads suggested finding a vacation resort.
Sean volunteered Atlassian Yokohama.
* Running from @ *
Obvious answer is upstream more.
If people having problems can bisect down a patch that hurts, community will take an interest in why it hurts.
Acceptance criteria is that tests run on one platform - Macs are much slower than Linux, so people don't tend to run on Mac..
Augie thinks this release cycle was unusual - Bryan O'Sullivan triggering Augie's pager work and then Pierre-Yves finishing off color makes this special.
What sort of freeze relaxation would work? Can we get people to test the release without relaxation somehow, given that we really want FB on the release for testing reasons?
It sounds like this is all expected failures, from using the freeze to test RCs - Facebook is basically the big tester of frozen code.
Big thing we want is reminders as the freeze comes up and as the freeze draws to an end.
Perhaps build 3 release trains - nightly (@), beta (stable) plus releases.
Flags and defaults breakout
=====================
Env variables: maybe we should add them to the stack of global/per-user/per-repo/--config/--otherflags priorities => becomes global/per-user/per-repo/environment/--config/--otherflags or maybe global/per-user/environment/per-repo/--config/--otherflags
Defaults as they exist now:
[defaults]
log = --follow --graph
New style:
[defaults]
log.follow = True
log.graph = True
(Implemented in a patch that Rodrigo sent)
Ryan asks: Why is this better than having, for example:
[log]
follow = True
graph = True
Answer:
The defaults version integrates into fancyopts so commands dont' need to look for specific options and users don't need to learn two different terms for the same thing since everything is command-line flags. Having command-line flags for all behavior also allows aliases that "override config" without shelling out to $HG
Why [defaults] were "deprecated" (from Augie):
1) because they had no way of turning them off,
2) because HGPLAIN didn't exist at the time iirc,
3) because conflicting flags,
4) because they screw with any sort of command that the server wants to output (i.e. if you want to say "run `rebase --continue`", you don't want to really run rebase -d master/head --continue.)
update --check --clean: possibility - passing a fancier object as the value, with methods to detect overrides, default changes, etc.
New feature needed to make this work: a way to programatically check for conflicts, so we can elide conflicting defaults
fancyopts can't have optional parameter values (e.g. both --check and --check 123)
Possibility: adding --no- for everything to *unset* defaults: does it revert to None or the default? -- discussion: revert to the default in the code
EXCEPTION: --no-[boolean-flag] -- always is False, not "default"
Lists: --no-rev (for example) sets list back to empty
EXCEPTION: positional arguments can overlap with named arguments -- for example `hg graft foo -r bar` (graft now prints a warning for this case). Resolution:
Positional arguments could optionally be mapped to options (e.g. hg update 123 becomes hg update -r 123 as far as the command implementation is concerned).
Follow-up: can we remove callables from fancyopts? They seem dangerous. (wth do we even have them?)