[RFC] Enable 'check for copy and renames' (-C) also when path filtering

[RFC] Enable 'check for copy and renames' (-C) also when path filtering

[Marco Costalba]

It seems that -C option of git-diff-tree it works only if the whole
changeset is retrieved.

>From git repository:

- Ask for all

$git diff-tree  -r -p -C 5d4a600
5d4a60033543e063bc9d77ca957de0187fb58fb3
diff --git a/Makefile b/Makefile
index 132c9cf..4fd62bc 100644
--- a/Makefile
+++ b/Makefile
@@ -177,7 +177,7 @@ PROGRAMS = \
  	git-convert-objects$X git-fetch-pack$X git-fsck-objects$X \

            ----cut----

diff --git a/pack-objects.c b/builtin-pack-objects.c
similarity index 100%                          <-------  similarity and
rename from pack-objects.c              <--------  rename info shown
rename to builtin-pack-objects.c      <--------  only in this case
index 861c7f0..2301cd5 100644
--- a/pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1,3 +1,4 @@
+#include "builtin.h"
 #include "cache.h"


- Ask for pack-objects.c only

$git diff-tree  -r -p -C 5d4a600 -- pack-objects.c
5d4a60033543e063bc9d77ca957de0187fb58fb3
diff --git a/pack-objects.c b/pack-objects.c
deleted file mode 100644
index 861c7f0..0000000
--- a/pack-objects.c
+++ /dev/null
@@ -1,1376 +0,0 @@
-#include "cache.h"
-#include "object.h"


- Ask for builtin-pack-objects.conly

$git diff-tree  -r -p -C 5d4a600 -- builtin-pack-objects.c
5d4a60033543e063bc9d77ca957de0187fb58fb3
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
new file mode 100644
index 0000000..2301cd5
--- /dev/null
+++ b/builtin-pack-objects.c
@@ -0,0 +1,1376 @@
+#include "builtin.h"
+#include "cache.h"
+#include "object.h"

Showing rename info also when filtering on a specified path could be
useful to retrieve a single file history following renames.

Thanks
Marco

Re: [RFC] Enable 'check for copy and renames' (-C) also when path filtering

[Junio C Hamano]

"Marco Costalba" <mcostalba@gmail.com> writes:

> It seems that -C option of git-diff-tree it works only if the whole
> changeset is retrieved.

Correct (sort of).  Pathspec works on the input side not on the
output side.  It's been specified and worked that way from the
beginning (check the list archive to see me arguing that it
would be easier to use on the output side, and Linus vetoing
because following a single file is not that interesting and the
cost outweighs the benefit of that uninteresting case).

Always feeding the whole tree is wasteful, but if we are
interested in following a single file, we could do something
like:

 - follow that file and that file only from the recent to past;

 - notice when that file disappears -- that is the point the
   file was created.  it may have created from scratch, it may
   have been renamed or copied.

 - on that commit that creates the file, look at the whole tree
   to see if we can find an origin.

 - if we find that the file was created by renaming or copying
   another, keep following that other file from that point on.

Re: [RFC] Enable 'check for copy and renames' (-C) also when path filtering

[Marco Costalba]

On 8/16/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > It seems that -C option of git-diff-tree it works only if the whole
> > changeset is retrieved.
>
> Correct (sort of).  Pathspec works on the input side not on the
> output side.  It's been specified and worked that way from the
> beginning (check the list archive to see me arguing that it
> would be easier to use on the output side, and Linus vetoing
> because following a single file is not that interesting and the
> cost outweighs the benefit of that uninteresting case).
>
> Always feeding the whole tree is wasteful, but if we are
> interested in following a single file, we could do something
> like:
>
>  - follow that file and that file only from the recent to past;
>
>  - notice when that file disappears -- that is the point the
>    file was created.  it may have created from scratch, it may
>    have been renamed or copied.
>
>  - on that commit that creates the file, look at the whole tree
>    to see if we can find an origin.
>
>  - if we find that the file was created by renaming or copying
>    another, keep following that other file from that point on.
>

Yes, I was thinking about something like this, Thanks for point me out
this, now I am quite sure it's the correct way to go ;-)

   Marco

P.S: The first thing will be to teach qgit about renames and copies,
i.e. diff-tree with -C option. I'm cooking a patch on this.

BTW, regarding copies, there are only 6 (6973dca, 8752d11, 927a503,
2276aa6, ddafa7e9 and 7ef7692) in git tree, against 181 renames.

Re: [RFC] Enable 'check for copy and renames' (-C) also when path filtering

[Junio C Hamano]

"Marco Costalba" <mcostalba@gmail.com> writes:

> On 8/16/06, Junio C Hamano <junkio@cox.net> wrote:
>> "Marco Costalba" <mcostalba@gmail.com> writes:
>>
>> > It seems that -C option of git-diff-tree it works only if the whole
>> > changeset is retrieved.
>>
>> Correct (sort of).  Pathspec works on the input side not on the
>> output side.  It's been specified and worked that way from the
>> beginning (check the list archive to see me arguing that it
>> would be easier to use on the output side, and Linus vetoing
>> because following a single file is not that interesting and the
>> cost outweighs the benefit of that uninteresting case).
>>
>> Always feeding the whole tree is wasteful, but if we are
>> interested in following a single file, we could do something
>> like:
>>
>>  - follow that file and that file only from the recent to past;
>>
>>  - notice when that file disappears -- that is the point the
>>    file was created.  it may have created from scratch, it may
>>    have been renamed or copied.
>>
>>  - on that commit that creates the file, look at the whole tree
>>    to see if we can find an origin.
>>
>>  - if we find that the file was created by renaming or copying
>>    another, keep following that other file from that point on.
>
> Yes, I was thinking about something like this, Thanks for point me out
> this, now I am quite sure it's the correct way to go ;-)

You may want to talk with Fredrik about this.  The above is not
entirely my making but was an outline brought up while we
discussed his "rename following revision walker" on the list
recently.