Torsten Bögershausen [off-list ref] writes:
quoted
+--[no-]fold-case::
+ When files/directories with the same name but a different case
+ are detected, they are treated as the same (--fold-case) or as
+ being different (--no-fold-case). The default is --fold-case
+ when `core.ignorecase` is set to `true`, and --no-fold-case when
+ it is `false`.
+
Most often the we use the term "ignore-case", could that be a better name ?
Other opinions, pros/cons ?
Yeah, --[no-]ignore-case sounds more in line with how other
commands' options are spelled.
But I somehow thought this "case-folding" was deliberately done as
an improvement against the original that did not have a way to do
the "ignore-case"?
http://thread.gmane.org/gmane.comp.version-control.git/200597/focus=200625
I am not sure why not until now I did not find the original
justification dubious, but I think fast-export should never do case
folding---Joshua talks about working trees on a file system that is
incapable of expressing different cases, but "export" is about
reading in-repository histories, whose trees are fully capable of
expressing paths in different cases just fine, and spitting out a
file that can be processed by fast-import. I do not see why it
should collapse two different paths that differ in case at export
time.
If the original history is broken by Perforce or whatever and
recording the history of the same path in different case
combinations in different commits, perhaps the right thing to do is
to fix the original history in Git repository before exporting in
the first place.
I do not see how such a corruption is related to the characteristics
of the filesystem where "export" is run. Perhaps a case-insensitive
filesystem may helped Perforce to corrupt the history when initial
import of the history into Git was done, but core.ignorecase of the
current repository does not help us decide if that was actually the
case---the import may have been done on a completely different
machine.
So perhaps we should rip the case folding out altogether instead?
The entry for the change in the Release Notes may say:
* "git fast-import" incorrectly case-folded the paths recorded in
the history when core.ignorease is set (i.e. the repository's
working tree is incapable of expressing paths that differ only in
their cases); this old bug was reported in 2012 and was finally
corrected.
or something like that?
On Fri, Apr 17, 2015 at 11:44:00AM -0700, Junio C Hamano wrote:
So perhaps we should rip the case folding out altogether instead?
The entry for the change in the Release Notes may say:
* "git fast-import" incorrectly case-folded the paths recorded in
the history when core.ignorease is set (i.e. the repository's
working tree is incapable of expressing paths that differ only in
their cases); this old bug was reported in 2012 and was finally
corrected.
or something like that?
Is anything else then git-p4 known to rely on case folding? If not, I
guess that's a reasonable plan. We could even add an option to
fast-import that would allow to turn case folding back on, and make
git-p4 use it, so that its expectations are fulfilled. Although at some
point, it could (should?) do case folding itself(?)
Mike
On 18/04/15 08:36, Mike Hommey wrote:
On Fri, Apr 17, 2015 at 11:44:00AM -0700, Junio C Hamano wrote:
quoted
So perhaps we should rip the case folding out altogether instead?
The entry for the change in the Release Notes may say:
* "git fast-import" incorrectly case-folded the paths recorded in
the history when core.ignorease is set (i.e. the repository's
working tree is incapable of expressing paths that differ only in
their cases); this old bug was reported in 2012 and was finally
corrected.
or something like that?
Is anything else then git-p4 known to rely on case folding? If not, I
guess that's a reasonable plan. We could even add an option to
fast-import that would allow to turn case folding back on, and make
git-p4 use it, so that its expectations are fulfilled. Although at some
point, it could (should?) do case folding itself(?)
git-p4 has a single line of code that checks if core.ignorecase is
turned on, and uses this to decide whether to skip files that are
outside the depot being tracked and I *think* is not really related to
fast-import.
I don't know to what extent though git-p4 relies on the current
behaviour of git fast-import to fold case for it.
There's a 'p4 info' command which tells you what the server thinks it's
doing:
$ p4 info | grep Case
Case Handling: sensitive
I don't know how long that support has been present (it might not work
on older servers that some people are still using).
It's also possible to force the server to be case-insensitive on the
Linux version. That's useful, as it we could construct some test cases
to see what we're likely to break without having to force people to
install a case-insensitive OS in order to run the git regression tests.
Luke
Mike
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html