|
Size: 1672
Comment:
|
Size: 2641
Comment: add notes from sprint session on
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 7: | Line 7: |
| Ideas that the community has discussed and largely approved of, but no one has yet implemented. This is somewhat distinct from [[https://www.mercurial-scm.org/wiki/Mercurial?action=fullsearch&value=Plan&titlesearch=Titles|Plan pages]], although the two lists may overlap. | Ideas that the community has discussed and largely approved of, but no one has yet implemented. This is somewhat distinct from [[CategoryNewFeatures|Plan pages]], although the two lists may overlap. |
| Line 24: | Line 24: |
| Notes from the [[4.4Sprint]] on this topic: * FB has scm-prompt.sh in fb-hgext/scripts/ (demoed by [[RyanMcElroy|Ryan]]) * Commonly requested feature: status. Too slow to include though * Possible solutions: async zsh prompts; watchman-push updated prompt simple dict file in .hg (could also be cronned or only updated when hg commands are run) * [[KevinBullock|Kevin]] likes the template language for "[[PromptExtension|hgprompt]]" (author: sjl on bitbucket). Idea: have extension print out some shell code that could be evaled. Since it's owned by mercurial, it can do things the "best" way given the current mercurial release (eg, in a future with minimal startup time, could be an hg command, but for how could be something more similar to scm-prompt.sh) |
|
| Line 28: | Line 35: |
| == Make -S/--subrepos flags unnecessary == It has always been the intention to make commands like `hg status`, `hg add`, `hg remove`, etc. handle subrepos transparently. The way to go about that is [[https://www.mercurial-scm.org/pipermail/mercurial-devel/2011-October/034816.html|outlined here]]; status of this work was being tracked on SubrepoWork. |
|
| Line 30: | Line 41: |
| * [[https://www.mercurial-scm.org/wiki/Mercurial?action=fullsearch&value=Plan&titlesearch=Titles|Plan pages]] | * CategoryNewFeatures |
Note:
This page is primarily intended for developers of Mercurial.
Good Ideas for Enhancements
Ideas that the community has discussed and largely approved of, but no one has yet implemented. This is somewhat distinct from Plan pages, although the two lists may overlap.
Projects listed here may be a good starting point for new contributors wanting to take on a more significant contribution than fixing "easy" bugs, without having to take on an up-front design discussion.
1. Expect Revset
expect(<set>, <int>) revset: fails if <set> isn’t exactly <int> elements
expect(<set>, <min>, <max>) revset: fails if <set> isn’t exactly between <min> and <max> inclusive
one(<set>) alias for expect(<set>, 1)
This then allows an alias for hg next to be update -r one(children(.)) with sane failure behavior, and also makes some other scripting tasks a little less difficult.
2. hg shellprompt
hg shellprompt bash "{branch} {node|shortest}": emits string for eval in bash to efficiently produce the specified template. Opens the door to first-part native prompt helpers that don’t have to start a Python. Prior art in docker’s command line tools?
Notes from the 4.4Sprint on this topic:
FB has scm-prompt.sh in fb-hgext/scripts/ (demoed by Ryan)
- Commonly requested feature: status. Too slow to include though
- Possible solutions: async zsh prompts; watchman-push updated prompt simple dict file in .hg (could also be cronned or only updated when hg commands are run)
Kevin likes the template language for "hgprompt" (author: sjl on bitbucket). Idea: have extension print out some shell code that could be evaled. Since it's owned by mercurial, it can do things the "best" way given the current mercurial release (eg, in a future with minimal startup time, could be an hg command, but for how could be something more similar to scm-prompt.sh)
3. Make `hg grep` do what people expect
See GrepPlan for details. Not a small project, but would be greatly appreciated by many users.
4. Make -S/--subrepos flags unnecessary
It has always been the intention to make commands like hg status, hg add, hg remove, etc. handle subrepos transparently. The way to go about that is outlined here; status of this work was being tracked on SubrepoWork.