Re: Intensive rename detection

Re: Intensive rename detection

[Andrew Arnott]

I'm refactoring a library including renaming both files and
directories.  A few lines of each file are also changed, but they are
substantially unchanged in content.  I've done a git add to put all my
changes into the index, but a git status shows that git only detected
a few of the renames... most of them are delete-add operations.  Is
there anything I can do to help git recognize the rename so that
history is preserved across this commit?

Thanks.

Re: Intensive rename detection

[Junio C Hamano]

"Andrew Arnott" <andrewarnott@gmail.com> writes:

> I'm refactoring a library including renaming both files and
> directories.  A few lines of each file are also changed, but they are
> substantially unchanged in content.  I've done a git add to put all my
> changes into the index, but a git status shows that git only detected
> a few of the renames... most of them are delete-add operations.  Is
> there anything I can do to help git recognize the rename so that
> history is preserved across this commit?

There is no need to do anything at commit time.

After making the commit, you can look at it with lower similarity
threashold, e.g.

	git show --stat -M1 HEAD

The default behaviour IIRC corresponds to -M5 (that is 50%).

Re: Intensive rename detection

[Linus Torvalds]

On Mon, 3 Nov 2008, Andrew Arnott wrote:
>
> I'm refactoring a library including renaming both files and
> directories.  A few lines of each file are also changed, but they are
> substantially unchanged in content.  I've done a git add to put all my
> changes into the index, but a git status shows that git only detected
> a few of the renames... most of them are delete-add operations.  Is
> there anything I can do to help git recognize the rename so that
> history is preserved across this commit?

How many renames do you have? Modern versions of git will do any number of 
exact renames, but the (rather expensive) inexact rename detection has a 
default limit of something fairly small.

You could try adding

	[diff]
		renamelimit=0

to your ~/.gitconfig file. It can be quite expensive though.

			Linus

Re: Intensive rename detection

[Linus Torvalds]

On Mon, 3 Nov 2008, Linus Torvalds wrote:
> 
> You could try adding
> 
> 	[diff]
> 		renamelimit=0
> 
> to your ~/.gitconfig file. It can be quite expensive though.

Oh, and obviously Junio is right that some create/deletes won't be seen as 
renames anyway, if you changed enough of the file and/or if the files in 
question are so small that they end up being considered rewrites just 
because of that.

		Linus

Re: Intensive rename detection

[Jeff King]

On Mon, Nov 03, 2008 at 08:22:34PM -0800, Linus Torvalds wrote:

> How many renames do you have? Modern versions of git will do any number of 
> exact renames, but the (rather expensive) inexact rename detection has a 
> default limit of something fairly small.

I was about to say "git should have complained about turning off the
requested rename detection", but I forgot that we silenced that warning
except for merges.

Maybe it makes sense for "status" or a single "diff" (but definitely not
"log", where it isn't even clear which diff caused it!). I dunno. I find
it clutter for anything except a merge, but if that is in fact what is
happening here, it might have produced one slightly less confused user.

-Peff

Re: Intensive rename detection

[Andrew Arnott]

Awesome.  Per Linus' tip, I just noticed at the top of a long list of
messages git said:
warning: too many files, skipping inexact rename detection

So I added the config file change, and that did the trick.  Thanks, everyone!

Here's a related but slightly different question: I've been stashing
and unstashing in the midst of all these renames and refactoring, and
now I'm left with some files listed in git status 3 times.  I
understand why this is, but I don't know the best way to proceed.  Git
is telling me:

$ git status | grep MessageBase
src/DotNetOAuth/Messages/MessageBase.cs: needs merge
src/DotNetOAuth/OAuth/Messages/MessageBase.cs: needs merge
src/DotNetOpenAuth/Messages/MessageBase.cs: needs merge
#       unmerged:   src/DotNetOAuth/Messages/MessageBase.cs
#       unmerged:   src/DotNetOAuth/OAuth/Messages/MessageBase.cs
#       unmerged:   src/DotNetOpenAuth/Messages/MessageBase.cs

I want to end up with MessageBase.cs in
src/DotNetOpenAuth/OAuth/Messages/MessageBase.cs, which ironically is
none of these three.  And the couple of lines that changed in the file
need to be merged.  Only two of these listed files exist on disk.  How
can I best leverage git to merge the two files on disk while moving it
to a new location?

> On Mon, Nov 3, 2008 at 8:22 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>>
>> On Mon, 3 Nov 2008, Andrew Arnott wrote:
>> >
>> > I'm refactoring a library including renaming both files and
>> > directories.  A few lines of each file are also changed, but they are
>> > substantially unchanged in content.  I've done a git add to put all my
>> > changes into the index, but a git status shows that git only detected
>> > a few of the renames... most of them are delete-add operations.  Is
>> > there anything I can do to help git recognize the rename so that
>> > history is preserved across this commit?
>>
>> How many renames do you have? Modern versions of git will do any number of
>> exact renames, but the (rather expensive) inexact rename detection has a
>> default limit of something fairly small.
>>
>> You could try adding
>>
>>        [diff]
>>                renamelimit=0
>>
>> to your ~/.gitconfig file. It can be quite expensive though.
>>
>>                        Linus
>

Re: Intensive rename detection

[Andrew Arnott]

Hmmm.... actually on second run I am still getting the too many files
warning.  I put the [diff] section in a ~/.gitconfig file, a
.gitconfig file in the root of my repo, and in the .git/config file,
but none of them seem to get rid of the message.

I'm running git version 1.5.5.1015.g9d258

Is that too old for this removal of a file rename limit?

On Mon, Nov 3, 2008 at 9:19 PM, Andrew Arnott <andrewarnott@gmail.com> wrote:
> Awesome.  Per Linus' tip, I just noticed at the top of a long list of
> messages git said:
> warning: too many files, skipping inexact rename detection
>
> So I added the config file change, and that did the trick.  Thanks, everyone!
>
> Here's a related but slightly different question: I've been stashing
> and unstashing in the midst of all these renames and refactoring, and
> now I'm left with some files listed in git status 3 times.  I
> understand why this is, but I don't know the best way to proceed.  Git
> is telling me:
>
> $ git status | grep MessageBase
> src/DotNetOAuth/Messages/MessageBase.cs: needs merge
> src/DotNetOAuth/OAuth/Messages/MessageBase.cs: needs merge
> src/DotNetOpenAuth/Messages/MessageBase.cs: needs merge
> #       unmerged:   src/DotNetOAuth/Messages/MessageBase.cs
> #       unmerged:   src/DotNetOAuth/OAuth/Messages/MessageBase.cs
> #       unmerged:   src/DotNetOpenAuth/Messages/MessageBase.cs
>
> I want to end up with MessageBase.cs in
> src/DotNetOpenAuth/OAuth/Messages/MessageBase.cs, which ironically is
> none of these three.  And the couple of lines that changed in the file
> need to be merged.  Only two of these listed files exist on disk.  How
> can I best leverage git to merge the two files on disk while moving it
> to a new location?
>
>> On Mon, Nov 3, 2008 at 8:22 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>>
>>>
>>> On Mon, 3 Nov 2008, Andrew Arnott wrote:
>>> >
>>> > I'm refactoring a library including renaming both files and
>>> > directories.  A few lines of each file are also changed, but they are
>>> > substantially unchanged in content.  I've done a git add to put all my
>>> > changes into the index, but a git status shows that git only detected
>>> > a few of the renames... most of them are delete-add operations.  Is
>>> > there anything I can do to help git recognize the rename so that
>>> > history is preserved across this commit?
>>>
>>> How many renames do you have? Modern versions of git will do any number of
>>> exact renames, but the (rather expensive) inexact rename detection has a
>>> default limit of something fairly small.
>>>
>>> You could try adding
>>>
>>>        [diff]
>>>                renamelimit=0
>>>
>>> to your ~/.gitconfig file. It can be quite expensive though.
>>>
>>>                        Linus
>>
>

Re: Intensive rename detection

[Jeff King]

On Mon, Nov 03, 2008 at 10:02:37PM -0800, Andrew Arnott wrote:

> Hmmm.... actually on second run I am still getting the too many files
> warning.  I put the [diff] section in a ~/.gitconfig file, a
> .gitconfig file in the root of my repo, and in the .git/config file,
> but none of them seem to get rid of the message.

Where are you getting the warning? On "git status"?

If so, then this is an instance of the problem I mentioned here:

  [PATCH v3 7/8] wt-status: load diff ui config
  20081026044935.GG21047@coredump.intra.peff.net

(sorry, I would link to gmane, but it seems to be down at the moment).
Junio, maybe it is worth applying after all (we could also do just the
diff "basic" config instead).

-Peff

Re: Intensive rename detection

[Andrew Arnott]

Yes, on git status.  I'm afraid I don't know how to look up the
reference you gave.

On Mon, Nov 3, 2008 at 10:16 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Nov 03, 2008 at 10:02:37PM -0800, Andrew Arnott wrote:
>
>> Hmmm.... actually on second run I am still getting the too many files
>> warning.  I put the [diff] section in a ~/.gitconfig file, a
>> .gitconfig file in the root of my repo, and in the .git/config file,
>> but none of them seem to get rid of the message.
>
> Where are you getting the warning? On "git status"?
>
> If so, then this is an instance of the problem I mentioned here:
>
>  [PATCH v3 7/8] wt-status: load diff ui config
>  20081026044935.GG21047@coredump.intra.peff.net
>
> (sorry, I would link to gmane, but it seems to be down at the moment).
> Junio, maybe it is worth applying after all (we could also do just the
> diff "basic" config instead).
>
> -Peff
>

Re: Intensive rename detection

[Björn Steinbrink]

On 2008.11.03 22:36:42 -0800, Andrew Arnott wrote:
> On Mon, Nov 3, 2008 at 10:16 PM, Jeff King <peff@peff.net> wrote:
> > On Mon, Nov 03, 2008 at 10:02:37PM -0800, Andrew Arnott wrote:
> >
> >> Hmmm.... actually on second run I am still getting the too many files
> >> warning.  I put the [diff] section in a ~/.gitconfig file, a
> >> .gitconfig file in the root of my repo, and in the .git/config file,
> >> but none of them seem to get rid of the message.
> >
> > Where are you getting the warning? On "git status"?
> >
> > If so, then this is an instance of the problem I mentioned here:
> >
> >  [PATCH v3 7/8] wt-status: load diff ui config
> >  20081026044935.GG21047@coredump.intra.peff.net
>
> Yes, on git status.  I'm afraid I don't know how to look up the
> reference you gave.

http://marc.info/?l=git&m=122499658810367&w=2

Björn

Re: Intensive rename detection

[Jeff King]

On Mon, Nov 03, 2008 at 10:36:42PM -0800, Andrew Arnott wrote:

> Yes, on git status.  I'm afraid I don't know how to look up the
> reference you gave.

Sorry, gmane is back up, so the link is:

  http://article.gmane.org/gmane.comp.version-control.git/99147

With that patch, and this one on top, "git status" should respect your
rename limits (though I haven't tested it).

---
diff --git a/wt-status.c b/wt-status.c
index c3a9cab..0b92ac3 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -214,7 +214,6 @@ static void wt_status_print_updated(struct wt_status *s)
 	rev.diffopt.format_callback = wt_status_print_updated_cb;
 	rev.diffopt.format_callback_data = s;
 	rev.diffopt.detect_rename = 1;
-	rev.diffopt.rename_limit = 200;
 	rev.diffopt.break_opt = 0;
 	run_diff_index(&rev, 1);
 }

-Peff