git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* fast-import [mis?]-honors core.ignorecase
@ 2012-06-25 20:48 Jay Soffian
  2012-06-26  3:45 ` Joshua Jensen
  0 siblings, 1 reply; 2+ messages in thread
From: Jay Soffian @ 2012-06-25 20:48 UTC (permalink / raw)
  To: git, Shawn Pearce

I was using a "fast-export | <filter program> | fast-import" as a much
faster filter-branch --env-filter (I needed to rewrite
author/committer email-addresses) and was surprised that after the
pipeline was done, the new ref's trees didn't match the old ref's
trees. i.e.:

  $ cmp <(git log old-ref --pretty='%T')  <(git log --pretty='%T' new-ref)

didn't return 0. Comparing one of the differing tree-pairs indicated
it was due to a case-difference in a file which had been renamed.
After some experimenting I finally tracked this down to having
core.ignorecase set to "true" on the repo in which I was running the
pipeline. By setting it to "false" the filtering pipeline completes
with new-ref (and all its ancestors) being tree-identical to old-ref.

Is there any reason for fast-import to honor ignorecase?

j.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: fast-import [mis?]-honors core.ignorecase
  2012-06-25 20:48 fast-import [mis?]-honors core.ignorecase Jay Soffian
@ 2012-06-26  3:45 ` Joshua Jensen
  0 siblings, 0 replies; 2+ messages in thread
From: Joshua Jensen @ 2012-06-26  3:45 UTC (permalink / raw)
  To: Jay Soffian; +Cc: git, Shawn Pearce

----- Original Message -----
From: Jay Soffian
Date: 6/25/2012 2:48 PM
> I was using a "fast-export | <filter program> | fast-import" as a much
> faster filter-branch --env-filter (I needed to rewrite
> author/committer email-addresses) and was surprised that after the
> pipeline was done, the new ref's trees didn't match the old ref's
> trees. i.e.:
>
>    $ cmp <(git log old-ref --pretty='%T')  <(git log --pretty='%T' new-ref)
>
> didn't return 0. Comparing one of the differing tree-pairs indicated
> it was due to a case-difference in a file which had been renamed.
> After some experimenting I finally tracked this down to having
> core.ignorecase set to "true" on the repo in which I was running the
> pipeline. By setting it to "false" the filtering pipeline completes
> with new-ref (and all its ancestors) being tree-identical to old-ref.
>
> Is there any reason for fast-import to honor ignorecase?
I provided this change in ac1c80f7645b6fa90534890e1f83005d40d98281.

In my mind, core.ignorecase=true means that the file system cannot 
handle case-sensitive filenames.  Files held in the repository should 
conform to a single case.

When I was getting a 'fast export' of our Perforce repository, I found 
file case was all over the map.  Perforce internally handles its files 
for a case preserving case insensitive file system in a case insensitive 
manner.  File case can change from changelist to changelist!  The 
fast-exported file was a mess.  In the original fast-imported version, 
'git status' thought that one case of file was modified when another 
case of the same file was the same.  Git could not follow the history 
over all of the filename case changes.

The case folding patches were created to handle this.  Specifically, the 
fast-import patch serves as a catch-all to handle repositories that do 
not conform to a single case as they were created and in operation.  It 
folds the incoming file case to match that of what is in the existing 
repository.  The end result is a clean repository with one file case for 
a given filename.  'git status' works.  File history can be followed.  
'git add' knows which name to match against.

(I am a firm believer that Git should handle *all* case _internally_ as 
insensitive when core.ignorecase=true, and I have work-in-progress 
patches that illustrate this behavior.  Others here (particularly on the 
msysgit mailing list) are adamantly against those patches.  Nonetheless, 
there would be no need to fold case if the Git internals handled 
comparisons in a case insensitive fashion.)

I do understand your point above, and I have no good answer.  Your file 
case was changed during a rename.  The fast-import core.ignorecase=true 
process did not preserve that case change despite it being right and 
appropriate for your repository. core.ignorecase=false did preserve the 
case.  I guess the solution here depends on what core.ignorecase=true 
should mean.

Nevertheless, I am certain Git fast-import needs to retain the case 
folding behavior during fast-import, even if it means enabling it via a 
command-line flag instead of core.ignorecase=true.

-Josh

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-06-26  4:00 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-06-25 20:48 fast-import [mis?]-honors core.ignorecase Jay Soffian
2012-06-26  3:45 ` Joshua Jensen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).