This is an archive of the discontinued Mercurial Phabricator instance.

narrow: add --no-backup option for narrowing
ClosedPublic

Authored by martinvonz on Feb 3 2021, 5:07 PM.

Details

Summary

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.

Diff Detail

Repository
rHG Mercurial
Branch
default
Lint
No Linters Available
Unit
No Unit Test Coverage

Event Timeline

martinvonz created this revision.Feb 3 2021, 5:07 PM
pulkit accepted this revision.Feb 10 2021, 7:08 AM
This revision is now accepted and ready to land.Feb 10 2021, 7:08 AM
pulkit added inline comments.Feb 10 2021, 7:09 AM
hgext/narrow/narrowcommands.py
276

Even when we backup, we can probably use soft-strip to make this faster.

This revision was automatically updated to reflect the committed changes.
martinvonz added inline comments.Feb 10 2021, 12:22 PM
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!

martinvonz added inline comments.Feb 10 2021, 7:23 PM
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.