Removing => 0 changes to 0 files

Matt Mackall mpm at selenic.com
Fri Nov 30 22:05:27 UTC 2012


On Fri, 2012-11-30 at 22:50 +0100, Arne Babenhauserheide wrote:
> Am Freitag, 30. November 2012, 08:58:28 schrieb Bryan O'Sullivan:
> > On Fri, Nov 30, 2012 at 1:05 AM, gideon <voldermort at hotmail.com> wrote:
> > > Removed files don't seem to be included in the summary given by push. If I
> > > remove 1 file, I get "remote: added 1 changesets with 0 changes to 0
> > > files".
> > > Is this correct?
> > 
> > It's not "correct" exactly, but it is expected. Deleting a file amounts to
> > removing its entry from the manifest, and nothing more; the actual file
> > data remains untouched. Turning that information into a "we deleted a file"
> > message is too expensive to be worth the trouble.
> 
> How come that that is expensive?
> 
> All information we need is available locally, so accessing it should be an 
> order of magnitude faster than transferring the pushed changesets.

> It should just require:
> 
>     for ctx in $transferred; do
>         hg status --removed --change $ctx
>     done | wc -l

Have you ever wondered what the above does? I'll tell you:

- unpack full manifest for $ctx
- unpack full manifest for p1($ctx)
- compare item by item

This is fast enough for interactive use, but a single such comparison
can easily be more expensive than pushing 100 csets on some
repos/networks.

However, we could potentially just count the total files listed in
transferred changesets ("changes") and the total unique files ("files").
This would change the semantics a bit: the current scheme just counts
new file revisions, this would count removes and x-bit changes but
double-count renames, reverts and backouts.

-- 
Mathematics is the supreme nostalgia of our time.





More information about the Mercurial mailing list