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