Users and particularly automation can benefit from having the new
revision hashes as part of the output of rebase and other operations that
update nodes. Right now, hacks such as getting the tip revision are used to get
that information.
Details
- Reviewers
ryanmce - Group Reviewers
Restricted Project - Commits
- rFBHGXdec644524c33: tweakdefaults: output new hashes when nodes get updated
unit tests
Diff Detail
- Repository
- rFBHGX Facebook Mercurial Extensions
- Branch
- default
- Lint
Lint OK - Unit
Unit Test Errors
Event Timeline
Have you considered wrapping scmutil.cleanupnodes ? That allows people to get new hashes for not only rebase, but also histedit and amend (and more things to come).
hgext3rd/tweakdefaults.py | ||
---|---|---|
676 | Is the limit useful? I think the source revisions are usually limited. | |
693 | Maybe [:10] can be removed since we have short (equivalent to hex(node)[:12]) already. | |
tests/test-tweakdefaults-ordering.t | ||
30 | This 0000000000 seems weird (same as below). Could you check what's happening here? |
To your queue to answer questions about scmutil.cleanupnodes
hgext3rd/tweakdefaults.py | ||
---|---|---|
676 | If you get rid of the maxoutput then loop can be simplified to for key, value in rebaseruntime.state.iteritems(): | |
tests/test-fbamend-userestack.t | ||
59–62 | It probably shouldn't but I'm still curious if it can break current automation. |
Will take a look at wrapping scmutil.cleanupnodes.
hgext3rd/tweakdefaults.py | ||
---|---|---|
676 | We do the same thing in pushrebase. Source can be an arbitrary revset right? For example someone with a lot of heads rebasing everything on top of master. More than happy to get rid of this. cc @durham who advised. | |
693 | This is to shave another 2 characters off to limit output, but I agree that maybe it's a little silly. |
tests/test-fbamend-userestack.t | ||
---|---|---|
59–62 | I wondered the same. Durham wasn't concerned, mostly due to the unstructured output of rebase. Also this is in fb-hgext. Upstream might be a different story. |
hgext3rd/tweakdefaults.py | ||
---|---|---|
676 | That actually makes sense, thanks for explanation |
hgext3rd/tweakdefaults.py | ||
---|---|---|
676 | I would make this configurable and if it's 0 have no limit. Then nuclide could, for example, get all the output hashes. If it's nonzero, divide the number in half and take the first N/2 and last N/2 hashes produced, if more hashes than N are produced. Output a ... in between if we elide any. The first and last hash are the most important. | |
689 | magic number 50 I don't think the description is too useful either. rebase already prints it out when it says "rebasing...". I think just the mapping is the useful thing here. |
This is clearly an improvement even if its verbose in some places. Let's get it in and iterate as needed.
Is the limit useful? I think the source revisions are usually limited.