We will soon want to pass in overrides for bookmark movements and this
will make that patch simpler. I also think this makes the code easier
to follow regardless of the later patch.
Details
- Reviewers
quark durin42 - Group Reviewers
hg-reviewers - Commits
- rHG033a5befbaf7: cleanupnodes: separate out bookmark destination calculation from actual update
Diff Detail
- Repository
- rHG Mercurial
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Event Timeline
I noticed the change from repo to unfi. That actually looks better. Since we are not querying "descendants", it won't cause correctness issues.
mercurial/scmutil.py | ||
---|---|---|
645–646 | This could be removed then. |
Yes, that was necessary because oldnode could be obsolete and that was previously protected by "if not oldbmarks", which I didn't think would belong in the new loop.
Ah, I didn't realize that minor difference. So the new code could have unnecessary computation - it calculates "moves" for every node even if there is no move needed for it.
I think we still want an extra moves argument, but use it inside the for loop (so the if ...: continue shortcut works).
I think either you or me can update the code. If you're busy with other things, I can update (and split) the original fix directly.
Yes. I simply didn't think it would be a noticeable extra computation. For working copy movement that's coming in your later patch, I also assumed that would just do "newwc = moves[oldwc]" (simplified), but I now see that it looks more complex.
I think we still want an extra moves argument, but use it inside the for loop (so the if ...: continue shortcut works).
I'd rather move the " if not oldbmarks:" to the new loop if you think that's necessary.
mercurial/scmutil.py | ||
---|---|---|
604 | I thought this could be O(changelog), but it's O(1) given generatorset implicitly requires the generator to be sorted. |
I thought this could be O(changelog), but it's O(1) given generatorset implicitly requires the generator to be sorted.