Re: Following renames

From: Petr Baudis <pasky@suse.cz>
Date: Mar 26, 2006, 21:09 UTC
Message-ID: <20060326210956.GS18185@pasky.or.cz>
In-Reply-To: <44264426.8010608@michonline.com>

Dear diary, on Sun, Mar 26, 2006 at 09:35:02AM CEST, I got a letter where Ryan Anderson <ryan@michonline.com> said that...

Show 16 quoted lines

> Linus Torvalds wrote:
> > On Sun, 26 Mar 2006, Petr Baudis wrote:
> >   
> >>   In [1], Linus suggests a non-core solution. Unfortunately, it doesn't
> >> fly - it requires at least two git-ls-tree calls per revision which
> >> would bog things down awfully (to roughly half of the original speed).
> >>     
> >
> > No it doesn't. It requires one git-ls-tree WHEN SOMETHING IS RENAMED.
> >
> > In other words, basically never.
> >   
> 
> A simple example is the first loop in git-annotate.perl.  (Which was
> basically written by Linus, I just translated it from a
> shell/pseudo-code example into Perl)

One case it does not handle:

         2
      -- b --
  1 /         \ 6
  a             d
    \ 3     5 /
      c --- d

git-rev-list at 6 will (understandably) show

        6 5
        5

and you will never detect the d -> b rename leading to 2.

This is one reason why I'm actually not using --parents and pipe stuff directly to git-diff-tree --stdin -M and then read its output. This also lets me merge parallel lines of development based on date and I don't have to fork per each file deletion.

With any luck I'll have the first draft of my (also perlish) script done this evening yet. (BTW, it has the same output format as

	git-rev-list | git-diff-tree --pretty=raw -M

so with some tweaking it could also serve as a git-whatchanged backend. Actually, it would be nice to have it in core Git in the long term so that it gets all the portability tweaks and such.)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.