[PATCH 3 of 3] graft: apply get-only changes in-memory

[Matt Mackall]

On Mon, 2012-11-19 at 16:08 -0600, Sean Farley wrote:
> On Mon, Nov 19, 2012 at 3:33 PM, Matt Mackall <mpm at selenic.com> wrote:
> > On Mon, 2012-11-19 at 14:36 -0600, Sean Farley wrote:
> >> On Mon, Nov 19, 2012 at 2:01 PM, David Schleimer <dschleimer at fb.com> wrote:
> >> > # HG changeset patch
> >> > # User David Schleimer <dschleimer at fb.com>
> >> > # Date 1353354272 28800
> >> > # Node ID d4f1efa15442572e7ea658b50a02e093492797d7
> >> > # Parent  a77f8405c800c27ba5cb97b7482410c6438c81c8
> >> > graft: apply get-only changes in-memory
> >> >
> >> > This changes the graft code to apply the simplest-possible changes
> >> > in-memory.  Specifically, changes where all we need to do is set the
> >> > contents of files to the version in the commit being grafted.  This
> >> > means that no files were deleted and no files were modified on by both
> >> > the target branch and the change we're grafting.
> >> >
> >> > Based on one of our real-world branches, with 497 grafts,
> >> > approximately 80% of cherry-picked commits will fall into the fast
> >> > case here.  This patch takes a graft with all 497 revisions on the
> >> > branch in question from 5250 seconds to 3251 seconds.
> >> >
> >> > The revisions that fall in the fast case were more common near the
> >> > beginning of the branch than the end.  Longer lived branches are
> >> > likely to see less of an improvement from this patch, but they should
> >> > be unlikely to see a regression.
> >>
> >> Nice, +1! Would this also work for the 'import' command?
> >
> > Import already has an analogous feature: --bypass.
> 
> >_<
> 
> >>  Or even
> >> better, for incoming changesets via 'pull' so that the working files
> >> aren't touched if there is no merge / conflict?
> >
> > Pull?? Pull does not touch the working directory.
> 
> Yeah ... I'm an idiot.
> 
> > Perhaps you mean pull --update, which is not a special type of pull that
> > does an update. It's just a pull, followed by an update. And of course,
> > update definitionally touches the working directory.
> 
> I did indeed mean this, so thanks for seeing through my garbling.
> Currently, even if a file has no diff, it will be touched by the
> update command.

Not sure what this means either. When Mercurial updates the working
directory from rev X to rev Y, it will generally not touch file F in the
working directory if file F is unchanged from X to Y.

(Unless perhaps you're using some anti-feature like keywords or
eol-mangling and have thereby self-banished yourself to performance
hell.)

-- 
Mathematics is the supreme nostalgia of our time.