threads / rfc / 5295

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

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

## tl;dr

4 messages between Aug 16, 2006 and Aug 16, 2006.

replies: 3people: 2as markdown or json

Marco Costalba· Aug 16, 2006, 09:06 UTC · lore

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

Junio C Hamano· Aug 16, 2006, 17:51 UTC · re: Marco Costalba · lore

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

"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.

Marco Costalba· Aug 16, 2006, 20:49 UTC · re: Junio C Hamano · lore

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

On 8/16/06, Junio C Hamano <junkio@cox.net> wrote:

Show 28 quoted lines

> "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.

Junio C Hamano· Aug 16, 2006, 21:11 UTC · re: Marco Costalba · lore

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

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

Show 31 quoted lines

> 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.