This was probably also obsoleted by D7629
Active Repositories
Active Repositories
- rNRWHG narrowhg
- 369 Commits
- ·
- Restricted Project
- Jan 26 2018, 6:48 PM
- Mercurial
Recent Activity
Recent Activity
Today
Today
I think this was obsoleted by D7776
martinvonz added inline comments to D7839: nodemap: deleted older raw data file when creating a new ones.
@martinvonz yeah, probably wrote the doc-comment too fast
D7837: nodemap: only use persistent nodemap for non-inlined revlog is now accepted and ready to land.
D7931: rust-status: use bare hg status fastpath from Python now requires review to proceed.
D7931: rust-status: use bare hg status fastpath from Python now requires changes to proceed.
hooo, I am a bot
marmoute added a comment to D7894: nodemap: introduce an option to use mmap to read the nodemap mapping.
hooo, I am a bot
D7866: rust-pathauditor: add Rust implementation of the `pathauditor` now requires changes to proceed.
In D7517#117274, @marmoute wrote:This have been around for a while. What should we do with it?
I'm -0 on auto-formatting third-party code at all, and that includes zstandard stuff. Why do we care if it's in the ignorelist?
In D7898#117294, @marmoute wrote:I don't see any mention of "in-memory" in the current hook documentation. Can you clarify to which section we are thinking about?
This seems useful but lingering. @pulkit what's the status of this.
If we have one, we'll want it to be generic (so also for changelog). Do we have performance number of the time it takes to build it ?
Waht'a sup on this. Seems to be open for a long while.
I don't see any mention of "in-memory" in the current hook documentation. Can you clarify to which section we are thinking about?
marmoute added a comment to D6123: similar: add condition to avoid Zerodivisonerror in function _score() (issue6099).
Gentle ping on this. This has been around for a long time, what's the status of it?
marmoute added a comment to D6026: lock: Improve the waiting for lock message which will help newcomers
(issue6081).
Gentle ping on this. This has been around for a long time, what's the status of it?
D5812: py3: pass str into ValueError to prevent b'' prefix in output now requires changes to proceed.
moving to need revision according to yuya feedback
D5737: py3: convert info.name to bytes in subrepo.py now requires changes to proceed.
moving to need revision according to yuya feedback
Maybe we should not try to use boolean. we could have
What;s the status of this? is it both flagged as "need review" and "INCOMPLETE".
This have been around for a while. What should we do with it?
I like the idea of using adding this to graft.
In D7630#115320, @pulkit wrote:This results in an empty commit which is not similar to what rebase or evolve will generally result in after D7631 unless ui.allowemptycommit=True is set. I think good behavior is to obsolete the absorbed changeset in favour of either it's parent or one of the revs in which it was absorbed.
I made a related comment on the parent patch before I realized that this patch adds obsmarker handling. My suggestion there was to mark all the commits that got absorbed into as successors, and if there's anything left in the absorbed commit, that would be yet another successor. Would that work?
Yep, that sounds good.
I think is would be simpler and sfare to prevent unrelated operation during rebase. If the user cannot prune here we won't have to deal with it. This woudl also apply to other operation that can alter the repository, like another rebase, amend or a pull. Starting using a unified and safe approach seems to provide more benefit with less chance of UI inconsistency.
crecord: fix a concatenation of bytes and str on py3
recover: fix typos
crecord: fix a concatenation of bytes and str on py3