Most of our users at Google use Mercurial on a file system that keeps
backups of previous versions of all files, including those in
.hg/. They therefore don't need a separate backup in the file system
when narrowing their repo (which they typically do by running `hg
tracked --auto-remove-includes`). Backups can be very slow. hg strip
already has a --no-backup option. This patch adds the same option to
hg tracked --removeinclude/--addexclude.
Details
- Reviewers
durin42 pulkit - Group Reviewers
hg-reviewers - Commits
- rHG3c360ab2688d: narrow: add --no-backup option for narrowing
Diff Detail
- Repository
- rHG Mercurial
- Branch
- default
- Lint
No Linters Available - Unit
No Unit Test Coverage
Event Timeline
hgext/narrow/narrowcommands.py | ||
---|---|---|
276 | Even when we backup, we can probably use soft-strip to make this faster. |
hgext/narrow/narrowcommands.py | ||
---|---|---|
276 | Oh, good point! I initially thought that we couldn't, but I think you're right. The reason that narrowing strips commits is because local commits may have file revisions that we can't get back from the server one a later re-widening. That means that we need the backup. I didn't realize that soft-strip also supports creating a backup (and does so by default). I'll send a patch. Thanks! |
hgext/narrow/narrowcommands.py | ||
---|---|---|
276 | I finally remember the other reason for stripping commits (because tests reminded me). I was half right about later re-widening, but the backup is for users, and the real problem with re-widening is that don't apply a backup. So if your local commit touches some file and you then remove that path from your repo, we put the affected commit in a bundle, remove the commit, and then remove the revlog. When you later widen to include that path, we won't get the file revision from the server, which leaves that commit broken. |
Even when we backup, we can probably use soft-strip to make this faster.