* Re: RFD: Handling case-colliding filenames on case-insensitive filesystems
@ 2011-02-23 22:52 6% ` Marc Branchaud
0 siblings, 0 replies; 200+ results
From: Marc Branchaud @ 2011-02-23 22:52 UTC (permalink / raw)
To: Jay Soffian; +Cc: Johan Herland, git
On 11-02-23 02:07 PM, Jay Soffian wrote:
> On Wed, Feb 23, 2011 at 12:11 PM, Johan Herland <johan@herland.net> wrote:
>> A colleague suggested instead that Git should notice that the collision
>> will occur, and work around the failure to represent the repository
>> objects in the file system with a one-to-one match. Either by checking
>> out only _one_ of the colliding files, or by using a non-colliding name
>> for the second file. After all, Git already has functionality for
>> manipulating the file contents on checkout (CRLF conversion). Doesn't
>> it make sense to add functionality for manipulating the _directory_
>> contents on checkout as well? Even if that makes sense, I'm not sure
>> that implementing it will be straightforward.
>>
>> Are there better suggestions on how to deal with this?
>
> The general problem is aliasing in the working-tree, of which
> case-insenitivity is the most common form, but it also happens due to
> HFS's use of NFD. A search on gmane for "insensitive" or "nfd" will
> return many hits.
>
> I think the argument against remapping filenames is that it doesn't
> really help the user.
>
> Let's say (for the sake of argument) that git supported remapping
> between the index and the working-tree. Further, my repo has:
>
> $ cat Foo.c
> #include "Foo.h"
>
> $ cat foo.c
> #include "foo.h"
>
> And on a case-insensitive file-system, git has remapped foo.[ch] to
> foo~2.[ch] for the purposes of avoiding collisions on checkout.
>
> The checkout can't be compiled correctly, so what's the point of even
> allowing it?
In our case it would be useful to still have that checkout because the people
working on the case-insensitive systems are dealing with a different part of
the tree and don't care about the part with the collision.
A build designed to exploit case-sensitivity obviously won't work on a
case-insensitive system, but there's no reason to expect a git repo to have a
single, monolithic build. There are a couple of parts of our code tree --
parts that are out of our control -- that use case sensitive file names, but
most of it doesn't. It would be good if git would allow people on
case-insensitive systems to work with the repository, if not the complete build.
I suggest:
1. Git should emit a warning when checking out a case-colliding file (or
directory) on a case-insensitive system. I don't really care _what_ gets
checked out for that file -- whatever it is ain't gonna work anyway. Let's
say it checks out the associated blob the first time it runs across
thing.foo, but then emits the warning when it tries to check out Thing.Foo.
2. Git should forbid (yes, *forbid*) a user on a case-insensitive system from
adding any change to any files stored in the repository under
case-conflicting names. The error message should basically be "You need to
use a case-sensitive system to work on this file."
3. I'm OK with git allowing case-insensitive users to forcibly delete
case-conflicting files. "git rm thing.foo" should, on case-insensitive
systems, fail and display all case-colliding names for
[tT][hH][iI][nN][gG].[fF][oO][oO], and tell the user to use -f if they really
want to delete *all* those files.
M.
^ permalink raw reply [relevance 6%]
* [PATCH] Distinguish branches by more than case in tests.
@ 2007-04-06 5:42 6% Brian Gernhardt
0 siblings, 0 replies; 200+ results
From: Brian Gernhardt @ 2007-04-06 5:42 UTC (permalink / raw)
To: git
The renaming without config test changed a branch from q to Q, which
fails on non-case sensitive file systems. Change the test to use q
and q2.
---
Notably, HFS+ is not case sensitive. IIRC there are others. This isn't
a flaw of git, just a bad choice of branch names for certain systems.
t/t3200-branch.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index ce2c5f4..3ca1a32 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -85,9 +85,9 @@ test_expect_failure \
mv .git/config .git/config-saved
-test_expect_success 'git branch -m q Q without config should succeed' '
- git-branch -m q Q &&
- git-branch -m Q q
+test_expect_success 'git branch -m q q2 without config should succeed' '
+ git-branch -m q q2 &&
+ git-branch -m q2 q
'
mv .git/config-saved .git/config
--
1.5.1.32.gdd6cd
^ permalink raw reply related [relevance 6%]
* Re: [RFC] Case insensitive Git attributes
2017-01-23 18:42 6% ` Lars Schneider
@ 2017-01-23 19:25 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2017-01-23 19:25 UTC (permalink / raw)
To: Lars Schneider
Cc: Dakota Hawkins, Duy Nguyen, Johannes Schindelin, Stefan Beller,
git
Lars Schneider <larsxschneider@gmail.com> writes:
> Problem:
> Git attributes for path names are generally case sensitive. However, on
> a case insensitive file system (e.g. macOS/Windows) they appear to be
> case insensitive (`*.bar` would match `foo.bar` and `foo.BAR`). That
> works great until a Git users joins the party with a case sensitive file
> system. For this Git user the attributes pattern only matches files with
> the exact case (*.bar` would match only `foo.bar`).
>
> Question/Proposal:
> Could we introduce some flag to signal that certain attribute patterns
> are always case insensitive?
>
> Thread:
> http://public-inbox.org/git/C83BE22D-EAC8-49E2-AEE3-22D4A99AE205@gmail.com/#t
Thanks for a pointer.
So you are worried about the case where somebody on a case
insensitive but case preserving system would do
$ edit file.txt
$ edit .gitattributes
$ git add file.txt .gitattributes
and adds "*.TXT someattr=true" to the attributes file, which
would set someattr to true on his system for file.txt, but when the
result is checked out on a case sensitive system, it would behave
differently because "*.TXT" does not match "file.txt"?
How do other systems address it? Your Java, Ruby, etc. sources may
refer to another file with "import" and the derivation of the file
names from class names or package names would have the same issue,
isn't it? Do they have an option that lets you say
Even though the import statements may say "import a.b.C", we
know that the source tarball was prepared on a case insensitive
system, and I want you to look for a/b/C.java and a/b/c.java and
use what was found.
or something like that? Same for anything that records other
filenames in the content to refer to them, like "Makefile".
My knee jerk reaction to that is that .gitattributes and .gitignore
should not be instructed to go case insensitive on case sensitive
systems. If the system is case insensitive but case preserving,
it probably would make sense not to do case insensitive matching,
which would prevent the issue from happening in the first place.
^ permalink raw reply [relevance 6%]
* Re: Re-casing directories on case-insensitive systems
@ 2008-01-12 15:03 6% ` Dmitry Potapov
0 siblings, 0 replies; 200+ results
From: Dmitry Potapov @ 2008-01-12 15:03 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Junio C Hamano, git
On Fri, Jan 11, 2008 at 08:43:35PM -0500, Kevin Ballard wrote:
>
> Fair enough, though I believe OS X has a good reason, namely it's an
> OS designed for regular users rather than servers or programmers. Case-
> sensitivity would confuse my mother.
Many of *nix servers are running web-services and samba servers, yet most
users are even not aware of whether they dealing with case-sensitive file
system or not, let alone being confused by that. This is because most
regular users will type the name only once when they create a new file
and then just click on this name. So case-sensitive file systems can
really confuse only some badly written applications...
Dmitry
^ permalink raw reply [relevance 6%]
* Re: OSX, ZFS, UTF8, git - somebody hates me in this list
@ 2008-05-05 6:52 6% ` David Brown
0 siblings, 0 replies; 200+ results
From: David Brown @ 2008-05-05 6:52 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Shawn O. Pearce, git
On Sun, May 04, 2008 at 03:00:11PM -0700, Randal L. Schwartz wrote:
>Ahh, oddly enough, it does exactly the same on HFS+, but *not* UFS, which is
>why I hadn't noticed it yet, since all of my things I mirror are on my UFS
>partition, just in case they have case-colliding names.
Anyone know if 'case sensitive' HFS+ does name mangling? Perhaps ZFS can
also be formed as case sensitive.
David
^ permalink raw reply [relevance 6%]
* Re: Request for detailed documentation of git pack protocol
@ 2009-06-03 12:29 6% ` Jakub Narebski
0 siblings, 0 replies; 200+ results
From: Jakub Narebski @ 2009-06-03 12:29 UTC (permalink / raw)
To: Scott Chacon; +Cc: Shawn O. Pearce, git
On Tue, 2 Jun 2009, Jakub Narebski wrote:
> Should we describe here, or in appendix, or in sidenote, or
> in a footnote, all currently supported client capabilities
> and server capabilities?
>
> * multi_ack (why not multi-ack?)
> * thin-pack
> * side-band
> * side-band-64k
> * ofs-delta
> * shallow
> * no-progress
There is also another capability
* include-tag
What does it mean? Is it about sending tags if we are sending objects
they point to, or is it about sending all tags?
P.S. Is hexdigit length case sensitive i.e. 0-9a-f, or is it not
case sensitive i.e. 0-9a-fA-F?
--
Jakub Narebski
Poland
^ permalink raw reply [relevance 6%]
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
@ 2009-09-25 14:04 6% ` Marco Costalba
0 siblings, 0 replies; 200+ results
From: Marco Costalba @ 2009-09-25 14:04 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
On Fri, Sep 25, 2009 at 12:30, Marco Costalba <mcostalba@gmail.com> wrote:
>
> So I am thinking to some setup somewhere that makes git to use
> abbreviated commits instead of full names. Does exist something like
> this ?
>
Here it is very strange. The problem is that git shell is no more case
sensitive.
I have tried git commit -F ...
and I got error:unkown switch 'f'
So somehow the problem is that all the commands are lowercased, and
this explains why pretty format %H is interpreted as %h so that sha
abbreviated form is used.
Now the question is: how to restore normal case sensitive command parsing ?
Thanks
Marco
P.S: Please, at least answer this last question ;-)
^ permalink raw reply [relevance 6%]
* Re: Odd issue - The Diffs That WILL NOT DIE.
2011-12-07 22:58 6% ` Carlos Martín Nieto
@ 2011-12-07 23:06 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2011-12-07 23:06 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Chris Patti, git
On Wed, Dec 07, 2011 at 11:58:27PM +0100, Carlos Martín Nieto wrote:
> If you want to use OSX to develop this project, you'll have to either
> rename one of those files or set your filesystem to be case-sensitive
> (and unset core.ignorecase afterwards). From what I've heard, the OS
> itself will work fine with a case-sensitive filesystem, but not all
> applications might. YMMV.
I've never done it, but my understanding is that for HFS+, going
case-sensitive is not a simple flip of a switch, but you have to
actually make a new filesystem. Given that complexity, and the fact that
some other apps might not like it, your best bet might be to create a
new case-sensitive filesystem in a loopback file, and then mount that
just for this project.
I'm not sure of the exact commands under OS X, but I'm sure some
googling could probably turn up a solution.
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'
@ 2012-03-22 11:25 6% ` Zbigniew Jędrzejewski-Szmek
2012-03-22 14:12 14% ` Jeff King
0 siblings, 1 reply; 200+ results
From: Zbigniew Jędrzejewski-Szmek @ 2012-03-22 11:25 UTC (permalink / raw)
To: Johannes Sixt, Peter J. Weisberg; +Cc: git, Junio C Hamano
On 03/22/2012 07:49 AM, Johannes Sixt wrote:
> Am 3/21/2012 23:50, schrieb Peter J. Weisberg:
>> +test_expect_failure "diff-files doesn't show case change when ignorecase=true" '
>> + git config core.ignorecase true&&
>> +
>> + touch foo&&
>> + git add foo&&
>> + git commit -m "foo"&&
>> + mv foo FOO&&
>> +
>> + test -z "$(git diff-files)"
>> +'
>
> I tried this in my git.git clone on Windows (NTFS), and it did not produce
> the expected failure:
...
> What am I missing?
The OP meant a case-sensitive fs, not an insensitive one.
"On a filesystem that *is* case-sensitive, ..."
This is a question about core.ignorecase=true. The description in
git-config(1) is so vague, that it's hard to say what behaviour is expected.
Zbyszek
^ permalink raw reply [relevance 6%]
* Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'
@ 2012-03-22 21:08 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2012-03-22 21:08 UTC (permalink / raw)
To: PJ Weisberg; +Cc: Junio C Hamano, git
PJ Weisberg <pj@irregularexpressions.net> writes:
> On Wed, Mar 21, 2012 at 4:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> underlying system calls like open("foo") will *not* magically start
>> returning a file descriptor opened for "FOO" if your filesystem is not
>> case insensitive.
>
> No, but magic_open("foo") might, if someone had put forth the effort
> to write a function called magic_open.
Exactly.
That is why we avoid describing what happens when you set it on a case
sensitive filesystem, to leave the door open for such a cleverness.
It may still be a mistake in the manual that we did not explicitly say
that setting core.ignorecase on a case sensitive system will give you an
undefined behaviour.
^ permalink raw reply [relevance 6%]
* Re: Branch Name Case Sensitivity
@ 2014-02-28 13:56 6% ` Karsten Blees
0 siblings, 0 replies; 200+ results
From: Karsten Blees @ 2014-02-28 13:56 UTC (permalink / raw)
To: Johannes Sixt, Lee Hopkins; +Cc: Torsten Bögershausen, Junio C Hamano, git
Am 28.02.2014 07:41, schrieb Johannes Sixt:
> Am 2/28/2014 0:38, schrieb Lee Hopkins:
>>> If I understand the issue correctly, the problem is that packed-refs
>>> are always case-sensitive, even if core.ignorecase=true. OTOH,
>
> core.ignorecase is intended to affect filenames of the worktree, not
> anything else, BTW.
>
from git-config(1):
"enables various workarounds to enable git to work better on filesystems that are not case sensitive"
It says nothing about work-tree only, so I'd expect it to apply to all git components that store potentially case-sensitive information in file names.
...it also says "better", not "flawlessly" :-)
>>> checking / updating _unpacked_ refs on a case-insensitive file system
>>> is naturally case-insensitive. So wouldn't it be a better workaround
>>> to disallow packed refs (i.e. 'git config gc.packrefs false')?
>>
>> You are correct, the issue boils down to mixing the usage of
>> packed-refs and loose refs on case insensitive file systems. So either
>> always using packed-refs or always using loose refs would take care of
>> the problem. Based Michael Haggerty's response, it seems that always
>> using loose refs would be a better workaround.
>
> So, everybody on a case-insensitive file system should pay the price even
> if they do not need the "feature"? No way.
>
> If you are on a case-insensitive filesystem, or work on a cross-platform
> project, ensure that you avoid ambiguous refs. Problem solved.
>
So its OK to lose data if you accidentally use an ambiguous ref? I cannot believe you actually meant that.
IMO the proper solution is to teach packed-refs about core.ignorecase. Until that happens, disabling gc.packrefs seems to be a valid workaround for people who have that problem.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 7/9] gpg-interface: introduce new config to select per gpg format program
@ 2018-07-16 21:35 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2018-07-16 21:35 UTC (permalink / raw)
To: brian m. carlson, Henning Schild, git, Eric Sunshine,
Junio C Hamano, Martin Ågren, Ben Toews, Taylor Blau
On Sat, Jul 14, 2018 at 06:13:47PM +0000, brian m. carlson wrote:
> On Tue, Jul 10, 2018 at 12:56:38PM -0400, Jeff King wrote:
> > On Tue, Jul 10, 2018 at 12:54:13PM -0400, Jeff King wrote:
> >
> > > Should we allow:
> > >
> > > [gpg "OpenPGP"]
> > > program = whatever
> > >
> > > given that we allow:
> > >
> > > [gpg]
> > > format = OpenPGP
> > >
> > > ? I think just using strcasecmp() here would be sufficient. But I wonder
> > > if it is a symptom of using the wrong tool (subsections) when we don't
> > > need it.
> >
> > I did just read the discussion in response to v1, where everybody told
> > you the opposite. ;)
> >
> > So I guess my question/points are more for brian and Junio.
>
> I'm okay with us forcing "openpgp". That seems sane enough for now, and
> if people scream loudly, we can loosen it.
Well, I specifically meant "are you sure subsections like this are a
good idea". But it seems like people think so?
If so, then I think the best route is just dictating that yes,
gpg.format is case-sensitive because it is referencing
gpg.<format>.program, which is itself case-sensitive (and "openpgp" is
the right spelling).
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH] apply: support case-only renames in case-insensitive filesystems
2022-06-11 17:03 13% [PATCH] apply: support case-only renames in case-insensitive filesystems Tao Klerks via GitGitGadget
@ 2022-06-12 23:30 6% ` Junio C Hamano
2022-06-14 6:16 7% ` Tao Klerks
2022-06-19 16:10 6% ` [PATCH v2 0/3] RFC: " Tao Klerks via GitGitGadget
2 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2022-06-12 23:30 UTC (permalink / raw)
To: Tao Klerks via GitGitGadget; +Cc: git, Tao Klerks
"Tao Klerks via GitGitGadget" <gitgitgadget@gmail.com> writes:
> +if ! test_have_prereq CASE_INSENSITIVE_FS
> +then
> + test_set_prereq CASE_SENSITIVE_FS
> + echo nuts
> +fi
You can easily say !CASE_INSENSITIVE_FS as the prerequiste, so I do
not see the point of this. I do not see the point of "nuts", either.
But it probably is a moot point as I do not think you should do the
prerequisite at all.
Instead, you can explicitly set the core.ignorecase configuration,
i.e. "git -c core.ignorecase=yes/no", and possibly "apply --cached"
so that you do not have to worry about the case sensitivity of the
filesystem at all.
> +test_expect_success setup '
> + echo "This is some content in the file." > file1 &&
Style. Redirection operator ">" sticks to its operand, i.e.
echo "This is some content in the file." >file1 &&
> + echo "A completely different file." > file2 &&
> + git update-index --add file1 &&
> + git update-index --add file2 &&
> + cat >case_only_rename_patch <<-\EOF
> + diff --git a/file1 b/File1
> + similarity index 100%
> + rename from file1
> + rename to File1
> + EOF
You are better off not writing the diff output manually. Instead,
you can let the test write it for you, e.g.
echo "This is some content in the file." >file1 &&
git update-index --add file1 &&
file1blob=$(git rev-parse :file1) &&
git commit -m "Initial - file1" &&
git update-index --add --cacheinfo 100644,$file1blob,File1 &&
git rm --cached file1 &&
git diff --cached -M HEAD >case-only-rename-patch
If you want to be extra careful not to rely on your filesystem
corrupting the pathnames you feed (e.g. the redireciton to "file1"
might create file FILE1 on MS-DOS ;-), you could even do:
file1blob=$(echo "This is some content in the file." |
git hash-object -w --stdin) &&
file2blob=$(echo "A completeloy different contents." |
git hash-object -w --stdin) &&
git update-index --add --cacheinfo 100644,$file1blob,file1 &&
git commit -m "Initial - file1" &&
git update-index --add --cacheinfo 100644,$file1blob,File1 &&
git rm --cached file1 &&
git diff --cached -M HEAD >rename-file1-to-File2 &&
git reset --hard HEAD &&
git update-index --add --cacheinfo 100644,$file1blob,file2 &&
git rm --cached file1 &&
git diff --cached -M HEAD >rename-file1-to-file2 &&
# from here on, HEAD has file1 and file2
git reset --hard HEAD &&
git update-index --add --cacheinfo 100644,$file2blob,file2 &&
git commit -m 'file1 and file2'
> +'
> +
> +test_expect_success 'refuse to apply rename patch with conflict' '
> + cat >conflict_patch <<-\EOF &&
> + diff --git a/file1 b/file2
> + similarity index 100%
> + rename from file1
> + rename to file2
> + EOF
> + test_must_fail git apply --index conflict_patch
And then, you could use --cached (not --index) to bypass the working
tree altogether, which is a good way to test the feature without
getting affected by the underlying filesystem. Check both case
sensitive and case insensitive cases:
# Start from a known state
git reset --hard HEAD &&
test_must_fail git -c core.ignorecase=no apply --cached rename-file1-to-file2 &&
# Start from a known state
git reset --hard HEAD &&
test_must_fail git -c core.ignorecase=yes apply --cached rename-file1-to-file2 &&
> +'
> +
> +test_expect_success CASE_SENSITIVE_FS 'refuse to apply case-only rename patch with conflict, in case-sensitive FS' '
Lose the prerequisite, replace --index with --cached, and force core.ignorecase
to both case insensitive and sensitive to check the behaviour.
> + test_when_finished "git mv File1 file2" &&
> + git mv file2 File1 &&
> + test_must_fail git apply --index case_only_rename_patch
> +'
> +
> +test_expect_success 'apply case-only rename patch without conflict' '
Likewise, try both sensitive and insensitive one.
> + git apply --index case_only_rename_patch
> +'
> +
> +test_done
>
> base-commit: 1e59178e3f65880188caedb965e70db5ceeb2d64
Thanks.
^ permalink raw reply [relevance 6%]
* Re: An idea: maybe Git should use a lock/unlock file mode for problematic files? [Was: Re: after first git clone of linux kernel repository there are changed files in working dir]
@ 2009-01-21 0:03 6% ` Daniel Barkalow
0 siblings, 0 replies; 200+ results
From: Daniel Barkalow @ 2009-01-21 0:03 UTC (permalink / raw)
To: Alex Riesen; +Cc: John Chapman, Hannu Koivisto, rdkrsr, git
On Wed, 21 Jan 2009, Alex Riesen wrote:
> 2009/1/20 Daniel Barkalow <barkalow@iabervon.org>:
> > My impression was that this didn't happen in practice, because teams
> > would tend to not have two people create the same file at the same time,
> > but with different cases, and people interacting with the same file at
> > different times would use whatever case it was introduced with.
>
> It will and does happen in practice (annoingly too often even). Not with Git
> yet (with Perforce), where people do "branching" by simply copying things
> in another directory (perforce world does not know real branches),
> renaming files randomly, and putting the new directory back in the
> system (or maybe it is the strange tools here which do that - often
> it is the first character of a directory or file which gets down- or up-cased).
How does the resulting code work at all? With a case-sensitive filesystem,
most of the files you're using don't have the expected names any more, and
most systems will therefore not actually build or run.
I have to assume it's your strange tools, because we never have this
problem at my work, where we also use Perforce. Perhaps it's that we
always use "p4 integrate //some/project/version/...
//some/other/project/version/..." which inherently preserves the case of
all of the filenames within the project.
> As Perforce itself is case sensitive (like Git), using of such branches
> is a nightmare: the files get overwritten in checkout order which is
> not always sorted in predictable order. Combined with case-stupidity
> of the file system the working directories sometimes cause "interesting
> time" for unlucky users.
> Luckily (sadly) it is all-opening-in-a-wall shop, so the problem with "fanthom"
> files is rare (it is hard to notice) for most. Which actually makes it more
> frustrating when the real shit happens.
>
> And it will happen to Git as well, especially if development go crossplatform.
> It is not that hard to accidentally rename a file on case-sensitive file system,
> "git add *" it and commit without thinking (that's how most of software
> development happens, come to think of it).
People can accidentally rename files? And still have things work when they
do it on a case-sensitive filesystem?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [relevance 6%]
* [PATCH (GIT-GUI)] git-gui: Fix focus transition in the blame viewer.
@ 2008-11-09 15:36 6% Alexander Gavrilov
0 siblings, 0 replies; 200+ results
From: Alexander Gavrilov @ 2008-11-09 15:36 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
Now that the blame viewer has a search panel, it should be
taken into account by the focus transition code. Otherwise
showing a commit tip (by accidentally moving the mouse to
the text frame) causes the focus to transfer away from the
search field.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
lib/blame.tcl | 16 ++++++++++++----
lib/search.tcl | 14 +++++++++++---
2 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/lib/blame.tcl b/lib/blame.tcl
index 765d08c..642f5ca 100644
--- a/lib/blame.tcl
+++ b/lib/blame.tcl
@@ -321,7 +321,7 @@ constructor new {i_commit i_path i_jump} {
tk_popup $w.ctxm %X %Y
"
bind $i <Shift-Tab> "[list focus $w_cviewer];break"
- bind $i <Tab> "[list focus $w_cviewer];break"
+ bind $i <Tab> "[cb _focus_search $w_cviewer];break"
}
foreach i [concat $w_columns $w_cviewer] {
@@ -337,10 +337,10 @@ constructor new {i_commit i_path i_jump} {
bind $i <Control-Key-f> {catch {%W yview scroll 1 pages};break}
}
- bind $w_cviewer <Shift-Tab> "[list focus $w_file];break"
+ bind $w_cviewer <Shift-Tab> "[cb _focus_search $w_file];break"
bind $w_cviewer <Tab> "[list focus $w_file];break"
- bind $w_cviewer <Button-1> [list focus $w_cviewer]
- bind $w_file <Visibility> [list focus $w_file]
+ bind $w_cviewer <Button-1> [list focus $w_cviewer]
+ bind $w_file <Visibility> [cb _focus_search $w_file]
bind $top <F7> [list searchbar::show $finder]
bind $top <Escape> [list searchbar::hide $finder]
bind $top <F3> [list searchbar::find_next $finder]
@@ -382,6 +382,14 @@ constructor new {i_commit i_path i_jump} {
_load $this $i_jump
}
+method _focus_search {win} {
+ if {[searchbar::visible $finder]} {
+ focus [searchbar::editor $finder]
+ } else {
+ focus $win
+ }
+}
+
method _handle_destroy {win} {
if {$win eq $w} {
_kill $this
diff --git a/lib/search.tcl b/lib/search.tcl
index d292f20..32c8656 100644
--- a/lib/search.tcl
+++ b/lib/search.tcl
@@ -19,11 +19,11 @@ constructor new {i_w i_text args} {
frame $w
label $w.l -text [mc Find:]
+ entry $w.ent -textvariable ${__this}::searchstring -background lightgreen
button $w.bn -text [mc Next] -command [cb find_next]
button $w.bp -text [mc Prev] -command [cb find_prev]
checkbutton $w.cs -text [mc Case-Sensitive] \
-variable ${__this}::casesensitive -command [cb _incrsearch]
- entry $w.ent -textvariable ${__this}::searchstring -background lightgreen
pack $w.l -side left
pack $w.cs -side right
pack $w.bp -side right
@@ -40,19 +40,27 @@ constructor new {i_w i_text args} {
}
method show {} {
- if {![winfo ismapped $w]} {
+ if {![visible $this]} {
grid $w
}
focus -force $w.ent
}
method hide {} {
- if {[winfo ismapped $w]} {
+ if {[visible $this]} {
focus $ctext
grid remove $w
}
}
+method visible {} {
+ return [winfo ismapped $w]
+}
+
+method editor {} {
+ return $w.ent
+}
+
method _get_new_anchor {} {
# use start of selection if it is visible,
# or the bounds of the visible area
--
1.6.0.3.15.gb8d36
^ permalink raw reply related [relevance 6%]
* Re: git on MacOSX and files with decomposed utf-8 file names
@ 2008-01-17 18:38 6% ` Pedro Melo
0 siblings, 0 replies; 200+ results
From: Pedro Melo @ 2008-01-17 18:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mark Junker, git@vger.kernel.org
Hi,
On Jan 17, 2008, at 6:18 PM, Johannes Schindelin wrote:
> On Thu, 17 Jan 2008, Pedro Melo wrote:
>> On Jan 17, 2008, at 6:09 PM, Mark Junker wrote:
>>
>>> IMHO it would be the best solution when git stores all string meta
>>> data in UTF-8 and converts it to the target systems file system
>>> encoding. That would fix all those problems with different
>>> locales and
>>> file system encodings ...
>>
>> +1.
>
> -1.
>
> It's just too arrogant to force your particular preferences down the
> throat of every git user.
Do you agree that you need to store or at least calculate a
normalized version of each filename to see if you are already
tracking the file, to take in account all the the filesystems out
there who are not case-preserving, case-sensitive?
If so, do you think those rules should be an option? Or a preference?
Should I specify in my config file that I want my filenames to be
normalized?
Ignoring encoding, and case-sensitive issues in the git index creates
problems for those people who want/need to use non-ascii chars in
their filenames, and have some change of being able to collaborate
with other users on different operating systems.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ permalink raw reply [relevance 6%]
* Re: git on MacOSX and files with decomposed utf-8 file names
@ 2008-01-23 0:38 6% ` Kevin Ballard
0 siblings, 0 replies; 200+ results
From: Kevin Ballard @ 2008-01-23 0:38 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 5932 bytes --]
On Jan 22, 2008, at 7:08 PM, Theodore Tso wrote:
> On Tue, Jan 22, 2008 at 08:34:27AM -0500, Theodore Tso wrote:
>> * Documenting HFS+'s current pseudo-normalization algorithm.
>> It's not enough to say that you need to decompose all
>> Unicode characters, since you've claimed that HFS+ doesn't
>> decompose Unicode characters after some magic date,
>> presumably roughly 9 years ago.
>
> I did some research on this point, since if we really are going to be
> compatible with MacOS X's crappy HFS+ system, we need to know what the
> decomposition algorithm actually is. Turns out, there are *two* of
> them. Kevin didn't know what he was talking about. In fact,
> different versions of Mac OS X use different normalization algorithms.
>
> Mac OS X 8.1 through 10.2.x used decompositions based on Unicode 2.1.
> Mac OS X 10.3 and later use decompositions based on Unicode 3.2.[1]
>
> As I correctly predicted, Apple is changing their normalization
> algorithm in different versions of Mac OS X. It is not static, which
> meands there will be compatibility problems when moving hard drives
> between Mac OS X versions. I don't know if they try to fix this in
> their fsck or not, when upgrading from 10.2 to 10.3, but if not,
> certain files could disappear as part of the Mac OS X upgrade. Fun
> fun fun.
>
> And clearly Kevin didn't read the tech note very carefully, since it
> clearly admits why they did it. The Mac OS X developers were being
> cheasy with how they implemented their HFS B-tree algorithms, and took
> the cheap, easy way out. So yeah, "crappy" is the only word that can
> be used for what Mac OS X perpetuated on the world. Because of that,
> a quick Google search shows it causes problems all over the stack, for
> many different programs beyond just git, including limewire and
> gnutella[2][3], Slim[4], and no doubt others.
>
> [1] http://developer.apple.com/technotes/tn/tn1150.html#UnicodeSubtleties
> [2] http://lists.limewire.org/pipermail/gui-dev/2003-January/001110.html
> [3] http://osdir.com/ml/network.gnutella.limewire.core.devel/2003-01/msg00000.html
> [4] http://forums.slimdevices.com/showthread.php?t=40582
>
> In any case, it seems pretty clear that by now everyone except Kevin
> has realized that HFS+ is crappy and causes Internet-wide
> interoperability problems. So I'll justify sending this note by
> pointing out the specific table of Mac OS's filesystem corruption
> algorithm can be found here:
>
> http://developer.apple.com/technotes/tn/tn1150table.html
>
> I'd also recommend that the Mac OS X code try to either figure out
> whether it is running on an HFS+ partition, or let the HFS+ workaround
> code be something that can be controlled via .git/config. It
> shouldn't be on unconditionally even on a Mac OS X system, since if
> the git repository is on a ZFS or NFS filesystem, there's no reason to
> pay the overhead of working around the HFS+ bugs.
I just finished talking to one of the HFS+ developers, so I suspect I
know a lot more on this subject now than you do. Here's some of the
relevant information:
* Any new characters added to Unicode will only have one form
(decomposed), so HFS+ will always accept new characters as they will
be NFD. The only exception is case-sensitivity, as the case-folding
tables in HFS+ are static, so new characters with case variants will
be treated in a case-sensitive manner. However, as they are already
decomposed, the NFD algorithm will not change their encoding. This
means that no, there are zero problems moving HFS+ drives between
versions of OS X.
* At the time HFS+ was developed, there was no one common standard for
normalization. The HFS+ developers picked NFD because they thought it
was "a more flexible, future-looking form", but Microsoft ended up
picking the opposite just a short time later. Interestingly, NFC is a
weird hybrid form which only has composed forms for pre-existing
characters, and decomposed forms for all new characters (as they only
have one form). So in a sense NFD is more sane then NFC.
* The core issue here, which is why you think HFS+ is so stupid, is
that you guys see no problem with having 2 files "Märchen" (NFC) and
"Märchen" (NFD), whereas the HFS+ developers don't consider it
acceptable to have 2 visually identical names as independent files.
Unfortunately, the only way to do this matching is to store the
normalized form in the filesystem, because it would be a performance
nightmare to try and do this matching any other way. The HFS+
developers considered it an acceptable trade-off, and as an
application developer I tend to agree with them.
As I have stated in the past, this isn't a case of HFS+ being stupid
and causing problems, it's a case of HFS+ being *different* and
causing problems. But this difference is just as much your fault as it
is HFS+'s fault.
* For detecting case-sensitive filesystems you can use pathconf(2):
_PC_CASE_SENSITIVE (if unsupported, you can assume the filesystem is
case-sensitive). There is also the getattrlist(2) attribute:
VOL_CAP_FMT_CASE_SENSITIVE.
There appears to be no API for determining if normalization will be
applied. However, any filesystem that uses UTF-8 explicitly as storage
(unlike the Linux filesystems, which you claim use UTF-8 but is
obviously you really use nothing at all) is pretty much guaranteed to
have to normalize or it will have abysmal performance.
I must say it is shocking that someone as smart as you is still more
interested in finding ways to prove me wrong then to actually address
the problem. It's obvious that the only research you did was intended
to find ways to call me stupid.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2432 bytes --]
^ permalink raw reply [relevance 6%]
* Re: [PATCH v10 11/12] Documentation: add documentation for 'git interpret-trailers'
@ 2014-04-08 7:30 6% ` Michael Haggerty
0 siblings, 0 replies; 200+ results
From: Michael Haggerty @ 2014-04-08 7:30 UTC (permalink / raw)
To: Christian Couder, Junio C Hamano
Cc: git, Johan Herland, Josh Triplett, Thomas Rast, Dan Carpenter,
Greg Kroah-Hartman, Jeff King, Eric Sunshine, Ramsay Jones,
Jonathan Nieder
Sorry for reappearing in this thread after such a long absence. I
wanted to see what is coming up (I think this interpret-trailers command
will be handy!) so I read this documentation patch carefully, and added
some questions and suggestions below.
On 04/06/2014 07:02 PM, Christian Couder wrote:
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Documentation/git-interpret-trailers.txt | 123 +++++++++++++++++++++++++++++++
> 1 file changed, 123 insertions(+)
> create mode 100644 Documentation/git-interpret-trailers.txt
>
> diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt
> new file mode 100644
> index 0000000..75ae386
> --- /dev/null
> +++ b/Documentation/git-interpret-trailers.txt
> @@ -0,0 +1,123 @@
> +git-interpret-trailers(1)
> +=========================
> +
> +NAME
> +----
> +git-interpret-trailers - help add stuctured information into commit messages
> +
> +SYNOPSIS
> +--------
> +[verse]
> +'git interpret-trailers' [--trim-empty] [(<token>[(=|:)<value>])...]
> +
> +DESCRIPTION
> +-----------
> +Help add RFC 822-like headers, called 'trailers', at the end of the
> +otherwise free-form part of a commit message.
> +
> +This command is a filter. It reads the standard input for a commit
> +message and applies the `token` arguments, if any, to this
> +message. The resulting message is emited on the standard output.
s/emited/emitted/
> +
> +Some configuration variables control the way the `token` arguments are
> +applied to the message and the way any existing trailer in the message
> +is changed. They also make it possible to automatically add some
> +trailers.
> +
> +By default, a 'token=value' or 'token:value' argument will be added
> +only if no trailer with the same (token, value) pair is already in the
> +message. The 'token' and 'value' parts will be trimmed to remove
> +starting and trailing whitespace, and the resulting trimmed 'token'
> +and 'value' will appear in the message like this:
> +
> +------------------------------------------------
> +token: value
> +------------------------------------------------
> +
> +By default, if there are already trailers with the same 'token', the
> +new trailer will appear just after the last trailer with the same
> +'token'. Otherwise it will appear at the end of the message.
How are existing trailers recognized in the input commit message? Do
trailers have to be configured to be recognized? Or are all lines
matching a specific pattern considered trailers? If so, it might be
helpful to include a regexp here that describes the trailer "syntax".
What about blank lines? I see that you try to add a blank line before
new trailers. But what about on input? Do the trailer lines have to be
separated from the free-form comment by a blank line to be recognized?
What if there are blank lines between trailer lines, or after them? Is
it allowed to have non-trailer lines between or after trailer lines?
> +
> +Note that 'trailers' do not follow and are not intended to follow many
> +rules that are in RFC 822. For example they do not follow the line
> +breaking rules, the encoding rules and probably many other rules.
> +
> +OPTIONS
> +-------
> +--trim-empty::
> + If the 'value' part of any trailer contains only whitespace,
> + the whole trailer will be removed from the resulting message.
Does this apply to existing trailers, new trailers, or both? If it
applies to existing trailers, then it seems a bit dangerous, in the
sense that the command might end up changing trailers that are unrelated
to the one that the command is trying to add.
> +
> +CONFIGURATION VARIABLES
> +-----------------------
> +
> +trailer.<token>.key::
> + This 'key' will be used instead of 'token' in the
> + trailer. After some alphanumeric characters, it can contain
Trailer keys can also contain '-', right?
> + some non alphanumeric characters like ':', '=' or '#' that will
> + be used instead of ':' to separate the token from the value in
> + the trailer, though the default ':' is more standard.
Above it looks like the default separator is not ':' but rather ': '
(with a space). Is the space always added regardless of the value of
this configuration variable, or should the configuration value include
the trailing space if it is desired? Is there any way to get a trailer
that doesn't include a space, like
foo=bar
? (Changing this to "foo= bar" would look pretty ugly.)
If a commit message containing trailer lines with separators other than
':' is input to the program, will it recognize them as trailer lines?
Do such trailer lines have to have the same separator as the one listed
in this configuration setting to be recognized?
I suppose that there is some compelling reason to allow non-colon
separators here. If not, it seems like it adds a lot of complexity and
should maybe be omitted, or limited to only a few specific separators.
> +
> +trailer.<token>.where::
> + This can be either `after`, which is the default, or
> + `before`. If it is `before`, then a trailer with the specified
> + token, will appear before, instead of after, other trailers
> + with the same token, or otherwise at the beginning, instead of
> + at the end, of all the trailers.
Brainstorming: some other options that might make sense here someday:
`end`: add new trailer after all existing trailers (even those with
different keys). This would allow trailers to be kept in chronological
order.
`beginning`: add new trailer before the first existing trailer (allows
reverse chronological order).
`sorted`: add new trailer among the existing trailers with the same key
so as to keep their values in lexicographic order.
> +
> +trailer.<token>.ifexist::
> + This option makes it possible to choose what action will be
> + performed when there is already at least one trailer with the
> + same token in the message.
> ++
> +The valid values for this option are: `addIfDifferent` (this is the
> +default), `addIfDifferentNeighbor`, `add`, `overwrite` or `doNothing`.
Are these option values case sensitive? If so, it might be a little bit
confusing because the same camel-case is often used in documentation for
configuration *keys*, which are not case sensitive [1], and users might
have gotten used to thinking of strings that look like this to be
non-case-sensitive.
> ++
> +With `addIfDifferent`, a new trailer will be added only if no trailer
> +with the same (token, value) pair is already in the message.
> ++
> +With `addIfDifferentNeighbor`, a new trailer will be added only if no
> +trailer with the same (token, value) pair is above or below the line
> +where the new trailer will be added.
> ++
> +With `add`, a new trailer will be added, even if some trailers with
> +the same (token, value) pair are already in the message.
> ++
> +With `overwrite`, the new trailer will overwrite an existing trailer
> +with the same token.
What if there are multiple existing trailers with the same token? Are
they all overwritten?
> ++
> +With `doNothing`, nothing will be done, that is no new trailer will be
> +added if there is already one with the same token in the message.
> +
> +trailer.<token>.ifmissing::
> + This option makes it possible to choose what action will be
> + performed when there is not yet any trailer with the same
> + token in the message.
> ++
> +The valid values for this option are: `add` (this is the default) and
> +`doNothing`.
> ++
> +With `add`, a new trailer will be added.
> ++
> +With `doNothing`, nothing will be done.
> +
> +trailer.<token>.command::
> + This option can be used to specify a shell command that will
> + be used to automatically add or modify a trailer with the
> + specified 'token'.
> ++
> +When this option is specified, it is like if a special 'token=value'
> +argument is added at the end of the command line, where 'value' will
> +be given by the standard output of the specified command.
Maybe reword to
When this option is specified, the behavior is as if a special
'token=value' argument were added at the end of the command line,
where 'value' is taken to be the standard output of the specified
command.
And if it is the case, maybe add "with leading and trailing whitespace
trimmed off" at the end of the sentence.
> ++
> +If the command contains the `$ARG` string, this string will be
> +replaced with the 'value' part of an existing trailer with the same
> +token, if any, before the command is launched.
What if the key appears multiple times in existing trailers?
> +
> +SEE ALSO
> +--------
> +linkgit:git-commit[1]
> +
> +GIT
> +---
> +Part of the linkgit:git[1] suite
>
Doesn't this command have to be added to command-list.txt?
Michael
[1] Anti-nitpick declaration: yes, I know that the middle part of
configuration keys is case-sensitive.
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply [relevance 6%]
* Re: Fwd: after first git clone of linux kernel repository there are changed files in working dir
@ 2008-12-11 17:41 6% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2008-12-11 17:41 UTC (permalink / raw)
To: rdkrsr; +Cc: git
On Thu, 11 Dec 2008, rdkrsr wrote:
>
> I'm sorry that I didn't answer to git mailing list address. So here
> comes the email again.
You have a broken filesystem.
> $ git status
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> #
> # modified: Documentation/IO-mapping.txt
> # modified: include/linux/netfilter/xt_CONNMARK.h
> # modified: include/linux/netfilter/xt_DSCP.h
> # modified: include/linux/netfilter/xt_MARK.h
> # modified: include/linux/netfilter/xt_RATEEST.h
...
This is _exactly_ what happens if you try to develop the Linux kernel on a
case-insensitive filesystem. The kernel source tree has several files that
differ only in case, eg
Documentation/IO-mapping.txt
Documentation/io-mapping.txt
include/linux/netfilter/xt_tcpmss.h
include/linux/netfilter/xt_TCPMSS.h
..
and if you try to check it out on a broken filesystem, then the second
file will overwrite the first one, and git will think that you have
modified it.
OS X? Afaik, you can fix it by using NFS or UFS. And I think ZFS has a
case-sensitive mode too (and it may even be the default). In fact, I think
newer versions of OS X even allow that piece-of-sh*t HFS+ to be case
sensitive (and thus make it much less sh*tty).
Of course, there are reports of some Mac software breaking when they use a
real filesystem, but hey, what else is new?
Linus
^ permalink raw reply [relevance 6%]
* [PATCH v2 0/3] RFC: apply: support case-only renames in case-insensitive filesystems
2022-06-11 17:03 13% [PATCH] apply: support case-only renames in case-insensitive filesystems Tao Klerks via GitGitGadget
2022-06-12 23:30 6% ` Junio C Hamano
@ 2022-06-19 16:10 6% ` Tao Klerks via GitGitGadget
2022-06-19 16:10 11% ` [PATCH v2 3/3] " Tao Klerks via GitGitGadget
2 siblings, 2 replies; 200+ results
From: Tao Klerks via GitGitGadget @ 2022-06-19 16:10 UTC (permalink / raw)
To: git; +Cc: Tao Klerks, Junio C Hamano, Tao Klerks
As suggested recently in thread
CAPMMpojwV+f=z9sgc_GaUOTFBCUVdbrGW8WjatWWmC3WTcsoXw@mail.gmail.com,
proposing a fix to git-apply for case-only renames on case-insensitive
filesystems.
Changes in V2:
* Prepended a commit from Junio, with new apply tests to build on
* Added a largely-unrelated new known failing test, concerning reset --hard
in the presence of index case conflicts on a case-insensitive filesystem,
which we later need to work around in a corner-case test
* Moved test cases to build on Junio's new test file
* Switched fix approach from "allow same-name commit explicitly" to "track
files marked for deletion case-insensitively for filesystem checks",
which addresses the issue noted and other more obscure ones like "rename
swap with case change"
* Added a test case for "rename swap with case change"
* Added test cases setting "core.ignorecase" on and off explicitly
* Added a test case exposing one remaining surprising behavior
POSSIBLE CONCERN:
This fix was originally much simpler - it just made the "fn_table" string
list use a case-insensitive string comparison - using case-insensitive
comparisons when dealing with all replacement checks, both on the index and
on the filesystem.
However, with that simple implementation, there was at least one edge-case
where data loss could result: If the index contained two files differing
only by case, with different content, and we were doing a case-only rename,
a swap, or some other operation involving the deletion and creation of a
file with that name (ignoring case), then both of the files with that name
in the index would be overwritten - even though only one of them had the
expected content, and even though the one deleted might never have been
committed.
It seems as though the core.ignorecase option should typically only apply to
filesystem checks - that the index is always case-sensitive.
The current fix proposal therefore splits the string list used for "can I
create a file that already exists?" checks into two such structures - one
string list used for filesystem checks, which is case-insensitive when
specified by core.ignorecase, and one used for index checks, which is always
case-sensitive.
The resulting duplication is not appealing, but I'm not sure how to address
it / how to do this more elegantly. I'm also still not completely certain
that my rule of thumb about the index always being case-sensitive is the
right way of thinking of things.
Junio C Hamano (1):
t4141: test "git apply" with core.ignorecase
Tao Klerks (2):
reset: new failing test for reset of case-insensitive duplicate in
index
apply: support case-only renames in case-insensitive filesystems
apply.c | 81 +++++++++----
apply.h | 5 +-
t/t4141-apply-icase.sh | 258 +++++++++++++++++++++++++++++++++++++++++
t/t7104-reset-hard.sh | 11 ++
4 files changed, 334 insertions(+), 21 deletions(-)
create mode 100755 t/t4141-apply-icase.sh
base-commit: 1e59178e3f65880188caedb965e70db5ceeb2d64
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1257%2FTaoK%2Ftao-apply-case-insensitive-renames-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1257/TaoK/tao-apply-case-insensitive-renames-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/1257
Range-diff vs v1:
1: b8bd612aa1e ! 1: efd3bd4cdda apply: support case-only renames in case-insensitive filesystems
@@
## Metadata ##
-Author: Tao Klerks <tao@klerks.biz>
+Author: Junio C Hamano <gitster@pobox.com>
## Commit message ##
- apply: support case-only renames in case-insensitive filesystems
+ t4141: test "git apply" with core.ignorecase
- "git apply" checks, when validating a patch, to ensure that any files
- being added aren't already in the worktree.
+ Signed-off-by: Junio C Hamano <gitster@pobox.com>
- When this check runs on a case-only rename, in a case-insensitive
- filesystem, this leads to a false positive - the command fails with an
- error like:
- error: File1: already exists in working directory
-
- Fix this existence check to allow the file to exist, for a case-only
- rename when config core.ignorecase is set.
-
- Also add a test for this case, while verifying that conflicting file
- conditions are still caught correctly, including case-only conflicts on
- case-sensitive filesystems.
-
- Signed-off-by: Tao Klerks <tao@klerks.biz>
-
- ## apply.c ##
-@@ apply.c: static int check_patch(struct apply_state *state, struct patch *patch)
- if ((tpatch = in_fn_table(state, new_name)) &&
- (was_deleted(tpatch) || to_be_deleted(tpatch)))
- ok_if_exists = 1;
-+ else if (ignore_case && !strcasecmp(old_name, new_name))
-+ ok_if_exists = 1;
- else
- ok_if_exists = 0;
-
-
- ## t/t4141-apply-case-insensitive-rename.sh (new) ##
+ ## t/t4141-apply-icase.sh (new) ##
@@
+#!/bin/sh
+
-+test_description='git apply should handle case-only renames on case-insensitive filesystems'
++test_description='git apply with core.ignorecase'
+
-+TEST_PASSES_SANITIZE_LEAK=true
+. ./test-lib.sh
+
-+# Please note, this test assumes that core.ignorecase is set appropriately for the filesystem,
-+# as tested in t0050. Case-only rename conflicts are only tested in case-sensitive filesystems.
++test_expect_success setup '
++ # initial commit has file0 only
++ test_commit "initial" file0 "initial commit with file0" initial &&
+
-+if ! test_have_prereq CASE_INSENSITIVE_FS
-+then
-+ test_set_prereq CASE_SENSITIVE_FS
-+ echo nuts
-+fi
++ # current commit has file1 as well
++ test_commit "current" file1 "initial content of file1" current &&
++ file0blob=$(git rev-parse :file0) &&
++ file1blob=$(git rev-parse :file1) &&
+
-+test_expect_success setup '
-+ echo "This is some content in the file." > file1 &&
-+ echo "A completely different file." > file2 &&
-+ git update-index --add file1 &&
-+ git update-index --add file2 &&
-+ cat >case_only_rename_patch <<-\EOF
-+ diff --git a/file1 b/File1
-+ similarity index 100%
-+ rename from file1
-+ rename to File1
-+ EOF
++ # prepare sample patches
++ # file0 is modified
++ echo modification to file0 >file0 &&
++ git add file0 &&
++ modifiedfile0blob=$(git rev-parse :file0) &&
++
++ # file1 is removed and then ...
++ git rm --cached file1 &&
++ # ... identical copies are placed at File1 and file2
++ git update-index --add --cacheinfo 100644,$file1blob,file2 &&
++ git update-index --add --cacheinfo 100644,$file1blob,File1 &&
++
++ # then various patches to do basic things
++ git diff HEAD^ HEAD -- file1 >creation-patch &&
++ git diff HEAD HEAD^ -- file1 >deletion-patch &&
++ git diff --cached HEAD -- file1 file2 >rename-file1-to-file2-patch &&
++ git diff --cached HEAD -- file1 File1 >rename-file1-to-File1-patch &&
++ git diff --cached HEAD -- file0 >modify-file0-patch
+'
+
-+test_expect_success 'refuse to apply rename patch with conflict' '
-+ cat >conflict_patch <<-\EOF &&
-+ diff --git a/file1 b/file2
-+ similarity index 100%
-+ rename from file1
-+ rename to file2
-+ EOF
-+ test_must_fail git apply --index conflict_patch
++# Basic creation, deletion, modification and renaming.
++test_expect_success 'creation and deletion' '
++ # start at "initial" with file0 only
++ git reset --hard initial &&
++
++ # add file1
++ git -c core.ignorecase=false apply --cached creation-patch &&
++ test_cmp_rev :file1 "$file1blob" &&
++
++ # remove file1
++ git -c core.ignorecase=false apply --cached deletion-patch &&
++ test_must_fail git rev-parse --verify :file1 &&
++
++ # do the same with ignorecase
++ git -c core.ignorecase=true apply --cached creation-patch &&
++ test_cmp_rev :file1 "$file1blob" &&
++ git -c core.ignorecase=true apply --cached deletion-patch &&
++ test_must_fail git rev-parse --verify :file1
+'
+
-+test_expect_success CASE_SENSITIVE_FS 'refuse to apply case-only rename patch with conflict, in case-sensitive FS' '
-+ test_when_finished "git mv File1 file2" &&
-+ git mv file2 File1 &&
-+ test_must_fail git apply --index case_only_rename_patch
++test_expect_success 'modificaiton' '
++ # start at "initial" with file0 only
++ git reset --hard initial &&
++
++ # modify file0
++ git -c core.ignorecase=false apply --cached modify-file0-patch &&
++ test_cmp_rev :file0 "$modifiedfile0blob" &&
++ git -c core.ignorecase=false apply --cached -R modify-file0-patch &&
++ test_cmp_rev :file0 "$file0blob" &&
++
++ # do the same with ignorecase
++ git -c core.ignorecase=true apply --cached modify-file0-patch &&
++ test_cmp_rev :file0 "$modifiedfile0blob" &&
++ git -c core.ignorecase=true apply --cached -R modify-file0-patch &&
++ test_cmp_rev :file0 "$file0blob"
++'
++
++test_expect_success 'rename file1 to file2' '
++ # start from file0 and file1
++ git reset --hard current &&
++
++ # rename file1 to file2
++ git -c core.ignorecase=false apply --cached rename-file1-to-file2-patch &&
++ test_must_fail git rev-parse --verify :file1 &&
++ test_cmp_rev :file2 "$file1blob" &&
++ git -c core.ignorecase=false apply --cached -R rename-file1-to-file2-patch &&
++ test_must_fail git rev-parse --verify :file2 &&
++ test_cmp_rev :file1 "$file1blob" &&
++
++ # do the same with ignorecase
++ git -c core.ignorecase=true apply --cached rename-file1-to-file2-patch &&
++ test_must_fail git rev-parse --verify :file1 &&
++ test_cmp_rev :file2 "$file1blob" &&
++ git -c core.ignorecase=true apply --cached -R rename-file1-to-file2-patch &&
++ test_must_fail git rev-parse --verify :file2 &&
++ test_cmp_rev :file1 "$file1blob"
++'
++
++test_expect_success 'rename file1 to file2' '
++ # start from file0 and file1
++ git reset --hard current &&
++
++ # rename file1 to File1
++ git -c core.ignorecase=false apply --cached rename-file1-to-File1-patch &&
++ test_must_fail git rev-parse --verify :file1 &&
++ test_cmp_rev :File1 "$file1blob" &&
++ git -c core.ignorecase=false apply --cached -R rename-file1-to-File1-patch &&
++ test_must_fail git rev-parse --verify :File1 &&
++ test_cmp_rev :file1 "$file1blob" &&
++
++ # do the same with ignorecase
++ git -c core.ignorecase=true apply --cached rename-file1-to-File1-patch &&
++ test_must_fail git rev-parse --verify :file1 &&
++ test_cmp_rev :File1 "$file1blob" &&
++ git -c core.ignorecase=true apply --cached -R rename-file1-to-File1-patch &&
++ test_must_fail git rev-parse --verify :File1 &&
++ test_cmp_rev :file1 "$file1blob"
++'
++
++# We may want to add tests with working tree here, without "--cached" and
++# with and without "--index" here. For example, should modify-file0-patch
++# apply cleanly if we have File0 with $file0blob in the index and the working
++# tree if core.icase is set?
++
++test_expect_success CASE_INSENSITIVE_FS 'a test only for icase fs' '
++ : sample
+'
+
-+test_expect_success 'apply case-only rename patch without conflict' '
-+ git apply --index case_only_rename_patch
++test_expect_success !CASE_INSENSITIVE_FS 'a test only for !icase fs' '
++ : sample
+'
+
+test_done
-: ----------- > 2: 1226fbd3caf reset: new failing test for reset of case-insensitive duplicate in index
-: ----------- > 3: 04d83283716 apply: support case-only renames in case-insensitive filesystems
--
gitgitgadget
^ permalink raw reply [relevance 6%]
* Re: [PATCH v4 0/1] receive-pack: optionally deny case clone refs
@ 2014-06-18 11:33 6% ` Michael Haggerty
0 siblings, 0 replies; 200+ results
From: Michael Haggerty @ 2014-06-18 11:33 UTC (permalink / raw)
To: Junio C Hamano, Ronnie Sahlberg
Cc: David Turner, git@vger.kernel.org, Jonathan Nieder
On 06/13/2014 11:25 PM, Junio C Hamano wrote:
> Ronnie Sahlberg <sahlberg@google.com> writes:
>
>> It gets even more hairy :
>> If the server has A/a and a/b and you clone it it becomes A/a and A/b
>> locally. Then you push back to the server and you end up with three
>> refs on the server: A/a A/b and a/b.
>
> That is part of the transition in deployment. David who wants to
> forbid A/a and a/b mixed in his project will surely correct the
> situation at the server end so "somebody fetches A/a and a/b and
> ends up with A/a and A/b" will not happen. They will fetch A/a and
> A/b.
>
> If a user is with an older Git and he has his own a/c, fetching A/a
> and A/b from a corrected central repository will still give the user
> a/a and a/b, but then pushing it back will be forbidden. The user's
> repository needs to be fixed and installation of Git needs to be
> updated to the version with an equivalent of David's "optionally
> deny" feature implemented for the fetching side, so that the user
> notices the local a/c is bad and not allowed within the context of
> his project, deletes it and recreates it as A/c before he can fetch
> A/a and A/b from the central repository.
>
> I agree that the transition may be painful, but as long as the
> desired semantics is "If you have A/a, you are not allowed to have
> a/a or a/b", it cannot be avoided---in that sense, I view it as a
> lower priority issue.
>
> Having said that, it may indicate that the desired semantics above
> may not be the optimal one. Perhaps the flag might want to be "on
> this platform, we cannot do case sensitive refs, so pretend as if
> all refs are lowercase" instead. I suspect that such a flag may
> allow smoother transition than what has been proposed.
>
> Underlying refs "A/a" and "a/b" can stay as they are in David's
> central repository, but ref enumeration with the flag enabled will
> return a/a and a/b, and these are the names that will be fetched by
> the users. If the user had an existing A/c, then fetching these
> will still create A/a and A/b locally, but pushing them back will,
> under that flag enabled, be turned into updates to a/a, a/b, and a/c
> on the central server side with updated Git.
The discussion here has made it pretty clear that, given our current
loose reference and reflog storage schemes, it is not possible to
implement case-sensitive references or even case-insensitive but
case-preserving references correctly on a non-case-sensitive filesystem.
We would always have spooky non-local conflicts like A/a vs. a/b.
I think we *could* correctly implement
* case-folded reference names (e.g., all lower-case; I wonder if
that would also apply to HEAD etc.?)
* case-folded reference names except for the last component, which
could be case-insensitive but case-preserving:
refs/heads/MyCrazyBranch. I suppose that many mixed-OS projects
effectively use this policy nowadays and that is why we don't hear
more complaints about this Git deficiency.
If we had an option to use only packed references in a repository, I
think we could also implement case-insensitive but case-preserving
references on a non-case-preserving filesystem. The packed-refs file
would be authoritative WRT case, and the case of the reflog directories
and files would be ignored. But I would be nervous about promoting this
style, because it will likely cause performance problems for repos that
have a lot of refs.
To support arbitrary refname policies on arbitrary filesystems, we of
course need a different way of storing references and reflogs.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply [relevance 6%]
* Re: [PATCH 0/4] Honor core.ignorecase for attribute patterns
@ 2011-09-15 18:12 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2011-09-15 18:12 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, gitster, sunshine, bharrosh, trast, zapped
On Wed, Sep 14, 2011 at 08:59:35PM -0500, Brandon Casey wrote:
> > I haven't even tested that it runs. :) No, I was hoping someone
> > who was more interested would finish it, and maybe even test on
> > an affected system.
>
> Ok, I lied. Here's a series that needs testing by people on a
> case-insensitive filesystem and some comments.
Thanks. I was trying to decide if I was interested enough to work on it,
but procrastination wins again.
I'm not sure I understand why you need a case-insensitive file system
for the final set of tests. If we have a case-sensitive system, we can
force the filesystem to show us whatever cases we want, and check
against them with both core.ignorecase off and on[1]. What are these
tests checking that requires the actual behavior of a case-insensitive
filesystem?
I'm sure there is something subtle that I'm missing. Can you explain it
either here or in the commit message?
-Peff
[1] Actually, I wondered at first if the other tests needed to be marked
for only case-sensitive systems, since we can't rely on the behavior of
insensitive ones (e.g., are they case-preserving, always downcasing,
etc). But looking at t0003, we don't seem to actually create the files
in the filesystem at all.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 1/1] sparse-checkout: respect core.ignoreCase in cone mode
@ 2019-12-11 19:11 6% ` Derrick Stolee
0 siblings, 0 replies; 200+ results
From: Derrick Stolee @ 2019-12-11 19:11 UTC (permalink / raw)
To: Junio C Hamano, Derrick Stolee via GitGitGadget
Cc: git, szeder.dev, newren, Derrick Stolee
On 12/11/2019 1:44 PM, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> Another option would be to do case-insensitive checks while
>> updating the skip-worktree bits during unpack_trees(). Outside of
>> the potential performance loss on a more expensive code path, that
>> also breaks compatibility with older versions of Git as using the
>> same sparse-checkout file would change the paths that are included.
>
> I haven't thought things through, but that sounds as if saying that
> we cannot fix old bugs. We use the entries in the index as a hint
> for "correcting" a path to the right case on a case-insensitive
> filesystem to avoid corrupting the case in the index, which is case
> sensitive and is a way to convey the intended case (by writing them
> out to a tree object) to those who use systems that can reliably
> reproduce cases in pathnames. But that still does not mean on a
> case-insensitive filesystem, "hello.c" in the "right" case recorded
> in the index will always be spelled like so---somebody can make
> readdir() or equivalent to yield "Hello.c" for it, and if the user
> tells us to say they want to do X (e.g. ignore, skip checkout, etc.)
> to "hello.c", we should do the same to "Hello.c" on such a system, I
> would think.
>
> If the runtime needs to deal with the case insensitive filesystems
> anyway (and I suspect it does), there isn't much point matching and
> forcing the case to the paths in the index like this patch does, I
> think. So...
I'm trying to find a way around these two ideas:
1. The index is case-sensitive, and the sparse-checkout patterns are
case-sensitive.
2. If a filesystem is case-insensitive, most index-change operations
already succeed with incorrect case, especially with core.ignoreCase
enabled.
The approach I have is to allow a user to provide a case that does not
match the index, and then we store the pattern in the sparse-checkout
that matches the case in the index.
Another approach would be to make the sparse-checkout patterns be
case-insensitive when core.ignoreCase is enabled. I chose against
this due to the compatibility and the performance cost. We would
likely pay that performance penalty even if all the patterns have
the correct case. It violates the existing "contract" with the
sparse-checkout file, and that is probably what you are talking about
with "we cannot fix old bugs".
It sounds like you are preferring this second option, despite the
performance costs. It is possible to use a case-insensitive hashing
algorithm when in the cone mode, but I'm not sure about how to do
a similar concept for the normal mode.
Thanks,
-Stolee
^ permalink raw reply [relevance 6%]
* Re: [PATCH] rev-parse: match @{u}, @{push} and ^{<type>} case-insensitively
@ 2017-03-19 10:04 6% ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2017-03-19 10:04 UTC (permalink / raw)
To: Duy Nguyen
Cc: Git Mailing List, Junio C Hamano, Conrad Irwin, Sitaram Chamarty,
Michael J Gruber, Jeff King, Richard Hansen, Brian M . Carlson
On Sun, Mar 19, 2017 at 10:19 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Sun, Mar 19, 2017 at 5:34 AM, Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
>> index ba11b9c95e..55bde6ea65 100644
>> --- a/Documentation/revisions.txt
>> +++ b/Documentation/revisions.txt
>> @@ -96,7 +96,8 @@ some output processing may assume ref names in UTF-8.
>> refers to the branch that the branch specified by branchname is set to build on
>> top of (configured with `branch.<name>.remote` and
>> `branch.<name>.merge`). A missing branchname defaults to the
>> - current one.
>> + current one. Both '@\{upstream\}', '@\{u\}' are case-insensitive, so e.g.
>> + '@\{UPSTREAM\}', '@\{U\}' or '@\{Upstream\}' also work.
>
> Since this change makes @{everything} case-insensitive and there's no
> new one on the horizon, can we just say "everything in @{..} is
> case-insensitive unless otherwise specified" and not updating every
> @{case}? It sets a new common rule for these @{}, which I think is
> good (easier to remember as a user).
I have a slight bias to keeping it the way it is, just because of the
distracted user in a hurry use-case that's looking up only @{u} and
not reading the manpage all the way through.
But yeah, I could do that, i.e. have some blurb at the top noting that
all of the magical syntax is case insensitive unless otherwise noted.
AFAICT the only thing that's case sensitive now is the ^{/regex} form.
Also an advantage of that would be that currently we don't note that
e.g. sha1s like dae86e aren't case sensitive and can be written like
DAE86E, and the @{<date>} syntax doesn't note that it's case
insensitive. A blurb at the top would cover that.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 3/4] t0050: Set core.ignorecase case to activate case insensitivity
@ 2008-05-11 17:10 6% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2008-05-11 17:10 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git
On Sun, 11 May 2008, Steffen Prohaska wrote:
>
> Case insensitive file handling is only active when
> core.ignorecase = true. Hence, we need to set it to give the tests
> in t0050 a chance to succeed. Setting core.ignorecase explicitly
> allows to test some aspects of case handling even on case sensitive file
> systems.
The patch series looks fine to me, but I just wanted to underline the use
of that "*some*aspects*" part.
On a filesystem that is case sensitive, doing "core.ignorecase = true"
doesn't magically make git act as if the filesystem was insensitive to
case. In particular, since the filesystem very much can contain two
different versions of a filename in different case, git will actually
notice that, and notice that "CamelCase" and "camelcase" are not
necessarily the same file.
To emulate case insensitivity on filesyststems that are actually
sensitive, we could do some tests that do things like
echo Hello > CamelCase
ln CamelCase camelcase
and now git will see something that is *closer* to a real case-insensitive
filesystem: two names that resolve to the same stat information.
It's still obviously not identical (because "readdir()" will get two
entries), and as such a test that succeeds in a true case-insensitive
environment will not necessarily work in the above fake kind of situation,
but at least you can test some cases.
Renaming the same file to a case that is different is also a worthwhile
thing to try to "emulate" case insensitivity.
Linus
^ permalink raw reply [relevance 6%]
* Re: [PATCH] apply: support case-only renames in case-insensitive filesystems
2022-06-14 5:13 6% ` Tao Klerks
@ 2022-06-18 0:45 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2022-06-18 0:45 UTC (permalink / raw)
To: Tao Klerks; +Cc: Tao Klerks via GitGitGadget, git
Tao Klerks <tao@klerks.biz> writes:
>> We need a new test or two to see if a straight creation or deletion
>> patch does work correctly with icase set, before we even dream of
>> handling rename patches. Not having tests for such basic cases is
>> quite surprising, but apparently the above line passed the CI.
>
> This is where I made some very bad assumptions: I only manually ran
> the new "t4141-apply-case-insensitive-rename.sh" test, and assumed
> that the test suite ran against linux, windows, and OSX, with the
> latter two running on case-insensitive filesystems. I assumed that
> both case-sensitive and case-insensitive code paths would be tested by
> the complete CI suite.
Apparently we were surprised the same way ;-)
> *Do* we expect to run the full test suite on case-insensitive systems
> in gitlab, or do we expect to need to add explicit "-C
> core.ignorecase" tests as you have done here?
Running all tests on case-insensitive systems and expect them to
pass is reasonable; we need to sprinkle !CASE_INSENSITIVE_FS
prerequiste to skip certain tests that exercise functionalities that
case insensitive filesystem will never be able to support (e.g. you
cannot by their design have file1.txt and File1.txt at the same time
on the filesystem, so any test with "test_cmp file1.txt FIle1.txt"
must be marked with !CASE_INSENSITIVE_FS prerequisite).
When the system I am primary owrking on is case sensitive, it is
always nice to be able to discover that I broke something on case
INsensitive system before I conclude my WIP into a commit and throw
it at CI. We may have to case-insensitively treat the paths in the
index in order to match what the working tree would do to make "git
checkout -- <path>" work case-insentively, and doing in-index-only
mode of operation with core.ignorecase=yes on case-sensitive system
may be a way to "emulate" some of the requirement case-insentive
systems have with these "-c core.ignorecase" trick, but of course
not all scenarios can be tested without being on case-insensitive
systems.
So we need both, I think.
^ permalink raw reply [relevance 6%]
* Re: Files that cannot be added to the index
@ 2011-08-27 15:35 6% ` seanh
0 siblings, 0 replies; 200+ results
From: seanh @ 2011-08-27 15:35 UTC (permalink / raw)
To: Shaun Ruffell; +Cc: git
On Fri, Aug 26, 2011 at 04:12:33PM -0500, Shaun Ruffell wrote:
> Not sure if this is your problem exactly but awhile back I ran into
> something similar to what you describe and tracked it down to the
> fact that my filesystem was case insensitive. i.e.
My filesystem (HFS+ on OSX Lion) is case-insensitive, yeah. I bet you're
right, because in one repo the modified file shows up in `git status` as
LOG.txt but in the output from `ls` it is called `Log.txt`. It's the
same in the other repo that has the problem, the case of the filename
that is having the problem is different in `git status` and `ls`.
Perhaps the problem might have been introduced by moving the repo from a
case-sensitive to an insensitive filesystem? Or by originally starting
the repo on a sensitive fs and then using git clone to clone it onto an
insensitive one. Or, maybe at some point I committed a change to the
case of the filename and that introduced a problem on case-insenstive
filesystems.
Did you find a way around the problem? I guess that the repo does not
really have any uncommitted changes, so I just want to convince `git
status` and `git diff` of this.
^ permalink raw reply [relevance 6%]
* [PATCH 0/3] Resending sb/config-write-fix
@ 2018-08-08 19:50 6% Stefan Beller
2018-08-08 19:50 20% ` [PATCH 2/3] config: fix case sensitive subsection names on writing Stefan Beller
2018-08-08 19:50 7% ` [PATCH 1/3] t1300: document current behavior of setting options Stefan Beller
0 siblings, 2 replies; 200+ results
From: Stefan Beller @ 2018-08-08 19:50 UTC (permalink / raw)
To: gitster; +Cc: git, Stefan Beller
This is a resend of sb/config-write-fix, with a slightly
better commit message and a renamed variable.
Thanks,
Stefan
Stefan Beller (3):
t1300: document current behavior of setting options
config: fix case sensitive subsection names on writing
git-config: document accidental multi-line setting in deprecated
syntax
Documentation/git-config.txt | 21 +++++++++
config.c | 12 ++++-
t/t1300-config.sh | 87 ++++++++++++++++++++++++++++++++++++
3 files changed, 119 insertions(+), 1 deletion(-)
./git-range-diff origin/sb/config-write-fix...HEAD >>0000-cover-letter.patch
2.18.0.597.ga71716f1ad-goog
1: 999d9026272 ! 1: e40f57f3da1 t1300: document current behavior of setting options
@@ -7,7 +7,6 @@
for the follow up that will fix some issues with the current behavior.
Signed-off-by: Stefan Beller <sbeller@google.com>
- Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
--- a/t/t1300-config.sh
2: c667e555066 ! 2: f01cb1d9dae config: fix case sensitive subsection names on writing
@@ -2,8 +2,8 @@
config: fix case sensitive subsection names on writing
- A use reported a submodule issue regarding strange case indentation
- issues, but it could be boiled down to the following test case:
+ A user reported a submodule issue regarding a section mix-up,
+ but it could be boiled down to the following test case:
$ git init test && cd test
$ git config foo."Bar".key test
@@ -32,7 +32,6 @@
Reported-by: JP Sugarbroad <jpsugar@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
- Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --git a/config.c b/config.c
--- a/config.c
@@ -41,7 +40,7 @@
int eof;
struct strbuf value;
struct strbuf var;
-+ unsigned section_name_old_dot_style : 1;
++ unsigned subsection_case_sensitive : 1;
int (*do_fgetc)(struct config_source *c);
int (*do_ungetc)(int c, struct config_source *conf);
@@ -49,7 +48,7 @@
static int get_extended_base_var(struct strbuf *name, int c)
{
-+ cf->section_name_old_dot_style = 0;
++ cf->subsection_case_sensitive = 0;
do {
if (c == '\n')
goto error_incomplete_line;
@@ -57,7 +56,7 @@
static int get_base_var(struct strbuf *name)
{
-+ cf->section_name_old_dot_style = 1;
++ cf->subsection_case_sensitive = 1;
for (;;) {
int c = get_next_char();
if (cf->eof)
@@ -70,7 +69,7 @@
if (cf->var.len < 2 || cf->var.buf[cf->var.len - 1] != '.')
return error("invalid section name '%s'", cf->var.buf);
-+ if (cf->section_name_old_dot_style)
++ if (cf->subsection_case_sensitive)
+ cmpfn = strncasecmp;
+ else
+ cmpfn = strncmp;
3: 6749bb283a8 ! 3: 6b5ad773490 git-config: document accidental multi-line setting in deprecated syntax
@@ -29,7 +29,6 @@
spend time on fixing the behavior and just document it instead.
Signed-off-by: Stefan Beller <sbeller@google.com>
- Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
--- a/Documentation/git-config.txt
^ permalink raw reply [relevance 6%]
* Re: how to revert changes in working tree?
@ 2006-12-06 18:13 6% ` Shawn Pearce
0 siblings, 0 replies; 200+ results
From: Shawn Pearce @ 2006-12-06 18:13 UTC (permalink / raw)
To: Liu Yubao; +Cc: Alex Riesen, git
Liu Yubao <yubao.liu@gmail.com> wrote:
> $ git merge "sync from origin" HEAD origin
> Updating 088406b..ff51a98
> include/linux/netfilter/xt_CONNMARK.h: needs update
> include/linux/netfilter/xt_DSCP.h: needs update
> include/linux/netfilter/xt_MARK.h: needs update
> include/linux/netfilter_ipv4/ipt_CONNMARK.h: needs update
> include/linux/netfilter_ipv4/ipt_DSCP.h: needs update
> include/linux/netfilter_ipv4/ipt_ECN.h: needs update
> include/linux/netfilter_ipv4/ipt_MARK.h: needs update
> include/linux/netfilter_ipv4/ipt_TCPMSS.h: needs update
> include/linux/netfilter_ipv4/ipt_TOS.h: needs update
> include/linux/netfilter_ipv4/ipt_TTL.h: needs update
> include/linux/netfilter_ipv6/ip6t_HL.h: needs update
> include/linux/netfilter_ipv6/ip6t_MARK.h: needs update
> net/ipv4/netfilter/ipt_ECN.c: needs update
> net/ipv4/netfilter/ipt_TOS.c: needs update
> net/ipv4/netfilter/ipt_TTL.c: needs update
> net/ipv6/netfilter/ip6t_HL.c: needs update
> net/netfilter/xt_CONNMARK.c: needs update
> net/netfilter/xt_DSCP.c: needs update
> net/netfilter/xt_MARK.c: needs update
> fatal: Entry 'net/ipv4/netfilter/ipt_ECN.c' not uptodate. Cannot merge.
>
> I really have never modified these files manually.
You are just *very unlucky*. :-)
The Linux kernel has case sensitive file names. In other words there
are two files in the kernel:
net/netfilter/xt_MARK.c
net/netfilter/xt_mark.c
and they have different content! On NTFS or FAT, where filenames
are not case sensitive, these become the same file. So Git now
starts to think that the file was modified, because one of those
files overwrote the other when they were checked out.
Moral of the story: You cannot work with the linux.git repository
on a case insensitive filesystem, like NTFS, FAT (Windows), or HFS+
(Mac OS X).
--
^ permalink raw reply [relevance 6%]
* Re: [BUG] git-filter-branch and filename case changes on insensitive file systems
@ 2007-10-10 13:49 6% ` Jonathan del Strother
0 siblings, 0 replies; 200+ results
From: Jonathan del Strother @ 2007-10-10 13:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
On 10 Oct 2007, at 14:39, Johannes Schindelin wrote:
> On Wed, 10 Oct 2007, Jonathan del Strother wrote:
>
>> My repo has a change where a directory named Src was renamed to src.
>
> That is no problem for git-filter-branch.
>
>> I'm using case insensitive HFS+.
>
> That is the problem.
...
> I vote for wont-fix (or more accurately "invalid") in git and
> please-fix-in-your-setup.
Would love to switch to case sensitive HFS+, but it causes a number of
problems for OS X users - a number of 3rd party applications don't
bother supporting case sensitive formatting (notably Adobe :/ ).
I appreciate that it's difficult and/or impossible to make certain
operations work on case insensitive FS's, but it seems like git ought
to at least complain noisily when it encounters such a situation...
^ permalink raw reply [relevance 6%]
* Re: Re-casing directories on case-insensitive systems
@ 2008-01-11 23:12 6% ` Kevin Ballard
0 siblings, 0 replies; 200+ results
From: Kevin Ballard @ 2008-01-11 23:12 UTC (permalink / raw)
To: David Kastrup; +Cc: Linus Torvalds, Johannes Schindelin, git
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]
On Jan 11, 2008, at 6:10 PM, David Kastrup wrote:
>> But considering that they exist, we should probably offer at least
>> *some* help for people who didn't realize that you could make OS X
>> behave better.
>
> It is not like Linux does not support some case-insensitive file
> system
> types, too. So the same problems can be had there as well.
In addition, while there is an option for HFS+ Case-Sensitive, using
that can cause bad things to happen as Mac OS X programs are written
under a case-insensitive assumption and may behave badly when
presented with a case-sensitive filesystem.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2432 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Modified files directly after clone
@ 2010-03-09 21:59 6% ` Tarmigan
0 siblings, 0 replies; 200+ results
From: Tarmigan @ 2010-03-09 21:59 UTC (permalink / raw)
To: Benedikt Andreas Koeppel; +Cc: git
On Tue, Mar 9, 2010 at 12:26 PM, Benedikt Andreas Koeppel
> How can this happen? Does my Mac somehow interfere with
> the newly cloned repository?
By default HFS+ filesystems on OSX are case insensitive so you see
problems like you described with the linux kernel source which has
different files named xt_TCPMSS.c and xt_tcpmss.c.
HFS+ partitions can be case sensitive, but are not by default. Unlike
some earlier versions, OSX 10.6 can boot from a case sensitive HFS+
filesystem. Even if you do that, OSX (or maybe HFS+) still has issues
with unicode normalization described in the archive, but I haven't had
a problem with the normalization in practice.
Thanks,
Tarmigan
^ permalink raw reply [relevance 6%]
* Re: Does changing filename case breaks git's rename heuristic?
@ 2010-08-27 16:22 6% ` Stephen Bash
0 siblings, 0 replies; 200+ results
From: Stephen Bash @ 2010-08-27 16:22 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Dan Loewenherz
> > I'm using a Mac with a journaled filesystem and Git version 1.7.2.1.
>
> The journalling is no problem, but HFS is. I'm no Macxpert but if I
> remember correctly, then under HFS "readme" and "README" are the same
> file, i.e. HFS only remembers how you want it spelled. People will
> correct me where I'm wrong.
>
> Your test script should produce the expected result if you use, say,
> "readme" and "RAEDME" , i.e. names which differ by more than just
> case.
It's a problem on some (most?) Macs. A while back Apple introduced an option to format a partition as case sensitive (Wikipedia implies 10.3 introduced this feature). For a long time after the feature was introduced the factory install continued to be not case sensitive, but I don't know if that's still the case (no pun intended).
Stephen
^ permalink raw reply [relevance 6%]
* Re: [PATCH] config: introduce an Operating System-specific `includeIf` condition
@ 2022-11-21 15:51 6% ` Phillip Wood
0 siblings, 0 replies; 200+ results
From: Phillip Wood @ 2022-11-21 15:51 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason,
Johannes Schindelin via GitGitGadget
Cc: git, Johannes Schindelin
Hi Dscho and Ævar
On 21/11/2022 13:51, Ævar Arnfjörð Bjarmason wrote:
>
> On Mon, Nov 21 2022, Johannes Schindelin via GitGitGadget wrote:
>
>> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>>
>> It is relatively common for users to maintain identical `~/.gitconfig`
>> files across all of their setups, using the `includeIf` construct
>> liberally to adjust the settings to the respective setup as needed.
>>
>> In case of Operating System-specific adjustments, Git currently offers
>> no support to the users and they typically use a work-around like this:
>>
>> [includeIf "gitdir:/home/"]
>> path = ~/.gitconfig-linux
>> [includeIf "gitdir:/Users/"]
>> path = ~/.gitconfig-mac
>> [includeIf "gitdir:C:"]
>> path = ~/.gitconfig-windows
>>
>> However, this is fragile, as it would not even allow to discern between
>> Operating Systems that happen to host their home directories in
>> `/home/`, such as Linux and the BSDs.
>
> This looks like a really sensible thing to do, thanks.
Yes, it looks like a really useful enhancement
>> +`os`::
>> + The data that follows this keyword is taken as the name of an
>> + Operating System; If it matches the output of `uname -s`, the
Maybe add e.g. "Windows or Linux" after Operating System?
>> +static int include_by_os(const char *cond, size_t cond_len)
>> +{
>> + struct utsname uname_info;
>> +
>> + return !uname(&uname_info) &&
>> + !strncasecmp(uname_info.sysname, cond, cond_len) &&
>
> Our config.mak.uname doesn't to case-insensitive uname matching, and
> AFAIK these don't change between platforms versions. So why do we need
> to support LINUX, LiNuX etc. in addition to the canonical Linux?
>
> I'm not opposed to it if there's a good reason, but as we have "gitdir"
> and "gitdir/i" shouldn't we make that "os/i" for consistency, if it's
> needed?
Why should we penalize users who write "linux" rather than "Linux"?
Making the comparison case insensitive seems eminently sensible. File
systems can be case sensitive so having the option to specify whether a
match for "gitdir" is case sensitive or not makes sense there but not
for the name of an operating system.
Best Wishes
Phillip
^ permalink raw reply [relevance 6%]
* Re: What's cooking in git.git (topics)
@ 2008-05-15 5:51 6% ` Steffen Prohaska
0 siblings, 0 replies; 200+ results
From: Steffen Prohaska @ 2008-05-15 5:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, 14 May 2008, Junio C Hamano wrote:
>
> For 1.5.6.
>
> * sp/ignorecase (Sun May 11 18:16:42 2008 +0200) 4 commits
> - t0050: Add test for case insensitive add
> - t0050: Set core.ignorecase case to activate case insensitivity
> - t0050: Test autodetect core.ignorecase
> - git-init: autodetect core.ignorecase
>
> This unfortunately seems to break on natively case sensitive filesystems.
>From 92ec8c8a12cdc45a69f6612af340a8ce50976ab1 Mon Sep 17 00:00:00 2001
From: Steffen Prohaska <prohaska@zib.de>
Date: Thu, 15 May 2008 07:19:54 +0200
Subject: [PATCH] t0050: Fix merge test on case sensitive file systems
On a case sensitive filesystem, "git reset --hard" might refuse to
overwrite a file whose name differs only by case, even if
core.ignorecase is set. It is not clear which circumstances cause this
behavior. This commit simply works around the problem by removing
the case changing file before running "git reset --hard".
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
t/t0050-filesystem.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index 0e33c4b..c5360e2 100755
--- a/t/t0050-filesystem.sh
+++ b/t/t0050-filesystem.sh
@@ -72,6 +72,8 @@ $test_case 'rename (case change)' '
$test_case 'merge (case change)' '
+ rm -f CamelCase &&
+ rm -f camelcase &&
git reset --hard initial &&
git merge topic
--
1.5.5.1.349.g99d0
^ permalink raw reply related [relevance 6%]
* Re: Commit graph chains with no corresponding files?
@ 2020-06-30 1:51 6% ` Derrick Stolee
0 siblings, 0 replies; 200+ results
From: Derrick Stolee @ 2020-06-30 1:51 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git
On 6/29/2020 6:07 PM, Jonathan Tan wrote:
> At $DAYJOB, a few people have reported "warning: unable to find all
> commit-graph files" warnings. Their commit-graph-chain files have a few
> lines, but they only have one commit graph file with very few commits. I
> suspected something happening during fetch, because (as far as I know) a
> fetch may cause an incremental commit graph to be written, but I ran a
> fetch on a large repository myself and didn't run into this problem.
>
> Has anyone ran into this problem before, and know how to reproduce?
The incremental commit-graph code deletes any commit-graph files
that do not appear in the chain. I believe this is done by comparing
the contents of the ".git/objects/info/commit-graphs/" directory to
the contents of the chain file.
These appear to be case-sensitive, full-path comparisons.
It is _possible_ that something like a case switch or a symlink
could be causing a problem here. That's where I would look on
the affected systems.
Likely the full-path comparison in expire_commit_graphs() should
be dropped in favor of local filename comparisons. A case-
sensitive match is less likely to be important here since Git
is writing the paths itself and should get the proper case back
from the directory listing.
Thanks,
-Stolee
^ permalink raw reply [relevance 6%]
* Re: [PATCH] fast-import.c: always honor the filename case
@ 2014-02-04 0:14 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2014-02-04 0:14 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Reuben Hawkins, git, Dmitry Potapov, Joshua Jensen
Torsten Bögershausen <tboegi@web.de> writes:
> []
>> So to summarize, when fast-import uses strncmp_icase (what fast-import does now) import on a repository where ignorecase=true is wrong. My patch, "fast-import.c: always honor the filename case" fixes this. Can you verify?
>>
>> Thanks in advance,
>> Reuben
>>
> Yes, I can verify. My feeling is that
> a) the fast-export should generate the rename the other way around.
> Would that be feasable ?
> Or generate a real rename ?
> (I'm not using fast-export or import myself)
I do not think this matters. Or at least, it should not matter. As
Peff said in the nearby message, core.ignorecase is completely about
the _filesystem_, and that git should generally be case-sensitive
internally.
And fast-import is about reading internal representation of paths
and data to populate the repository, without having to guess what
pathnames were meant to be used---the guess is only needed if we
need to consult the filesystem that loses case information.
The change made by 50906e04 (Support case folding in git fast-import
when core.ignorecase=true, 2010-10-03) should probably be half
reverted by making the case-squashing an optional feature, that
could be used even on a system with case sensitive filesystems.
^ permalink raw reply [relevance 6%]
* [PATCH 2/3] t0050: honor CASE_INSENSITIVE_FS in add (with different case)
@ 2013-01-19 7:19 6% Torsten Bögershausen
0 siblings, 0 replies; 200+ results
From: Torsten Bögershausen @ 2013-01-19 7:19 UTC (permalink / raw)
To: git; +Cc: tboegi
The test case "add (with different case)" indicates a
known breakage when run on a case sensitive file system.
The test is invalid for case sensitive file system,
check the precondition CASE_INSENSITIVE_FS before running it.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
t/t0050-filesystem.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index ccd685d..a6fa3c5 100755
--- a/t/t0050-filesystem.sh
+++ b/t/t0050-filesystem.sh
@@ -88,7 +88,7 @@ test_expect_success 'merge (case change)' '
-test_expect_failure 'add (with different case)' '
+test_expect_failure CASE_INSENSITIVE_FS 'add (with different case)' '
git reset --hard initial &&
rm camelcase &&
--
1.8.0.197.g5a90748
^ permalink raw reply related [relevance 6%]
* [RFC] Case insensitive URL rewrite
@ 2015-12-11 13:45 6% Lars Schneider
0 siblings, 0 replies; 200+ results
From: Lars Schneider @ 2015-12-11 13:45 UTC (permalink / raw)
To: Git Users
Hi,
the "url.<someURL>.insteadOf" git config is case sensitive. I understand that this makes sense on case sensitive file systems. However, URLs are mostly case insensitive:
Consider this:
git clone https://GIThub.com/GIT/GIT
git clone https://github.com/git/git
Both commands will clone the same repository.
Interestingly enough this works, too:
git clone git@GIThub.com:GIT/GIT
What do you think about a flag that makes these rewrites case insensitive? E.g. with the following config flag:
[url "<actual url base>"]
insteadOf = <other url base>
ignorecase = true
Thanks,
Lars
^ permalink raw reply [relevance 6%]
* Git clone and case sensitivity
@ 2018-07-27 9:59 6% Paweł Paruzel
0 siblings, 0 replies; 200+ results
From: Paweł Paruzel @ 2018-07-27 9:59 UTC (permalink / raw)
To: git
Hi,
Lately, I have been wondering why my test files in repo are modified after I clone it. It turned out to be two files: boolStyle_t_f and boolStyle_T_F.
The system that pushed those files was case sensitive while my mac after High Sierra update had APFS which is by default case-insensitive. I highly suggest that git clone threw an exception when files are case sensitive and being cloned to a case insensitive system. This has caused problems with overriding files for test cases without any warning.
Thanks in advance.
Regards,
Pawel Paruzel
^ permalink raw reply [relevance 6%]
* [PATCH v5 07/10] wildmatch test: perform all tests under all wildmatch() modes
2018-01-30 21:21 6% ` [PATCH v5 08/10] wildmatch test: create & test files on disk in addition to in-memory Ævar Arnfjörð Bjarmason
@ 2018-01-30 21:21 6% ` Ævar Arnfjörð Bjarmason
2 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2018-01-30 21:21 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy,
Anthony Ramine, Johannes Sixt, Adam Dinwoodie,
Johannes Schindelin, Kyle J . McKay,
Ævar Arnfjörð Bjarmason
Rewrite the wildmatch() test suite so that each test now tests all
combinations of the wildmatch() WM_CASEFOLD and WM_PATHNAME flags.
Before this change some test inputs were not tested on
e.g. WM_PATHNAME. Now the function is stress tested on all possible
inputs, and for each input we declare what the result should be if the
mode is case-insensitive, or pathname matching, or case-sensitive or
not matching pathnames.
Also before this change, nothing was testing case-insensitive
non-pathname matching, so I've added that to test-wildmatch.c and made
use of it.
This yields a rather scary patch, but there are no functional changes
here, just more test coverage. Some now-redundant tests were deleted
as a result of this change, since they were now duplicating an earlier
test.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
t/helper/test-wildmatch.c | 2 +
t/t3070-wildmatch.sh | 478 ++++++++++++++++++++++------------------------
2 files changed, 228 insertions(+), 252 deletions(-)
diff --git a/t/helper/test-wildmatch.c b/t/helper/test-wildmatch.c
index 921d7b3e7e..66d33dfcfd 100644
--- a/t/helper/test-wildmatch.c
+++ b/t/helper/test-wildmatch.c
@@ -16,6 +16,8 @@ int cmd_main(int argc, const char **argv)
return !!wildmatch(argv[3], argv[2], WM_PATHNAME | WM_CASEFOLD);
else if (!strcmp(argv[1], "pathmatch"))
return !!wildmatch(argv[3], argv[2], 0);
+ else if (!strcmp(argv[1], "ipathmatch"))
+ return !!wildmatch(argv[3], argv[2], WM_CASEFOLD);
else
return 1;
}
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index fe0e5103a3..3e75cb0cbe 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -4,278 +4,252 @@ test_description='wildmatch tests'
. ./test-lib.sh
-match() {
- if test "$1" = 1
- then
- test_expect_success "wildmatch: match '$2' '$3'" "
- test-wildmatch wildmatch '$2' '$3'
- "
- elif test "$1" = 0
- then
- test_expect_success "wildmatch: no match '$2' '$3'" "
- test_must_fail test-wildmatch wildmatch '$2' '$3'
- "
- else
- test_expect_success "PANIC: Test framework error. Unknown matches value $1" 'false'
- fi
-}
+match_with_function() {
+ text=$1
+ pattern=$2
+ match_expect=$3
+ match_function=$4
-imatch() {
- if test "$1" = 1
+ if test "$match_expect" = 1
then
- test_expect_success "iwildmatch: match '$2' '$3'" "
- test-wildmatch iwildmatch '$2' '$3'
+ test_expect_success "$match_function: match '$text' '$pattern'" "
+ test-wildmatch $match_function '$text' '$pattern'
"
- elif test "$1" = 0
+ elif test "$match_expect" = 0
then
- test_expect_success "iwildmatch: no match '$2' '$3'" "
- test_must_fail test-wildmatch iwildmatch '$2' '$3'
+ test_expect_success "$match_function: no match '$text' '$pattern'" "
+ test_must_fail test-wildmatch $match_function '$text' '$pattern'
"
else
- test_expect_success "PANIC: Test framework error. Unknown matches value $1" 'false'
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_expect" 'false'
fi
+
}
-pathmatch() {
- if test "$1" = 1
- then
- test_expect_success "pathmatch: match '$2' '$3'" "
- test-wildmatch pathmatch '$2' '$3'
- "
- elif test "$1" = 0
- then
- test_expect_success "pathmatch: no match '$2' '$3'" "
- test_must_fail test-wildmatch pathmatch '$2' '$3'
- "
- else
- test_expect_success "PANIC: Test framework error. Unknown matches value $1" 'false'
- fi
+match() {
+ match_glob=$1
+ match_iglob=$2
+ match_pathmatch=$3
+ match_pathmatchi=$4
+ text=$5
+ pattern=$6
+
+ # $1: Case sensitive glob match: test-wildmatch & ls-files
+ match_with_function "$text" "$pattern" $match_glob "wildmatch"
+
+ # $2: Case insensitive glob match: test-wildmatch & ls-files
+ match_with_function "$text" "$pattern" $match_iglob "iwildmatch"
+
+ # $3: Case sensitive path match: test-wildmatch & ls-files
+ match_with_function "$text" "$pattern" $match_pathmatch "pathmatch"
+
+ # $4: Case insensitive path match: test-wildmatch & ls-files
+ match_with_function "$text" "$pattern" $match_pathmatchi "ipathmatch"
}
-# Basic wildmat features
-match 1 foo foo
-match 0 foo bar
-match 1 '' ""
-match 1 foo '???'
-match 0 foo '??'
-match 1 foo '*'
-match 1 foo 'f*'
-match 0 foo '*f'
-match 1 foo '*foo*'
-match 1 foobar '*ob*a*r*'
-match 1 aaaaaaabababab '*ab'
-match 1 'foo*' 'foo\*'
-match 0 foobar 'foo\*bar'
-match 1 'f\oo' 'f\\oo'
-match 1 ball '*[al]?'
-match 0 ten '[ten]'
-match 0 ten '**[!te]'
-match 0 ten '**[!ten]'
-match 1 ten 't[a-g]n'
-match 0 ten 't[!a-g]n'
-match 1 ton 't[!a-g]n'
-match 1 ton 't[^a-g]n'
-match 1 'a]b' 'a[]]b'
-match 1 a-b 'a[]-]b'
-match 1 'a]b' 'a[]-]b'
-match 0 aab 'a[]-]b'
-match 1 aab 'a[]a-]b'
-match 1 ']' ']'
+# Basic wildmatch features
+match 1 1 1 1 foo foo
+match 0 0 0 0 foo bar
+match 1 1 1 1 '' ""
+match 1 1 1 1 foo '???'
+match 0 0 0 0 foo '??'
+match 1 1 1 1 foo '*'
+match 1 1 1 1 foo 'f*'
+match 0 0 0 0 foo '*f'
+match 1 1 1 1 foo '*foo*'
+match 1 1 1 1 foobar '*ob*a*r*'
+match 1 1 1 1 aaaaaaabababab '*ab'
+match 1 1 1 1 'foo*' 'foo\*'
+match 0 0 0 0 foobar 'foo\*bar'
+match 1 1 1 1 'f\oo' 'f\\oo'
+match 1 1 1 1 ball '*[al]?'
+match 0 0 0 0 ten '[ten]'
+match 0 0 1 1 ten '**[!te]'
+match 0 0 0 0 ten '**[!ten]'
+match 1 1 1 1 ten 't[a-g]n'
+match 0 0 0 0 ten 't[!a-g]n'
+match 1 1 1 1 ton 't[!a-g]n'
+match 1 1 1 1 ton 't[^a-g]n'
+match 1 1 1 1 'a]b' 'a[]]b'
+match 1 1 1 1 a-b 'a[]-]b'
+match 1 1 1 1 'a]b' 'a[]-]b'
+match 0 0 0 0 aab 'a[]-]b'
+match 1 1 1 1 aab 'a[]a-]b'
+match 1 1 1 1 ']' ']'
# Extended slash-matching features
-match 0 'foo/baz/bar' 'foo*bar'
-match 0 'foo/baz/bar' 'foo**bar'
-match 0 'foobazbar' 'foo**bar'
-match 1 'foo/baz/bar' 'foo/**/bar'
-match 1 'foo/baz/bar' 'foo/**/**/bar'
-match 1 'foo/b/a/z/bar' 'foo/**/bar'
-match 1 'foo/b/a/z/bar' 'foo/**/**/bar'
-match 1 'foo/bar' 'foo/**/bar'
-match 1 'foo/bar' 'foo/**/**/bar'
-match 0 'foo/bar' 'foo?bar'
-match 0 'foo/bar' 'foo[/]bar'
-match 0 'foo/bar' 'foo[^a-z]bar'
-match 0 'foo/bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
-match 1 'foo-bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
-match 1 'foo' '**/foo'
-match 1 'XXX/foo' '**/foo'
-match 1 'bar/baz/foo' '**/foo'
-match 0 'bar/baz/foo' '*/foo'
-match 0 'foo/bar/baz' '**/bar*'
-match 1 'deep/foo/bar/baz' '**/bar/*'
-match 0 'deep/foo/bar/baz/' '**/bar/*'
-match 1 'deep/foo/bar/baz/' '**/bar/**'
-match 0 'deep/foo/bar' '**/bar/*'
-match 1 'deep/foo/bar/' '**/bar/**'
-match 0 'foo/bar/baz' '**/bar**'
-match 1 'foo/bar/baz/x' '*/bar/**'
-match 0 'deep/foo/bar/baz/x' '*/bar/**'
-match 1 'deep/foo/bar/baz/x' '**/bar/*/*'
+match 0 0 1 1 'foo/baz/bar' 'foo*bar'
+match 0 0 1 1 'foo/baz/bar' 'foo**bar'
+match 0 0 1 1 'foobazbar' 'foo**bar'
+match 1 1 1 1 'foo/baz/bar' 'foo/**/bar'
+match 1 1 0 0 'foo/baz/bar' 'foo/**/**/bar'
+match 1 1 1 1 'foo/b/a/z/bar' 'foo/**/bar'
+match 1 1 1 1 'foo/b/a/z/bar' 'foo/**/**/bar'
+match 1 1 0 0 'foo/bar' 'foo/**/bar'
+match 1 1 0 0 'foo/bar' 'foo/**/**/bar'
+match 0 0 1 1 'foo/bar' 'foo?bar'
+match 0 0 1 1 'foo/bar' 'foo[/]bar'
+match 0 0 1 1 'foo/bar' 'foo[^a-z]bar'
+match 0 0 1 1 'foo/bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
+match 1 1 1 1 'foo-bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
+match 1 1 0 0 'foo' '**/foo'
+match 1 1 1 1 'XXX/foo' '**/foo'
+match 1 1 1 1 'bar/baz/foo' '**/foo'
+match 0 0 1 1 'bar/baz/foo' '*/foo'
+match 0 0 1 1 'foo/bar/baz' '**/bar*'
+match 1 1 1 1 'deep/foo/bar/baz' '**/bar/*'
+match 0 0 1 1 'deep/foo/bar/baz/' '**/bar/*'
+match 1 1 1 1 'deep/foo/bar/baz/' '**/bar/**'
+match 0 0 0 0 'deep/foo/bar' '**/bar/*'
+match 1 1 1 1 'deep/foo/bar/' '**/bar/**'
+match 0 0 1 1 'foo/bar/baz' '**/bar**'
+match 1 1 1 1 'foo/bar/baz/x' '*/bar/**'
+match 0 0 1 1 'deep/foo/bar/baz/x' '*/bar/**'
+match 1 1 1 1 'deep/foo/bar/baz/x' '**/bar/*/*'
# Various additional tests
-match 0 'acrt' 'a[c-c]st'
-match 1 'acrt' 'a[c-c]rt'
-match 0 ']' '[!]-]'
-match 1 'a' '[!]-]'
-match 0 '' '\'
-match 0 '\' '\'
-match 0 'XXX/\' '*/\'
-match 1 'XXX/\' '*/\\'
-match 1 'foo' 'foo'
-match 1 '@foo' '@foo'
-match 0 'foo' '@foo'
-match 1 '[ab]' '\[ab]'
-match 1 '[ab]' '[[]ab]'
-match 1 '[ab]' '[[:]ab]'
-match 0 '[ab]' '[[::]ab]'
-match 1 '[ab]' '[[:digit]ab]'
-match 1 '[ab]' '[\[:]ab]'
-match 1 '?a?b' '\??\?b'
-match 1 'abc' '\a\b\c'
-match 0 'foo' ''
-match 1 'foo/bar/baz/to' '**/t[o]'
+match 0 0 0 0 'acrt' 'a[c-c]st'
+match 1 1 1 1 'acrt' 'a[c-c]rt'
+match 0 0 0 0 ']' '[!]-]'
+match 1 1 1 1 'a' '[!]-]'
+match 0 0 0 0 '' '\'
+match 0 0 0 0 '\' '\'
+match 0 0 0 0 'XXX/\' '*/\'
+match 1 1 1 1 'XXX/\' '*/\\'
+match 1 1 1 1 'foo' 'foo'
+match 1 1 1 1 '@foo' '@foo'
+match 0 0 0 0 'foo' '@foo'
+match 1 1 1 1 '[ab]' '\[ab]'
+match 1 1 1 1 '[ab]' '[[]ab]'
+match 1 1 1 1 '[ab]' '[[:]ab]'
+match 0 0 0 0 '[ab]' '[[::]ab]'
+match 1 1 1 1 '[ab]' '[[:digit]ab]'
+match 1 1 1 1 '[ab]' '[\[:]ab]'
+match 1 1 1 1 '?a?b' '\??\?b'
+match 1 1 1 1 'abc' '\a\b\c'
+match 0 0 0 0 'foo' ''
+match 1 1 1 1 'foo/bar/baz/to' '**/t[o]'
# Character class tests
-match 1 'a1B' '[[:alpha:]][[:digit:]][[:upper:]]'
-match 0 'a' '[[:digit:][:upper:][:space:]]'
-match 1 'A' '[[:digit:][:upper:][:space:]]'
-match 1 '1' '[[:digit:][:upper:][:space:]]'
-match 0 '1' '[[:digit:][:upper:][:spaci:]]'
-match 1 ' ' '[[:digit:][:upper:][:space:]]'
-match 0 '.' '[[:digit:][:upper:][:space:]]'
-match 1 '.' '[[:digit:][:punct:][:space:]]'
-match 1 '5' '[[:xdigit:]]'
-match 1 'f' '[[:xdigit:]]'
-match 1 'D' '[[:xdigit:]]'
-match 1 '_' '[[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]]'
-match 1 '.' '[^[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:lower:][:space:][:upper:][:xdigit:]]'
-match 1 '5' '[a-c[:digit:]x-z]'
-match 1 'b' '[a-c[:digit:]x-z]'
-match 1 'y' '[a-c[:digit:]x-z]'
-match 0 'q' '[a-c[:digit:]x-z]'
-
-# Additional tests, including some malformed wildmats
-match 1 ']' '[\\-^]'
-match 0 '[' '[\\-^]'
-match 1 '-' '[\-_]'
-match 1 ']' '[\]]'
-match 0 '\]' '[\]]'
-match 0 '\' '[\]]'
-match 0 'ab' 'a[]b'
-match 0 'a[]b' 'a[]b'
-match 0 'ab[' 'ab['
-match 0 'ab' '[!'
-match 0 'ab' '[-'
-match 1 '-' '[-]'
-match 0 '-' '[a-'
-match 0 '-' '[!a-'
-match 1 '-' '[--A]'
-match 1 '5' '[--A]'
-match 1 ' ' '[ --]'
-match 1 '$' '[ --]'
-match 1 '-' '[ --]'
-match 0 '0' '[ --]'
-match 1 '-' '[---]'
-match 1 '-' '[------]'
-match 0 'j' '[a-e-n]'
-match 1 '-' '[a-e-n]'
-match 1 'a' '[!------]'
-match 0 '[' '[]-a]'
-match 1 '^' '[]-a]'
-match 0 '^' '[!]-a]'
-match 1 '[' '[!]-a]'
-match 1 '^' '[a^bc]'
-match 1 '-b]' '[a-]b]'
-match 0 '\' '[\]'
-match 1 '\' '[\\]'
-match 0 '\' '[!\\]'
-match 1 'G' '[A-\\]'
-match 0 'aaabbb' 'b*a'
-match 0 'aabcaa' '*ba*'
-match 1 ',' '[,]'
-match 1 ',' '[\\,]'
-match 1 '\' '[\\,]'
-match 1 '-' '[,-.]'
-match 0 '+' '[,-.]'
-match 0 '-.]' '[,-.]'
-match 1 '2' '[\1-\3]'
-match 1 '3' '[\1-\3]'
-match 0 '4' '[\1-\3]'
-match 1 '\' '[[-\]]'
-match 1 '[' '[[-\]]'
-match 1 ']' '[[-\]]'
-match 0 '-' '[[-\]]'
+match 1 1 1 1 'a1B' '[[:alpha:]][[:digit:]][[:upper:]]'
+match 0 1 0 1 'a' '[[:digit:][:upper:][:space:]]'
+match 1 1 1 1 'A' '[[:digit:][:upper:][:space:]]'
+match 1 1 1 1 '1' '[[:digit:][:upper:][:space:]]'
+match 0 0 0 0 '1' '[[:digit:][:upper:][:spaci:]]'
+match 1 1 1 1 ' ' '[[:digit:][:upper:][:space:]]'
+match 0 0 0 0 '.' '[[:digit:][:upper:][:space:]]'
+match 1 1 1 1 '.' '[[:digit:][:punct:][:space:]]'
+match 1 1 1 1 '5' '[[:xdigit:]]'
+match 1 1 1 1 'f' '[[:xdigit:]]'
+match 1 1 1 1 'D' '[[:xdigit:]]'
+match 1 1 1 1 '_' '[[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]]'
+match 1 1 1 1 '.' '[^[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:lower:][:space:][:upper:][:xdigit:]]'
+match 1 1 1 1 '5' '[a-c[:digit:]x-z]'
+match 1 1 1 1 'b' '[a-c[:digit:]x-z]'
+match 1 1 1 1 'y' '[a-c[:digit:]x-z]'
+match 0 0 0 0 'q' '[a-c[:digit:]x-z]'
-# Test recursion and the abort code (use "wildtest -i" to see iteration counts)
-match 1 '-adobe-courier-bold-o-normal--12-120-75-75-m-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
-match 0 '-adobe-courier-bold-o-normal--12-120-75-75-X-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
-match 0 '-adobe-courier-bold-o-normal--12-120-75-75-/-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
-match 1 'XXX/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
-match 0 'XXX/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
-match 1 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txt' '**/*a*b*g*n*t'
-match 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txtz' '**/*a*b*g*n*t'
-match 0 foo '*/*/*'
-match 0 foo/bar '*/*/*'
-match 1 foo/bba/arr '*/*/*'
-match 0 foo/bb/aa/rr '*/*/*'
-match 1 foo/bb/aa/rr '**/**/**'
-match 1 abcXdefXghi '*X*i'
-match 0 ab/cXd/efXg/hi '*X*i'
-match 1 ab/cXd/efXg/hi '*/*X*/*/*i'
-match 1 ab/cXd/efXg/hi '**/*X*/**/*i'
+# Additional tests, including some malformed wildmatch patterns
+match 1 1 1 1 ']' '[\\-^]'
+match 0 0 0 0 '[' '[\\-^]'
+match 1 1 1 1 '-' '[\-_]'
+match 1 1 1 1 ']' '[\]]'
+match 0 0 0 0 '\]' '[\]]'
+match 0 0 0 0 '\' '[\]]'
+match 0 0 0 0 'ab' 'a[]b'
+match 0 0 0 0 'a[]b' 'a[]b'
+match 0 0 0 0 'ab[' 'ab['
+match 0 0 0 0 'ab' '[!'
+match 0 0 0 0 'ab' '[-'
+match 1 1 1 1 '-' '[-]'
+match 0 0 0 0 '-' '[a-'
+match 0 0 0 0 '-' '[!a-'
+match 1 1 1 1 '-' '[--A]'
+match 1 1 1 1 '5' '[--A]'
+match 1 1 1 1 ' ' '[ --]'
+match 1 1 1 1 '$' '[ --]'
+match 1 1 1 1 '-' '[ --]'
+match 0 0 0 0 '0' '[ --]'
+match 1 1 1 1 '-' '[---]'
+match 1 1 1 1 '-' '[------]'
+match 0 0 0 0 'j' '[a-e-n]'
+match 1 1 1 1 '-' '[a-e-n]'
+match 1 1 1 1 'a' '[!------]'
+match 0 0 0 0 '[' '[]-a]'
+match 1 1 1 1 '^' '[]-a]'
+match 0 0 0 0 '^' '[!]-a]'
+match 1 1 1 1 '[' '[!]-a]'
+match 1 1 1 1 '^' '[a^bc]'
+match 1 1 1 1 '-b]' '[a-]b]'
+match 0 0 0 0 '\' '[\]'
+match 1 1 1 1 '\' '[\\]'
+match 0 0 0 0 '\' '[!\\]'
+match 1 1 1 1 'G' '[A-\\]'
+match 0 0 0 0 'aaabbb' 'b*a'
+match 0 0 0 0 'aabcaa' '*ba*'
+match 1 1 1 1 ',' '[,]'
+match 1 1 1 1 ',' '[\\,]'
+match 1 1 1 1 '\' '[\\,]'
+match 1 1 1 1 '-' '[,-.]'
+match 0 0 0 0 '+' '[,-.]'
+match 0 0 0 0 '-.]' '[,-.]'
+match 1 1 1 1 '2' '[\1-\3]'
+match 1 1 1 1 '3' '[\1-\3]'
+match 0 0 0 0 '4' '[\1-\3]'
+match 1 1 1 1 '\' '[[-\]]'
+match 1 1 1 1 '[' '[[-\]]'
+match 1 1 1 1 ']' '[[-\]]'
+match 0 0 0 0 '-' '[[-\]]'
-pathmatch 1 foo foo
-pathmatch 0 foo fo
-pathmatch 1 foo/bar foo/bar
-pathmatch 1 foo/bar 'foo/*'
-pathmatch 1 foo/bba/arr 'foo/*'
-pathmatch 1 foo/bba/arr 'foo/**'
-pathmatch 1 foo/bba/arr 'foo*'
-pathmatch 1 foo/bba/arr 'foo**'
-pathmatch 1 foo/bba/arr 'foo/*arr'
-pathmatch 1 foo/bba/arr 'foo/**arr'
-pathmatch 0 foo/bba/arr 'foo/*z'
-pathmatch 0 foo/bba/arr 'foo/**z'
-pathmatch 1 foo/bar 'foo?bar'
-pathmatch 1 foo/bar 'foo[/]bar'
-pathmatch 1 foo/bar 'foo[^a-z]bar'
-pathmatch 0 foo '*/*/*'
-pathmatch 0 foo/bar '*/*/*'
-pathmatch 1 foo/bba/arr '*/*/*'
-pathmatch 1 foo/bb/aa/rr '*/*/*'
-pathmatch 1 abcXdefXghi '*X*i'
-pathmatch 1 ab/cXd/efXg/hi '*/*X*/*/*i'
-pathmatch 1 ab/cXd/efXg/hi '*Xg*i'
+# Test recursion
+match 1 1 1 1 '-adobe-courier-bold-o-normal--12-120-75-75-m-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
+match 0 0 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-X-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
+match 0 0 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-/-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
+match 1 1 1 1 'XXX/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
+match 0 0 0 0 'XXX/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
+match 1 1 1 1 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txt' '**/*a*b*g*n*t'
+match 0 0 0 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txtz' '**/*a*b*g*n*t'
+match 0 0 0 0 foo '*/*/*'
+match 0 0 0 0 foo/bar '*/*/*'
+match 1 1 1 1 foo/bba/arr '*/*/*'
+match 0 0 1 1 foo/bb/aa/rr '*/*/*'
+match 1 1 1 1 foo/bb/aa/rr '**/**/**'
+match 1 1 1 1 abcXdefXghi '*X*i'
+match 0 0 1 1 ab/cXd/efXg/hi '*X*i'
+match 1 1 1 1 ab/cXd/efXg/hi '*/*X*/*/*i'
+match 1 1 1 1 ab/cXd/efXg/hi '**/*X*/**/*i'
-# Case-sensitivity features
-match 0 'a' '[A-Z]'
-match 1 'A' '[A-Z]'
-match 0 'A' '[a-z]'
-match 1 'a' '[a-z]'
-match 0 'a' '[[:upper:]]'
-match 1 'A' '[[:upper:]]'
-match 0 'A' '[[:lower:]]'
-match 1 'a' '[[:lower:]]'
-match 0 'A' '[B-Za]'
-match 1 'a' '[B-Za]'
-match 0 'A' '[B-a]'
-match 1 'a' '[B-a]'
-match 0 'z' '[Z-y]'
-match 1 'Z' '[Z-y]'
+# Extra pathmatch tests
+match 0 0 0 0 foo fo
+match 1 1 1 1 foo/bar foo/bar
+match 1 1 1 1 foo/bar 'foo/*'
+match 0 0 1 1 foo/bba/arr 'foo/*'
+match 1 1 1 1 foo/bba/arr 'foo/**'
+match 0 0 1 1 foo/bba/arr 'foo*'
+match 0 0 1 1 foo/bba/arr 'foo**'
+match 0 0 1 1 foo/bba/arr 'foo/*arr'
+match 0 0 1 1 foo/bba/arr 'foo/**arr'
+match 0 0 0 0 foo/bba/arr 'foo/*z'
+match 0 0 0 0 foo/bba/arr 'foo/**z'
+match 0 0 1 1 foo/bar 'foo?bar'
+match 0 0 1 1 foo/bar 'foo[/]bar'
+match 0 0 1 1 foo/bar 'foo[^a-z]bar'
+match 0 0 1 1 ab/cXd/efXg/hi '*Xg*i'
-imatch 1 'a' '[A-Z]'
-imatch 1 'A' '[A-Z]'
-imatch 1 'A' '[a-z]'
-imatch 1 'a' '[a-z]'
-imatch 1 'a' '[[:upper:]]'
-imatch 1 'A' '[[:upper:]]'
-imatch 1 'A' '[[:lower:]]'
-imatch 1 'a' '[[:lower:]]'
-imatch 1 'A' '[B-Za]'
-imatch 1 'a' '[B-Za]'
-imatch 1 'A' '[B-a]'
-imatch 1 'a' '[B-a]'
-imatch 1 'z' '[Z-y]'
-imatch 1 'Z' '[Z-y]'
+# Extra case-sensitivity tests
+match 0 1 0 1 'a' '[A-Z]'
+match 1 1 1 1 'A' '[A-Z]'
+match 0 1 0 1 'A' '[a-z]'
+match 1 1 1 1 'a' '[a-z]'
+match 0 1 0 1 'a' '[[:upper:]]'
+match 1 1 1 1 'A' '[[:upper:]]'
+match 0 1 0 1 'A' '[[:lower:]]'
+match 1 1 1 1 'a' '[[:lower:]]'
+match 0 1 0 1 'A' '[B-Za]'
+match 1 1 1 1 'a' '[B-Za]'
+match 0 1 0 1 'A' '[B-a]'
+match 1 1 1 1 'a' '[B-a]'
+match 0 1 0 1 'z' '[Z-y]'
+match 1 1 1 1 'Z' '[Z-y]'
test_done
--
2.15.1.424.g9478a66081
^ permalink raw reply related [relevance 6%]
* Re: [PATCH] apply: support case-only renames in case-insensitive filesystems
@ 2022-06-14 5:13 6% ` Tao Klerks
2022-06-18 0:45 6% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Tao Klerks @ 2022-06-14 5:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tao Klerks via GitGitGadget, git
On Sat, Jun 11, 2022 at 9:17 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Tao Klerks via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: Tao Klerks <tao@klerks.biz>
> >
> > "git apply" checks, when validating a patch, to ensure that any files
> > being added aren't already in the worktree.
> >
> > When this check runs on a case-only rename, in a case-insensitive
> > filesystem, this leads to a false positive - the command fails with an
> > error like:
> > error: File1: already exists in working directory
> >
> > Fix this existence check to allow the file to exist, for a case-only
> > rename when config core.ignorecase is set.
>
> Hmph, close, but the patch as-posted may be fatally buggy, I think.
>
Yes indeed, very much so.
> At the beginning of the function there is this block:
>
> const char *old_name = patch->old_name;
> const char *new_name = patch->new_name;
> const char *name = old_name ? old_name : new_name;
>
> which makes us realize that old_name CAN legitimately be NULL. That
> is true for a creation patch. new_name can also be NULL for a
> deletion patch.
>
Yep, I was aware of the nulls, but I was unaware that passing nulls
into "strcasecmp()" was a bad thing to do. I just assumed a non-zero
comparison result would ensue.
> > if ((tpatch = in_fn_table(state, new_name)) &&
> > (was_deleted(tpatch) || to_be_deleted(tpatch)))
> > ok_if_exists = 1;
> > + else if (ignore_case && !strcasecmp(old_name, new_name))
> > + ok_if_exists = 1;
>
> You'd get a segfault when the patch is creating a file at new_name,
> or deleting a file at old_name, wouldn't you?
>
Indeed you do (when ignorecase is true of course).
> We need a new test or two to see if a straight creation or deletion
> patch does work correctly with icase set, before we even dream of
> handling rename patches. Not having tests for such basic cases is
> quite surprising, but apparently the above line passed the CI.
>
This is where I made some very bad assumptions: I only manually ran
the new "t4141-apply-case-insensitive-rename.sh" test, and assumed
that the test suite ran against linux, windows, and OSX, with the
latter two running on case-insensitive filesystems. I assumed that
both case-sensitive and case-insensitive code paths would be tested by
the complete CI suite.
The OSX tests were not running for me at all in GitGitGadget (seems to
be an ongoing struggle), but I assumed that everything was still
tested in case-insensitive mode because of the windows suite. It looks
like that was wrong, although I still don´t know how/why.
Had I run "t4114-apply-typechange.sh" (or probably some others in the
41XX range) on the OSX environment where I happen to have developed
this weekend, I would have seen the failures immediately.
> > else
> > ok_if_exists = 0;
>
> Having said that, I wonder what the existing check before the new
> condition is doing? Especially, what is in_fn_table() for and how
> does it try to do its work?
>
> Reading the big comment before it, it seems that it tries to deal
> with tricky delete/create case already. With a typechange patch
> that first removes a regular file "hello.txt" and then creates a
> symbolic link "hello.txt" is exempted from the "what you are
> creating should not exist already" rule by using in_fn_table()
> check. If it tries to create a symlink "Hello.txt" instead,
> shouldn't we allow it the same way on case-insensitive systems? I
> do not think in_fn_table() pays attention to "ignore_case" option,
> so there may be an existing bug there already, regardless of the
> problem you are trying to address with your patch.
>
> And I wonder if doing case-insensitive match in in_fn_table() lets
> us cover this new case as well as "fixing" the existing issue.
>
Yep, I confirmed that as you expect, it does fix the issue I set out
to fix, and as you noted also fixes other (slightly more obscure?)
existing issues with "git apply" on case-insensitive filesystems.
This time I tested all of t41XX on a case-insensitive system, and the
CI process ran in GitLab, presumably on case-sensitive filesystems
only.
I'm not sure what more to look out for, and will note as much in the
patch v2 comments.
> In any case, here are such two tests to make sure creation and
> deletion patches on icase systems are not broken by careless
> mistakes like the one in this patch.
I have a question related to this:
*Do* we expect to run the full test suite on case-insensitive systems
in gitlab, or do we expect to need to add explicit "-C
core.ignorecase" tests as you have done here? The latter seems risky
both because the behavior is not representatively tested (because it's
still actually running in a case-sensitive filesystem), and because
it's hard to predict all the things that should be explicitly retested
in this way.
I don't think these specific tests were necessary, and I guess they
are replaced by later ones in this thread, so I will ignore this bit
specifically.
Thanks for the careful review, my apologies for the careless patch.
^ permalink raw reply [relevance 6%]
* Re: Odd issue - The Diffs That WILL NOT DIE.
@ 2011-12-07 22:58 6% ` Carlos Martín Nieto
2011-12-07 23:06 6% ` Jeff King
0 siblings, 1 reply; 200+ results
From: Carlos Martín Nieto @ 2011-12-07 22:58 UTC (permalink / raw)
To: Chris Patti; +Cc: Jeff King, git
[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]
On Wed, Dec 07, 2011 at 05:30:19PM -0500, Chris Patti wrote:
> Actually I'm wrong on that count, but in an interesting way.
>
> Both CloudSponge.php and Cloudsponge.php exist and are *not* deleted
> in the remote repository, but on OSX only Cloudsponge.php shows up on
> the filesystem, yet CloudSponge.php is being reported as modified.
>
> Turns out two of our other developers are also seeing this behavior.
HFS+ (the filesystem used by OSX) is case insensitive unless you
toggle some magic switch, so git set core.ignorecase to true on clone
(the config manpage claims its done on init or clone, in any case)
which makes it assume that Cloudsponge.php and CloudSponge.php are the
same file (which in a case-insensitive filesystem is true).
If you want to use OSX to develop this project, you'll have to either
rename one of those files or set your filesystem to be case-sensitive
(and unset core.ignorecase afterwards). From what I've heard, the OS
itself will work fine with a case-sensitive filesystem, but not all
applications might. YMMV.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [relevance 6%]
* Re: [PATCH 1/2] submodule: fix confusing variable name
@ 2013-08-11 19:53 6% ` Mark Levedahl
0 siblings, 0 replies; 200+ results
From: Mark Levedahl @ 2013-08-11 19:53 UTC (permalink / raw)
To: Ramsay Jones
Cc: Fredrik Gustafsson, Jens Lehmann, Jonathan Nieder,
brian m. carlson, git, judge.packham, Jorge-Juan.Garcia-Garcia,
gitster
On 08/08/2013 01:44 PM, Ramsay Jones wrote:
> Fredrik Gustafsson wrote:
>> On Sun, Aug 04, 2013 at 07:34:48PM +0200, Jens Lehmann wrote:
>>> But we'll have to use sm_path here (like everywhere else in the
>>> submodule script), because we'll run into problems under Windows
>>> otherwise (see 64394e3ae9 for details). Apart from that the patch
>>> is fine.
>>
>> We're still using path= in the foreach-script. Or rather, we're setting
>> it. From what I can see and from the commit message 64394e3ae9 it could
>> possible be a problem.
>
> Please do not use a $path variable in any script intended to be run on
> windows; those poor souls who would otherwise have to fix the bugs will
> thank you! :-D
>
> Actually, it's not so much the use of a $path variable, rather the act
> of _exporting_ such a variable that causes the problem. (Which is why
> using $path with eval_gettext[ln] is such a problem, of course.)
>
Please note that especially in this case, Cygwin != Windows. Cygwin
allows $path, $Path, $PATH, etc., to all coexist and be accessed case
sensitively. Exporting $path causes no problem, either. Should the eval
invoke a Windows program, $PATH is converted to Windows format and
exported, the other case-sensitive variants of path remain in the
environment and can be accessed by any program implementing
case-sensitive lookup as well. Not sure what will happen with
case-insensitive lookups, but a quick test showed that cmd.exe is not
bothered by $path given $PATH exists.
Mark
^ permalink raw reply [relevance 6%]
* Re: Bug: Changing folder case with `git mv` crashes on case-insensitive file system
@ 2021-05-06 9:12 6% ` Mark Amery
0 siblings, 0 replies; 200+ results
From: Mark Amery @ 2021-05-06 9:12 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Junio C Hamano, git
So, I'm just a dumb Git user who doesn't even write C, so much of this
discussion is over my head, but I have a few thoughts that may be
helpful:
• The mv utility on Mac is capable of doing `mv bär.txt bÄr.txt` just
fine. Maybe `git mv` can learn something from whatever `mv` does?
• On a case-insensitive file system, `git mv somedir sOMEdir` is a
rename. But on a case-sensitive file system, it might NOT be a rename;
it might be the case that `somedir` and `sOMEdir` both exist and that
the command should put `somedir` inside `sOMEdir`. I mention this
because I can imagine some naive attempts at fixing the original bug
by doing a case-insensitive comparison of the two names ending up
breaking this behaviour on case-sensitive file systems by wrongly
treating such a command as a rename. It's probably worth having a test
that this scenario gets handled cleanly on case-sensitive file
systems? (I haven't checked whether Torsten's proposed diff falls into
this trap or not.)
• Above, Torsten mentions that there are filesystem-specific rules
about what names are equal to each other that Git can't easily handle,
because they go beyond just ASCII case changes. In that case, maybe
the right solution is to always defer the question to the filesystem
rather than Git trying to figure out the answer "in its head"?
That is: first check the inode or file ID of the src and dst passed
to `git mv`. If they are different and the second one is a folder,
move src inside the existing folder. If either they are the same or
the second one is not a folder, then do a rename.
It seems to me that this approach automatically handles stuff like
`git mv bär.txt bÄr.txt` plus any other rules about names being equal
(like two different sequences of code points that both express "à"),
all without Git ever needing to explicitly check whether two names are
case-insensitively equal. Am I missing something?
Sorry if any of the above is dumb or if I'm reiterating things others
have already said without realising it.
On Thu, May 6, 2021 at 5:34 AM Torsten Bögershausen <tboegi@web.de> wrote:
>
> On Wed, May 05, 2021 at 09:23:05AM +0900, Junio C Hamano wrote:
> > Torsten Bögershausen <tboegi@web.de> writes:
> >
> > > To my undestanding we try to rename
> > > foo/ into FOO/.
> > > But because FOO/ already "exists" as directory,
> > > Git tries to move foo/ into FOO/foo, which fails.
> > >
> > > And no, the problem is probably not restricted to MacOs,
> > > Windows and all case-insenstive file systems should show
> > > the same, but I haven't tested yet, so it's more a suspicion.
> > >
> > > The following diff allows to move foo/ into FOO/
> > > If someone wants to make a patch out if, that would be good.
> >
> > Is strcasecmp() sufficient for macOS whose filesystem has not just
> > case insensitivity but UTF-8 normalization issues?
> >
>
> Strictly speaking: no.
>
> The Git code doesn't handle UTF-8 uppper/lower case at all:
> git mv bar.txt BAR.TXT works because strcasecmp() is catching it.
>
> git mv bär.txt BÄR.TXT needs the long way:
> git mv bär.txt baer.txt && git mv baer.txt BÄR.TXT
>
> We have been restricting the case-change-is-allowed to ASCII filenames
> all the time.
> There is no information, which code points map onto each other in Git,
> since this is all file system dependent.
> NTFS has one way, HFS+, APFS another, VFAT a third one, and if I expose
> ext4 via SAMBA we probably have another one.
> Not mentioniong that ext4 can be use case-insensitve on later Linux kernels,
> which sticks to unicode.
> Or Git repos running on machines using ISO-8859-1, those should be rare these
> days.
>
> That said, people are renaming files in ASCII only and are happy,
> and in that sense renaming directories in ASCII can be supported
> without major hassle.
>
> And the inode approach mentioned as well:
> This could go on top of strcasecmp() to cover non-ASCII filenames
> or other oddities, if someone implements it.
>
>
^ permalink raw reply [relevance 6%]
* [PATCH v6 2/6] t1300: fix over-indented HERE-DOCs
@ 2020-01-29 3:34 6% ` Matthew Rogers via GitGitGadget
1 sibling, 0 replies; 200+ results
From: Matthew Rogers via GitGitGadget @ 2020-01-29 3:34 UTC (permalink / raw)
To: git; +Cc: Matthew Rogers, Matthew Rogers
From: Matthew Rogers <mattr94@gmail.com>
Prepare for the following patches by removing extraneous indents from
HERE-DOCs used in config tests.
Signed-off-by: Matthew Rogers <mattr94@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t1300-config.sh | 168 +++++++++++++++++++++++-----------------------
1 file changed, 84 insertions(+), 84 deletions(-)
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index 983a0a1583..e8b4575758 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -1191,47 +1191,47 @@ test_expect_success 'old-fashioned settings are case insensitive' '
test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
cat >testConfig_actual <<-EOF &&
- [V.A]
- r = value1
+ [V.A]
+ r = value1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V.A]
- Qr = value2
+ [V.A]
+ Qr = value2
EOF
git config -f testConfig_actual "v.a.r" value2 &&
test_cmp testConfig_expect testConfig_actual &&
cat >testConfig_actual <<-EOF &&
- [V.A]
- r = value1
+ [V.A]
+ r = value1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V.A]
- QR = value2
+ [V.A]
+ QR = value2
EOF
git config -f testConfig_actual "V.a.R" value2 &&
test_cmp testConfig_expect testConfig_actual &&
cat >testConfig_actual <<-EOF &&
- [V.A]
- r = value1
+ [V.A]
+ r = value1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V.A]
- r = value1
- Qr = value2
+ [V.A]
+ r = value1
+ Qr = value2
EOF
git config -f testConfig_actual "V.A.r" value2 &&
test_cmp testConfig_expect testConfig_actual &&
cat >testConfig_actual <<-EOF &&
- [V.A]
- r = value1
+ [V.A]
+ r = value1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V.A]
- r = value1
- Qr = value2
+ [V.A]
+ r = value1
+ Qr = value2
EOF
git config -f testConfig_actual "v.A.r" value2 &&
test_cmp testConfig_expect testConfig_actual
@@ -1241,26 +1241,26 @@ test_expect_success 'setting different case sensitive subsections ' '
test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
cat >testConfig_actual <<-EOF &&
- [V "A"]
- R = v1
- [K "E"]
- Y = v1
- [a "b"]
- c = v1
- [d "e"]
- f = v1
+ [V "A"]
+ R = v1
+ [K "E"]
+ Y = v1
+ [a "b"]
+ c = v1
+ [d "e"]
+ f = v1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V "A"]
- Qr = v2
- [K "E"]
- Qy = v2
- [a "b"]
- Qc = v2
- [d "e"]
- f = v1
- [d "E"]
- Qf = v2
+ [V "A"]
+ Qr = v2
+ [K "E"]
+ Qy = v2
+ [a "b"]
+ Qc = v2
+ [d "e"]
+ f = v1
+ [d "E"]
+ Qf = v2
EOF
# exact match
git config -f testConfig_actual a.b.c v2 &&
@@ -1622,40 +1622,40 @@ test_expect_success 'set up --show-origin tests' '
INCLUDE_DIR="$HOME/include" &&
mkdir -p "$INCLUDE_DIR" &&
cat >"$INCLUDE_DIR"/absolute.include <<-\EOF &&
- [user]
- absolute = include
+ [user]
+ absolute = include
EOF
cat >"$INCLUDE_DIR"/relative.include <<-\EOF &&
- [user]
- relative = include
+ [user]
+ relative = include
EOF
cat >"$HOME"/.gitconfig <<-EOF &&
- [user]
- global = true
- override = global
- [include]
- path = "$INCLUDE_DIR/absolute.include"
+ [user]
+ global = true
+ override = global
+ [include]
+ path = "$INCLUDE_DIR/absolute.include"
EOF
cat >.git/config <<-\EOF
- [user]
- local = true
- override = local
- [include]
- path = ../include/relative.include
+ [user]
+ local = true
+ override = local
+ [include]
+ path = ../include/relative.include
EOF
'
test_expect_success '--show-origin with --list' '
cat >expect <<-EOF &&
- file:$HOME/.gitconfig user.global=true
- file:$HOME/.gitconfig user.override=global
- file:$HOME/.gitconfig include.path=$INCLUDE_DIR/absolute.include
- file:$INCLUDE_DIR/absolute.include user.absolute=include
- file:.git/config user.local=true
- file:.git/config user.override=local
- file:.git/config include.path=../include/relative.include
- file:.git/../include/relative.include user.relative=include
- command line: user.cmdline=true
+ file:$HOME/.gitconfig user.global=true
+ file:$HOME/.gitconfig user.override=global
+ file:$HOME/.gitconfig include.path=$INCLUDE_DIR/absolute.include
+ file:$INCLUDE_DIR/absolute.include user.absolute=include
+ file:.git/config user.local=true
+ file:.git/config user.override=local
+ file:.git/config include.path=../include/relative.include
+ file:.git/../include/relative.include user.relative=include
+ command line: user.cmdline=true
EOF
git -c user.cmdline=true config --list --show-origin >output &&
test_cmp expect output
@@ -1663,16 +1663,16 @@ test_expect_success '--show-origin with --list' '
test_expect_success '--show-origin with --list --null' '
cat >expect <<-EOF &&
- file:$HOME/.gitconfigQuser.global
- trueQfile:$HOME/.gitconfigQuser.override
- globalQfile:$HOME/.gitconfigQinclude.path
- $INCLUDE_DIR/absolute.includeQfile:$INCLUDE_DIR/absolute.includeQuser.absolute
- includeQfile:.git/configQuser.local
- trueQfile:.git/configQuser.override
- localQfile:.git/configQinclude.path
- ../include/relative.includeQfile:.git/../include/relative.includeQuser.relative
- includeQcommand line:Quser.cmdline
- trueQ
+ file:$HOME/.gitconfigQuser.global
+ trueQfile:$HOME/.gitconfigQuser.override
+ globalQfile:$HOME/.gitconfigQinclude.path
+ $INCLUDE_DIR/absolute.includeQfile:$INCLUDE_DIR/absolute.includeQuser.absolute
+ includeQfile:.git/configQuser.local
+ trueQfile:.git/configQuser.override
+ localQfile:.git/configQinclude.path
+ ../include/relative.includeQfile:.git/../include/relative.includeQuser.relative
+ includeQcommand line:Quser.cmdline
+ trueQ
EOF
git -c user.cmdline=true config --null --list --show-origin >output.raw &&
nul_to_q <output.raw >output &&
@@ -1684,9 +1684,9 @@ test_expect_success '--show-origin with --list --null' '
test_expect_success '--show-origin with single file' '
cat >expect <<-\EOF &&
- file:.git/config user.local=true
- file:.git/config user.override=local
- file:.git/config include.path=../include/relative.include
+ file:.git/config user.local=true
+ file:.git/config user.override=local
+ file:.git/config include.path=../include/relative.include
EOF
git config --local --list --show-origin >output &&
test_cmp expect output
@@ -1694,8 +1694,8 @@ test_expect_success '--show-origin with single file' '
test_expect_success '--show-origin with --get-regexp' '
cat >expect <<-EOF &&
- file:$HOME/.gitconfig user.global true
- file:.git/config user.local true
+ file:$HOME/.gitconfig user.global true
+ file:.git/config user.local true
EOF
git config --show-origin --get-regexp "user\.[g|l].*" >output &&
test_cmp expect output
@@ -1703,7 +1703,7 @@ test_expect_success '--show-origin with --get-regexp' '
test_expect_success '--show-origin getting a single key' '
cat >expect <<-\EOF &&
- file:.git/config local
+ file:.git/config local
EOF
git config --show-origin user.override >output &&
test_cmp expect output
@@ -1712,14 +1712,14 @@ test_expect_success '--show-origin getting a single key' '
test_expect_success 'set up custom config file' '
CUSTOM_CONFIG_FILE="file\" (dq) and spaces.conf" &&
cat >"$CUSTOM_CONFIG_FILE" <<-\EOF
- [user]
- custom = true
+ [user]
+ custom = true
EOF
'
test_expect_success !MINGW '--show-origin escape special file name characters' '
cat >expect <<-\EOF &&
- file:"file\" (dq) and spaces.conf" user.custom=true
+ file:"file\" (dq) and spaces.conf" user.custom=true
EOF
git config --file "$CUSTOM_CONFIG_FILE" --show-origin --list >output &&
test_cmp expect output
@@ -1727,7 +1727,7 @@ test_expect_success !MINGW '--show-origin escape special file name characters' '
test_expect_success '--show-origin stdin' '
cat >expect <<-\EOF &&
- standard input: user.custom=true
+ standard input: user.custom=true
EOF
git config --file - --show-origin --list <"$CUSTOM_CONFIG_FILE" >output &&
test_cmp expect output
@@ -1735,11 +1735,11 @@ test_expect_success '--show-origin stdin' '
test_expect_success '--show-origin stdin with file include' '
cat >"$INCLUDE_DIR"/stdin.include <<-EOF &&
- [user]
- stdin = include
+ [user]
+ stdin = include
EOF
cat >expect <<-EOF &&
- file:$INCLUDE_DIR/stdin.include include
+ file:$INCLUDE_DIR/stdin.include include
EOF
echo "[include]path=\"$INCLUDE_DIR\"/stdin.include" |
git config --show-origin --includes --file - user.stdin >output &&
@@ -1750,7 +1750,7 @@ test_expect_success '--show-origin stdin with file include' '
test_expect_success !MINGW '--show-origin blob' '
blob=$(git hash-object -w "$CUSTOM_CONFIG_FILE") &&
cat >expect <<-EOF &&
- blob:$blob user.custom=true
+ blob:$blob user.custom=true
EOF
git config --blob=$blob --show-origin --list >output &&
test_cmp expect output
@@ -1758,7 +1758,7 @@ test_expect_success !MINGW '--show-origin blob' '
test_expect_success !MINGW '--show-origin blob ref' '
cat >expect <<-\EOF &&
- blob:"master:file\" (dq) and spaces.conf" user.custom=true
+ blob:"master:file\" (dq) and spaces.conf" user.custom=true
EOF
git add "$CUSTOM_CONFIG_FILE" &&
git commit -m "new config file" &&
--
gitgitgadget
^ permalink raw reply related [relevance 6%]
* [PATCH v7 02/10] t1300: fix over-indented HERE-DOCs
@ 2020-02-10 0:30 6% ` Matthew Rogers via GitGitGadget
0 siblings, 0 replies; 200+ results
From: Matthew Rogers via GitGitGadget @ 2020-02-10 0:30 UTC (permalink / raw)
To: git; +Cc: Matthew Rogers, Matthew Rogers
From: Matthew Rogers <mattr94@gmail.com>
Prepare for the following patches by removing extraneous indents from
HERE-DOCs used in config tests.
Signed-off-by: Matthew Rogers <mattr94@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t1300-config.sh | 168 +++++++++++++++++++++++-----------------------
1 file changed, 84 insertions(+), 84 deletions(-)
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index 983a0a1583..e8b4575758 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -1191,47 +1191,47 @@ test_expect_success 'old-fashioned settings are case insensitive' '
test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
cat >testConfig_actual <<-EOF &&
- [V.A]
- r = value1
+ [V.A]
+ r = value1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V.A]
- Qr = value2
+ [V.A]
+ Qr = value2
EOF
git config -f testConfig_actual "v.a.r" value2 &&
test_cmp testConfig_expect testConfig_actual &&
cat >testConfig_actual <<-EOF &&
- [V.A]
- r = value1
+ [V.A]
+ r = value1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V.A]
- QR = value2
+ [V.A]
+ QR = value2
EOF
git config -f testConfig_actual "V.a.R" value2 &&
test_cmp testConfig_expect testConfig_actual &&
cat >testConfig_actual <<-EOF &&
- [V.A]
- r = value1
+ [V.A]
+ r = value1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V.A]
- r = value1
- Qr = value2
+ [V.A]
+ r = value1
+ Qr = value2
EOF
git config -f testConfig_actual "V.A.r" value2 &&
test_cmp testConfig_expect testConfig_actual &&
cat >testConfig_actual <<-EOF &&
- [V.A]
- r = value1
+ [V.A]
+ r = value1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V.A]
- r = value1
- Qr = value2
+ [V.A]
+ r = value1
+ Qr = value2
EOF
git config -f testConfig_actual "v.A.r" value2 &&
test_cmp testConfig_expect testConfig_actual
@@ -1241,26 +1241,26 @@ test_expect_success 'setting different case sensitive subsections ' '
test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
cat >testConfig_actual <<-EOF &&
- [V "A"]
- R = v1
- [K "E"]
- Y = v1
- [a "b"]
- c = v1
- [d "e"]
- f = v1
+ [V "A"]
+ R = v1
+ [K "E"]
+ Y = v1
+ [a "b"]
+ c = v1
+ [d "e"]
+ f = v1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V "A"]
- Qr = v2
- [K "E"]
- Qy = v2
- [a "b"]
- Qc = v2
- [d "e"]
- f = v1
- [d "E"]
- Qf = v2
+ [V "A"]
+ Qr = v2
+ [K "E"]
+ Qy = v2
+ [a "b"]
+ Qc = v2
+ [d "e"]
+ f = v1
+ [d "E"]
+ Qf = v2
EOF
# exact match
git config -f testConfig_actual a.b.c v2 &&
@@ -1622,40 +1622,40 @@ test_expect_success 'set up --show-origin tests' '
INCLUDE_DIR="$HOME/include" &&
mkdir -p "$INCLUDE_DIR" &&
cat >"$INCLUDE_DIR"/absolute.include <<-\EOF &&
- [user]
- absolute = include
+ [user]
+ absolute = include
EOF
cat >"$INCLUDE_DIR"/relative.include <<-\EOF &&
- [user]
- relative = include
+ [user]
+ relative = include
EOF
cat >"$HOME"/.gitconfig <<-EOF &&
- [user]
- global = true
- override = global
- [include]
- path = "$INCLUDE_DIR/absolute.include"
+ [user]
+ global = true
+ override = global
+ [include]
+ path = "$INCLUDE_DIR/absolute.include"
EOF
cat >.git/config <<-\EOF
- [user]
- local = true
- override = local
- [include]
- path = ../include/relative.include
+ [user]
+ local = true
+ override = local
+ [include]
+ path = ../include/relative.include
EOF
'
test_expect_success '--show-origin with --list' '
cat >expect <<-EOF &&
- file:$HOME/.gitconfig user.global=true
- file:$HOME/.gitconfig user.override=global
- file:$HOME/.gitconfig include.path=$INCLUDE_DIR/absolute.include
- file:$INCLUDE_DIR/absolute.include user.absolute=include
- file:.git/config user.local=true
- file:.git/config user.override=local
- file:.git/config include.path=../include/relative.include
- file:.git/../include/relative.include user.relative=include
- command line: user.cmdline=true
+ file:$HOME/.gitconfig user.global=true
+ file:$HOME/.gitconfig user.override=global
+ file:$HOME/.gitconfig include.path=$INCLUDE_DIR/absolute.include
+ file:$INCLUDE_DIR/absolute.include user.absolute=include
+ file:.git/config user.local=true
+ file:.git/config user.override=local
+ file:.git/config include.path=../include/relative.include
+ file:.git/../include/relative.include user.relative=include
+ command line: user.cmdline=true
EOF
git -c user.cmdline=true config --list --show-origin >output &&
test_cmp expect output
@@ -1663,16 +1663,16 @@ test_expect_success '--show-origin with --list' '
test_expect_success '--show-origin with --list --null' '
cat >expect <<-EOF &&
- file:$HOME/.gitconfigQuser.global
- trueQfile:$HOME/.gitconfigQuser.override
- globalQfile:$HOME/.gitconfigQinclude.path
- $INCLUDE_DIR/absolute.includeQfile:$INCLUDE_DIR/absolute.includeQuser.absolute
- includeQfile:.git/configQuser.local
- trueQfile:.git/configQuser.override
- localQfile:.git/configQinclude.path
- ../include/relative.includeQfile:.git/../include/relative.includeQuser.relative
- includeQcommand line:Quser.cmdline
- trueQ
+ file:$HOME/.gitconfigQuser.global
+ trueQfile:$HOME/.gitconfigQuser.override
+ globalQfile:$HOME/.gitconfigQinclude.path
+ $INCLUDE_DIR/absolute.includeQfile:$INCLUDE_DIR/absolute.includeQuser.absolute
+ includeQfile:.git/configQuser.local
+ trueQfile:.git/configQuser.override
+ localQfile:.git/configQinclude.path
+ ../include/relative.includeQfile:.git/../include/relative.includeQuser.relative
+ includeQcommand line:Quser.cmdline
+ trueQ
EOF
git -c user.cmdline=true config --null --list --show-origin >output.raw &&
nul_to_q <output.raw >output &&
@@ -1684,9 +1684,9 @@ test_expect_success '--show-origin with --list --null' '
test_expect_success '--show-origin with single file' '
cat >expect <<-\EOF &&
- file:.git/config user.local=true
- file:.git/config user.override=local
- file:.git/config include.path=../include/relative.include
+ file:.git/config user.local=true
+ file:.git/config user.override=local
+ file:.git/config include.path=../include/relative.include
EOF
git config --local --list --show-origin >output &&
test_cmp expect output
@@ -1694,8 +1694,8 @@ test_expect_success '--show-origin with single file' '
test_expect_success '--show-origin with --get-regexp' '
cat >expect <<-EOF &&
- file:$HOME/.gitconfig user.global true
- file:.git/config user.local true
+ file:$HOME/.gitconfig user.global true
+ file:.git/config user.local true
EOF
git config --show-origin --get-regexp "user\.[g|l].*" >output &&
test_cmp expect output
@@ -1703,7 +1703,7 @@ test_expect_success '--show-origin with --get-regexp' '
test_expect_success '--show-origin getting a single key' '
cat >expect <<-\EOF &&
- file:.git/config local
+ file:.git/config local
EOF
git config --show-origin user.override >output &&
test_cmp expect output
@@ -1712,14 +1712,14 @@ test_expect_success '--show-origin getting a single key' '
test_expect_success 'set up custom config file' '
CUSTOM_CONFIG_FILE="file\" (dq) and spaces.conf" &&
cat >"$CUSTOM_CONFIG_FILE" <<-\EOF
- [user]
- custom = true
+ [user]
+ custom = true
EOF
'
test_expect_success !MINGW '--show-origin escape special file name characters' '
cat >expect <<-\EOF &&
- file:"file\" (dq) and spaces.conf" user.custom=true
+ file:"file\" (dq) and spaces.conf" user.custom=true
EOF
git config --file "$CUSTOM_CONFIG_FILE" --show-origin --list >output &&
test_cmp expect output
@@ -1727,7 +1727,7 @@ test_expect_success !MINGW '--show-origin escape special file name characters' '
test_expect_success '--show-origin stdin' '
cat >expect <<-\EOF &&
- standard input: user.custom=true
+ standard input: user.custom=true
EOF
git config --file - --show-origin --list <"$CUSTOM_CONFIG_FILE" >output &&
test_cmp expect output
@@ -1735,11 +1735,11 @@ test_expect_success '--show-origin stdin' '
test_expect_success '--show-origin stdin with file include' '
cat >"$INCLUDE_DIR"/stdin.include <<-EOF &&
- [user]
- stdin = include
+ [user]
+ stdin = include
EOF
cat >expect <<-EOF &&
- file:$INCLUDE_DIR/stdin.include include
+ file:$INCLUDE_DIR/stdin.include include
EOF
echo "[include]path=\"$INCLUDE_DIR\"/stdin.include" |
git config --show-origin --includes --file - user.stdin >output &&
@@ -1750,7 +1750,7 @@ test_expect_success '--show-origin stdin with file include' '
test_expect_success !MINGW '--show-origin blob' '
blob=$(git hash-object -w "$CUSTOM_CONFIG_FILE") &&
cat >expect <<-EOF &&
- blob:$blob user.custom=true
+ blob:$blob user.custom=true
EOF
git config --blob=$blob --show-origin --list >output &&
test_cmp expect output
@@ -1758,7 +1758,7 @@ test_expect_success !MINGW '--show-origin blob' '
test_expect_success !MINGW '--show-origin blob ref' '
cat >expect <<-\EOF &&
- blob:"master:file\" (dq) and spaces.conf" user.custom=true
+ blob:"master:file\" (dq) and spaces.conf" user.custom=true
EOF
git add "$CUSTOM_CONFIG_FILE" &&
git commit -m "new config file" &&
--
gitgitgadget
^ permalink raw reply related [relevance 6%]
* Re: [PATCH v2 0/6] Extensions of core.ignorecase=true support
@ 2010-10-06 22:46 6% ` Joshua Jensen
0 siblings, 0 replies; 200+ results
From: Joshua Jensen @ 2010-10-06 22:46 UTC (permalink / raw)
To: Robert Buck; +Cc: Johannes Sixt, git
----- Original Message -----
From: Robert Buck
Date: 10/6/2010 4:04 PM
> Let's say I want to have .gitignore be case insensitive with respect
> to matches so I can simplify the file by not having [D][d]ebug sorts
> of messes. But let's say I also want to support files whose names only
> differ by case (just like Unix supports). Can your current patch
> series support this? Does the current patch series break this?
>
> Could you share how this would or would not work, and if not, how you
> might accomplish this?
With this patch series, you are either on a case sensitive file system
(core.ignorecase = false) or a case insensitive file system
(core.ignorecase = true).
There is no specific configuration for .gitignore case insensitivity.
It only pays attention to core.ignorecase.
This is something that could be added, but I don't fully understand the
need. On case sensitive file systems, the case of the resultant
filename is guaranteed. If you have both a Debug/ and debug/ directory,
I would expect two entries in the .gitignore.
?
Josh
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition
@ 2022-11-22 14:31 6% ` Phillip Wood
0 siblings, 0 replies; 200+ results
From: Phillip Wood @ 2022-11-22 14:31 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason,
Johannes Schindelin via GitGitGadget
Cc: git, Phillip Wood, Johannes Schindelin
On 22/11/2022 14:01, Ævar Arnfjörð Bjarmason wrote:
>
> On Mon, Nov 21 2022, Johannes Schindelin via GitGitGadget wrote:
>
>> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>>
>> +`os`::
>> + The data that follows this keyword is taken as the name of an
>> + Operating System, e.g. `Linux` or `Windows`; If it matches the
>> + current Operating System, the include condition is met.
>> +
>> A few more notes on matching via `gitdir` and `gitdir/i`:
>
> The reste of the "includeif" use glob matching and "/i" for icase. IOW
> this is how this new feature would fit in:
>
> |--------+--------+----------+----------+------------------+----|
> | | gitdir | gitdir/i | onbranch | hasconfig:remote | os |
> |--------+--------+----------+----------+------------------+----|
> | icase? | N | Y | N | N | Y |
> | glob? | Y | Y | Y | Y | N |
> | path? | Y | Y | Y | Y | N |
> |--------+--------+----------+----------+------------------+----|
>
> I think at least flipping that "glob" to "Y" so you could match e.g.
> "*BSD" would be useful, and easier to explain in context, rather than
> why the rest use wildmatch() and this doesn't.
Globbing could be useful for the BSDs.
One other thing I thought of is will users know "Darwin" means MacOS?
> For matching the uname the case doesn't really matter, but for
> consistency of the interface I think making it case-sensitive or adding
> an "os/i" would make sense. I.e. let's consistently use "/i" if & when
> something's case-insensitive.
All the other items listed in your table such as branch names are case
sensitive. The os name is not so it is of no benefit at all to the user
to match it case sensitively. Let's consistently test case sensitive
keys cases sensitively and case insensitive keys case insensitively.
Best Wishes
Phillip
>> +test_expect_success '[includeIf "os:..."]' '
>> + test_config x.y 0 &&
>> + echo "[x] y = z" >.git/xyz &&
>> +
>> + if test_have_prereq MINGW
>> + then
>> + uname_s=Windows
>> + else
>> + uname_s="$(uname -s)"
>> + fi &&
>> + test_config "includeIf.os:not-$uname_s.path" xyz &&
>> + test 0 = "$(git config x.y)" &&
>> + test_config "includeIf.os:$uname_s.path" xyz &&
>> + test z = "$(git config x.y)"
>> +'
>
> As I pointed out in the v1, this still:
>
> * Hides segfaults in "git config", let's check the exit code.
> * Doesn't test the "icase" semantics you're introducing. Let's do that
> if it's intentional.
^ permalink raw reply [relevance 6%]
* [PATCH v4 2/6] t1300: fix over-indented HERE-DOCs
@ 2020-01-24 0:21 6% ` Matthew Rogers via GitGitGadget
1 sibling, 0 replies; 200+ results
From: Matthew Rogers via GitGitGadget @ 2020-01-24 0:21 UTC (permalink / raw)
To: git; +Cc: Matthew Rogers, Matthew Rogers
From: Matthew Rogers <mattr94@gmail.com>
Prepare for the following patches by removing extraneous indents from
HERE-DOCs used in config tests.
Signed-off-by: Matthew Rogers <mattr94@gmail.com>
---
t/t1300-config.sh | 168 +++++++++++++++++++++++-----------------------
1 file changed, 84 insertions(+), 84 deletions(-)
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index 983a0a1583..e8b4575758 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -1191,47 +1191,47 @@ test_expect_success 'old-fashioned settings are case insensitive' '
test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
cat >testConfig_actual <<-EOF &&
- [V.A]
- r = value1
+ [V.A]
+ r = value1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V.A]
- Qr = value2
+ [V.A]
+ Qr = value2
EOF
git config -f testConfig_actual "v.a.r" value2 &&
test_cmp testConfig_expect testConfig_actual &&
cat >testConfig_actual <<-EOF &&
- [V.A]
- r = value1
+ [V.A]
+ r = value1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V.A]
- QR = value2
+ [V.A]
+ QR = value2
EOF
git config -f testConfig_actual "V.a.R" value2 &&
test_cmp testConfig_expect testConfig_actual &&
cat >testConfig_actual <<-EOF &&
- [V.A]
- r = value1
+ [V.A]
+ r = value1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V.A]
- r = value1
- Qr = value2
+ [V.A]
+ r = value1
+ Qr = value2
EOF
git config -f testConfig_actual "V.A.r" value2 &&
test_cmp testConfig_expect testConfig_actual &&
cat >testConfig_actual <<-EOF &&
- [V.A]
- r = value1
+ [V.A]
+ r = value1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V.A]
- r = value1
- Qr = value2
+ [V.A]
+ r = value1
+ Qr = value2
EOF
git config -f testConfig_actual "v.A.r" value2 &&
test_cmp testConfig_expect testConfig_actual
@@ -1241,26 +1241,26 @@ test_expect_success 'setting different case sensitive subsections ' '
test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
cat >testConfig_actual <<-EOF &&
- [V "A"]
- R = v1
- [K "E"]
- Y = v1
- [a "b"]
- c = v1
- [d "e"]
- f = v1
+ [V "A"]
+ R = v1
+ [K "E"]
+ Y = v1
+ [a "b"]
+ c = v1
+ [d "e"]
+ f = v1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V "A"]
- Qr = v2
- [K "E"]
- Qy = v2
- [a "b"]
- Qc = v2
- [d "e"]
- f = v1
- [d "E"]
- Qf = v2
+ [V "A"]
+ Qr = v2
+ [K "E"]
+ Qy = v2
+ [a "b"]
+ Qc = v2
+ [d "e"]
+ f = v1
+ [d "E"]
+ Qf = v2
EOF
# exact match
git config -f testConfig_actual a.b.c v2 &&
@@ -1622,40 +1622,40 @@ test_expect_success 'set up --show-origin tests' '
INCLUDE_DIR="$HOME/include" &&
mkdir -p "$INCLUDE_DIR" &&
cat >"$INCLUDE_DIR"/absolute.include <<-\EOF &&
- [user]
- absolute = include
+ [user]
+ absolute = include
EOF
cat >"$INCLUDE_DIR"/relative.include <<-\EOF &&
- [user]
- relative = include
+ [user]
+ relative = include
EOF
cat >"$HOME"/.gitconfig <<-EOF &&
- [user]
- global = true
- override = global
- [include]
- path = "$INCLUDE_DIR/absolute.include"
+ [user]
+ global = true
+ override = global
+ [include]
+ path = "$INCLUDE_DIR/absolute.include"
EOF
cat >.git/config <<-\EOF
- [user]
- local = true
- override = local
- [include]
- path = ../include/relative.include
+ [user]
+ local = true
+ override = local
+ [include]
+ path = ../include/relative.include
EOF
'
test_expect_success '--show-origin with --list' '
cat >expect <<-EOF &&
- file:$HOME/.gitconfig user.global=true
- file:$HOME/.gitconfig user.override=global
- file:$HOME/.gitconfig include.path=$INCLUDE_DIR/absolute.include
- file:$INCLUDE_DIR/absolute.include user.absolute=include
- file:.git/config user.local=true
- file:.git/config user.override=local
- file:.git/config include.path=../include/relative.include
- file:.git/../include/relative.include user.relative=include
- command line: user.cmdline=true
+ file:$HOME/.gitconfig user.global=true
+ file:$HOME/.gitconfig user.override=global
+ file:$HOME/.gitconfig include.path=$INCLUDE_DIR/absolute.include
+ file:$INCLUDE_DIR/absolute.include user.absolute=include
+ file:.git/config user.local=true
+ file:.git/config user.override=local
+ file:.git/config include.path=../include/relative.include
+ file:.git/../include/relative.include user.relative=include
+ command line: user.cmdline=true
EOF
git -c user.cmdline=true config --list --show-origin >output &&
test_cmp expect output
@@ -1663,16 +1663,16 @@ test_expect_success '--show-origin with --list' '
test_expect_success '--show-origin with --list --null' '
cat >expect <<-EOF &&
- file:$HOME/.gitconfigQuser.global
- trueQfile:$HOME/.gitconfigQuser.override
- globalQfile:$HOME/.gitconfigQinclude.path
- $INCLUDE_DIR/absolute.includeQfile:$INCLUDE_DIR/absolute.includeQuser.absolute
- includeQfile:.git/configQuser.local
- trueQfile:.git/configQuser.override
- localQfile:.git/configQinclude.path
- ../include/relative.includeQfile:.git/../include/relative.includeQuser.relative
- includeQcommand line:Quser.cmdline
- trueQ
+ file:$HOME/.gitconfigQuser.global
+ trueQfile:$HOME/.gitconfigQuser.override
+ globalQfile:$HOME/.gitconfigQinclude.path
+ $INCLUDE_DIR/absolute.includeQfile:$INCLUDE_DIR/absolute.includeQuser.absolute
+ includeQfile:.git/configQuser.local
+ trueQfile:.git/configQuser.override
+ localQfile:.git/configQinclude.path
+ ../include/relative.includeQfile:.git/../include/relative.includeQuser.relative
+ includeQcommand line:Quser.cmdline
+ trueQ
EOF
git -c user.cmdline=true config --null --list --show-origin >output.raw &&
nul_to_q <output.raw >output &&
@@ -1684,9 +1684,9 @@ test_expect_success '--show-origin with --list --null' '
test_expect_success '--show-origin with single file' '
cat >expect <<-\EOF &&
- file:.git/config user.local=true
- file:.git/config user.override=local
- file:.git/config include.path=../include/relative.include
+ file:.git/config user.local=true
+ file:.git/config user.override=local
+ file:.git/config include.path=../include/relative.include
EOF
git config --local --list --show-origin >output &&
test_cmp expect output
@@ -1694,8 +1694,8 @@ test_expect_success '--show-origin with single file' '
test_expect_success '--show-origin with --get-regexp' '
cat >expect <<-EOF &&
- file:$HOME/.gitconfig user.global true
- file:.git/config user.local true
+ file:$HOME/.gitconfig user.global true
+ file:.git/config user.local true
EOF
git config --show-origin --get-regexp "user\.[g|l].*" >output &&
test_cmp expect output
@@ -1703,7 +1703,7 @@ test_expect_success '--show-origin with --get-regexp' '
test_expect_success '--show-origin getting a single key' '
cat >expect <<-\EOF &&
- file:.git/config local
+ file:.git/config local
EOF
git config --show-origin user.override >output &&
test_cmp expect output
@@ -1712,14 +1712,14 @@ test_expect_success '--show-origin getting a single key' '
test_expect_success 'set up custom config file' '
CUSTOM_CONFIG_FILE="file\" (dq) and spaces.conf" &&
cat >"$CUSTOM_CONFIG_FILE" <<-\EOF
- [user]
- custom = true
+ [user]
+ custom = true
EOF
'
test_expect_success !MINGW '--show-origin escape special file name characters' '
cat >expect <<-\EOF &&
- file:"file\" (dq) and spaces.conf" user.custom=true
+ file:"file\" (dq) and spaces.conf" user.custom=true
EOF
git config --file "$CUSTOM_CONFIG_FILE" --show-origin --list >output &&
test_cmp expect output
@@ -1727,7 +1727,7 @@ test_expect_success !MINGW '--show-origin escape special file name characters' '
test_expect_success '--show-origin stdin' '
cat >expect <<-\EOF &&
- standard input: user.custom=true
+ standard input: user.custom=true
EOF
git config --file - --show-origin --list <"$CUSTOM_CONFIG_FILE" >output &&
test_cmp expect output
@@ -1735,11 +1735,11 @@ test_expect_success '--show-origin stdin' '
test_expect_success '--show-origin stdin with file include' '
cat >"$INCLUDE_DIR"/stdin.include <<-EOF &&
- [user]
- stdin = include
+ [user]
+ stdin = include
EOF
cat >expect <<-EOF &&
- file:$INCLUDE_DIR/stdin.include include
+ file:$INCLUDE_DIR/stdin.include include
EOF
echo "[include]path=\"$INCLUDE_DIR\"/stdin.include" |
git config --show-origin --includes --file - user.stdin >output &&
@@ -1750,7 +1750,7 @@ test_expect_success '--show-origin stdin with file include' '
test_expect_success !MINGW '--show-origin blob' '
blob=$(git hash-object -w "$CUSTOM_CONFIG_FILE") &&
cat >expect <<-EOF &&
- blob:$blob user.custom=true
+ blob:$blob user.custom=true
EOF
git config --blob=$blob --show-origin --list >output &&
test_cmp expect output
@@ -1758,7 +1758,7 @@ test_expect_success !MINGW '--show-origin blob' '
test_expect_success !MINGW '--show-origin blob ref' '
cat >expect <<-\EOF &&
- blob:"master:file\" (dq) and spaces.conf" user.custom=true
+ blob:"master:file\" (dq) and spaces.conf" user.custom=true
EOF
git add "$CUSTOM_CONFIG_FILE" &&
git commit -m "new config file" &&
--
gitgitgadget
^ permalink raw reply related [relevance 6%]
* [PATCH v5 2/6] t1300: fix over-indented HERE-DOCs
@ 2020-01-25 0:39 6% ` Matthew Rogers via GitGitGadget
1 sibling, 0 replies; 200+ results
From: Matthew Rogers via GitGitGadget @ 2020-01-25 0:39 UTC (permalink / raw)
To: git; +Cc: Matthew Rogers, Matthew Rogers
From: Matthew Rogers <mattr94@gmail.com>
Prepare for the following patches by removing extraneous indents from
HERE-DOCs used in config tests.
Signed-off-by: Matthew Rogers <mattr94@gmail.com>
---
t/t1300-config.sh | 168 +++++++++++++++++++++++-----------------------
1 file changed, 84 insertions(+), 84 deletions(-)
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index 983a0a1583..e8b4575758 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -1191,47 +1191,47 @@ test_expect_success 'old-fashioned settings are case insensitive' '
test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
cat >testConfig_actual <<-EOF &&
- [V.A]
- r = value1
+ [V.A]
+ r = value1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V.A]
- Qr = value2
+ [V.A]
+ Qr = value2
EOF
git config -f testConfig_actual "v.a.r" value2 &&
test_cmp testConfig_expect testConfig_actual &&
cat >testConfig_actual <<-EOF &&
- [V.A]
- r = value1
+ [V.A]
+ r = value1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V.A]
- QR = value2
+ [V.A]
+ QR = value2
EOF
git config -f testConfig_actual "V.a.R" value2 &&
test_cmp testConfig_expect testConfig_actual &&
cat >testConfig_actual <<-EOF &&
- [V.A]
- r = value1
+ [V.A]
+ r = value1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V.A]
- r = value1
- Qr = value2
+ [V.A]
+ r = value1
+ Qr = value2
EOF
git config -f testConfig_actual "V.A.r" value2 &&
test_cmp testConfig_expect testConfig_actual &&
cat >testConfig_actual <<-EOF &&
- [V.A]
- r = value1
+ [V.A]
+ r = value1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V.A]
- r = value1
- Qr = value2
+ [V.A]
+ r = value1
+ Qr = value2
EOF
git config -f testConfig_actual "v.A.r" value2 &&
test_cmp testConfig_expect testConfig_actual
@@ -1241,26 +1241,26 @@ test_expect_success 'setting different case sensitive subsections ' '
test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
cat >testConfig_actual <<-EOF &&
- [V "A"]
- R = v1
- [K "E"]
- Y = v1
- [a "b"]
- c = v1
- [d "e"]
- f = v1
+ [V "A"]
+ R = v1
+ [K "E"]
+ Y = v1
+ [a "b"]
+ c = v1
+ [d "e"]
+ f = v1
EOF
q_to_tab >testConfig_expect <<-EOF &&
- [V "A"]
- Qr = v2
- [K "E"]
- Qy = v2
- [a "b"]
- Qc = v2
- [d "e"]
- f = v1
- [d "E"]
- Qf = v2
+ [V "A"]
+ Qr = v2
+ [K "E"]
+ Qy = v2
+ [a "b"]
+ Qc = v2
+ [d "e"]
+ f = v1
+ [d "E"]
+ Qf = v2
EOF
# exact match
git config -f testConfig_actual a.b.c v2 &&
@@ -1622,40 +1622,40 @@ test_expect_success 'set up --show-origin tests' '
INCLUDE_DIR="$HOME/include" &&
mkdir -p "$INCLUDE_DIR" &&
cat >"$INCLUDE_DIR"/absolute.include <<-\EOF &&
- [user]
- absolute = include
+ [user]
+ absolute = include
EOF
cat >"$INCLUDE_DIR"/relative.include <<-\EOF &&
- [user]
- relative = include
+ [user]
+ relative = include
EOF
cat >"$HOME"/.gitconfig <<-EOF &&
- [user]
- global = true
- override = global
- [include]
- path = "$INCLUDE_DIR/absolute.include"
+ [user]
+ global = true
+ override = global
+ [include]
+ path = "$INCLUDE_DIR/absolute.include"
EOF
cat >.git/config <<-\EOF
- [user]
- local = true
- override = local
- [include]
- path = ../include/relative.include
+ [user]
+ local = true
+ override = local
+ [include]
+ path = ../include/relative.include
EOF
'
test_expect_success '--show-origin with --list' '
cat >expect <<-EOF &&
- file:$HOME/.gitconfig user.global=true
- file:$HOME/.gitconfig user.override=global
- file:$HOME/.gitconfig include.path=$INCLUDE_DIR/absolute.include
- file:$INCLUDE_DIR/absolute.include user.absolute=include
- file:.git/config user.local=true
- file:.git/config user.override=local
- file:.git/config include.path=../include/relative.include
- file:.git/../include/relative.include user.relative=include
- command line: user.cmdline=true
+ file:$HOME/.gitconfig user.global=true
+ file:$HOME/.gitconfig user.override=global
+ file:$HOME/.gitconfig include.path=$INCLUDE_DIR/absolute.include
+ file:$INCLUDE_DIR/absolute.include user.absolute=include
+ file:.git/config user.local=true
+ file:.git/config user.override=local
+ file:.git/config include.path=../include/relative.include
+ file:.git/../include/relative.include user.relative=include
+ command line: user.cmdline=true
EOF
git -c user.cmdline=true config --list --show-origin >output &&
test_cmp expect output
@@ -1663,16 +1663,16 @@ test_expect_success '--show-origin with --list' '
test_expect_success '--show-origin with --list --null' '
cat >expect <<-EOF &&
- file:$HOME/.gitconfigQuser.global
- trueQfile:$HOME/.gitconfigQuser.override
- globalQfile:$HOME/.gitconfigQinclude.path
- $INCLUDE_DIR/absolute.includeQfile:$INCLUDE_DIR/absolute.includeQuser.absolute
- includeQfile:.git/configQuser.local
- trueQfile:.git/configQuser.override
- localQfile:.git/configQinclude.path
- ../include/relative.includeQfile:.git/../include/relative.includeQuser.relative
- includeQcommand line:Quser.cmdline
- trueQ
+ file:$HOME/.gitconfigQuser.global
+ trueQfile:$HOME/.gitconfigQuser.override
+ globalQfile:$HOME/.gitconfigQinclude.path
+ $INCLUDE_DIR/absolute.includeQfile:$INCLUDE_DIR/absolute.includeQuser.absolute
+ includeQfile:.git/configQuser.local
+ trueQfile:.git/configQuser.override
+ localQfile:.git/configQinclude.path
+ ../include/relative.includeQfile:.git/../include/relative.includeQuser.relative
+ includeQcommand line:Quser.cmdline
+ trueQ
EOF
git -c user.cmdline=true config --null --list --show-origin >output.raw &&
nul_to_q <output.raw >output &&
@@ -1684,9 +1684,9 @@ test_expect_success '--show-origin with --list --null' '
test_expect_success '--show-origin with single file' '
cat >expect <<-\EOF &&
- file:.git/config user.local=true
- file:.git/config user.override=local
- file:.git/config include.path=../include/relative.include
+ file:.git/config user.local=true
+ file:.git/config user.override=local
+ file:.git/config include.path=../include/relative.include
EOF
git config --local --list --show-origin >output &&
test_cmp expect output
@@ -1694,8 +1694,8 @@ test_expect_success '--show-origin with single file' '
test_expect_success '--show-origin with --get-regexp' '
cat >expect <<-EOF &&
- file:$HOME/.gitconfig user.global true
- file:.git/config user.local true
+ file:$HOME/.gitconfig user.global true
+ file:.git/config user.local true
EOF
git config --show-origin --get-regexp "user\.[g|l].*" >output &&
test_cmp expect output
@@ -1703,7 +1703,7 @@ test_expect_success '--show-origin with --get-regexp' '
test_expect_success '--show-origin getting a single key' '
cat >expect <<-\EOF &&
- file:.git/config local
+ file:.git/config local
EOF
git config --show-origin user.override >output &&
test_cmp expect output
@@ -1712,14 +1712,14 @@ test_expect_success '--show-origin getting a single key' '
test_expect_success 'set up custom config file' '
CUSTOM_CONFIG_FILE="file\" (dq) and spaces.conf" &&
cat >"$CUSTOM_CONFIG_FILE" <<-\EOF
- [user]
- custom = true
+ [user]
+ custom = true
EOF
'
test_expect_success !MINGW '--show-origin escape special file name characters' '
cat >expect <<-\EOF &&
- file:"file\" (dq) and spaces.conf" user.custom=true
+ file:"file\" (dq) and spaces.conf" user.custom=true
EOF
git config --file "$CUSTOM_CONFIG_FILE" --show-origin --list >output &&
test_cmp expect output
@@ -1727,7 +1727,7 @@ test_expect_success !MINGW '--show-origin escape special file name characters' '
test_expect_success '--show-origin stdin' '
cat >expect <<-\EOF &&
- standard input: user.custom=true
+ standard input: user.custom=true
EOF
git config --file - --show-origin --list <"$CUSTOM_CONFIG_FILE" >output &&
test_cmp expect output
@@ -1735,11 +1735,11 @@ test_expect_success '--show-origin stdin' '
test_expect_success '--show-origin stdin with file include' '
cat >"$INCLUDE_DIR"/stdin.include <<-EOF &&
- [user]
- stdin = include
+ [user]
+ stdin = include
EOF
cat >expect <<-EOF &&
- file:$INCLUDE_DIR/stdin.include include
+ file:$INCLUDE_DIR/stdin.include include
EOF
echo "[include]path=\"$INCLUDE_DIR\"/stdin.include" |
git config --show-origin --includes --file - user.stdin >output &&
@@ -1750,7 +1750,7 @@ test_expect_success '--show-origin stdin with file include' '
test_expect_success !MINGW '--show-origin blob' '
blob=$(git hash-object -w "$CUSTOM_CONFIG_FILE") &&
cat >expect <<-EOF &&
- blob:$blob user.custom=true
+ blob:$blob user.custom=true
EOF
git config --blob=$blob --show-origin --list >output &&
test_cmp expect output
@@ -1758,7 +1758,7 @@ test_expect_success !MINGW '--show-origin blob' '
test_expect_success !MINGW '--show-origin blob ref' '
cat >expect <<-\EOF &&
- blob:"master:file\" (dq) and spaces.conf" user.custom=true
+ blob:"master:file\" (dq) and spaces.conf" user.custom=true
EOF
git add "$CUSTOM_CONFIG_FILE" &&
git commit -m "new config file" &&
--
gitgitgadget
^ permalink raw reply related [relevance 6%]
* Re: Request for detailed documentation of git pack protocol
@ 2009-06-04 8:45 6% ` Jakub Narebski
2009-06-04 18:41 6% ` Shawn O. Pearce
0 siblings, 1 reply; 200+ results
From: Jakub Narebski @ 2009-06-04 8:45 UTC (permalink / raw)
To: Tony Finch; +Cc: Shawn O. Pearce, Scott Chacon, git
Dnia środa 3. czerwca 2009 23:53, Tony Finch napisał:
> On Wed, 3 Jun 2009, Jakub Narebski wrote:
> >
> > Actually git accepts both lowercase and uppercase in HEXDIG (at least
> > for pkt-length), but it prefers lowercase.
>
> You should ensure that all hex digit strings follow the same rule.
> Are SHA-1 object names case insensitive too?
>
> Case insensitivity has a history of being awkward. SMTP has always had
> case-insensitive commands, though the RFCs have always written them in
> upper case and implementations have pretty much all emitted them in upper
> case. See http://tools.ietf.org/html/rfc5321#section-2.4 especially the
> caveat about broken case-sensitive implementations.
There should be no problem with pkt-length being case insensitive, as
standard conversion routines (strtol, sprintf) accept 0-9a-fA-F for
base 16 / hexadecimal conversion. The requirement here is that client
and server SHOULD use lowercase, but MUST accept mixed case (do case
insensitive parsing of hex4).
I think SHA-1 is lowercased, so mixed case should work there. Well, at
least "git show 6096D7" (note the uppercase 'D' in shortened SHA-1 name)
works as expected.
But I do not know what are, or what should be protocol requirements.
Should SHA-1 use lowercase, or be case insensitive? Should commands such
as "have", "want", "done" use lower case or be case insensitive? Should
status indicators "ACK" and "NAK" be upper case, or should be case
insensitive? Should capabilities be case sensitive, and should they be
compared case sensitive or not?
--
Jakub Narebski
Poland
^ permalink raw reply [relevance 6%]
* Re: [PATCH 00/30] [RFC] extensions.refFormat and packed-refs v2 file format
@ 2022-11-16 14:45 6% ` Derrick Stolee
0 siblings, 0 replies; 200+ results
From: Derrick Stolee @ 2022-11-16 14:45 UTC (permalink / raw)
To: Elijah Newren; +Cc: Derrick Stolee via GitGitGadget, git, jrnieder
On 11/14/22 9:47 PM, Elijah Newren wrote:
> On Sun, Nov 13, 2022 at 4:07 PM Derrick Stolee <derrickstolee@github.com> wrote:
>>
>> On 11/11/22 6:28 PM, Elijah Newren wrote:
>>> On Mon, Nov 7, 2022 at 11:01 AM Derrick Stolee via GitGitGadget
>>> <gitgitgadget@gmail.com> wrote:
>>>>
>>>> Introduction
>>>> ============
>>>>
>>>> I became interested in our packed-ref format based on the asymmetry between
>>>> ref updates and ref deletions: if we delete a packed ref, then the
>>>> packed-refs file needs to be rewritten. Compared to writing a loose ref,
>>>> this is an O(N) cost instead of O(1).
>>>>
>>>> In this way, I set out with some goals:
>>>>
>>>> * (Primary) Make packed ref deletions be nearly as fast as loose ref
>>>> updates.
>>>
>>> Performance is always nice. :-)
>>>
>>>> * (Secondary) Allow using a packed ref format for all refs, dropping loose
>>>> refs and creating a clear way to snapshot all refs at a given point in
>>>> time.
>>>
>>> Is this secondary goal the actual goal you have, or just the
>>> implementation by which you get the real underlying goal?
>>
>> To me, the primary goal takes precedence. It turns out that the best
>> way to solve for that goal happens to also make it possible to store
>> all refs in a packed form, because we can update the packed form
>> much faster than our current setup. There are alternatives that I
>> considered (and prototyped) that were more specific to the deletions
>> case, but they were not actually as fast as the stacked method. Those
>> alternatives also would never help reach the secondary goal, but I
>> probably would have considered them anyway if they were faster, if
>> only for their simplicity.
>
> That's orthogonal to my question, though. For your primary goal, you
> stated it in a form where it was obvious what benefit it would provide
> to end users. Your secondary goal, as stated, didn't list any benefit
> to end users that I could see (update: reading the rest of your
> response it appears I just didn't understand it), so I was trying to
> guess at why your secondary goal might be a goal, i.e. what the real
> secondary goal was.
The reason is in the goal "creating a clear way to snapshot all refs
at a given point in time". This is a server-side benefit with no
visible benefit to users, immediately.
The D/F conflicts and case-sensitive parts that could fall from that
are not included in my goals. Part of that is because we would need a
new reflog format to complete that part. Let's take things one step
at a time and handle reflogs after we have ref update performance
handled.
>>> To me, it appears that such a capability would solve both (a) D/F
>>> conflict problems (i.e. the ability to simultaneously have a
>>> refs/heads/feature and refs/heads/feature/shiny ref), and (b) case
>>> sensitivity issues in refnames (i.e. inability of some users to work
>>> with both a refs/heads/feature and a refs/heads/FeAtUrE, due to
>>> constraints of their filesystem and the loose storage mechanism). Are
>>> either of those the goal you are trying to achieve (I think both would
>>> be really nice, more so than the performance goal you have), or is
>>> there another?
>>
>> For a Git host provider, these D/F conflict and case-sensitivity
>> situations probably would need to stay as restrictions on the
>> server side for quite some time because we don't want users on
>> older Git clients to be unable to fetch a repository just because
>> we updated our ref storage to allow for such possibilities.
>
> Okay, but even if not used on the server side, this capability could
> still be used on the client side and provide a big benefit to end
> users.
>
> But I think there's a minor issue with what you stated; as far as I
> can tell, there is no case-sensitivity restriction on the server side
> for GitHub currently, and users do currently have problems cloning and
> using repositories with branches that differ in case only. See e.g.
> https://github.com/newren/git-filter-repo/issues/48 and the multiple
> duplicates which reference that issue. We've also had issues at
> $DAYJOB, though for GHE we added some hooks to deny creating branches
> that differ only in case from another branch to avoid the problem.
Yes, you're right here. We could do better in rejecting case-sensitive
matches upon request.
> Also, D/F restrictions on the server do not stop users from having D/F
> problems when fetching. If users forget to use `--prune`, then when a
> refs/heads/foo has already been fetched is deleted and replaced by a
> refs/heads/foo/bar, then the user gets errors. This issue actually
> caused a bit of a fire-drill for us just recently.
And similar to the case-sensitive situation, I'm not sure if we have
checks to avoid D/F conflicts if they happen across the loose/packed
boundary. We might just be using the filesystem as a constraint. I'll
need to dig in more here.
(This is all the more reason why this space is already complicated and
will take some time to unwind.)
> So both kinds of problems already exist, for users with any git client
> version (although the former only for users with unfortunate file
> systems). And both problems cause pain. Both issues are caused by
> loose refs, so limiting git storage to packed refs would fix both
> issues.
>
>> The biggest benefit on the server side is actually for consistency
>> checks. Using a stacked packed-refs (especially with a tip file
>> that describes all of the layers) allows an atomic way to take a
>> snapshot of the refs and run a checksum operation on their values.
>> With loose refs, concurrent updates can modify the checksum during
>> its computation. This is a super niche reason for this, but it's
>> nice that the performance-only focus also ends up with a design
>> that satisfies this goal.
>
> Ah...so this is the reason for your secondary goal? Re-reading it
> looks like you did state this, I just missed it without the longer
> explanation.
>
> Anyway, it might be worth calling out in your cover letter that there
> are (at least) three benefits to this secondary goal of yours -- the
> one you list here, plus the two I list above.
I suppose I assumed that the D/F and case conflicts were a "known"
benefit and a huge motivation of the reftable work. Instead of trying
to solve all of the ref problems at once, I wanted to focus on the
subset that I knew could be solved with a simpler solution, leaving
the full solution to later steps. It would help to be explicit about
how this direction helps solve this problem while also being clear
about how it does not solve it completely.
Thanks,
-Stolee
^ permalink raw reply [relevance 6%]
* Re: [RFC] Case insensitive Git attributes
@ 2017-01-23 18:42 6% ` Lars Schneider
2017-01-23 19:25 6% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Lars Schneider @ 2017-01-23 18:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dakota Hawkins, Duy Nguyen, Johannes Schindelin, Stefan Beller,
git
> On 23 Jan 2017, at 19:35, Junio C Hamano <gitster@pobox.com> wrote:
>
> Dakota Hawkins <dakota@dakotahawkins.com> writes:
>
>> Apologies for the delayed bump. I think because we're talking about
>> affecting the behavior of .gitattributes that it would be better to
>> have a distinct .gitattributes option, whether or not you also have a
>> similar config option.
>
> As I know I am on the To: line of the message I am responding to,
> let me quicly let you know that I won't be responding to this thread
> for a while as I don't recall what the discussion was about. I will
> after I'll dig and find out what the thread was about but it won't
> happen immediately. Sorry about that.
Problem:
Git attributes for path names are generally case sensitive. However, on
a case insensitive file system (e.g. macOS/Windows) they appear to be
case insensitive (`*.bar` would match `foo.bar` and `foo.BAR`). That
works great until a Git users joins the party with a case sensitive file
system. For this Git user the attributes pattern only matches files with
the exact case (*.bar` would match only `foo.bar`).
Question/Proposal:
Could we introduce some flag to signal that certain attribute patterns
are always case insensitive?
Thread:
http://public-inbox.org/git/C83BE22D-EAC8-49E2-AEE3-22D4A99AE205@gmail.com/#t
Cheers,
Lars
^ permalink raw reply [relevance 6%]
* Re: Request for detailed documentation of git pack protocol
2009-06-04 8:45 6% ` Jakub Narebski
@ 2009-06-04 18:41 6% ` Shawn O. Pearce
0 siblings, 0 replies; 200+ results
From: Shawn O. Pearce @ 2009-06-04 18:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Tony Finch, Scott Chacon, git
Jakub Narebski <jnareb@gmail.com> wrote:
> Dnia ?roda 3. czerwca 2009 23:53, Tony Finch napisa?:
> > On Wed, 3 Jun 2009, Jakub Narebski wrote:
> > >
> > > Actually git accepts both lowercase and uppercase in HEXDIG (at least
> > > for pkt-length), but it prefers lowercase.
> >
> > You should ensure that all hex digit strings follow the same rule.
> > Are SHA-1 object names case insensitive too?
> >
> > Case insensitivity has a history of being awkward. SMTP has always had
> > case-insensitive commands, though the RFCs have always written them in
> > upper case and implementations have pretty much all emitted them in upper
> > case. See http://tools.ietf.org/html/rfc5321#section-2.4 especially the
> > caveat about broken case-sensitive implementations.
>
> There should be no problem with pkt-length being case insensitive, as
> standard conversion routines (strtol, sprintf) accept 0-9a-fA-F for
> base 16 / hexadecimal conversion. The requirement here is that client
> and server SHOULD use lowercase, but MUST accept mixed case (do case
> insensitive parsing of hex4).
ACK. This is what C Git does today. JGit sends lower case, but
is wrong by only accepting lowercase. I will patch it today to
accept mixed case.
> I think SHA-1 is lowercased, so mixed case should work there. Well, at
> least "git show 6096D7" (note the uppercase 'D' in shortened SHA-1 name)
> works as expected.
ACK. Mixed case SHA-1 MUST be accepted, but lower case SHOULD
be output.
> But I do not know what are, or what should be protocol requirements.
> Should SHA-1 use lowercase, or be case insensitive?
SHA-1 SHOULD be lowercase (a-f), MUST accept a-f or A-F.
> Should commands such as "have", "want", "done" use lower case or
> be case insensitive?
These MUST be lowercase.
> Should status indicators "ACK" and "NAK" be upper case,
These MUST be uppercase. Though "ACK %s continue" MUST be mixed
case, as I just wrote it.
> Should capabilities be case sensitive, and should they be
> compared case sensitive or not?
No, they are case sensitive.
Why? All of the above is the current C code implementation.
We have to follow what the code does today, and it does case
sensitive compares almost everywhere... except in the SHA-1 parsing.
--
Shawn.
^ permalink raw reply [relevance 6%]
* [PATCH v5 08/10] wildmatch test: create & test files on disk in addition to in-memory
@ 2018-01-30 21:21 6% ` Ævar Arnfjörð Bjarmason
2018-01-30 21:21 6% ` [PATCH v5 07/10] wildmatch test: perform all tests under all wildmatch() modes Ævar Arnfjörð Bjarmason
2 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2018-01-30 21:21 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy,
Anthony Ramine, Johannes Sixt, Adam Dinwoodie,
Johannes Schindelin, Kyle J . McKay,
Ævar Arnfjörð Bjarmason
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
t/t3070-wildmatch.sh | 201 ++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 190 insertions(+), 11 deletions(-)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index 3e75cb0cbe..bd11e5acb0 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -4,6 +4,72 @@ test_description='wildmatch tests'
. ./test-lib.sh
+should_create_test_file() {
+ file=$1
+
+ case $file in
+ # `touch .` will succeed but obviously not do what we intend
+ # here.
+ ".")
+ return 1
+ ;;
+ # We cannot create a file with an empty filename.
+ "")
+ return 1
+ ;;
+ # The tests that are testing that e.g. foo//bar is matched by
+ # foo/*/bar can't be tested on filesystems since there's no
+ # way we're getting a double slash.
+ *//*)
+ return 1
+ ;;
+ # When testing the difference between foo/bar and foo/bar/ we
+ # can't test the latter.
+ */)
+ return 1
+ ;;
+ # On Windows, \ in paths is silently converted to /, which
+ # would result in the "touch" below working, but the test
+ # itself failing. See 6fd1106aa4 ("t3700: Skip a test with
+ # backslashes in pathspec", 2009-03-13) for prior art and
+ # details.
+ *\\*)
+ if ! test_have_prereq BSLASHPSPEC
+ then
+ return 1
+ fi
+ # NOTE: The ;;& bash extension is not portable, so
+ # this test needs to be at the end of the pattern
+ # list.
+ #
+ # If we want to add more conditional returns we either
+ # need a new case statement, or turn this whole thing
+ # into a series of "if" tests.
+ ;;
+ esac
+
+
+ # On Windows proper (i.e. not Cygwin) many file names which
+ # under Cygwin would be emulated don't work.
+ if test_have_prereq MINGW
+ then
+ case $file in
+ " ")
+ # Files called " " are forbidden on Windows
+ return 1
+ ;;
+ *\<*|*\>*|*:*|*\"*|*\|*|*\?*|*\**)
+ # Files with various special characters aren't
+ # allowed on Windows. Sourced from
+ # https://stackoverflow.com/a/31976060
+ return 1
+ ;;
+ esac
+ fi
+
+ return 0
+}
+
match_with_function() {
text=$1
pattern=$2
@@ -26,25 +92,133 @@ match_with_function() {
}
+match_with_ls_files() {
+ text=$1
+ pattern=$2
+ match_expect=$3
+ match_function=$4
+ ls_files_args=$5
+
+ match_stdout_stderr_cmp="
+ tr -d '\0' <actual.raw >actual &&
+ >expect.err &&
+ test_cmp expect.err actual.err &&
+ test_cmp expect actual"
+
+ if test "$match_expect" = 'E'
+ then
+ if test -e .git/created_test_file
+ then
+ test_expect_success "$match_function (via ls-files): match dies on '$pattern' '$text'" "
+ printf '%s' '$text' >expect &&
+ test_must_fail git$ls_files_args ls-files -z -- '$pattern'
+ "
+ else
+ test_expect_failure "$match_function (via ls-files): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_expect" = 1
+ then
+ if test -e .git/created_test_file
+ then
+ test_expect_success "$match_function (via ls-files): match '$pattern' '$text'" "
+ printf '%s' '$text' >expect &&
+ git$ls_files_args ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ $match_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "$match_function (via ls-files): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_expect" = 0
+ then
+ if test -e .git/created_test_file
+ then
+ test_expect_success "$match_function (via ls-files): no match '$pattern' '$text'" "
+ >expect &&
+ git$ls_files_args ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ $match_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "$match_function (via ls-files): no match skip '$pattern' '$text'" 'false'
+ fi
+ else
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_expect" 'false'
+ fi
+}
+
match() {
- match_glob=$1
- match_iglob=$2
- match_pathmatch=$3
- match_pathmatchi=$4
- text=$5
- pattern=$6
+ if test "$#" = 6
+ then
+ # When test-wildmatch and git ls-files produce the same
+ # result.
+ match_glob=$1
+ match_file_glob=$match_glob
+ match_iglob=$2
+ match_file_iglob=$match_iglob
+ match_pathmatch=$3
+ match_file_pathmatch=$match_pathmatch
+ match_pathmatchi=$4
+ match_file_pathmatchi=$match_pathmatchi
+ text=$5
+ pattern=$6
+ elif test "$#" = 10
+ then
+ match_glob=$1
+ match_iglob=$2
+ match_pathmatch=$3
+ match_pathmatchi=$4
+ match_file_glob=$5
+ match_file_iglob=$6
+ match_file_pathmatch=$7
+ match_file_pathmatchi=$8
+ text=$9
+ pattern=${10}
+ fi
+
+ test_expect_success 'cleanup after previous file test' '
+ if test -e .git/created_test_file
+ then
+ git reset &&
+ git clean -df
+ fi
+ '
+
+ printf '%s' "$text" >.git/expected_test_file
+
+ test_expect_success "setup match file test for $text" '
+ file=$(cat .git/expected_test_file) &&
+ if should_create_test_file "$file"
+ then
+ dirs=${file%/*}
+ if test "$file" != "$dirs"
+ then
+ mkdir -p -- "$dirs" &&
+ touch -- "./$text"
+ else
+ touch -- "./$file"
+ fi &&
+ git add -A &&
+ printf "%s" "$file" >.git/created_test_file
+ elif test -e .git/created_test_file
+ then
+ rm .git/created_test_file
+ fi
+ '
# $1: Case sensitive glob match: test-wildmatch & ls-files
match_with_function "$text" "$pattern" $match_glob "wildmatch"
+ match_with_ls_files "$text" "$pattern" $match_file_glob "wildmatch" " --glob-pathspecs"
# $2: Case insensitive glob match: test-wildmatch & ls-files
match_with_function "$text" "$pattern" $match_iglob "iwildmatch"
+ match_with_ls_files "$text" "$pattern" $match_file_iglob "iwildmatch" " --glob-pathspecs --icase-pathspecs"
# $3: Case sensitive path match: test-wildmatch & ls-files
match_with_function "$text" "$pattern" $match_pathmatch "pathmatch"
+ match_with_ls_files "$text" "$pattern" $match_file_pathmatch "pathmatch" ""
# $4: Case insensitive path match: test-wildmatch & ls-files
match_with_function "$text" "$pattern" $match_pathmatchi "ipathmatch"
+ match_with_ls_files "$text" "$pattern" $match_file_pathmatchi "ipathmatch" " --icase-pathspecs"
}
# Basic wildmatch features
@@ -113,7 +287,8 @@ match 1 1 1 1 'acrt' 'a[c-c]rt'
match 0 0 0 0 ']' '[!]-]'
match 1 1 1 1 'a' '[!]-]'
match 0 0 0 0 '' '\'
-match 0 0 0 0 '\' '\'
+match 0 0 0 0 \
+ 1 1 1 1 '\' '\'
match 0 0 0 0 'XXX/\' '*/\'
match 1 1 1 1 'XXX/\' '*/\\'
match 1 1 1 1 'foo' 'foo'
@@ -127,7 +302,8 @@ match 1 1 1 1 '[ab]' '[[:digit]ab]'
match 1 1 1 1 '[ab]' '[\[:]ab]'
match 1 1 1 1 '?a?b' '\??\?b'
match 1 1 1 1 'abc' '\a\b\c'
-match 0 0 0 0 'foo' ''
+match 0 0 0 0 \
+ E E E E 'foo' ''
match 1 1 1 1 'foo/bar/baz/to' '**/t[o]'
# Character class tests
@@ -157,8 +333,10 @@ match 1 1 1 1 ']' '[\]]'
match 0 0 0 0 '\]' '[\]]'
match 0 0 0 0 '\' '[\]]'
match 0 0 0 0 'ab' 'a[]b'
-match 0 0 0 0 'a[]b' 'a[]b'
-match 0 0 0 0 'ab[' 'ab['
+match 0 0 0 0 \
+ 1 1 1 1 'a[]b' 'a[]b'
+match 0 0 0 0 \
+ 1 1 1 1 'ab[' 'ab['
match 0 0 0 0 'ab' '[!'
match 0 0 0 0 'ab' '[-'
match 1 1 1 1 '-' '[-]'
@@ -226,7 +404,8 @@ match 1 1 1 1 foo/bar 'foo/*'
match 0 0 1 1 foo/bba/arr 'foo/*'
match 1 1 1 1 foo/bba/arr 'foo/**'
match 0 0 1 1 foo/bba/arr 'foo*'
-match 0 0 1 1 foo/bba/arr 'foo**'
+match 0 0 1 1 \
+ 1 1 1 1 foo/bba/arr 'foo**'
match 0 0 1 1 foo/bba/arr 'foo/*arr'
match 0 0 1 1 foo/bba/arr 'foo/**arr'
match 0 0 0 0 foo/bba/arr 'foo/*z'
--
2.15.1.424.g9478a66081
^ permalink raw reply related [relevance 6%]
* [PATCH v3] Documentation fixes in git-config
2011-01-21 10:25 6% ` [PATCH v2] " Libor Pechacek
@ 2012-03-01 8:19 6% ` Libor Pechacek
2012-03-01 10:59 6% ` [PATCH v4] " Libor Pechacek
0 siblings, 1 reply; 200+ results
From: Libor Pechacek @ 2012-03-01 8:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
Variable names must start with an alphabetic character, regexp config key
matching has its limits.
Signed-off-by: Libor Pechacek <lpechacek@suse.cz>
Acked-by: Jeff King <peff@peff.net>
---
Hello Junio,
This patch has fallen through the cracks, therefore I re-send it. Previous
discussion about this patch is at http://www.spinics.net/lists/git/msg149593.html.
The only change I've done since version 2 of this patch is replacing
apostrophes with backticks in the first hunk.
Be so kind as to apply the fix.
Libor
Documentation/config.txt | 12 +++++++-----
Documentation/git-config.txt | 9 +++++++--
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e55dae1..078313e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -12,8 +12,9 @@ The configuration variables are used by both the git plumbing
and the porcelains. The variables are divided into sections, wherein
the fully qualified variable name of the variable itself is the last
dot-separated segment and the section name is everything before the last
-dot. The variable names are case-insensitive and only alphanumeric
-characters are allowed. Some variables may appear multiple times.
+dot. The variable names are case-insensitive, allow only alphanumeric
+characters and `-`, and must start with an alphabetic character. Some
+variables may appear multiple times.
Syntax
~~~~~~
@@ -54,9 +55,10 @@ All the other lines (and the remainder of the line after the section
header) are recognized as setting variables, in the form
'name = value'. If there is no equal sign on the line, the entire line
is taken as 'name' and the variable is recognized as boolean "true".
-The variable names are case-insensitive and only alphanumeric
-characters and `-` are allowed. There can be more than one value
-for a given variable; we say then that variable is multivalued.
+The variable names are case-insensitive, allow only alphanumeric characters
+and `-`, and must start with an alphabetic character. There can be more
+than one value for a given variable; we say then that variable is
+multivalued.
Leading and trailing whitespace in a variable value is discarded.
Internal whitespace within a variable value is retained verbatim.
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index aa8303b..a54fee8 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -85,8 +85,13 @@ OPTIONS
is not exactly one.
--get-regexp::
- Like --get-all, but interprets the name as a regular expression.
- Also outputs the key names.
+ Like --get-all, but interprets the name as a regular expression and
+ writes out the key names. Regular expression matching is currently
+ case-sensitive and done against a canonicalized version of the key
+ in which section and variable names are lowercased, but subsection
+ names are not. Regular expressions are partially lower-cased
+ before matching (everything before the first dot and after the last
+ dot), which makes things like "Core.*' work.
--global::
For writing options: write to global ~/.gitconfig file rather than
--
1.7.9.2.324.g78dedf
^ permalink raw reply related [relevance 6%]
* [PATCH v3 05/15] t0003: don't use `test_must_fail attr_check`
@ 2019-12-20 18:15 6% ` Denton Liu
0 siblings, 0 replies; 200+ results
From: Denton Liu @ 2019-12-20 18:15 UTC (permalink / raw)
To: Git Mailing List; +Cc: Eric Sunshine, Johannes Sixt, Junio C Hamano
In an effort to remove test_must_fail for all invocations not related to
git or test-tool, replace invocations of `test_must_fail attr_check`
with a plain attr_check call with the $expect argument set to the
actual value output by git.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
---
t/t0003-attributes.sh | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index c30c736d3f..b660593c20 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -24,7 +24,7 @@ attr_check_quote () {
test_expect_success 'open-quoted pathname' '
echo "\"a test=a" >.gitattributes &&
- test_must_fail attr_check a a
+ attr_check a unspecified
'
@@ -109,20 +109,20 @@ test_expect_success 'attribute test' '
test_expect_success 'attribute matching is case sensitive when core.ignorecase=0' '
- test_must_fail attr_check F f "-c core.ignorecase=0" &&
- test_must_fail attr_check a/F f "-c core.ignorecase=0" &&
- test_must_fail attr_check a/c/F f "-c core.ignorecase=0" &&
- test_must_fail attr_check a/G a/g "-c core.ignorecase=0" &&
- test_must_fail attr_check a/B/g a/b/g "-c core.ignorecase=0" &&
- test_must_fail attr_check a/b/G a/b/g "-c core.ignorecase=0" &&
- test_must_fail attr_check a/b/H a/b/h "-c core.ignorecase=0" &&
- test_must_fail attr_check a/b/D/g "a/b/d/*" "-c core.ignorecase=0" &&
- test_must_fail attr_check oNoFf unset "-c core.ignorecase=0" &&
- test_must_fail attr_check oFfOn set "-c core.ignorecase=0" &&
+ attr_check F unspecified "-c core.ignorecase=0" &&
+ attr_check a/F unspecified "-c core.ignorecase=0" &&
+ attr_check a/c/F unspecified "-c core.ignorecase=0" &&
+ attr_check a/G unspecified "-c core.ignorecase=0" &&
+ attr_check a/B/g a/g "-c core.ignorecase=0" &&
+ attr_check a/b/G unspecified "-c core.ignorecase=0" &&
+ attr_check a/b/H unspecified "-c core.ignorecase=0" &&
+ attr_check a/b/D/g a/g "-c core.ignorecase=0" &&
+ attr_check oNoFf unspecified "-c core.ignorecase=0" &&
+ attr_check oFfOn unspecified "-c core.ignorecase=0" &&
attr_check NO unspecified "-c core.ignorecase=0" &&
- test_must_fail attr_check a/b/D/NO "a/b/d/*" "-c core.ignorecase=0" &&
+ attr_check a/b/D/NO unspecified "-c core.ignorecase=0" &&
attr_check a/b/d/YES a/b/d/* "-c core.ignorecase=0" &&
- test_must_fail attr_check a/E/f "A/e/F" "-c core.ignorecase=0"
+ attr_check a/E/f f "-c core.ignorecase=0"
'
@@ -146,8 +146,8 @@ test_expect_success 'attribute matching is case insensitive when core.ignorecase
'
test_expect_success CASE_INSENSITIVE_FS 'additional case insensitivity tests' '
- test_must_fail attr_check a/B/D/g "a/b/d/*" "-c core.ignorecase=0" &&
- test_must_fail attr_check A/B/D/NO "a/b/d/*" "-c core.ignorecase=0" &&
+ attr_check a/B/D/g a/g "-c core.ignorecase=0" &&
+ attr_check A/B/D/NO unspecified "-c core.ignorecase=0" &&
attr_check A/b/h a/b/h "-c core.ignorecase=1" &&
attr_check a/B/D/g "a/b/d/*" "-c core.ignorecase=1" &&
attr_check A/B/D/NO "a/b/d/*" "-c core.ignorecase=1"
--
2.24.1.703.g2f499f1283
^ permalink raw reply related [relevance 6%]
* [PATCH v2 06/16] t0003: don't use `test_must_fail attr_check`
@ 2019-12-19 22:22 6% ` Denton Liu
1 sibling, 0 replies; 200+ results
From: Denton Liu @ 2019-12-19 22:22 UTC (permalink / raw)
To: Git Mailing List; +Cc: Eric Sunshine, Johannes Sixt, Junio C Hamano
In an effort to remove test_must_fail for all invocations not related to
git or test-tool, replace invocations of `test_must_fail attr_check`
with a plain attr_check call with the $expect argument set to the
actual value output by git.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
---
t/t0003-attributes.sh | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index c30c736d3f..b660593c20 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -24,7 +24,7 @@ attr_check_quote () {
test_expect_success 'open-quoted pathname' '
echo "\"a test=a" >.gitattributes &&
- test_must_fail attr_check a a
+ attr_check a unspecified
'
@@ -109,20 +109,20 @@ test_expect_success 'attribute test' '
test_expect_success 'attribute matching is case sensitive when core.ignorecase=0' '
- test_must_fail attr_check F f "-c core.ignorecase=0" &&
- test_must_fail attr_check a/F f "-c core.ignorecase=0" &&
- test_must_fail attr_check a/c/F f "-c core.ignorecase=0" &&
- test_must_fail attr_check a/G a/g "-c core.ignorecase=0" &&
- test_must_fail attr_check a/B/g a/b/g "-c core.ignorecase=0" &&
- test_must_fail attr_check a/b/G a/b/g "-c core.ignorecase=0" &&
- test_must_fail attr_check a/b/H a/b/h "-c core.ignorecase=0" &&
- test_must_fail attr_check a/b/D/g "a/b/d/*" "-c core.ignorecase=0" &&
- test_must_fail attr_check oNoFf unset "-c core.ignorecase=0" &&
- test_must_fail attr_check oFfOn set "-c core.ignorecase=0" &&
+ attr_check F unspecified "-c core.ignorecase=0" &&
+ attr_check a/F unspecified "-c core.ignorecase=0" &&
+ attr_check a/c/F unspecified "-c core.ignorecase=0" &&
+ attr_check a/G unspecified "-c core.ignorecase=0" &&
+ attr_check a/B/g a/g "-c core.ignorecase=0" &&
+ attr_check a/b/G unspecified "-c core.ignorecase=0" &&
+ attr_check a/b/H unspecified "-c core.ignorecase=0" &&
+ attr_check a/b/D/g a/g "-c core.ignorecase=0" &&
+ attr_check oNoFf unspecified "-c core.ignorecase=0" &&
+ attr_check oFfOn unspecified "-c core.ignorecase=0" &&
attr_check NO unspecified "-c core.ignorecase=0" &&
- test_must_fail attr_check a/b/D/NO "a/b/d/*" "-c core.ignorecase=0" &&
+ attr_check a/b/D/NO unspecified "-c core.ignorecase=0" &&
attr_check a/b/d/YES a/b/d/* "-c core.ignorecase=0" &&
- test_must_fail attr_check a/E/f "A/e/F" "-c core.ignorecase=0"
+ attr_check a/E/f f "-c core.ignorecase=0"
'
@@ -146,8 +146,8 @@ test_expect_success 'attribute matching is case insensitive when core.ignorecase
'
test_expect_success CASE_INSENSITIVE_FS 'additional case insensitivity tests' '
- test_must_fail attr_check a/B/D/g "a/b/d/*" "-c core.ignorecase=0" &&
- test_must_fail attr_check A/B/D/NO "a/b/d/*" "-c core.ignorecase=0" &&
+ attr_check a/B/D/g a/g "-c core.ignorecase=0" &&
+ attr_check A/B/D/NO unspecified "-c core.ignorecase=0" &&
attr_check A/b/h a/b/h "-c core.ignorecase=1" &&
attr_check a/B/D/g "a/b/d/*" "-c core.ignorecase=1" &&
attr_check A/B/D/NO "a/b/d/*" "-c core.ignorecase=1"
--
2.24.1.703.g2f499f1283
^ permalink raw reply related [relevance 6%]
* Re: Unexpected ignorecase=false behavior on Windows
@ 2018-06-25 16:34 6% ` Junio C Hamano
2018-06-25 17:38 6% ` Bryan Turner
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2018-06-25 16:34 UTC (permalink / raw)
To: Bryan Turner; +Cc: marc.strapetz, j6t, Git Users
Bryan Turner <bturner@atlassian.com> writes:
> Git on Windows is not designed to run with anything other than
> core.ignoreCase=true, and attempting to do so will cause unexpected
> behavior.
Even though I fully agree with your conclusion that the document
must make it crystal clear that core.ignoreCase must be set to
reflect the reality, I found the above statement misleading and do
not want it to be used as the basis of a documentation update. But
it is possible that I am misunderstanding the current state of
affairs.
Is the case insensitivity that deeply ingrained in the Git for
Windows code?
IOW, even if the code used to build Git for Windows were executed on
a case sensitive filesystem, is there a case-smashing code on _our_
side that kicks in to cause unexpected behaviour, _even_ when
core.ignorecase is set to false to match (hypothetical) reality?
To put it yet another way, if a case sensitive filesystem were
available, wouldn't running "git init" from Git for Windows in a
directory on such a filesytem set core.ignoreCase to false in the
resulting repository and from then on wouldn't everything work fine?
If my suspicion (i.e. the code for Git for Windows is perfectly
fine---it is just the users are not running with case sensitive
filesystems and flipping core.ignoreCase to true does not make case
incapable filesystems suddenly capable) is correct, then it is not
"Git on Windows is not designed to run" from two angles. (1) it is
not just Git for Windows---Git running on UNIX that mounts VFAT, or
Git running on macOS with default HFS+, would exhibit the same
symptom, and (2) it is not "Git is not designed to run"---it is
core.ignoreCase that is not designed to be a way to make case
incapable filesystems suddenly capable of distinguishing cases in
filesystems.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH] rev-parse: Allow @{U} as a synonym for @{u}
@ 2011-08-19 18:54 6% ` Conrad Irwin
0 siblings, 0 replies; 200+ results
From: Conrad Irwin @ 2011-08-19 18:54 UTC (permalink / raw)
To: Michael J Gruber
Cc: Nguyen Thai Ngoc Duy, Junio C Hamano, git, Sitaram Chamarty
On Wed, Aug 17, 2011 at 3:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Currently, we use @{...} for:
>
> - Negative integers are "-N branch-switching ago" (only without any ref
> on the left);
> - Non-negative integers "The tip of the named ref before it was changed N
> times";
> - An approxidate that is case insensitive; or
> - "u" and "upstream".
[snip]
> The only remotely semi-plausible enhancement I could think of is perhaps
> to allow @{/regexp} to find a reflog entry that matches the given pattern,
> and in such a use case we would certainly want to take the pattern in a
> case sensitive way. This change closes the door to that, and that is the
> only downside I can think of right now.
I'm reasonably convinced by this argument as a refutation of the
consistency argument I proposed above. Given that the date format will
always be insensitive, and any enhancements added would probably want
to be case-sensitive (I can think of a few other things I'd "like",
but which are pretty silly: @{merge-base <commits>*}, @{octopus-base
<commits>*}); this syntax is always going to be inconsistent.
Additionally, as pointed out elsewhere in the thread, the most-similar
existing syntax (^{tree}) is already case-sensitive.
Given all of the above, I think that allowing @{upstream} to be
case-insensitive is certainly wrong, as it's slightly confusing and
not very useful.
Given that @{upstream} should be case-sensitive, it would be bizarre
to allow @{U} as a synonym, so I think I'm convinced that this is not
worth it, despite the convenience it brings.
On Thu, Aug 18, 2011 at 2:31 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
>>> As a simpler case, a user could tailor to her keyboard layout with
>>>
>>> git config revalias.↓ u
>>
Hmm, this opens up interesting ideas:
git config revalias.base = '! git merge-base -a "$@"'
git show HEAD@{base master}
but that seems like it's a bit over-the-top for some reason :).
Conrad
^ permalink raw reply [relevance 6%]
* Re: [PATCH/RFC] blame: respect "core.ignorecase"
@ 2012-09-10 16:13 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2012-09-10 16:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, Ralf Thielow, git
On Sun, Sep 09, 2012 at 12:24:58PM -0700, Junio C Hamano wrote:
> Having said all that, I am not sure if the "fixing" is really the
> right approach to begin with. Contrast these two:
>
> $ git blame MakeFILE
> $ git blame HEAD -- MakeFILE
>
> The latter, regardless of core.ignorecase, should fail, with "No
> such path MakeFILE in HEAD". The former is merely an extension to
> the latter, in the sense that the main traversal is exactly the same
> as the latter, but on top, local modifications are blamed to the
> working tree.
>
> If we were to do anything, I would think the most sane thing to do
> is a smaller patch to fix fake_working_tree_commit() where it calls
> lstat() and _should_ die with "Cannot lstat MakeFILE" on a sane
> filesystem. It does not currently make sure the path exists in the
> HEAD exactly as given by the user (i.e. without core.ignorecase
> matching), and die when it is not found.
Yes, I think that is the only sensible thing here. The rest of this
email is me essentially me agreeing with you and telling you things you
already know, but I had a slightly different line of reasoning, so I
thought I would share.
As far as the original patch, if you are going to change blame, then it
is only logical to change the whole revision parser so that "git log --
MAKEFILE" works. And I do not think that is a direction we want to go.
core.ignorecase has never been about "make git case-insensitive". Git
represents a case-sensitive tree, and will always do so because of the
sha1 we compute over the tree objects. core.ignorecase is really "make
case-sensitive git work around your case-insensitive filesystem"[1].
If the proposal were instead to add a certain type of pathspec that is
case-insensitive[2], that would make much more sense to me. It is not
violating git's case-sensitivity because it is purely a _query_ issue.
And it is a feature you might use whether or not your filesystem is case
sensitive.
-Peff
[1] I was going to submit a patch to Documentation/config.txt to make
this more clear, but IMHO the current text is already pretty clear.
[2] I did not keep up with Duy's work on pathspec magic-prefixes (and I
could not find anything relevant in the code or documentation), but
it seems like this would be a logical feature to support there.
^ permalink raw reply [relevance 6%]
* [PATCH 06/15] t0003: don't use `test_must_fail attr_check`
@ 2019-12-17 12:01 6% ` Denton Liu
1 sibling, 0 replies; 200+ results
From: Denton Liu @ 2019-12-17 12:01 UTC (permalink / raw)
To: Git Mailing List
In an effort to remove test_must_fail for all invocations not related to
git or test-tool, replace invocations of `test_must_fail attr_check`
with a plain attr_check call with the $expect argument set to the
actual value output by git.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
---
t/t0003-attributes.sh | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index 53a730e2ee..8d4343afdb 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -28,7 +28,7 @@ attr_check_quote () {
test_expect_success 'open-quoted pathname' '
echo "\"a test=a" >.gitattributes &&
- test_must_fail attr_check a a
+ attr_check a unspecified
'
@@ -113,20 +113,20 @@ test_expect_success 'attribute test' '
test_expect_success 'attribute matching is case sensitive when core.ignorecase=0' '
- test_must_fail attr_check F f "-c core.ignorecase=0" &&
- test_must_fail attr_check a/F f "-c core.ignorecase=0" &&
- test_must_fail attr_check a/c/F f "-c core.ignorecase=0" &&
- test_must_fail attr_check a/G a/g "-c core.ignorecase=0" &&
- test_must_fail attr_check a/B/g a/b/g "-c core.ignorecase=0" &&
- test_must_fail attr_check a/b/G a/b/g "-c core.ignorecase=0" &&
- test_must_fail attr_check a/b/H a/b/h "-c core.ignorecase=0" &&
- test_must_fail attr_check a/b/D/g "a/b/d/*" "-c core.ignorecase=0" &&
- test_must_fail attr_check oNoFf unset "-c core.ignorecase=0" &&
- test_must_fail attr_check oFfOn set "-c core.ignorecase=0" &&
+ attr_check F unspecified "-c core.ignorecase=0" &&
+ attr_check a/F unspecified "-c core.ignorecase=0" &&
+ attr_check a/c/F unspecified "-c core.ignorecase=0" &&
+ attr_check a/G unspecified "-c core.ignorecase=0" &&
+ attr_check a/B/g a/g "-c core.ignorecase=0" &&
+ attr_check a/b/G unspecified "-c core.ignorecase=0" &&
+ attr_check a/b/H unspecified "-c core.ignorecase=0" &&
+ attr_check a/b/D/g a/g "-c core.ignorecase=0" &&
+ attr_check oNoFf unspecified "-c core.ignorecase=0" &&
+ attr_check oFfOn unspecified "-c core.ignorecase=0" &&
attr_check NO unspecified "-c core.ignorecase=0" &&
- test_must_fail attr_check a/b/D/NO "a/b/d/*" "-c core.ignorecase=0" &&
+ attr_check a/b/D/NO unspecified "-c core.ignorecase=0" &&
attr_check a/b/d/YES a/b/d/* "-c core.ignorecase=0" &&
- test_must_fail attr_check a/E/f "A/e/F" "-c core.ignorecase=0"
+ attr_check a/E/f f "-c core.ignorecase=0"
'
@@ -150,8 +150,8 @@ test_expect_success 'attribute matching is case insensitive when core.ignorecase
'
test_expect_success CASE_INSENSITIVE_FS 'additional case insensitivity tests' '
- test_must_fail attr_check a/B/D/g "a/b/d/*" "-c core.ignorecase=0" &&
- test_must_fail attr_check A/B/D/NO "a/b/d/*" "-c core.ignorecase=0" &&
+ attr_check a/B/D/g a/g "-c core.ignorecase=0" &&
+ attr_check A/B/D/NO unspecified "-c core.ignorecase=0" &&
attr_check A/b/h a/b/h "-c core.ignorecase=1" &&
attr_check a/B/D/g "a/b/d/*" "-c core.ignorecase=1" &&
attr_check A/B/D/NO "a/b/d/*" "-c core.ignorecase=1"
--
2.24.0.627.geba02921db
^ permalink raw reply related [relevance 6%]
* Re: Possible bug with branch names and case sensitivity
@ 2011-11-22 18:01 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2011-11-22 18:01 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Jay Soffian, Gerd Knops, git
Michael Haggerty <mhagger@alum.mit.edu> writes:
> If we want to consider bending git's behavior, there are a number of
> ways we could go:
>
> 1. Remain case-sensitive but prohibit refnames that differ only in case.
I do not see a strong enough reason to be that draconian.
> 2. Remain case-sensitive but prohibit refnames that differ only in case
> *when running on a case-insensitive filesystem*.
If you make it conditional, it should be per-project, not per-repository.
You may be participating in a cross platform project and you may happen to
be on the case-sensitive system, but absense of such a check for you may
end up hurting other participants who work on a case-insensitive one.
> 3. Change the handling of refnames to be case-insensitive but
> case-preserving.
I do not see it is worth the effort. If you were to expend much effort
then I could see in the longer term (now I am talking about Git 2.0 in
this paragraph) one solution is to remove on-filesystem $GIT_DIR/refs/
hierarchy, put it in a trivial database of some sort, keyed with case
sensitive strings.
The transfer of refs over the wire will stay case sensitive so such a
change would be purely local to the repository, so transition would only
matter if you network mount a new style repository and attempt to use with
older version of Git.
If you go that route, we still would need to think about how to deal with
the $GIT_DIR/logs/ hierarchy, though.
^ permalink raw reply [relevance 6%]
* [PATCH v4] Documentation: declare "core.ignoreCase" as internal variable
2018-06-24 10:05 7% [PATCH] Documentation: declare "core.ignorecase" as internal variable Marc Strapetz
2018-06-26 21:50 6% ` [PATCH v3] " Marc Strapetz
2018-06-24 10:44 6% ` [PATCH v2] " Marc Strapetz
@ 2018-06-28 11:21 6% ` Marc Strapetz
2 siblings, 0 replies; 200+ results
From: Marc Strapetz @ 2018-06-28 11:21 UTC (permalink / raw)
To: git; +Cc: Marc Strapetz, sunshine, gitster, bturner
The current description of "core.ignoreCase" reads like an option which
is intended to be changed by the user while it's actually expected to
be set by Git on initialization only. Subsequently, Git relies on the
proper configuration of this variable, as noted by Bryan Turner [1]:
Git on a case-insensitive filesystem (APFS, HFS+, FAT32, exFAT,
vFAT, NTFS, etc.) is not designed to be run with anything other
than core.ignoreCase=true.
[1] https://marc.info/?l=git&m=152998665813997&w=2
mid:CAGyf7-GeE8jRGPkME9rHKPtHEQ6P1+ebpMMWAtMh01uO3bfy8w@mail.gmail.com
Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com>
---
Documentation/config.txt | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1cc18a828..c70cfe956 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -390,16 +390,19 @@ core.hideDotFiles::
default mode is 'dotGitOnly'.
core.ignoreCase::
- If true, this option enables various workarounds to enable
+ Internal variable which enables various workarounds to enable
Git to work better on filesystems that are not case sensitive,
- like FAT. For example, if a directory listing finds
- "makefile" when Git expects "Makefile", Git will assume
+ like APFS, HFS+, FAT, NTFS, etc. For example, if a directory listing
+ finds "makefile" when Git expects "Makefile", Git will assume
it is really the same file, and continue to remember it as
"Makefile".
+
The default is false, except linkgit:git-clone[1] or linkgit:git-init[1]
will probe and set core.ignoreCase true if appropriate when the repository
is created.
++
+Git relies on the proper configuration of this variable for your operating
+and file system. Modifying this value may result in unexpected behavior.
core.precomposeUnicode::
This option is only used by Mac OS implementation of Git.
--
2.17.0.rc0.3.gb1b5a51b2
^ permalink raw reply related [relevance 6%]
* Re: Unexpected ignorecase=false behavior on Windows
2018-06-25 16:34 6% ` Junio C Hamano
@ 2018-06-25 17:38 6% ` Bryan Turner
0 siblings, 0 replies; 200+ results
From: Bryan Turner @ 2018-06-25 17:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marc Strapetz, j6t, Git Users
On Mon, Jun 25, 2018 at 9:34 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Bryan Turner <bturner@atlassian.com> writes:
>
> > Git on Windows is not designed to run with anything other than
> > core.ignoreCase=true, and attempting to do so will cause unexpected
> > behavior.
>
> Even though I fully agree with your conclusion that the document
> must make it crystal clear that core.ignoreCase must be set to
> reflect the reality, I found the above statement misleading and do
> not want it to be used as the basis of a documentation update. But
> it is possible that I am misunderstanding the current state of
> affairs.
>
> Is the case insensitivity that deeply ingrained in the Git for
> Windows code?
>
> IOW, even if the code used to build Git for Windows were executed on
> a case sensitive filesystem, is there a case-smashing code on _our_
> side that kicks in to cause unexpected behaviour, _even_ when
> core.ignorecase is set to false to match (hypothetical) reality?
>
> To put it yet another way, if a case sensitive filesystem were
> available, wouldn't running "git init" from Git for Windows in a
> directory on such a filesytem set core.ignoreCase to false in the
> resulting repository and from then on wouldn't everything work fine?
>
> If my suspicion (i.e. the code for Git for Windows is perfectly
> fine---it is just the users are not running with case sensitive
> filesystems and flipping core.ignoreCase to true does not make case
> incapable filesystems suddenly capable) is correct, then it is not
> "Git on Windows is not designed to run" from two angles. (1) it is
> not just Git for Windows---Git running on UNIX that mounts VFAT, or
> Git running on macOS with default HFS+, would exhibit the same
> symptom, and (2) it is not "Git is not designed to run"---it is
> core.ignoreCase that is not designed to be a way to make case
> incapable filesystems suddenly capable of distinguishing cases in
> filesystems.
Apologies for the unclear word choice. Given Git was designed first to
work with case-sensitive filesystems, certainly the obvious (and
correct) conclusion is that Git itself is fine in a case-sensitive
environment. It wasn't my intention to suggest otherwise.
Note that my word choice was not "Git _for_ Windows", however; it was
"Git _on_ Windows". (This still doesn't change the correctness of your
clarification, let me be quick to add. I'm only pointing it out
because it's relevant to what I intended the comment to say.) On
Windows, the default filesystem is NTFS, and NTFS is not case
sensitive. Hence, Git on Windows (by which I'm implying Git on NTFS),
is not designed to run with anything other than core.ignoreCase=true,
because that setting aligns Git's expectations with how the underlying
filesystem actually works. In other words, Git on a case-insensitive
filesystem (APFS, HFS+, FAT32, exFAT, vFAT, NTFS, etc.) is not
designed to be run with anything other than core.ignoreCase=true.
Bryan
>
> Thanks.
^ permalink raw reply [relevance 6%]
* [PATCH v3] Documentation: declare "core.ignorecase" as internal variable
2018-06-24 10:05 7% [PATCH] Documentation: declare "core.ignorecase" as internal variable Marc Strapetz
@ 2018-06-26 21:50 6% ` Marc Strapetz
2018-06-24 10:44 6% ` [PATCH v2] " Marc Strapetz
2018-06-28 11:21 6% ` [PATCH v4] Documentation: declare "core.ignoreCase" " Marc Strapetz
2 siblings, 0 replies; 200+ results
From: Marc Strapetz @ 2018-06-26 21:50 UTC (permalink / raw)
To: git; +Cc: sunshine, gitster, bturner
The current description of "core.ignoreCase" reads like an option which
is intended to be changed by the user while it's actually expected to
be set by Git on initialization only. Subsequently, Git relies on the
proper configuration of this variable, as noted by Bryan Turner [1]:
Git on a case-insensitive filesystem (APFS, HFS+, FAT32, exFAT,
vFAT, NTFS, etc.) is not designed to be run with anything other
than core.ignoreCase=true.
[1] https://marc.info/?l=git&m=152998665813997&w=2
mid:CAGyf7-GeE8jRGPkME9rHKPtHEQ6P1+ebpMMWAtMh01uO3bfy8w@mail.gmail.com
Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com>
---
Documentation/config.txt | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1cc18a828..c70cfe956 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -390,16 +390,19 @@ core.hideDotFiles::
default mode is 'dotGitOnly'.
core.ignoreCase::
- If true, this option enables various workarounds to enable
+ Internal variable which enables various workarounds to enable
Git to work better on filesystems that are not case sensitive,
- like FAT. For example, if a directory listing finds
- "makefile" when Git expects "Makefile", Git will assume
+ like APFS, HFS+, FAT, NTFS, etc. For example, if a directory listing
+ finds "makefile" when Git expects "Makefile", Git will assume
it is really the same file, and continue to remember it as
"Makefile".
+
The default is false, except linkgit:git-clone[1] or linkgit:git-init[1]
will probe and set core.ignoreCase true if appropriate when the repository
is created.
++
+Git relies on the proper configuration of this variable for your operating
+and file system. Modifying this value may result in unexpected behavior.
core.precomposeUnicode::
This option is only used by Mac OS implementation of Git.
--
2.17.0.rc0.3.gb1b5a51b2
^ permalink raw reply related [relevance 6%]
* [PATCH v4] Documentation fixes in git-config
2012-03-01 8:19 6% ` [PATCH v3] " Libor Pechacek
@ 2012-03-01 10:59 6% ` Libor Pechacek
0 siblings, 0 replies; 200+ results
From: Libor Pechacek @ 2012-03-01 10:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
Variable names must start with an alphabetic character, regexp config key
matching has its limits, sentence grammar.
Signed-off-by: Libor Pechacek <lpechacek@suse.cz>
Acked-by: Jeff King <peff@peff.net>
---
Junio,
Jeff had two more comments, which I've incorporated into the fix. I think
we've reached the acme of patch polishing, and I'd call this patch final.
Please apply.
Documentation/config.txt | 12 +++++++-----
Documentation/git-config.txt | 7 +++++--
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e55dae1..5367ba9 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -12,8 +12,9 @@ The configuration variables are used by both the git plumbing
and the porcelains. The variables are divided into sections, wherein
the fully qualified variable name of the variable itself is the last
dot-separated segment and the section name is everything before the last
-dot. The variable names are case-insensitive and only alphanumeric
-characters are allowed. Some variables may appear multiple times.
+dot. The variable names are case-insensitive, allow only alphanumeric
+characters and `-`, and must start with an alphabetic character. Some
+variables may appear multiple times.
Syntax
~~~~~~
@@ -54,9 +55,10 @@ All the other lines (and the remainder of the line after the section
header) are recognized as setting variables, in the form
'name = value'. If there is no equal sign on the line, the entire line
is taken as 'name' and the variable is recognized as boolean "true".
-The variable names are case-insensitive and only alphanumeric
-characters and `-` are allowed. There can be more than one value
-for a given variable; we say then that variable is multivalued.
+The variable names are case-insensitive, allow only alphanumeric characters
+and `-`, and must start with an alphabetic character. There can be more
+than one value for a given variable; we say then that the variable is
+multivalued.
Leading and trailing whitespace in a variable value is discarded.
Internal whitespace within a variable value is retained verbatim.
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index aa8303b..81b0398 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -85,8 +85,11 @@ OPTIONS
is not exactly one.
--get-regexp::
- Like --get-all, but interprets the name as a regular expression.
- Also outputs the key names.
+ Like --get-all, but interprets the name as a regular expression and
+ writes out the key names. Regular expression matching is currently
+ case-sensitive and done against a canonicalized version of the key
+ in which section and variable names are lowercased, but subsection
+ names are not.
--global::
For writing options: write to global ~/.gitconfig file rather than
--
1.7.9.2.324.g78dedf
^ permalink raw reply related [relevance 6%]
* Re: [PATCH] t0050: mark TC merge (case change) as success
@ 2013-01-14 17:53 6% ` Torsten Bögershausen
0 siblings, 0 replies; 200+ results
From: Torsten Bögershausen @ 2013-01-14 17:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Torsten Bögershausen, git, prohaska
On 14.01.13 00:24, Junio C Hamano wrote:
> Torsten Bögershausen <tboegi@web.de> writes:
>
>> The test "merge (case change)" passes on a case ignoring file system
>>
>> Use test_expect_success to remove the "known breakage vanished"
>>
>> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
>> ---
>
> Interesting. When did this change? Do you happen to have a
> bisection?
This seems to be the commit:
commit 6aad47dec7a72bb36c64afb6c43f4dbcaa49e7f9
Merge: e13067a 0047dd2
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri May 23 16:05:52 2008 -0700
Merge branch 'sp/ignorecase'
* sp/ignorecase:
t0050: Fix merge test on case sensitive file systems
t0050: Add test for case insensitive add
t0050: Set core.ignorecase case to activate case insensitivity
t0050: Test autodetect core.ignorecase
git-init: autodetect core.ignorecase
Which comes from here:
commit 0047dd2fd1fc1980913901c5fa098357482c2842
Author: Steffen Prohaska <prohaska@zib.de>
Date: Thu May 15 07:19:54 2008 +0200
t0050: Fix merge test on case sensitive file systems
On a case sensitive filesystem, "git reset --hard" might refuse to
overwrite a file whose name differs only by case, even if
core.ignorecase is set. It is not clear which circumstances cause this
behavior. This commit simply works around the problem by removing
the case changing file before running "git reset --hard".
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
===========
>Or did the test pass from the very beginning?
Hm, reading the commit, it seems as if the "root problem" still exist:
git reset --hard does not change the case of an existing file
What is the exist behvior?
My feeling is that the test as such deserves some more improvements,
the result of the merge is not checked, files are empty so that
the content is not checked.
Another improvement:
Running under Linux gives:
not ok 6 - add (with different case) # TODO known breakage
(and running under mingw failes)
Please stay tuned for more updates, thanks for reviewing.
/Torsten
^ permalink raw reply [relevance 6%]
* [PATCH v2] Documentation: declare "core.ignorecase" as internal variable
2018-06-24 10:05 7% [PATCH] Documentation: declare "core.ignorecase" as internal variable Marc Strapetz
2018-06-26 21:50 6% ` [PATCH v3] " Marc Strapetz
@ 2018-06-24 10:44 6% ` Marc Strapetz
2018-06-28 11:21 6% ` [PATCH v4] Documentation: declare "core.ignoreCase" " Marc Strapetz
2 siblings, 0 replies; 200+ results
From: Marc Strapetz @ 2018-06-24 10:44 UTC (permalink / raw)
To: git; +Cc: sunshine
The current description of "core.ignoreCase" reads like an option which
is intended to be changed by the user while it's actually expected to
be set by Git on initialization only. This is especially important for
Git for Windows, as noted by Bryan Turner [1]:
Git on Windows is not designed to run with anything other than
core.ignoreCase=true, and attempting to do so will cause
unexpected behavior. In other words, it's not a behavior toggle so
user's can request the functionality to work one way or the other;
it's an implementation detail that `git init` and `git clone` set
when a repository is created purely so they don't have to probe
the file system each time you run a `git` command.
[1] https://marc.info/?l=git&m=152972992729761&w=2
Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com>
---
Documentation/config.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ab641bf5a..c25693828 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -390,7 +390,7 @@ core.hideDotFiles::
default mode is 'dotGitOnly'.
core.ignoreCase::
- If true, this option enables various workarounds to enable
+ Internal variable which enables various workarounds to enable
Git to work better on filesystems that are not case sensitive,
like FAT. For example, if a directory listing finds
"makefile" when Git expects "Makefile", Git will assume
@@ -399,7 +399,7 @@ core.ignoreCase::
+
The default is false, except linkgit:git-clone[1] or linkgit:git-init[1]
will probe and set core.ignoreCase true if appropriate when the repository
-is created.
+is created. Modifying this value afterwards may result in unexpected
behavior.
core.precomposeUnicode::
This option is only used by Mac OS implementation of Git.
--
2.17.0.rc0.3.gb1b5a51b2
^ permalink raw reply related [relevance 6%]
* [PATCH v2] Documentation fixes in git-config
@ 2011-01-21 10:25 6% ` Libor Pechacek
2012-03-01 8:19 6% ` [PATCH v3] " Libor Pechacek
0 siblings, 1 reply; 200+ results
From: Libor Pechacek @ 2011-01-21 10:25 UTC (permalink / raw)
To: git; +Cc: Jeff King
Variable names must start with an alphabetic character, regexp config key
matching has its limits.
Signed-off-by: Libor Pechacek <lpechacek@suse.cz>
Cc: Jeff King <peff@peff.net>
---
Documentation/config.txt | 12 +++++++-----
Documentation/git-config.txt | 9 +++++++--
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ff7c225..928ceda 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -12,8 +12,9 @@ The configuration variables are used by both the git plumbing
and the porcelains. The variables are divided into sections, wherein
the fully qualified variable name of the variable itself is the last
dot-separated segment and the section name is everything before the last
-dot. The variable names are case-insensitive and only alphanumeric
-characters are allowed. Some variables may appear multiple times.
+dot. The variable names are case-insensitive, allow only alphanumeric
+characters and '-', and must start with an alphabetic character. Some
+variables may appear multiple times.
Syntax
~~~~~~
@@ -53,9 +54,10 @@ All the other lines (and the remainder of the line after the section
header) are recognized as setting variables, in the form
'name = value'. If there is no equal sign on the line, the entire line
is taken as 'name' and the variable is recognized as boolean "true".
-The variable names are case-insensitive and only alphanumeric
-characters and `-` are allowed. There can be more than one value
-for a given variable; we say then that variable is multivalued.
+The variable names are case-insensitive, allow only alphanumeric characters
+and `-`, and must start with an alphabetic character. There can be more
+than one value for a given variable; we say then that variable is
+multivalued.
Leading and trailing whitespace in a variable value is discarded.
Internal whitespace within a variable value is retained verbatim.
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 543dd64..31f4658 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -83,8 +83,13 @@ OPTIONS
is not exactly one.
--get-regexp::
- Like --get-all, but interprets the name as a regular expression.
- Also outputs the key names.
+ Like --get-all, but interprets the name as a regular expression and
+ writes out the key names. Regular expression matching is currently
+ case-sensitive and done against a canonicalized version of the key
+ in which section and variable names are lowercased, but subsection
+ names are not. Regular expressions are partially lower-cased
+ before matching (everything before the first dot and after the last
+ dot), which makes things like "Core.*' work.
--global::
For writing options: write to global ~/.gitconfig file rather than
--
1.7.4.rc2.20.gdb1b81
^ permalink raw reply related [relevance 6%]
* RFC: optionally reject case-clone branch names
@ 2014-05-27 22:56 6% David Turner
0 siblings, 0 replies; 200+ results
From: David Turner @ 2014-05-27 22:56 UTC (permalink / raw)
To: git mailing list
At present, it is possible to have two branches which are the same but
for case. This works great on the case-sensitive filesystems, but not
so well on case-insensitive filesystems. It is fairly typical to have
case-insensitive clients (Macs, say) with a case-sensitive server
(GNU/Linux).
Should you attempt to pull on a Mac when you have case-clone branches
with differing contents, you'll get an error message containing
something like "Ref refs/remotes/origin/lower is at
[sha-of-lowercase-branch] but expected [sha-of-uppercase-branch]....
(unable to update local ref)"
Fortunately, nobody uses Macs for git servers, because on a Mac server,
if you push a branch called capital-M Master (that differs from
lowercase-m-master), nobody else can push to (lowercase-m) master until
the branch is removed. Once the branch has been removed, it can no
longer be recreated.
I think a git client that used only packed-refs would not have any
problems with case-sensitivity of branch names, but I assume that there
are good reasons this hasn't yet been done. At any rate, there are
plenty of older clients out there.
RFC follows:
1. On a case-insensitive server, git receive-pack ought to always reject
branches which are same-but-for-case of existing branches.
2. On a case-sensitive server, the same rule by default, with an option
to allow the old behavior.
Let me know if, should I write these patches, they would be likely to be
accepted.
^ permalink raw reply [relevance 6%]
* Problems with extra files on git filter-branch when core.ignorecase is true
@ 2010-08-28 22:21 7% Simeon Maxein
0 siblings, 0 replies; 200+ results
From: Simeon Maxein @ 2010-08-28 22:21 UTC (permalink / raw)
To: git
Today when trying to change the contents of a repository with git
filter-branch, a tool that was run on a part of the working tree for
each version reported an extra file that couldn't be accounted for.
After some testing and a small discussion on the irc channel, I was
able to come up with the following scenario to reproduce the issue.
The test was performed under Ubuntu with Git 1.7.0.4 on a case
sensitive file system:
> ~$ mkdir gittest
> ~$ cd gittest
> ~/gittest$ git init
> Initialized empty Git repository in /home/user/gittest/.git/
> ~/gittest$ git config core.ignorecase true
> ~/gittest$ echo 'foo' > testfile.txt
> ~/gittest$ git add testfile.txt
> ~/gittest$ git commit -m "initial commit"
> [master (root-commit) 794888c] initial commit
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 testfile.txt
> ~/gittest$ git rm testfile.txt
> rm 'testfile.txt'
> ~/gittest$ echo 'bar' > testFile.txt
> ~/gittest$ git add testFile.txt
> ~/gittest$ git commit -m "additional commit"
> [master a669956] additional commit
> 2 files changed, 1 insertions(+), 1 deletions(-)
> create mode 100644 testFile.txt
> delete mode 100644 testfile.txt
> ~/gittest$ git filter-branch --tree-filter 'ls' master
> Rewrite 794888cdbe107aa7408cc5ed4132dcd3bc2753c8 (1/2)testfile.txt
> Rewrite a66995628af5710828a6a59628553938bc30ee37 (2/2)testfile.txt testFile.txt
>
> WARNING: Ref 'refs/heads/master' is unchanged
In the second rewrite line, I would only expect testFile.txt to
appear, regardless of the core.ignorecase setting. On a case
insensitive filesystem the above example works correctly.
It might seem strange to set core.ignorecase to true on a case
sensitive filesystem, however, this issue also appears when using a
(case sensitive) tmpfs temp directory to filter a case insensitive
repository.
Thanks in advance for your help.
Simeon
^ permalink raw reply [relevance 7%]
* Re: Git branch capitalisation bug?
@ 2023-04-20 7:28 7% ` Chris Torek
0 siblings, 0 replies; 200+ results
From: Chris Torek @ 2023-04-20 7:28 UTC (permalink / raw)
To: Ilya Kamenshchikov; +Cc: Junio C Hamano, Torsten Bögershausen, git
On Thu, Apr 20, 2023 at 12:08 AM Ilya Kamenshchikov
<ikamenshchikov@gmail.com> wrote:
> I've recollected the history of how this issue occurred more and did
> few more tests. I'm now working with branch named "feature/git_repro":
> 1) The error first occurred when I worked with a colleague on a same
> branch, and he really used capital "Feature/branch".
The bug -- or "feature", depending on how you believe this all
*should* work -- is simple in concept and difficult in
reproduction because there are multiple moving parts.
Here's the concept:
* In Git, branch names are always case sensitive.
* But Git *sometimes* relies on the *OS* / file-system to
implement this.
* Some OSes / file-systems are case *in*sensitive.
When Git uses a case-INsensitive file-system to store a case-
sensitive branch name component, the OS / file-system loses the
case distinction. Exactly how that happens is up to the OS /
file-system, but we can see how common macOS and Windows systems
do it.
On these systems, when creating a file or directory, the *first*
creation attempt "wins". That is, if any command or process
goes to create a file or directory named "Feature", and no such
file or directory exists *now*, the file or directory is created
with precisely this set of casing. But if the file or directory
*already exists* in any casing (upper and/or lower), the system
uses the existing one: if "feature" exists, that's the name, or
if "featURE" exists, *that* is the name that is used.
So, if and when Git stores a branch name or component as a file-
system file or directory name *and* the system itself imposes this
case-folding match-some-existing-name scheme, Git's case
distinction -- the fact that Git considers "feature" and "Feature"
entirely different names -- is lost. Git is sure these are
different and will stay different, but they aren't and don't.
When Git reads these names back later, it finds the system's
names, rather than the ones Git attempted to store. Git believes
the system's names, rather than its own.
Sometimes, however, Git stores branch names in memory or in
file data, where this kind of case-folding never occurs. During
such periods, feature/git_repo and Feature/git_repo remain
different, distinct branch names.
To reproduce the problem, then, you must:
1. mix a case-sensitive system (e.g., a typical Linux setup
as found on GitHub) with a case-insensitive one (e.g., a
typical Windows or macOS system);
2. use the case-insensitive one yourself -- using the case-
sensitive system you will see branch names as they actually
appear, since they are never converted by the OS / file-system;
3. set up the problem; and
4. make sure Git stores the branch names in directories and
files, rather than in the .git/packed-refs file.
The cure for this would be for Git to stop using the file system's
names directly, the way it does now. There are some long term
projects to make this happen, but little progress has happened
with them.
Until then, the way to avoid the problem is simple:
A) insist that everyone use the same kind of OS, and/or
B) be careful not to depend on case differences.
Method (A) tends to be impractical but method (B) is easy: just
make sure all users use all-lowercase all the time, at least for
branch names. It's not very nice, but it's practical.
Chris
^ permalink raw reply [relevance 7%]
* Re: Can't handle renamed resources on case insensitive filesystems.
@ 2009-12-14 14:52 7% ` Tomas Carnecky
0 siblings, 0 replies; 200+ results
From: Tomas Carnecky @ 2009-12-14 14:52 UTC (permalink / raw)
To: Lhunath (Maarten B.); +Cc: Git Mailing List
On 12/14/09 3:27 PM, Lhunath (Maarten B.) wrote:
> GIT has quite a few issues concerning renamed files on case insensitive filesystems, such as Mac OS X's default HFS+.
>
> For instance:
>
> lhunath@Myst t $ git mv Foo foo
> fatal: destination exists, source=Foo, destination=foo
>
> Moreover, when a repository contains Foo and foo in one commit and in a subsequent commit, "foo" is removed; "Foo" will also disappear when checking out the latter.
>
> Most of these issues are likely just a result of the underlying file system's handling of GIT's commands; though considering that Mac OS X's default fs is case insensitive by default, and the Mac and Windows userbases combined are quite large; it might be very much appropriate to do a check for this (if needed) and handle renames (and other operations?) in a way that they would not cause conflicts on these file systems (eg. rename to a temporary filename first and then rename to destination).
>
> In particular; these issues make it awfully painful to refactor Java class names from things like JndiUtils -> JNDIUtils. Not only is it hard to get the commit INTO the repository correctly; it is also hard to check the commit OUT for somebody who has no idea any of this is needed.--
Create a disk image and format it with case-sensitive HFS+, create a new
partition and format it with case-sensitive HFS+, or reinstall Mac OS X
and choose case-sensitive HFS+ as the filesystem for the system partition.
After I found out that the default install of Mac OS X uses
case-insensitive filesystem, the first thing I did was reinstall the OS.
tom
^ permalink raw reply [relevance 7%]
* [PATCH 2/2] init-db.c: factor out probe_case_sensitivity func
@ 2014-02-01 9:14 7% ` Reuben Hawkins
0 siblings, 0 replies; 200+ results
From: Reuben Hawkins @ 2014-02-01 9:14 UTC (permalink / raw)
To: git; +Cc: dpotapov, Reuben Hawkins
create_default_files was getting a bit long and indented. This
particular bit of code got long enough to be its own function.
Signed-off-by: Reuben Hawkins <reubenhwk@gmail.com>
---
builtin/init-db.c | 97 +++++++++++++++++++++++++++++------------------------
1 file changed, 53 insertions(+), 44 deletions(-)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 34f09d8..bcf7f4c 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -177,6 +177,58 @@ static int git_init_db_config(const char *k, const char *v, void *cb)
return 0;
}
+static void probe_case_sensitivity(char *path, size_t len)
+{
+ int completely_insensitive_fs = 1;
+ char const * const case_check_filename = ".CaseCheck";
+ struct dirent *dirent;
+ FILE *case_file;
+ DIR *dir;
+
+ /*
+ * If we can't access "config" by the name "CoNfIg", this fs is
+ * case sensitive...so do nothing and return.
+ */
+ path[len] = 0;
+ strcpy(path + len, "CoNfIg");
+ if (access(path, F_OK))
+ return;
+
+ /*
+ * This filesystem is at least partially case-insensitive. Let's
+ * find out if this filesystem is completely case-insensitive.
+ *
+ * Create a CamelCase file here, make sure readdir reads a
+ * CamelCase file below.
+ */
+ path[len] = 0;
+ strcpy(path + len, case_check_filename);
+ case_file = fopen(path, "w");
+ if (!case_file)
+ die_errno(_("cannot open '%s'"), path);
+ fclose(case_file);
+
+ path[len] = 0;
+ dir = opendir(path);
+ if (!dir)
+ die_errno(_("cannot opendir '%s'"), path);
+
+ while ( (dirent = readdir(dir)) ) {
+ if (0 == strcmp(case_check_filename, dirent->d_name)) {
+ completely_insensitive_fs = 0;
+ break;
+ }
+ }
+
+ closedir(dir);
+ path[len] = 0;
+ strcpy(path + len, case_check_filename);
+ unlink(path);
+
+ if (completely_insensitive_fs)
+ git_config_set("core.ignorecase", "true");
+}
+
static int create_default_files(const char *template_path)
{
const char *git_dir = get_git_dir();
@@ -285,50 +337,7 @@ static int create_default_files(const char *template_path)
else
git_config_set("core.symlinks", "false");
- /* Check if the filesystem is case-insensitive */
- path[len] = 0;
- strcpy(path + len, "CoNfIg");
- if (!access(path, F_OK)) {
- /*
- * This filesystem is at least partially case-insensitive. Let's
- * find out if this filesystem is completely case-insensitive.
- *
- * Create a CamelCase file here, make sure readdir reads a
- * CamelCase file below.
- */
- int completely_insensitive_fs = 1;
- char const * const case_check_filename = ".CaseCheck";
- struct dirent *dirent;
- FILE *case_file;
- DIR *dir;
-
- path[len] = 0;
- strcpy(path + len, case_check_filename);
- case_file = fopen(path, "w");
- if (!case_file)
- die_errno(_("cannot open '%s'"), path);
- fclose(case_file);
-
- path[len] = 0;
- dir = opendir(path);
- if (!dir)
- die_errno(_("cannot opendir '%s'"), path);
-
- while ( (dirent = readdir(dir)) ) {
- if (0 == strcmp(case_check_filename, dirent->d_name)) {
- completely_insensitive_fs = 0;
- break;
- }
- }
-
- closedir(dir);
- path[len] = 0;
- strcpy(path + len, case_check_filename);
- unlink(path);
-
- if (completely_insensitive_fs)
- git_config_set("core.ignorecase", "true");
- }
+ probe_case_sensitivity(path, len);
probe_utf8_pathname_composition(path, len);
}
--
1.7.9.5
^ permalink raw reply related [relevance 7%]
* [PATCH 0/3] Reroll of sb/config-write-fix
2018-08-01 19:34 20% ` [PATCH 2/3] config: fix case sensitive subsection names on writing Stefan Beller
2018-08-01 19:34 7% ` [PATCH 1/3] t1300: document current behavior of setting options Stefan Beller
@ 2018-08-03 0:34 7% ` Stefan Beller
2018-08-03 0:34 20% ` [PATCH 2/3] config: fix case sensitive subsection names on writing Stefan Beller
2018-08-03 0:34 7% ` [PATCH 1/3] t1300: document current behavior of setting options Stefan Beller
2 siblings, 2 replies; 200+ results
From: Stefan Beller @ 2018-08-03 0:34 UTC (permalink / raw)
To: sbeller; +Cc: bmwill, git, gitster, johannes.schindelin, peff
Only fix was in the commit message of the second patch:
2: c667e555066 ! 1749: 38e5f6f335d config: fix case sensitive subsection names on writing
@@ -2,8 +2,8 @@
config: fix case sensitive subsection names on writing
- A use reported a submodule issue regarding strange case indentation
- issues, but it could be boiled down to the following test case:
+ A user reported a submodule issue regarding a section mix-up,
+ but it could be boiled down to the following test case:
previous version at
https://public-inbox.org/git/20180801193413.146994-1-sbeller@google.com/
Stefan Beller (3):
t1300: document current behavior of setting options
config: fix case sensitive subsection names on writing
git-config: document accidental multi-line setting in deprecated
syntax
Documentation/git-config.txt | 21 +++++++++
config.c | 12 ++++-
t/t1300-config.sh | 87 ++++++++++++++++++++++++++++++++++++
3 files changed, 119 insertions(+), 1 deletion(-)
--
2.18.0.132.g195c49a2227
^ permalink raw reply [relevance 7%]
* Re: BUG FOLLOWUP: Case insensitivity in worktrees
@ 2020-07-24 21:09 7% ` brian m. carlson
0 siblings, 0 replies; 200+ results
From: brian m. carlson @ 2020-07-24 21:09 UTC (permalink / raw)
To: Casey Meijer; +Cc: git@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 3352 bytes --]
On 2020-07-24 at 18:14:03, Casey Meijer wrote:
> I think I misunderstood your claim actually Brian. What is a bug is
> asking for worktree A's head and getting the main worktree's head. A
> super dangerous bug.
>
> I certainly disagree with your assertion that asking for head and not
> getting HEAD (or HeaD or hEAd) on a case-insensitive storage engine
> isn't a bug and it certainly shouldn't be a bug once extensible
> storage engines are in place: the storage engine should have final say
> on how objects are stored and retrieved, not git-core.
If you want to refer to HEAD, writing it "head" is always wrong. "head"
is not a special ref to Git, and on a case-sensitive system, I am fully
entitled to create a branch, tag, or other ref with that name that is
independent from HEAD.
It's wrong because regardless of operating system, you don't
intrinsically know whether the repository is case sensitive. Windows 10
permits case-sensitive directories and macOS has case-sensitive file
systems, so you cannot assume that "head" and "HEAD" are the same
without knowing the setting of "core.ignorecase" and the properties of
the file system.
So when you write "head", you are not asking for HEAD in any worktree or
repository at all.
We are fully aware that Git cannot consistently store refs differing in
case on case-insensitive file systems, and we agree that's a bug.
Reftable will fix that, and as I mentioned, it is being worked on. It
is not, however, a deficiency that refs are intrinsically case
sensitive, and let me explain why.
First, Git does not require that refs are in any particular encoding.
Specifically, they need not be in Unicode or UTF-8. It is valid to have
many characters in a ref name, including 0xff. That means any type of
case folding is not possible, since a ref need not correspond to actual
text.
Second, even if we did require them to be UTF-8, it is impossible to
consistently fold case in a way that works for all locales. Turkish and
other Turkic languages have a dotted I and a dotless I[0]. The ASCII
uppercase I would fold to a dotless lowercase I for Turkish and to the
ASCII (dotted) lowercase I for English. Similarly, the ASCII lowercase
I is dotted, and folds to a dotted uppercase I in Turkish and an ASCII
(dotless) uppercase I in English.
It is literally not possible to correctly perform case-folding in a
locale-independent way. Every attempt to do so will get at least this
case wrong (not to mention other cases that occur), and Turkic languages
are spoken by 200 million people, so ignoring their needs is not only
harmful, but also impacts a massive number of people. That major OS
designers have made this mistake doesn't mean that we should as well.
We wouldn't perform ASCII-only case folding for all of the reasons
mentioned above and because it's Anglocentric. As someone who speaks
both Spanish and French, I would find that unsuitable and the results
bizarre.
So I understand that you may expect that on Windows or macOS that you
can write "head" and get HEAD and be surprised when that doesn't work in
all cases. But that is not, and never has been, expected to work, nor
is it a bug that it doesn't.
[0] https://en.wikipedia.org/wiki/Dotted_and_dotless_I
--
brian m. carlson: Houston, Texas, US
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply [relevance 7%]
* [PATCH 1/3] t1300: document current behavior of setting options
2018-07-30 23:04 12% ` [PATCH 0/3] " Stefan Beller
2018-07-30 23:04 24% ` [PATCH 2/3] " Stefan Beller
2018-07-31 15:16 8% ` [PATCH 0/3] " Junio C Hamano
@ 2018-07-30 23:04 7% ` Stefan Beller
2 siblings, 0 replies; 200+ results
From: Stefan Beller @ 2018-07-30 23:04 UTC (permalink / raw)
To: johannes.schindelin; +Cc: bmwill, git, gitster, peff, sbeller
This documents current behavior of the config machinery, when changing
the value of some settings. This patch just serves to provide a baseline
for the follow up that will fix some issues with the current behavior.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
t/t1300-config.sh | 86 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 86 insertions(+)
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index 03c223708eb..ced13012409 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -1218,6 +1218,92 @@ test_expect_success 'last one wins: three level vars' '
test_cmp expect actual
'
+test_expect_success 'old-fashioned settings are case insensitive' '
+ test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V.A]
+ r = value1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V.A]
+ Qr = value2
+ EOF
+ git config -f testConfig_actual "v.a.r" value2 &&
+ test_cmp testConfig_expect testConfig_actual &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V.A]
+ r = value1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V.A]
+ QR = value2
+ EOF
+ git config -f testConfig_actual "V.a.R" value2 &&
+ test_cmp testConfig_expect testConfig_actual &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V.A]
+ r = value1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V.A]
+ r = value1
+ Qr = value2
+ EOF
+ git config -f testConfig_actual "V.A.r" value2 &&
+ test_cmp testConfig_expect testConfig_actual &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V.A]
+ r = value1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V.A]
+ r = value1
+ Qr = value2
+ EOF
+ git config -f testConfig_actual "v.A.r" value2 &&
+ test_cmp testConfig_expect testConfig_actual
+'
+
+test_expect_success 'setting different case sensitive subsections ' '
+ test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V "A"]
+ R = v1
+ [K "E"]
+ Y = v1
+ [a "b"]
+ c = v1
+ [d "e"]
+ f = v1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V "A"]
+ Qr = v2
+ [K "E"]
+ Qy = v2
+ [a "b"]
+ Qc = v2
+ [d "e"]
+ f = v1
+ Qf = v2
+ EOF
+ # exact match
+ git config -f testConfig_actual a.b.c v2 &&
+ # match section and subsection, key is cased differently.
+ git config -f testConfig_actual K.E.y v2 &&
+ # section and key are matched case insensitive, but subsection needs
+ # to match; When writing out new values only the key is adjusted
+ git config -f testConfig_actual v.A.r v2 &&
+ # subsection is not matched:
+ git config -f testConfig_actual d.E.f v2 &&
+ test_cmp testConfig_expect testConfig_actual
+'
+
for VAR in a .a a. a.0b a."b c". a."b c".0d
do
test_expect_success "git -c $VAR=VAL rejects invalid '$VAR'" '
--
2.18.0.132.g195c49a2227
^ permalink raw reply related [relevance 7%]
* [PATCH 1/3] t1300: document current behavior of setting options
2018-08-01 19:34 20% ` [PATCH 2/3] config: fix case sensitive subsection names on writing Stefan Beller
@ 2018-08-01 19:34 7% ` Stefan Beller
2018-08-03 0:34 7% ` [PATCH 0/3] Reroll of sb/config-write-fix Stefan Beller
2 siblings, 0 replies; 200+ results
From: Stefan Beller @ 2018-08-01 19:34 UTC (permalink / raw)
To: gitster; +Cc: bmwill, git, johannes.schindelin, peff, sbeller
This documents current behavior of the config machinery, when changing
the value of some settings. This patch just serves to provide a baseline
for the follow up that will fix some issues with the current behavior.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
t/t1300-config.sh | 86 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 86 insertions(+)
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index 03c223708eb..ced13012409 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -1218,6 +1218,92 @@ test_expect_success 'last one wins: three level vars' '
test_cmp expect actual
'
+test_expect_success 'old-fashioned settings are case insensitive' '
+ test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V.A]
+ r = value1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V.A]
+ Qr = value2
+ EOF
+ git config -f testConfig_actual "v.a.r" value2 &&
+ test_cmp testConfig_expect testConfig_actual &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V.A]
+ r = value1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V.A]
+ QR = value2
+ EOF
+ git config -f testConfig_actual "V.a.R" value2 &&
+ test_cmp testConfig_expect testConfig_actual &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V.A]
+ r = value1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V.A]
+ r = value1
+ Qr = value2
+ EOF
+ git config -f testConfig_actual "V.A.r" value2 &&
+ test_cmp testConfig_expect testConfig_actual &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V.A]
+ r = value1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V.A]
+ r = value1
+ Qr = value2
+ EOF
+ git config -f testConfig_actual "v.A.r" value2 &&
+ test_cmp testConfig_expect testConfig_actual
+'
+
+test_expect_success 'setting different case sensitive subsections ' '
+ test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V "A"]
+ R = v1
+ [K "E"]
+ Y = v1
+ [a "b"]
+ c = v1
+ [d "e"]
+ f = v1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V "A"]
+ Qr = v2
+ [K "E"]
+ Qy = v2
+ [a "b"]
+ Qc = v2
+ [d "e"]
+ f = v1
+ Qf = v2
+ EOF
+ # exact match
+ git config -f testConfig_actual a.b.c v2 &&
+ # match section and subsection, key is cased differently.
+ git config -f testConfig_actual K.E.y v2 &&
+ # section and key are matched case insensitive, but subsection needs
+ # to match; When writing out new values only the key is adjusted
+ git config -f testConfig_actual v.A.r v2 &&
+ # subsection is not matched:
+ git config -f testConfig_actual d.E.f v2 &&
+ test_cmp testConfig_expect testConfig_actual
+'
+
for VAR in a .a a. a.0b a."b c". a."b c".0d
do
test_expect_success "git -c $VAR=VAL rejects invalid '$VAR'" '
--
2.18.0.132.g195c49a2227
^ permalink raw reply related [relevance 7%]
* [PATCH 1/3] t1300: document current behavior of setting options
2018-08-03 0:34 7% ` [PATCH 0/3] Reroll of sb/config-write-fix Stefan Beller
2018-08-03 0:34 20% ` [PATCH 2/3] config: fix case sensitive subsection names on writing Stefan Beller
@ 2018-08-03 0:34 7% ` Stefan Beller
1 sibling, 0 replies; 200+ results
From: Stefan Beller @ 2018-08-03 0:34 UTC (permalink / raw)
To: sbeller; +Cc: bmwill, git, gitster, johannes.schindelin, peff
This documents current behavior of the config machinery, when changing
the value of some settings. This patch just serves to provide a baseline
for the follow up that will fix some issues with the current behavior.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
t/t1300-config.sh | 86 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 86 insertions(+)
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index 24706ba4125..e87cfc1804f 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -1218,6 +1218,92 @@ test_expect_success 'last one wins: three level vars' '
test_cmp expect actual
'
+test_expect_success 'old-fashioned settings are case insensitive' '
+ test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V.A]
+ r = value1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V.A]
+ Qr = value2
+ EOF
+ git config -f testConfig_actual "v.a.r" value2 &&
+ test_cmp testConfig_expect testConfig_actual &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V.A]
+ r = value1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V.A]
+ QR = value2
+ EOF
+ git config -f testConfig_actual "V.a.R" value2 &&
+ test_cmp testConfig_expect testConfig_actual &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V.A]
+ r = value1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V.A]
+ r = value1
+ Qr = value2
+ EOF
+ git config -f testConfig_actual "V.A.r" value2 &&
+ test_cmp testConfig_expect testConfig_actual &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V.A]
+ r = value1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V.A]
+ r = value1
+ Qr = value2
+ EOF
+ git config -f testConfig_actual "v.A.r" value2 &&
+ test_cmp testConfig_expect testConfig_actual
+'
+
+test_expect_success 'setting different case sensitive subsections ' '
+ test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V "A"]
+ R = v1
+ [K "E"]
+ Y = v1
+ [a "b"]
+ c = v1
+ [d "e"]
+ f = v1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V "A"]
+ Qr = v2
+ [K "E"]
+ Qy = v2
+ [a "b"]
+ Qc = v2
+ [d "e"]
+ f = v1
+ Qf = v2
+ EOF
+ # exact match
+ git config -f testConfig_actual a.b.c v2 &&
+ # match section and subsection, key is cased differently.
+ git config -f testConfig_actual K.E.y v2 &&
+ # section and key are matched case insensitive, but subsection needs
+ # to match; When writing out new values only the key is adjusted
+ git config -f testConfig_actual v.A.r v2 &&
+ # subsection is not matched:
+ git config -f testConfig_actual d.E.f v2 &&
+ test_cmp testConfig_expect testConfig_actual
+'
+
for VAR in a .a a. a.0b a."b c". a."b c".0d
do
test_expect_success "git -c $VAR=VAL rejects invalid '$VAR'" '
--
2.18.0.132.g195c49a2227
^ permalink raw reply related [relevance 7%]
* [PATCHv3] gitweb: Git config keys are case insensitive, make config search too
@ 2011-07-28 21:38 7% ` Jakub Narebski
0 siblings, 0 replies; 200+ results
From: Jakub Narebski @ 2011-07-28 21:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
"git config -z -l" that gitweb uses in git_parse_project_config() to
populate %config hash returns section and key names of config
variables in lowercase (they are case insensitive). When checking
%config in git_get_project_config() we have to take it into account.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
On Thu, 28 Jul 2011, Junio C Hamano napisał:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > "git config -z -l" that gitweb uses in git_parse_project_config() to
> > populate %config hash returns section and key names of config
> > variables in lowercase (they are case insensitive). When checking
> > %config in git_get_project_config() we have to take it into account.
> >
> > Gitweb does not (yet?) use git config variables with subsection, so we
> > can simply lowercase $key in git_get_project_config (only subsection
> > names are case sensitive).
>
> Why stop there, I have to wonder, instead of futureproofing with minimum
> cost, even with something naïve like:
>
> if (my ($hi, $mi, $lo) = ($key =~ /^([^.]*)\.(.*)\.(.*)$)) {
> $key = join(".", lc($hi), $mi, lc($lo);
> } else {
> $key = lc($key);
> }
Well, I thought it would be more involved than this.
Anyway, here it is:
gitweb/gitweb.perl | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1070805..f858d1b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2526,6 +2526,13 @@ sub git_get_project_config {
# key sanity check
return unless ($key);
+ # only subsection, if exists, is case sensitive,
+ # and not lowercased by 'git config -z -l'
+ if (my ($hi, $mi, $lo) = ($key =~ /^([^.]*)\.(.*)\.([^.]*)$/)) {
+ $key = join(".", lc($hi), $mi, lc($lo));
+ } else {
+ $key = lc($key);
+ }
$key =~ s/^gitweb\.//;
return if ($key =~ m/\W/);
--
1.7.5
^ permalink raw reply related [relevance 7%]
* [PATCH 1/3] t1300: document current behavior of setting options
2018-08-08 19:50 6% [PATCH 0/3] Resending sb/config-write-fix Stefan Beller
2018-08-08 19:50 20% ` [PATCH 2/3] config: fix case sensitive subsection names on writing Stefan Beller
@ 2018-08-08 19:50 7% ` Stefan Beller
1 sibling, 0 replies; 200+ results
From: Stefan Beller @ 2018-08-08 19:50 UTC (permalink / raw)
To: gitster; +Cc: git, Stefan Beller
This documents current behavior of the config machinery, when changing
the value of some settings. This patch just serves to provide a baseline
for the follow up that will fix some issues with the current behavior.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
t/t1300-config.sh | 86 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 86 insertions(+)
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index e43982a9c1f..c15c19bf78d 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -1188,6 +1188,92 @@ test_expect_success 'last one wins: three level vars' '
test_cmp expect actual
'
+test_expect_success 'old-fashioned settings are case insensitive' '
+ test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V.A]
+ r = value1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V.A]
+ Qr = value2
+ EOF
+ git config -f testConfig_actual "v.a.r" value2 &&
+ test_cmp testConfig_expect testConfig_actual &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V.A]
+ r = value1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V.A]
+ QR = value2
+ EOF
+ git config -f testConfig_actual "V.a.R" value2 &&
+ test_cmp testConfig_expect testConfig_actual &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V.A]
+ r = value1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V.A]
+ r = value1
+ Qr = value2
+ EOF
+ git config -f testConfig_actual "V.A.r" value2 &&
+ test_cmp testConfig_expect testConfig_actual &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V.A]
+ r = value1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V.A]
+ r = value1
+ Qr = value2
+ EOF
+ git config -f testConfig_actual "v.A.r" value2 &&
+ test_cmp testConfig_expect testConfig_actual
+'
+
+test_expect_success 'setting different case sensitive subsections ' '
+ test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
+
+ cat >testConfig_actual <<-EOF &&
+ [V "A"]
+ R = v1
+ [K "E"]
+ Y = v1
+ [a "b"]
+ c = v1
+ [d "e"]
+ f = v1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ [V "A"]
+ Qr = v2
+ [K "E"]
+ Qy = v2
+ [a "b"]
+ Qc = v2
+ [d "e"]
+ f = v1
+ Qf = v2
+ EOF
+ # exact match
+ git config -f testConfig_actual a.b.c v2 &&
+ # match section and subsection, key is cased differently.
+ git config -f testConfig_actual K.E.y v2 &&
+ # section and key are matched case insensitive, but subsection needs
+ # to match; When writing out new values only the key is adjusted
+ git config -f testConfig_actual v.A.r v2 &&
+ # subsection is not matched:
+ git config -f testConfig_actual d.E.f v2 &&
+ test_cmp testConfig_expect testConfig_actual
+'
+
for VAR in a .a a. a.0b a."b c". a."b c".0d
do
test_expect_success "git -c $VAR=VAL rejects invalid '$VAR'" '
--
2.18.0.597.ga71716f1ad-goog
^ permalink raw reply related [relevance 7%]
* Re: should config options be treated as case-sensitive?
2018-05-23 9:04 8% ` Robert P. J. Day
@ 2018-05-23 23:33 7% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2018-05-23 23:33 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Ævar Arnfjörð Bjarmason, Git Mailing list
"Robert P. J. Day" <rpjday@crashcourse.ca> writes:
>> Unfortunately, that line of thinking leads us to madness, as you are
>> exhibiting the typical symptom of "my today's immediate itch is the
>> most important one in the world"-itis....
>
> fair enough, point taken.
FWIW, everybody suffers from it, including me.
I was trying to come up with an update, and here is an attempted
rewrite of the earlier section. I am not sure if this is a good
direction to go in, but if so, we'd need to reduce the duplicated
info from the Syntax section that immediately follows.
Documentation/config.txt | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git i/Documentation/config.txt w/Documentation/config.txt
index 84e2891aed..5b79411b4b 100644
--- i/Documentation/config.txt
+++ w/Documentation/config.txt
@@ -9,13 +9,21 @@ fallback values for the `.git/config` file. The file `/etc/gitconfig`
can be used to store a system-wide default configuration.
The configuration variables are used by both the Git plumbing
-and the porcelains. The variables are divided into sections, wherein
-the fully qualified variable name of the variable itself is the last
-dot-separated segment and the section name is everything before the last
-dot. The variable names are case-insensitive, allow only alphanumeric
-characters and `-`, and must start with an alphabetic character. Some
-variables may appear multiple times; we say then that the variable is
-multivalued.
+and the porcelains. The variables are divided into sections, and some
+sections can have subsections. In a variable name that is fully
+spelled out, the part up to the first dot is the section, the part
+after the last dot is the variable. If these two dots are not the
+same, what's in the middle is the subsection.
+
+The section and the variable names are case-insensitive, allow only
+alphanumeric characters and `-`, and must start with an alphabetic
+character. Often multi-word variable names are spelled in CamelCase
+by convention for extra readability.
+
+Some variables may appear multiple times and their effects accumulate;
+we say then that such a variable is multivalued. For other variables,
+when they appear more than once, the last one takes effect.
+
Syntax
~~~~~~
^ permalink raw reply related [relevance 7%]
* Re: Race condition on `git checkout -c`
@ 2023-01-19 22:55 7% ` Chris Torek
0 siblings, 0 replies; 200+ results
From: Chris Torek @ 2023-01-19 22:55 UTC (permalink / raw)
To: Arthur Milchior; +Cc: git
(Top note: you mean `git checkout -b` or `git switch -c`, not `git
checkout -c`.)
On Thu, Jan 19, 2023 at 1:24 PM Arthur Milchior
<arthur.milchior@gmail.com> wrote:
>
> I expect either:
> * to see an error message stating that `b` already exists
> * to see `b` and `B` in the list of branch.
[snip]
> uname: Darwin 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51
Darwin (macOS) is your problem here. The same problem
occurs on Windows, but not on Linux, by default.
Technically the problem is in the file system itself, combined with
the ways (plural) that Git stores branch names.
As far as Git itself is concerned, branch names are *always* case
sensitive, so branches named `b` and `B` are different. But Git
stores branch names in two different formats, at the moment:
* Some are kept in a plain-text file `.git/packed-refs`.
* Some are stored as directory-and-file-names in `.git/refs/`.
If the OS's file system is case sensitive, as most standard Linux
file systems are, there's no problem with the latter. But if the OS's
file system is case-INsensitive, as the default file systems on
Windows and MacOS are, this becomes a problem: the attempt
to create both `refs/heads/b` and a different file, `refs/head/B`,
fails, with one of the two names "winning" and the other attempt
to create a new name simply re-using the existing name.
If you create a case-sensitive disk volume on your Mac, which
can be a simple click-to-mount virtual drive within your regular
case-insensitive file system, you can happily use Git without this
complication. Note that the same complication applies to file
names: Linux users can create two different, separate files
named `README.TXT` and `ReadMe.txt` in a GIt project, and
if you use the default case-insensitive macOS file system, you
won't be able to check out both files. Using your case sensitive
volume will allow you to work with the Linux group.
If and when a future version of Git starts using reftables instead
of the file system to store branch and tag names, this particular
issue will go away, but until then, I recommend keeping a case
sensitive volume handy on your mac, and more generally,
avoiding mixing upper and lower case branch and/or file names
(at all, ever) whenever possible. This avoids a lot of problems,
though nothing can get you past the Windows `aux.h` problem. :-)
Chris
^ permalink raw reply [relevance 7%]
* Re: [PATCH] apply: support case-only renames in case-insensitive filesystems
2022-06-12 23:30 6% ` Junio C Hamano
@ 2022-06-14 6:16 7% ` Tao Klerks
0 siblings, 0 replies; 200+ results
From: Tao Klerks @ 2022-06-14 6:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tao Klerks via GitGitGadget, git
On Mon, Jun 13, 2022 at 1:30 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Tao Klerks via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > +if ! test_have_prereq CASE_INSENSITIVE_FS
> > +then
> > + test_set_prereq CASE_SENSITIVE_FS
> > + echo nuts
> > +fi
>
> You can easily say !CASE_INSENSITIVE_FS as the prerequiste, so I do
> not see the point of this. I do not see the point of "nuts", either.
I was not aware of negated prerequisite support (I did not see it in
the README nor in any examples I scanned), but I agree this is much
cleaner of course!
"nuts" was a debugging leak, my apologies.
>
> But it probably is a moot point as I do not think you should do the
> prerequisite at all.
>
> Instead, you can explicitly set the core.ignorecase configuration,
> i.e. "git -c core.ignorecase=yes/no", and possibly "apply --cached"
> so that you do not have to worry about the case sensitivity of the
> filesystem at all.
Sure, I can see how we can test most of the case-sensitive logic, even
on a case-insensitive filesystem, with "--cached" and "-c
core.ignorecase=no". I'm not sure whether there's a need to test the
same things against the actual file system or not (certainly in the
case-insensitive path there is, as this is where the errors/conflicts
actually occur).
>
> > +test_expect_success setup '
> > + echo "This is some content in the file." > file1 &&
>
> Style. Redirection operator ">" sticks to its operand, i.e.
>
> echo "This is some content in the file." >file1 &&
>
Thx.
> > + echo "A completely different file." > file2 &&
> > + git update-index --add file1 &&
> > + git update-index --add file2 &&
> > + cat >case_only_rename_patch <<-\EOF
> > + diff --git a/file1 b/File1
> > + similarity index 100%
> > + rename from file1
> > + rename to File1
> > + EOF
>
> You are better off not writing the diff output manually. Instead,
> you can let the test write it for you, e.g.
>
> echo "This is some content in the file." >file1 &&
> git update-index --add file1 &&
> file1blob=$(git rev-parse :file1) &&
> git commit -m "Initial - file1" &&
> git update-index --add --cacheinfo 100644,$file1blob,File1 &&
> git rm --cached file1 &&
> git diff --cached -M HEAD >case-only-rename-patch
>
Makes sense, thx.
> If you want to be extra careful not to rely on your filesystem
> corrupting the pathnames you feed (e.g. the redireciton to "file1"
> might create file FILE1 on MS-DOS ;-), you could even do:
>
> file1blob=$(echo "This is some content in the file." |
> git hash-object -w --stdin) &&
> file2blob=$(echo "A completeloy different contents." |
> git hash-object -w --stdin) &&
> git update-index --add --cacheinfo 100644,$file1blob,file1 &&
>
> git commit -m "Initial - file1" &&
> git update-index --add --cacheinfo 100644,$file1blob,File1 &&
> git rm --cached file1 &&
> git diff --cached -M HEAD >rename-file1-to-File2 &&
>
> git reset --hard HEAD &&
> git update-index --add --cacheinfo 100644,$file1blob,file2 &&
> git rm --cached file1 &&
> git diff --cached -M HEAD >rename-file1-to-file2 &&
>
> # from here on, HEAD has file1 and file2
> git reset --hard HEAD &&
> git update-index --add --cacheinfo 100644,$file2blob,file2 &&
> git commit -m 'file1 and file2'
>
Cool, but probably excessive? (do we support MS-DOS??)
> > +'
> > +
> > +test_expect_success 'refuse to apply rename patch with conflict' '
> > + cat >conflict_patch <<-\EOF &&
> > + diff --git a/file1 b/file2
> > + similarity index 100%
> > + rename from file1
> > + rename to file2
> > + EOF
> > + test_must_fail git apply --index conflict_patch
>
> And then, you could use --cached (not --index) to bypass the working
> tree altogether, which is a good way to test the feature without
> getting affected by the underlying filesystem. Check both case
> sensitive and case insensitive cases:
>
> # Start from a known state
> git reset --hard HEAD &&
> test_must_fail git -c core.ignorecase=no apply --cached rename-file1-to-file2 &&
>
> # Start from a known state
> git reset --hard HEAD &&
> test_must_fail git -c core.ignorecase=yes apply --cached rename-file1-to-file2 &&
>
Makes sense, understanding that this tests "happy paths" - it doesn't
fail even if talking to the (case-insensitive) filesystem actually
would (which here it wouldn't of course).
> > +'
> > +
> > +test_expect_success CASE_SENSITIVE_FS 'refuse to apply case-only rename patch with conflict, in case-sensitive FS' '
>
> Lose the prerequisite, replace --index with --cached, and force core.ignorecase
> to both case insensitive and sensitive to check the behaviour.
>
Sure, makes sense - you can test case-sensitive behaviors in git
without needing a case-sensitive FS.
> > + test_when_finished "git mv File1 file2" &&
> > + git mv file2 File1 &&
> > + test_must_fail git apply --index case_only_rename_patch
> > +'
> > +
> > +test_expect_success 'apply case-only rename patch without conflict' '
>
> Likewise, try both sensitive and insensitive one.
>
This one will fail on a case-insensitive filesystem if you disable
core.ignorecase, so explicitly trying with both settings in a single
test, without prerequisites, presumably isn't the right thing. I
assume the right thing is to have 2 versions of the same test, one
which expects success in all cases on a case-sensitive filesystem, and
one which expects failure when case-insensitivity is disabled on a
case-insensitive filesystem?
> > + git apply --index case_only_rename_patch
> > +'
> > +
> > +test_done
> >
> > base-commit: 1e59178e3f65880188caedb965e70db5ceeb2d64
>
> Thanks.
>
Thank you!
^ permalink raw reply [relevance 7%]
* [RFC] Case insensitive Git attributes
@ 2016-10-17 1:04 7% Lars Schneider
0 siblings, 0 replies; 200+ results
From: Lars Schneider @ 2016-10-17 1:04 UTC (permalink / raw)
To: git
Hi,
Git attributes for path names are generally case sensitive. However, on
a case insensitive file system (e.g. macOS/Windows) they appear to be
case insensitive (`*.bar` would match `foo.bar` and `foo.BAR`). That
works great until a Git users joins the party with a case sensitive file
system. For this Git user only files that match the exact case of the
attribute pattern get the attributes (only `foo.bar`).
This inconsistent behavior can confuse Git users. An advanced Git user
could use a glob pattern (e.g. `*.[bB][aA][rR]) to match files in a
case insensitive way. However, this can get confusing quickly, too.
I wonder if we can do something about this. One idea could be to add an
attribute "case-sensitive" (or "caseSensitive") and set it to false
(if desired) for all files in .gitattributes for a given repo.
### .gitattributes example ###
* case-sensitive=false
*.bar something
###
I haven't looked into the feasibility of an implementation, yet. However,
would that be an acceptable approach?
Thanks,
Lars
^ permalink raw reply [relevance 7%]
* [PATCH] Documentation/config.txt: Document config file syntax better
@ 2007-01-20 14:03 7% ` Jakub Narebski
2007-01-22 15:25 7% ` Jakub Narebski
0 siblings, 1 reply; 200+ results
From: Jakub Narebski @ 2007-01-20 14:03 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin
Cc: Nikolai Weibull, Eric Wong, Jakub Narebski
Separate part of Documentation/config.txt which deals with git config file
syntax into "Syntax" subsection, and expand it. Add information about
subsections, boolean values, escaping and escape sequences in string
values, and continuing variable value on the next line.
Add also proxy settings to config file example to show example of
partially enclosed in double quotes string value.
Parts based on comments by Junio C Hamano, Johannes Schindelin,
and the smb.conf(5) man page.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
On Sat, 20 Jan 2007, Johannes Schindelin wrote:
> On Fri, 19 Jan 2007, Jakub Narebski wrote:
>> +in the section header, like in example below
>> +
>> + [section "subsection"]
>
> I wonder if we should also mention the (case insensitive) alternative
> "[section.subsection]", to give a better idea to people why we actually
> check for "section.subsection" in the code.
Added one line note about this.
>> +All the other lines are recognized as setting variables, in the form
>> +'name = value'. If there is no equal sign on the line, the entire line
>> +is taken as 'name' and the variable is recognized as boolean "true".
>> +Variable names are case insensitive.
>
> They cannot contain anything else than alphanumeric characters, in
> particular no whitespace.
It is mentioned above "Syntax" section, but perhaps it should be repeated.
I haven't took a look at code to check what values for section names and
for key/variable names are allowed.
>> +Some variables may require special value format.
>
> I think you can safely skip that; it should be evident that the format of
> the variables depends on the purpose.
This was in the original, and I think it is better left (at least for now).
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> I'm not sure how to tell that you can have [section] if you have
>> [section "subsection"], but you don't need to.
>
> s/I'm not .*that//; would be enough, I think.
Thanks for suggestion. I have used it (although perhaps the preceding
sentence is now not needed).
> One thing that left me puzzled after reading the description was
> what a user can do with "subsection". It is unclear from the
> description if [section "sub.section"], [section "sub.sec=ti.on"]
> or worse yet, [section "sub\nsection with an embbedded LF"] are
> allowed. The rest seemed sane.
I'm not sure what is allowed in section name, and in subsection name,
so for now I have left it as is. I can amend this commit, or add new
commit explaining this.
BTW. currently one of examples from git-repo-config(1) doesn't work:
To add a new proxy, without altering any of the existing ones, use
------------
% git repo-config core.gitproxy '"proxy" for example.com'
------------
I think it would be better instead of adding quotes if needed, just
do _not_ escape quotes. But that leaves the problem what to do if one
puts value with trailing or leading whitespace, or comment character
outside quotes using git-repo-config...
Documentation/config.txt | 69 +++++++++++++++++++++++++++++++++++++++++----
1 files changed, 62 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index da7fde5..03133e2 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -14,14 +14,65 @@ dot-separated segment and the section name is everything before the last
dot. The variable names are case-insensitive and only alphanumeric
characters are allowed. Some variables may appear multiple times.
+Syntax
+~~~~~~
+
The syntax is fairly flexible and permissive; whitespaces are mostly
-ignored. The '#' and ';' characters begin comments to the end of line,
-blank lines are ignored, lines containing strings enclosed in square
-brackets start sections and all the other lines are recognized
-as setting variables, in the form 'name = value'. If there is no equal
-sign on the line, the entire line is taken as 'name' and the variable
-is recognized as boolean "true". String values may be entirely or partially
-enclosed in double quotes; some variables may require special value format.
+ignored. The '#' and ';' characters begin comments to the end of line,
+blank lines are ignored.
+
+The file consists of sections and variables. A section begins with
+the name of the section in square brackets and continues until the next
+section begins. Section names are not case sensitive. Each variable
+must belong to some section, which means that there must be section
+header before first setting of a variable.
+
+Sections can be further divided into subsections. To begin a subsection
+put its name in double quotes, separated by space from the section name,
+in the section header, like in example below:
+
+--------
+ [section "subsection"]
+
+--------
+
+Subsection names can contain whitespace and are case sensitive. Variables
+may belong directly to a section, or to a given subsection. You can have
+`[section]` if you have `[section "subsection"]`, but you don't need to.
+
+There is also (case insensitive) alternative `[section.subsection]` syntax.
+
+All the other lines are recognized as setting variables, in the form
+'name = value'. If there is no equal sign on the line, the entire line
+is taken as 'name' and the variable is recognized as boolean "true".
+Variable names are case insensitive. There can be more than one value
+for a given variable; we say then that variable is multivalued.
+
+Leading and trailing whitespace in a variable value is discarded.
+Internal whitespace within a variable value is retained verbatim.
+
+The values following the equals sign in variable assign are all either
+a string, an integer, or a boolean. Boolean values may be given as yes/no,
+0/1 or true/false. Case is not significant in boolean values, when
+converting value to the canonical form using '--bool' type specifier;
+git-repo-config will ensure that the output is "true" or "false".
+
+String values may be entirely or partially enclosed in double quotes.
+You need to enclose variable value in double quotes if you want to
+preserve leading or trailing whitespace, or if variable value contains
+beginning of comment characters (if it contains '#' or ';').
+Double quote '`"`' and backslash '`\`' characters in variable value must
+be escaped: use '`\"`' for '`"`' and '`\\`' for '`\`'.
+
+The following escape sequences (beside '`\"`' and '`\\`') are recognized:
+'`\n`' for newline character (NL), '`\t`' for horizontal tabulation (HT, TAB)
+and '`\b`' for backspace (BS). No other char escape sequence, nor octal
+char sequences are valid.
+
+Variable value ending in a '`\`' is continued on the next line in the
+customary UNIX fashion.
+
+Some variables may require special value format.
Example
~~~~~~~
@@ -40,6 +91,10 @@ Example
remote = origin
merge = refs/heads/devel
+ # Proxy settings
+ [core]
+ gitProxy="ssh" for "ssh://kernel.org/"
+ gitProxy=default-proxy ; for the rest
Variables
~~~~~~~~~
--
1.4.4.3
^ permalink raw reply related [relevance 7%]
* Re: [PATCH v2] Allow git mv FileA fILEa on case ignore file systems
@ 2011-04-10 5:48 7% ` Torsten Bögershausen
0 siblings, 0 replies; 200+ results
From: Torsten Bögershausen @ 2011-04-10 5:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: kusmabite, git
On 20.03.11 06:50, Junio C Hamano wrote:
========================
>Torsten Bögershausen <tboegi@web.de> writes:
>
>> > The typical use case is when a file "FileA" should be renamed into fILEa
>> > and we are on a case insenstive file system (system core.ignorecase = true).
>> > Source and destination are the same file, it can be accessed under both names.
>> > This makes git think that the destination file exists.
>> > Unless used with --forced, git will refuse the "git mv FileA fILEa".
>> > This change will allow "git mv FileA fILEa" under the following condition:
>> > On Linux/Unix/Mac OS X the move is allowed when the inode of the source and
>> > destination are equal (and they are on the same device).
>> > This allows renames of MÄRCHEN into Märchen on Mac OS X.
>> > (As a side effect, a file can be renamed to a name which is already
>> > hard-linked to the same inode).
>> > On Windows, the function win_is_same_file() from compat/win32/same-file.c
>> > is used.
>> > It calls GetFileInformationByHandle() to check if both files are
>> > "the same".
>Yeek; is it just me or the above single block of text too dense to be
>readable? Can you use paragraph breaks?
Yes
>
>> > The typical use case is when a file "FileA" should be renamed into fILEa
>> > and we are on a case insenstive file system (system core.ignorecase = true).
>Huh? I don't think renaming "FileA" to "fILEa" is typical at all. It is
>very rarely done.
Probably this is not a good example, I changed it to "mv FILE File"
>
>> > (As a side effect, a file can be renamed to a name which is already
>> > hard-linked to the same inode).
>It is unclear "a side effect" means "an added bonus" or "a regression" in
>this sentence. I think this is latter.
If it is too much regression, we can check that the link count in struct stat
"if (1 == st_nlink)" .
>
>Allowing filesystem specific logic to detect that two different "names"
>actually refer to a single "file" and help renaming succeed is a sane
>approach, but I think this particular implementation is flawed.
>
>The important thing to notice is that "names" and "file" above refer to
>the entities from the end user's point of view. Two files hardlinked
>together on a filesystem with sane pathname handling are never the same
>"file". I would probably have called it equivalent_filenames() to stress
>the fact that two _different_ names alias to the same file. is_same_file()
>sounds more like you got two different filenames from the filesystem
>(i.e. readdir() gave you both at the same time) and you are trying to see
>if they are the same file, but that is not the case here.
Ok, I need to distinct beetwen file names and files.
>I also find it a bad taste to make this feature depend on win32; doesn't a
>Linux box mounting a vfat filesystem have the same issue that we should be
>able to solve with the same code? Can't we instead have a configuration
>variable that tells git that the working tree is on a filesystem with
>broken pathname semantics, and what kind of workaround is needed? Isn't
>core.ignorecase already that configuration variable for case insensitve
>filesystems [*1*]?
Agreed about the bad taste ;-)
The suggested patch works for Linux/UNIX/MAC OS X and Windows,
but the description wasn't to clear about it.
The same code is used for all OS, except Windows that needs some specific code
which is located in cygwin.c and mingw.c
>
>I would imagine that the implementation of equivalent_filenames(a,b) may
>be !strcmp(a,b) for a sane filesystem [*2*] and !strcasecmp(a,b) for a
>case insensitive filesystem. For a totally wacky filesystem, your
>lstat(2) based one might end up to be the best we could do [*3*].
>
>When two different _names_ "A" and "a" refer to a single file, the only
>thing that should happen for "git mv A a" is for the cache entry for "A"
>to be moved to cache entry for "a", and no rename("A", "a") should be run,
>but I don't see any such change in the code. It may happen to work (or be
>a no-op) on Windows, but because builtin/mv.c is supposed to be generic
>(and that is the reason you introduced the is_same_file() abstraction in
>the first place), I'd still see this as a breakage.
>
Why shouldn't the rename() be done?
"git mv A B" changes both the indes and the file system.
Isn't it natural to have file name "a" both in the index and in the
file system after "git mv A a"?
Note: Windows and MAC OS X allow "mv A a" from command line,
while Linux on VFAT gives an error "'A' and 'a' are the same file".
>
>[Footnote]
>
>*1* Off the top of my head, perhaps core.ignorecase may have to grow into
>boolean plus extra to cover "this is not just case insensitive, but isn't
>even case preserving" kind of broken filesystems like HFS+, but I didn't
>think things through.
It is not that bad.
My HFS+ here is both case insenstive and case preserving,
so that core.ignorecase can be used as it is.
Note: HFS+ can be formated to be case sensitive (at least at MAC OS X 10.6),
but the default is case insensitive.
>
>*2* Incidentally, wouldn't "!strcmp(a,b)" solution suddenly start allowing
>"git mv Makefile Makefile" that we currently disallow? Is it a regression
>(less safety against an unexpected input) or a good change?
When running "git mv git.c git.c", the current git says:
"fatal: can not move directory into itself, source=git.c, destination=git.c"
That test is done earlier in the code path,
so that this move is still not allowed.
The error message is somewhat confusing, as git.c is a file.
Is it worth to send a separate patch for that?
>
>*3* If we can find a solution that does not involve any calls to the
>filesystem, it would be ideal, as we can reuse it later in codepaths where
>neither file "a" or file "b" exists on the filesystem yet (think: "we are
>about to create 'a' and 'b'---is that sensible, or will they overwrite
>with each other on this filesystem?").
>
That would mean, that git needs to know the encoding of the local filesystem.
But we don't have that at the moment.
What do you have in mind?
I run a test script (see at the end of the mail, save it under test-mv.sh and
execute it with /bin/sh test-mv.sh).
I tested Linux, MAC OS X, cygwin 1.5, cygwin 1.7 and current msys(git).
Short summary: There are different flavors which filenames are equivalent.
I send out a new patch, thank you for reading this long stuff.
/Torsten
=======================
Linux 2.6.34.7-0.7-default
/dev/sda6 on /D type vfat (rw,noexec,nosuid,nodev,gid=100,umask=0002,utf8=true)
enc=UTF-8
a=A Case ignored
mv: `a' and `A' are the same file
æ=Æ Case ignored
mv: `æ' and `Æ' are the same file
ø=ø Case sensitive
mv: ø --> Ø OK
ä=Ä Case ignored
mv: `ä' and `Ä' are the same file
==================================================================
Linux 2.6.34.7-0.7-default
/dev/sda6 on /D type vfat (rw)
enc=UTF-8
a=A Case ignored
mv: `a' and `A' are the same file
æ=æ Case sensitive
mv: æ --> Æ OK
ø=ø Case sensitive
mv: ø --> Ø OK
ä=ä Case sensitive
mv: ä --> Ä OK
==================================================================
Linux 2.6.34.7-0.7-default
//birne/tb on /birne/tb type cifs (rw)
enc=UTF-8
a=A Case ignored
mv: a --> A OK
æ=Æ Case ignored
mv: æ --> Æ OK
ø=Ø Case ignored
mv: ø --> Ø OK
ä=Ä Case ignored
mv: ä --> Ä OK
==================================================================
Darwin 10.7.0
/dev/disk0s2 on / (hfs, local, journaled)
enc=UTF-8
a=A Case ignored
mv: a --> A OK
æ=Æ Case ignored
mv: æ --> Æ OK
ø=Ø Case ignored
mv: ø --> Ø OK
ä=Ä Case ignored
mv: ä --> Ä OK
==================================================================
Darwin 10.7.0
/dev/disk1s3 on /Volumes/LACIEFAT (msdos, local, nodev, nosuid, noowners)
enc=UTF-8
a=A Case ignored
mv: a --> A OK
æ=Æ Case ignored
mv: æ --> Æ OK
ø=Ø Case ignored
mv: ø --> Ø OK
ä=Ä Case ignored
mv: ä --> Ä OK
==================================================================
Darwin 10.7.0
/dev/disk1s2 on /Volumes/LacieMacOS (hfs, local, nodev, nosuid, journaled)
enc=UTF-8
a=a Case sensitive
mv: a --> A OK
æ=æ Case sensitive
mv: æ --> Æ OK
ø=ø Case sensitive
mv: ø --> Ø OK
ä=ä Case sensitive
mv: ä --> Ä OK
==================================================================
CYGWIN_NT-5.1 1.5.25(0.156/4/2)
C:\cygwin on / type system (binmode)
enc=ISO-8859-1
a=A Case ignored
mv: a --> A OK
æ=Æ Case ignored
mv: `æ' and `Æ' are the same file
ø=Ø Case ignored
mv: `ø' and `Ø' are the same file
ä=Ä Case ignored
mv: `ä' and `Ä' are the same file
==================================================================
CYGWIN_NT-5.1 1.7.8(0.236/5/3)
C:/cygwin on / type ntfs (binary,auto)
enc=UTF-8
a=A Case ignored
mv: a --> A OK
æ=Æ Case ignored
mv: `æ' and `Æ' are the same file
ø=Ø Case ignored
mv: `ø' and `Ø' are the same file
ä=Ä Case ignored
mv: `ä' and `Ä' are the same file
==================================================================
MINGW32_NT-5.1 1.0.12(0.46/3/2)
C:\msysgit\msysgit on / type user (binmode,noumount)
enc=ISO-8859-1
a=A Case ignored
mv: a --> A OK
æ=Æ Case ignored
mv: æ --> Æ OK
ø=Ø Case ignored
mv: ø --> Ø OK
ä=Ä Case ignored
mv: ä --> Ä OK
==========================================================
#!/bin/sh
testmv() {
(echo $1 > $1 && echo $2 > $2) || {
echo >&2 "Wrong encoding $enc"
cd ..
rm -rf $$.trash
exit 1
}
a=$(cat $1)
printf "$1=$a"
if test $(cat $1) != $1; then
echo " Case ignored"
else
echo " Case sensitive"
fi
rm -f $1 $2
echo $1 > $1
if mv $1 $2; then
echo "mv: $1 --> $2 OK"
fi
rm -f $1 $2
echo
return 0
}
rm -rf $$.trash
mkdir $$.trash || {
echo >&2 "mkdir $$.trash failed"
exit 1
}
cd $$.trash || {
echo >&2 "cd $$.trash failed"
exit 1
}
uname -sr
# get root dir
rdir=$PWD
while test "$rdir" != ""
do
if mount | grep $rdir; then
break
fi
rdir=${rdir%/*}
done
if test -z $rdir; then
mount | grep " / "
fi
enc=ISO-8859-1
#Find out if utf-8 is used
case "$LANG" in
*[uU][tT][fF]*8)
enc=UTF-8
;;
esac
case "$LC_CTYPE" in
*[uU][tT][fF]*8)
enc=UTF-8
;;
esac
case $(uname) in
Darwin)
enc=UTF-8
;;
esac
echo enc=$enc
case "$enc" in
UTF-8)
ae=$(printf '\303\246')
AE=$(printf '\303\206')
oe=$(printf '\303\270')
OE=$(printf '\303\230')
auml=$(printf '\303\244')
Auml=$(printf '\303\204')
;;
*)
ae=$(printf '\346')
AE=$(printf '\306')
oe=$(printf '\370')
OE=$(printf '\330')
auml=$(printf '\344')
Auml=$(printf '\304')
;;
esac
testmv a A
testmv $ae $AE
testmv $oe $OE
testmv $auml $Auml
cd ..
rm -rf $$.trash
^ permalink raw reply [relevance 7%]
* Re: [PATCH] config: fix case sensitive subsection names on writing
2018-07-28 3:52 8% ` Stefan Beller
@ 2018-07-28 10:53 7% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2018-07-28 10:53 UTC (permalink / raw)
To: Stefan Beller
Cc: Junio C Hamano, git, Brandon Williams, peff, Johannes Schindelin
On Fri, Jul 27, 2018 at 08:52:59PM -0700, Stefan Beller wrote:
> > > + for key in "v.a.r" "V.A.r" "v.A.r" "V.a.r"
> > > + do
> > > + cp testConfig testConfig_actual &&
> > > + git config -f testConfig_actual v.a.r value2 &&
> > > + test_cmp testConfig_expect testConfig_actual
> > > + done
> > > +'
> >
> > I think you meant to use "$key" when setting the variable to value2.
> >
> > When the test_cmp fails with "v.a.r" but later succeeds and most
> > importantly succeeds with "V.a.r" (i.e. the last one), wouldn't the
> > whole thing suceed? I think the common trick people use is to end
> > the last one with "|| return 1" in a loop inside test_expect_success.
>
> Hah, of course this patch is not as easy.
>
> The problem is in git_parse_source (config.c, line 755) when we call
> get_base_var it normalizes both styles, (and lower cases the dot style).
>
> So in case of dot style, the strncasecmp is correct, but for the new
> extended style we need to strncmp.
>
> So this is correct for extended but not any more for the former dot style.
Hmm, it looks like this has always been broken. Before your patch (but
after v2.18.0), running "git config v.A.r value2" writes:
[V.A]
r = value1
r = value2
which is obviously broken (we decided it was the right section, but
didn't match the variables, leading to a weird duplicate). After your
patch we write:
[V.A]
r = value1
[v "A"]
r = value2
I.e., we do not consider them the same value at all. But that's actually
what happened before v2.18, too. I think you could almost justify that
behavior as "The section.subsection syntax is deprecated, so we match it
case-insensitively on reading but not on writing; since we never write
such sections ourselves, you are on your own for modifying such entries
if you choose to write them manually".
I dunno. Maybe that is too harsh. But this syntax has been deprecated
for 7 years, and nobody has noticed the bug until now (when _still_
nobody wants to use it, but rather we're poking at it as "gee, I wonder
if this even works").
> I wonder if we want to either (a) add another CONFIG_EVENT_SECTION
> that indicates the difference between the two, or have a flag in 'cf' that
> tells us what kind of section style we have, such that we can check
> appropriately for the case.
I'd think that the parse_event_data could carry type-specific
information. But...
> Or we could encode it in the 'cf->var' value to distinguish the old
> and new style.
Even if we fix the section-matching here, I suspect that would just
trigger a separate bug later when we match the full key (so we might add
to the correct section, but we would not correctly replace an existing
key). To fix that, the information does need to be carried for the whole
lifetime of cf->var, not just during the header event.
-Peff
^ permalink raw reply [relevance 7%]
* Re: Files 'Test.txt' and 'test.txt' are different in Git database, but are the same on Windows file system issue
@ 2020-08-12 23:02 7% ` brian m. carlson
0 siblings, 0 replies; 200+ results
From: brian m. carlson @ 2020-08-12 23:02 UTC (permalink / raw)
To: Viktor Hozhyi; +Cc: git@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 2501 bytes --]
On 2020-08-12 at 19:58:55, Viktor Hozhyi wrote:
> On Wed, Aug 12, 2020 at 10:56 PM Viktor <viktor.hozhyi@gmail.com> wrote:
> >
> > Hi,
> >
> >
> >
> > I’m not sure whether this behavior is on Windows only, so it’s up to you guys.
This behavior happens on any case-insensitive file system. That means
on Windows when the directory is not marked case-sensitive, on macOS if
the file system is case-insensitive, and also in some other scenarios
(e.g., case-insensitive JFS on Linux).
Both Windows 10 and macOS are capable of using case-sensitive file
systems or directories, so this is not exclusive to any one operating
system.
> > Repro steps:
> >
> > 1. Having branch (let say) develop with empty working tree and empty repository – create 2 more branches (‘foo’ and ‘bar’)
> >
> > 2. Commit file ‘Test.txt’ with content ‘Test’ to ‘foo’ branch
> >
> > 3. Switch to ‘bar’ branch and commit file ‘test.txt’ with content ‘test’ (pay attention lower-case)
> >
> > 4. Merge ‘foo’ to develop
> >
> > 5. Merge ‘bar’ to develop
> >
> > After it when you switch to develop – you always will have ‘local changes’. You can perform stash, hard reset, commit – you always will have local changes (and many following errors on other git operations due to local changes).
> >
> > Reason – we have different files in Git DB (‘Test.txt’ and ‘test.txt’), but when git restores them onto Windows file system – it just will rewrite 1 file with another, because for Windows file system – it is 2 equal names.
Git was designed for Unix systems where files are case sensitive. This
is the only behavior that produces correct results for all languages and
locales; it's impossible to correctly do locale-insensitive case
folding. That Git is case sensitive is very much by design.
If you're seeing this problem, you can do something like this:
git mv --cached Test.txt test.txt
For a directory, you'd need to do this:
git mv Test temp
git mv temp test
That will move Test.txt into test.txt, which will solve your problem by
creating exactly one file. If you prefer, you can do it the other way
as well.
That's the only possible solution if you're using a case-insensitive
file system; the other choice is to use the Windows 10 tools to make the
repository and its child directories case sensitive.
--
brian m. carlson: Houston, Texas, US
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply [relevance 7%]
* [PATCH] config.txt: Document behavior of backslashes in subsections
@ 2017-12-21 13:10 7% Dave Borowitz
0 siblings, 0 replies; 200+ results
From: Dave Borowitz @ 2017-12-21 13:10 UTC (permalink / raw)
To: git; +Cc: jrn, Dave Borowitz
Unrecognized escape sequences are invalid in values:
$ git config -f - --list <<EOF
[foo]
bar = "\t\\\y\"\u"
EOF
fatal: bad config line 2 in standard input
But in subsection names, the backslash is simply dropped if the
following character does not produce a recognized escape sequence:
$ git config -f - --list <<EOF
[foo "\t\\\y\"\u"]
bar = baz
EOF
foo.t\y"u.bar=baz
Although it would be nice for subsection names and values to have
consistent behavior, changing the behavior for subsection names is a
nonstarter since it would cause existing, valid config files to
suddenly be interpreted differently.
Signed-off-by: Dave Borowitz <dborowitz@google.com>
---
Documentation/config.txt | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index b18c0f97fe..f772186c44 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -41,11 +41,13 @@ in the section header, like in the example below:
--------
Subsection names are case sensitive and can contain any characters except
-newline (doublequote `"` and backslash can be included by escaping them
-as `\"` and `\\`, respectively). Section headers cannot span multiple
-lines. Variables may belong directly to a section or to a given subsection.
-You can have `[section]` if you have `[section "subsection"]`, but you
-don't need to.
+newline and the null byte. Doublequote `"` and backslash can be included
+by escaping them as `\"` and `\\`, respectively. Backslashes preceding
+other characters are dropped when reading; for example, `\t` is read as
+`t` and `\0` is read as `0` Section headers cannot span multiple lines.
+Variables may belong directly to a section or to a given subsection. You
+can have `[section]` if you have `[section "subsection"]`, but you don't
+need to.
There is also a deprecated `[section.subsection]` syntax. With this
syntax, the subsection name is converted to lower-case and is also
--
2.15.1.620.gb9897f4670-goog
^ permalink raw reply related [relevance 7%]
* [PATCH] Documentation: declare "core.ignorecase" as internal variable
@ 2018-06-24 10:05 7% Marc Strapetz
2018-06-26 21:50 6% ` [PATCH v3] " Marc Strapetz
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Marc Strapetz @ 2018-06-24 10:05 UTC (permalink / raw)
To: git
The current description of "core.ignorecase" reads like an option which
is intended to be changed by the user while it's actually expected to
be set by Git only [1].
[1] https://marc.info/?l=git&m=152972992729761&w=2
Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com>
---
Documentation/config.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ab641bf5a..c25693828 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -390,7 +390,7 @@ core.hideDotFiles::
default mode is 'dotGitOnly'.
core.ignoreCase::
- If true, this option enables various workarounds to enable
+ Internal variable which enables various workarounds to enable
Git to work better on filesystems that are not case sensitive,
like FAT. For example, if a directory listing finds
"makefile" when Git expects "Makefile", Git will assume
@@ -399,7 +399,7 @@ core.ignoreCase::
+
The default is false, except linkgit:git-clone[1] or linkgit:git-init[1]
will probe and set core.ignoreCase true if appropriate when the repository
-is created.
+is created. Modifying this value afterwards may result in unexpected
behavior.
core.precomposeUnicode::
This option is only used by Mac OS implementation of Git.
--
2.17.0.rc0.3.gb1b5a51b2
^ permalink raw reply related [relevance 7%]
* [PATCH 1/2] merge-recursive.c: Fix case-changing merge.
@ 2014-05-06 22:59 7% ` dturner
0 siblings, 0 replies; 200+ results
From: dturner @ 2014-05-06 22:59 UTC (permalink / raw)
To: git; +Cc: gitster, David Turner
From: David Turner <dturner@twitter.com>
On a case-insensitive filesystem, when merging, a file would be
wrongly deleted from the working tree if an incoming commit had
renamed it changing only its case. When merging a rename, the file
with the old name would be deleted -- but since the filesystem
considers the old name to be the same as the new name, the new
file would in fact be deleted.
We avoid this by not deleting files that have a case-clone in the
index at stage 0.
Signed-off-by: David Turner <dturner@twitter.com>
---
merge-recursive.c | 6 +++++
t/t6039-merge-ignorecase.sh | 53 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 59 insertions(+)
create mode 100755 t/t6039-merge-ignorecase.sh
diff --git a/merge-recursive.c b/merge-recursive.c
index 4177092..cab16fa 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -589,6 +589,12 @@ static int remove_file(struct merge_options *o, int clean,
return -1;
}
if (update_working_directory) {
+ if (ignore_case) {
+ struct cache_entry *ce;
+ ce = cache_file_exists(path, strlen(path), ignore_case);
+ if (ce && ce_stage(ce) == 0)
+ return 0;
+ }
if (remove_path(path))
return -1;
}
diff --git a/t/t6039-merge-ignorecase.sh b/t/t6039-merge-ignorecase.sh
new file mode 100755
index 0000000..ad06752
--- /dev/null
+++ b/t/t6039-merge-ignorecase.sh
@@ -0,0 +1,53 @@
+#!/bin/sh
+
+test_description='git-merge with case-changing rename on case-insensitive file system'
+
+. ./test-lib.sh
+
+if ! test_have_prereq CASE_INSENSITIVE_FS
+then
+ skip_all='skipping case insensitive tests - case sensitive file system'
+ test_done
+fi
+
+test_expect_success 'merge with case-changing rename' '
+ test $(git config core.ignorecase) = true &&
+ > TestCase &&
+ git add TestCase &&
+ git commit -m "add TestCase" &&
+ git tag baseline
+ git checkout -b with-camel &&
+ > foo &&
+ git add foo &&
+ git commit -m "intervening commit" &&
+ git checkout master &&
+ git rm TestCase &&
+ > testcase &&
+ git add testcase &&
+ git commit -m "rename to testcase" &&
+ git checkout with-camel &&
+ git merge master -m "merge" &&
+ test -e testcase
+'
+
+test_expect_success 'merge with case-changing rename on both sides' '
+ git checkout master &&
+ git reset --hard baseline &&
+ git branch -D with-camel &&
+ git checkout -b with-camel &&
+ git mv --force TestCase testcase &&
+ git commit -m "recase on branch" &&
+ > foo &&
+ git add foo &&
+ git commit -m "intervening commit" &&
+ git checkout master &&
+ git rm TestCase &&
+ > testcase &&
+ git add testcase &&
+ git commit -m "rename to testcase" &&
+ git checkout with-camel &&
+ git merge master -m "merge" &&
+ test -e testcase
+'
+
+test_done
--
2.0.0.rc0.33.g27630aa
^ permalink raw reply related [relevance 7%]
* [PATCH 1/2] merge-recursive.c: Fix case-changing merge.
@ 2014-05-08 17:23 7% ` dturner
0 siblings, 0 replies; 200+ results
From: dturner @ 2014-05-08 17:23 UTC (permalink / raw)
To: git; +Cc: gitster, David Turner
From: David Turner <dturner@twitter.com>
On a case-insensitive filesystem, when merging, a file would be
wrongly deleted from the working tree if an incoming commit had
renamed it changing only its case. When merging a rename, the file
with the old name would be deleted -- but since the filesystem
considers the old name to be the same as the new name, the new
file would in fact be deleted.
We avoid this by not deleting files that have a case-clone in the
index at stage 0.
Signed-off-by: David Turner <dturner@twitter.com>
---
merge-recursive.c | 6 +++++
t/t6039-merge-ignorecase.sh | 53 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 59 insertions(+)
create mode 100755 t/t6039-merge-ignorecase.sh
diff --git a/merge-recursive.c b/merge-recursive.c
index 4177092..cab16fa 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -589,6 +589,12 @@ static int remove_file(struct merge_options *o, int clean,
return -1;
}
if (update_working_directory) {
+ if (ignore_case) {
+ struct cache_entry *ce;
+ ce = cache_file_exists(path, strlen(path), ignore_case);
+ if (ce && ce_stage(ce) == 0)
+ return 0;
+ }
if (remove_path(path))
return -1;
}
diff --git a/t/t6039-merge-ignorecase.sh b/t/t6039-merge-ignorecase.sh
new file mode 100755
index 0000000..dfc9f17
--- /dev/null
+++ b/t/t6039-merge-ignorecase.sh
@@ -0,0 +1,53 @@
+#!/bin/sh
+
+test_description='git-merge with case-changing rename on case-insensitive file system'
+
+. ./test-lib.sh
+
+if ! test_have_prereq CASE_INSENSITIVE_FS
+then
+ skip_all='skipping case insensitive tests - case sensitive file system'
+ test_done
+fi
+
+test_expect_success 'merge with case-changing rename' '
+ test $(git config core.ignorecase) = true &&
+ >TestCase &&
+ git add TestCase &&
+ git commit -m "add TestCase" &&
+ git tag baseline
+ git checkout -b with-camel &&
+ >foo &&
+ git add foo &&
+ git commit -m "intervening commit" &&
+ git checkout master &&
+ git rm TestCase &&
+ >testcase &&
+ git add testcase &&
+ git commit -m "rename to testcase" &&
+ git checkout with-camel &&
+ git merge master -m "merge" &&
+ test_path_is_file testcase
+'
+
+test_expect_success 'merge with case-changing rename on both sides' '
+ git checkout master &&
+ git reset --hard baseline &&
+ git branch -D with-camel &&
+ git checkout -b with-camel &&
+ git mv --force TestCase testcase &&
+ git commit -m "recase on branch" &&
+ >foo &&
+ git add foo &&
+ git commit -m "intervening commit" &&
+ git checkout master &&
+ git rm TestCase &&
+ >testcase &&
+ git add testcase &&
+ git commit -m "rename to testcase" &&
+ git checkout with-camel &&
+ git merge master -m "merge" &&
+ test_path_is_file testcase
+'
+
+test_done
--
2.0.0.rc0.33.g27630aa
^ permalink raw reply related [relevance 7%]
* Re: [PATCH 2/3] config: fix case sensitive subsection names on writing
2018-08-01 19:34 20% ` [PATCH 2/3] config: fix case sensitive subsection names on writing Stefan Beller
2018-08-01 21:01 8% ` Ramsay Jones
@ 2018-08-01 22:51 7% ` Junio C Hamano
2018-08-03 0:30 8% ` Stefan Beller
1 sibling, 1 reply; 200+ results
From: Junio C Hamano @ 2018-08-01 22:51 UTC (permalink / raw)
To: Stefan Beller; +Cc: bmwill, git, johannes.schindelin, peff
Stefan Beller <sbeller@google.com> writes:
> A use reported a submodule issue regarding strange case indentation
> issues, but it could be boiled down to the following test case:
Perhaps
s/use/user/
s/case indentation issues/section mix-up/
> ... However we do not have a test for writing out config correctly with
> case sensitive subsection names, which is why this went unnoticed in
> 6ae996f2acf (git_config_set: make use of the config parser's event
> stream, 2018-04-09)
s/unnoticed in \(.*04-09)\)/unnoticed when \1 broke it./
This is why I asked if the patch is a "FIX" for an issue introduced
by the cited commit.
> Unfortunately we have to make a distinction between old style configuration
> that looks like
>
> [foo.Bar]
> key = test
>
> and the new quoted style as seen above. The old style is documented as
> case-agnostic, hence we need to keep 'strncasecmp'; although the
> resulting setting for the old style config differs from the configuration.
> That will be fixed in a follow up patch.
>
> Reported-by: JP Sugarbroad <jpsugar@google.com>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
> config.c | 12 +++++++++++-
> t/t1300-config.sh | 1 +
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/config.c b/config.c
> index 7968ef7566a..1d3bf9b5fc0 100644
> --- a/config.c
> +++ b/config.c
> @@ -37,6 +37,7 @@ struct config_source {
> int eof;
> struct strbuf value;
> struct strbuf var;
> + unsigned section_name_old_dot_style : 1;
>
> int (*do_fgetc)(struct config_source *c);
> int (*do_ungetc)(int c, struct config_source *conf);
> @@ -605,6 +606,7 @@ static int get_value(config_fn_t fn, void *data, struct strbuf *name)
>
> static int get_extended_base_var(struct strbuf *name, int c)
> {
> + cf->section_name_old_dot_style = 0;
> do {
> if (c == '\n')
> goto error_incomplete_line;
> @@ -641,6 +643,7 @@ static int get_extended_base_var(struct strbuf *name, int c)
>
> static int get_base_var(struct strbuf *name)
> {
> + cf->section_name_old_dot_style = 1;
> for (;;) {
> int c = get_next_char();
> if (cf->eof)
OK, let me rephrase. The basic parse structure is that
* upon seeing '[', we call get_base_var(), which stuffs the
"section" (including subsection, if exists) in the strbuf.
* get_base_var() upon seeing a space after "[section ", calls
get_extended_base_var(). This space can never exist in an
old-style three-level names, where it is spelled as
"[section.subsection]". This space cannot exist in two-level
names, either. The closing ']' is eaten by this function before
it returns.
* get_extended_base_var() grabs the "double quoted" subsection name
and eats the closing ']' before it returns.
So you set the new bit (section_name_old_dot_style) at the beginning
of get_base_var(), i.e. declare that you assume we are reading old
style, but upon entering get_extended_base_var(), unset it, because
now you know we are parsing a modern style three-level name(s).
Feels quite sensible way to keep track of old/new styles.
When parsing two-level names, old-style bit is set, which we may
need to be careful, thoguh.
> @@ -2355,14 +2358,21 @@ static int store_aux_event(enum config_event_t type,
> store->parsed[store->parsed_nr].type = type;
>
> if (type == CONFIG_EVENT_SECTION) {
> + int (*cmpfn)(const char *, const char *, size_t);
> +
> if (cf->var.len < 2 || cf->var.buf[cf->var.len - 1] != '.')
> return error("invalid section name '%s'", cf->var.buf);
>
> + if (cf->section_name_old_dot_style)
> + cmpfn = strncasecmp;
> + else
> + cmpfn = strncmp;
> +
> /* Is this the section we were looking for? */
> store->is_keys_section =
> store->parsed[store->parsed_nr].is_keys_section =
> cf->var.len - 1 == store->baselen &&
> - !strncasecmp(cf->var.buf, store->key, store->baselen);
> + !cmpfn(cf->var.buf, store->key, store->baselen);
OK. Section names should still be case insensitive (only the case
sensitivity of subsection names is special), but presumably that's
already normalized by the caller so we do not have to worry when we
use strncmp()? Can we add a test to demonstrate that it works
correctly?
Thanks.
^ permalink raw reply [relevance 7%]
* Re* [PATCH] gitweb: make remote_heads config setting work.
@ 2012-11-20 22:21 7% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2012-11-20 22:21 UTC (permalink / raw)
To: Jeff King; +Cc: Phil Pennock, git
Jeff King <peff@peff.net> writes:
> On Thu, Nov 08, 2012 at 08:40:11PM -0800, Junio C Hamano wrote:
>
>> Looking at the code before this part:
>>
>> if (my ($hi, $mi, $lo) = ($key =~ /^([^.]*)\.(.*)\.([^.]*)$/)) {
>> $key = join(".", lc($hi), $mi, lc($lo));
>> } else {
>> $key = lc($key);
>> }
>> $key =~ s/^gitweb\.//;
>> return if ($key =~ m/\W/);
>>
>> the new code is munding the $hi and $mi parts, while the mistaken
>> configuration this patch is trying to correct is about the $lo part,
>> and possibly the $hi part, but never the $mi part.
>
> Good catch. I think the "return" in the existing code suffers from the
> same problem: it will bail on non-word characters in the $mi part, but
> that part should allow arbitrary characters.
I am tired of keeping the "expecting reroll" entries and having to
worry about them, so let's do this
-- >8 --
Subject: [squash] gitweb: make remote_heads config setting work
Only the top-level and bottom-level names are case insensitive and
spelled without "_". Protect future support of subsection names
from name mangling.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
gitweb/gitweb.perl | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git c/gitweb/gitweb.perl w/gitweb/gitweb.perl
index f2144c8..c421fa4 100755
--- c/gitweb/gitweb.perl
+++ w/gitweb/gitweb.perl
@@ -2697,13 +2697,15 @@ sub git_get_project_config {
# only subsection, if exists, is case sensitive,
# and not lowercased by 'git config -z -l'
if (my ($hi, $mi, $lo) = ($key =~ /^([^.]*)\.(.*)\.([^.]*)$/)) {
+ $lo =~ s/_//g;
$key = join(".", lc($hi), $mi, lc($lo));
+ return if ($lo =~ /\W/ || $hi =~ /\W/);
} else {
$key = lc($key);
+ $key =~ s/_//g;
+ return if ($key =~ /\W/);
}
$key =~ s/^gitweb\.//;
- $key =~ s/_//g;
- return if ($key =~ m/\W/);
# type sanity check
if (defined $type) {
^ permalink raw reply related [relevance 7%]
* [PATCH v2 4/7] hashmap: document memihash_cont, hashmap_disallow_rehash api
@ 2017-03-23 13:47 7% ` git
0 siblings, 0 replies; 200+ results
From: git @ 2017-03-23 13:47 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Jeff Hostetler
From: Jeff Hostetler <jeffhost@microsoft.com>
Document memihash_cont() and hashmap_disallow_rehash()
in Documentation/technical/api-hashmap.txt.
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
---
Documentation/technical/api-hashmap.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/Documentation/technical/api-hashmap.txt b/Documentation/technical/api-hashmap.txt
index a3f020c..ccc634b 100644
--- a/Documentation/technical/api-hashmap.txt
+++ b/Documentation/technical/api-hashmap.txt
@@ -21,6 +21,9 @@ that the hashmap is initialized. It may also be useful for statistical purposes
`cmpfn` stores the comparison function specified in `hashmap_init()`. In
advanced scenarios, it may be useful to change this, e.g. to switch between
case-sensitive and case-insensitive lookup.
++
+When `disallow_rehash` is set, automatic rehashes are prevented during inserts
+and deletes.
`struct hashmap_entry`::
@@ -57,6 +60,7 @@ Functions
`unsigned int strihash(const char *buf)`::
`unsigned int memhash(const void *buf, size_t len)`::
`unsigned int memihash(const void *buf, size_t len)`::
+`unsigned int memihash_cont(unsigned int hash_seed, const void *buf, size_t len)`::
Ready-to-use hash functions for strings, using the FNV-1 algorithm (see
http://www.isthe.com/chongo/tech/comp/fnv).
@@ -65,6 +69,9 @@ Functions
`memihash` operate on arbitrary-length memory.
+
`strihash` and `memihash` are case insensitive versions.
++
+`memihash_cont` is a variant of `memihash` that allows a computation to be
+continued with another chunk of data.
`unsigned int sha1hash(const unsigned char *sha1)`::
@@ -184,6 +191,21 @@ passed to `hashmap_cmp_fn` to decide whether the entry matches the key.
+
Returns the removed entry, or NULL if not found.
+`void hashmap_disallow_rehash(struct hashmap *map, unsigned value)`::
+
+ Disallow/allow automatic rehashing of the hashmap during inserts
+ and deletes.
++
+This is useful if the caller knows that the hashmap will be accessed
+by multiple threads.
++
+The caller is still responsible for any necessary locking; this simply
+prevents unexpected rehashing. The caller is also responsible for properly
+sizing the initial hashmap to ensure good performance.
++
+A call to allow rehashing does not force a rehash; that might happen
+with the next insert or delete.
+
`void hashmap_iter_init(struct hashmap *map, struct hashmap_iter *iter)`::
`void *hashmap_iter_next(struct hashmap_iter *iter)`::
`void *hashmap_iter_first(struct hashmap *map, struct hashmap_iter *iter)`::
--
2.7.4
^ permalink raw reply related [relevance 7%]
* [PATCH v1 2/4] hashmap: improve struct hashmap member documentation
@ 2014-07-02 22:21 7% ` Karsten Blees
0 siblings, 0 replies; 200+ results
From: Karsten Blees @ 2014-07-02 22:21 UTC (permalink / raw)
To: Git List
Signed-off-by: Karsten Blees <blees@dcon.de>
---
Documentation/technical/api-hashmap.txt | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/Documentation/technical/api-hashmap.txt b/Documentation/technical/api-hashmap.txt
index 4689968..dc21a7c 100644
--- a/Documentation/technical/api-hashmap.txt
+++ b/Documentation/technical/api-hashmap.txt
@@ -8,11 +8,19 @@ Data Structures
`struct hashmap`::
- The hash table structure.
+ The hash table structure. Members can be used as follows, but should
+ not be modified directly:
+
-The `size` member keeps track of the total number of entries. The `cmpfn`
-member is a function used to compare two entries for equality. The `table` and
-`tablesize` members store the hash table and its size, respectively.
+The `size` member keeps track of the total number of entries (0 means the
+hashmap is empty).
++
+`tablesize` is the allocated size of the hash table. A non-0 value indicates
+that the hashmap is initialized. It may also be useful for statistical purposes
+(i.e. `size / tablesize` is the current load factor).
++
+`cmpfn` stores the comparison function specified in `hashmap_init()`. In
+advanced scenarios, it may be useful to change this, e.g. to switch between
+case-sensitive and case-insensitive lookup.
`struct hashmap_entry`::
--
1.9.4.msysgit.0.dirty
^ permalink raw reply related [relevance 7%]
* [PATCH 6/6] wildmatch test: create & test files on disk in addition to in-memory
2017-12-25 0:28 8% ` [PATCH v2 7/7] wildmatch test: create & test files on disk in addition to in-memory Ævar Arnfjörð Bjarmason
@ 2017-12-23 21:30 7% ` Ævar Arnfjörð Bjarmason
1 sibling, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2017-12-23 21:30 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy,
Anthony Ramine, Ramsay Jones,
Ævar Arnfjörð Bjarmason
There has never been any full roundtrip testing of what git-ls-files
and other functions that use wildmatch() actually do, rather we've
been satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two, and even when we test for those (as with
9e4e8a64c2 ("pathspec: die on empty strings as pathspec", 2017-06-06))
there was no one place where you can review how these two modes
differ.
Now there is. With this admittedly very verbose code that's mostly
copy-pasted (it doesn't look worth the effort to me in clarity to
factor this into functions) we now attempt to create a file called
$haystack and match $needle against it for each pair of $needle and
$haystack that we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
As a result of doing this we can now see the cases where these two
ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in 9e4e8a64c2 above, where '' is
now an error as far as ls-files is concerned, but wildmatch() itself
happily accepts it.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
a[]b | 0
t/t3070-wildmatch.sh | 336 ++++++++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 319 insertions(+), 17 deletions(-)
create mode 100644 a[]b
diff --git a/a[]b b/a[]b
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index 47b479e423..d423bb01f3 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -4,31 +4,146 @@ test_description='wildmatch tests'
. ./test-lib.sh
+create_test_file() {
+ file=$1
+
+ # `touch .` will succeed but obviously not do what we intend
+ # here.
+ test "$file" = "." && return 1
+ # We cannot create a file with an empty filename.
+ test "$file" = "" && return 1
+ # The tests that are testing that e.g. foo//bar is matched by
+ # foo/*/bar can't be tested on filesystems since there's no
+ # way we're getting a double slash.
+ echo "$file" | grep -q -F '//' && return 1
+ # When testing the difference between foo/bar and foo/bar/ we
+ # can't test the latter.
+ echo "$file" | grep -q -E '/$' && return 1
+
+ dirs=$(echo "$file" | sed -r 's!/[^/]+$!!')
+
+ # We touch "./$file" instead of "$file" because even an
+ # escaped "touch -- -" means something different.
+ if test "$file" != "$dirs"
+ then
+ mkdir -p -- "$dirs" 2>/dev/null &&
+ touch -- "./$file" 2>/dev/null &&
+ return 0
+ else
+ touch -- "./$file" 2>/dev/null &&
+ return 0
+ fi
+ return 1
+}
+
wildtest() {
- match_w_glob=$1
- match_w_globi=$2
- match_w_pathmatch=$3
- match_w_pathmatchi=$4
- text=$5
- pattern=$6
+ if test "$#" = 6
+ then
+ # When test-wildmatch and git ls-files produce the same
+ # result.
+ match_w_glob=$1
+ match_f_w_glob=$match_w_glob
+ match_w_globi=$2
+ match_f_w_globi=$match_w_globi
+ match_w_pathmatch=$3
+ match_f_w_pathmatch=$match_w_pathmatch
+ match_w_pathmatchi=$4
+ match_f_w_pathmatchi=$match_w_pathmatchi
+ text=$5
+ pattern=$6
+ elif test "$#" = 10
+ then
+ match_w_glob=$1
+ match_w_globi=$2
+ match_w_pathmatch=$3
+ match_w_pathmatchi=$4
+ match_f_w_glob=$5
+ match_f_w_globi=$6
+ match_f_w_pathmatch=$7
+ match_f_w_pathmatchi=$8
+ text=$9
+ pattern=$10
+ fi
+ # $1: Case sensitive glob match: test-wildmatch
if test "$match_w_glob" = 1
then
- test_expect_success "wildmatch: match '$text' '$pattern'" "
+ test_expect_success "wildmatch: match '$text' '$pattern'" "
test-wildmatch wildmatch '$text' '$pattern'
"
elif test "$match_w_glob" = 0
then
- test_expect_success "wildmatch: no match '$text' '$pattern'" "
+ test_expect_success "wildmatch: no match '$text' '$pattern'" "
! test-wildmatch wildmatch '$text' '$pattern'
"
else
test_expect_success "PANIC: Test framework error. Unknown matches value $match_w_glob" 'false'
fi
+ # $1: Case sensitive glob match: ls-files
+ if test "$match_f_w_glob" = 'E'
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): match dies on '$pattern' '$text'" "
+ test_when_finished \"
+ rm -rf -- * &&
+ git reset
+ \" &&
+ git add -A &&
+ >expect.err &&
+ printf '%s' '$text' >expect &&
+ test_must_fail git --glob-pathspecs ls-files -z -- '$pattern'
+ "
+ else
+ test_expect_failure "wildmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_glob" = 1
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): match '$pattern' '$text'" "
+ test_when_finished \"
+ rm -rf -- * &&
+ git reset
+ \" &&
+ git add -A &&
+ >expect.err &&
+ printf '%s' '$text' >expect &&
+ git --glob-pathspecs ls-files -z -- '$pattern' 2>actual.err | tr -d '\0' >actual &&
+ test_cmp expect.err actual.err &&
+ test_cmp expect actual
+ "
+ else
+ test_expect_failure "wildmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_glob" = 0
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): no match '$pattern' '$text'" "
+ test_when_finished \"
+ rm -rf -- * &&
+ git reset
+ \" &&
+ git add -A &&
+ >expect.err &&
+ >expect &&
+ git --glob-pathspecs ls-files -z -- '$pattern' 2>actual.err | tr -d '\0' >actual &&
+ test_cmp expect.err actual.err &&
+ test_cmp expect actual
+ "
+ else
+ test_expect_failure "wildmatch(ls): no match skip '$pattern' '$text'" 'false'
+ fi
+ else
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_f_w_glob" 'false'
+ fi
+
+ # $2: Case insensitive glob match: test-wildmatch
if test "$match_w_globi" = 1
then
- test_expect_success "iwildmatch: match '$text' '$pattern'" "
+ test_expect_success "iwildmatch: match '$text' '$pattern'" "
test-wildmatch iwildmatch '$text' '$pattern'
"
elif test "$match_w_globi" = 0
@@ -40,23 +155,145 @@ wildtest() {
test_expect_success "PANIC: Test framework error. Unknown matches value $match_w_globi" 'false'
fi
+ # $2: Case insensitive glob match: ls-files
+ if test "$match_f_w_globi" = 'E'
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): match dies on '$pattern' '$text'" "
+ test_when_finished \"
+ rm -rf -- * &&
+ git reset
+ \" &&
+ git add -A &&
+ >expect.err &&
+ printf '%s' '$text' >expect &&
+ test_must_fail git --glob-pathspecs --icase-pathspecs ls-files -z -- '$pattern'
+ "
+ else
+ test_expect_failure "wildmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_globi" = 1
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): match '$pattern' '$text'" "
+ test_when_finished \"
+ rm -rf -- * &&
+ git reset
+ \" &&
+ git add -A &&
+ >expect.err &&
+ printf '%s' '$text' >expect &&
+ git --glob-pathspecs --icase-pathspecs ls-files -z -- '$pattern' 2>actual.err | tr -d '\0' >actual &&
+ test_cmp expect.err actual.err &&
+ test_cmp expect actual
+ "
+ else
+ test_expect_failure "wildmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_globi" = 0
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): no match '$pattern' '$text'" "
+ test_when_finished \"
+ rm -rf -- * &&
+ git reset
+ \" &&
+ git add -A &&
+ >expect.err &&
+ >expect &&
+ git --glob-pathspecs --icase-pathspecs ls-files -z -- '$pattern' 2>actual.err | tr -d '\0' >actual &&
+ test_cmp expect.err actual.err &&
+ test_cmp expect actual
+ "
+ else
+ test_expect_failure "wildmatch(ls): no match skip '$pattern' '$text'" 'false'
+ fi
+ else
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_f_w_globi" 'false'
+ fi
+
+ # $3: Case sensitive path match: test-wildmatch
if test "$match_w_pathmatch" = 1
then
- test_expect_success "pathmatch: match '$text' '$pattern'" "
+ test_expect_success "pathmatch: match '$text' '$pattern'" "
test-wildmatch pathmatch '$text' '$pattern'
"
elif test "$match_w_pathmatch" = 0
then
- test_expect_success "pathmatch: no match '$text' '$pattern'" "
+ test_expect_success "pathmatch: no match '$text' '$pattern'" "
! test-wildmatch pathmatch '$text' '$pattern'
"
else
test_expect_success "PANIC: Test framework error. Unknown matches value $match_w_pathmatch" 'false'
fi
+ # $4: Case sensitive path match: ls-files
+ if test "$match_f_w_pathmatch" = 'E'
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "pathmatch(ls): match dies on '$pattern' '$text'" "
+ test_when_finished \"
+ rm -rf -- * &&
+ git reset
+ \" &&
+ git add -A &&
+ >expect.err &&
+ printf '%s' '$text' >expect &&
+ test_must_fail git ls-files -z -- '$pattern'
+ "
+ else
+ test_expect_failure "pathmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_pathmatch" = 1
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "pathmatch(ls): match '$pattern' '$text'" "
+ test_when_finished \"
+ rm -rf -- * &&
+ git reset
+ \" &&
+ git add -A &&
+ >expect.err &&
+ printf '%s' '$text' >expect &&
+ git ls-files -z -- '$pattern' 2>actual.err | tr -d '\0' >actual &&
+ test_cmp expect.err actual.err &&
+ test_cmp expect actual
+ "
+ else
+ test_expect_failure "pathmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_pathmatch" = 0
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "pathmatch(ls): no match '$pattern' '$text'" "
+ test_when_finished \"
+ rm -rf -- * &&
+ git reset
+ \" &&
+ git add -A &&
+ >expect.err &&
+ >expect &&
+ git ls-files -z -- '$pattern' 2>actual.err | tr -d '\0' >actual &&
+ test_cmp expect.err actual.err &&
+ test_cmp expect actual
+ "
+ else
+ test_expect_failure "pathmatch(ls): no match skip '$pattern' '$text'" 'false'
+ fi
+ else
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_f_w_pathmatch" 'false'
+ fi
+
+ # $4: Case insensitive path match: test-wildmatch
if test "$match_w_pathmatchi" = 1
then
- test_expect_success "ipathmatch: match '$text' '$pattern'" "
+ test_expect_success "ipathmatch: match '$text' '$pattern'" "
test-wildmatch ipathmatch '$text' '$pattern'
"
elif test "$match_w_pathmatchi" = 0
@@ -67,6 +304,66 @@ wildtest() {
else
test_expect_success "PANIC: Test framework error. Unknown matches value $match_w_pathmatchi" 'false'
fi
+
+ # $4: Case insensitive path match: ls-files
+ if test "$match_f_w_pathmatchi" = 'E'
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "ipathmatch(ls): match dies on '$pattern' '$text'" "
+ test_when_finished \"
+ rm -rf -- * &&
+ git reset
+ \" &&
+ git add -A &&
+ >expect.err &&
+ printf '%s' '$text' >expect &&
+ test_must_fail git --icase-pathspecs ls-files -z -- '$pattern'
+ "
+ else
+ test_expect_failure "pathmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_pathmatchi" = 1
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "ipathmatch(ls): match '$pattern' '$text'" "
+ test_when_finished \"
+ rm -rf -- * &&
+ git reset
+ \" &&
+ git add -A &&
+ >expect.err &&
+ printf '%s' '$text' >expect &&
+ git --icase-pathspecs ls-files -z -- '$pattern' 2>actual.err | tr -d '\0' >actual &&
+ test_cmp expect.err actual.err &&
+ test_cmp expect actual
+ "
+ else
+ test_expect_failure "pathmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_pathmatchi" = 0
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "ipathmatch(ls): no match '$pattern' '$text'" "
+ test_when_finished \"
+ rm -rf -- * &&
+ git reset
+ \" &&
+ git add -A &&
+ >expect.err &&
+ >expect &&
+ git ls-files -z -- '$pattern' 2>actual.err | tr -d '\0' >actual &&
+ test_cmp expect.err actual.err &&
+ test_cmp expect actual
+ "
+ else
+ test_expect_failure "pathmatch(ls): no match skip '$pattern' '$text'" 'false'
+ fi
+ else
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_f_w_pathmatchi" 'false'
+ fi
}
# Basic wildmatch features
@@ -135,7 +432,8 @@ wildtest 1 1 1 1 'acrt' 'a[c-c]rt'
wildtest 0 0 0 0 ']' '[!]-]'
wildtest 1 1 1 1 'a' '[!]-]'
wildtest 0 0 0 0 '' '\'
-wildtest 0 0 0 0 '\' '\'
+wildtest 0 0 0 0 \
+ 1 1 1 1 '\' '\'
wildtest 0 0 0 0 'XXX/\' '*/\'
wildtest 1 1 1 1 'XXX/\' '*/\\'
wildtest 1 1 1 1 'foo' 'foo'
@@ -149,7 +447,8 @@ wildtest 1 1 1 1 '[ab]' '[[:digit]ab]'
wildtest 1 1 1 1 '[ab]' '[\[:]ab]'
wildtest 1 1 1 1 '?a?b' '\??\?b'
wildtest 1 1 1 1 'abc' '\a\b\c'
-wildtest 0 0 0 0 'foo' ''
+wildtest 0 0 0 0 \
+ E E E E 'foo' ''
wildtest 1 1 1 1 'foo/bar/baz/to' '**/t[o]'
# Character class tests
@@ -179,8 +478,10 @@ wildtest 1 1 1 1 ']' '[\]]'
wildtest 0 0 0 0 '\]' '[\]]'
wildtest 0 0 0 0 '\' '[\]]'
wildtest 0 0 0 0 'ab' 'a[]b'
-wildtest 0 0 0 0 'a[]b' 'a[]b'
-wildtest 0 0 0 0 'ab[' 'ab['
+wildtest 0 0 0 0 \
+ 1 1 1 1 'a[]b' 'a[]b'
+wildtest 0 0 0 0 \
+ 1 1 1 1 'ab[' 'ab['
wildtest 0 0 0 0 'ab' '[!'
wildtest 0 0 0 0 'ab' '[-'
wildtest 1 1 1 1 '-' '[-]'
@@ -248,7 +549,8 @@ wildtest 1 1 1 1 foo/bar 'foo/*'
wildtest 0 0 1 1 foo/bba/arr 'foo/*'
wildtest 1 1 1 1 foo/bba/arr 'foo/**'
wildtest 0 0 1 1 foo/bba/arr 'foo*'
-wildtest 0 0 1 1 foo/bba/arr 'foo**'
+wildtest 0 0 1 1 \
+ 1 1 1 1 foo/bba/arr 'foo**'
wildtest 0 0 1 1 foo/bba/arr 'foo/*arr'
wildtest 0 0 1 1 foo/bba/arr 'foo/**arr'
wildtest 0 0 0 0 foo/bba/arr 'foo/*z'
--
2.15.1.424.g9478a66081
^ permalink raw reply related [relevance 7%]
* [PATCH] Documentation/config.txt: Document config file syntax better
2007-01-20 14:03 7% ` [PATCH] Documentation/config.txt: Document config file syntax better Jakub Narebski
@ 2007-01-22 15:25 7% ` Jakub Narebski
2007-01-24 14:14 7% ` [PATCH 2/1] Documentation/config.txt: Correct info about subsection name Jakub Narebski
0 siblings, 1 reply; 200+ results
From: Jakub Narebski @ 2007-01-22 15:25 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jakub Narebski
Separate part of Documentation/config.txt which deals with git config file
syntax into "Syntax" subsection, and expand it. Add information about
subsections, boolean values, escaping and escape sequences in string
values, and continuing variable value on the next line.
Add also proxy settings to config file example to show example of
partially enclosed in double quotes string value.
Parts based on comments by Junio C Hamano, Johannes Schindelin,
config.c, and the smb.conf(5) man page.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> What about my Documentation/config.txt changes?
>
> I was not sure about that one, given a lot of commentary in your
> message, suggesting more research and revision is needed, like
> these...
>
>>>> +All the other lines are recognized as setting variables, in the form
>>>> +'name = value'. If there is no equal sign on the line, the entire line
>>>> +is taken as 'name' and the variable is recognized as boolean "true".
>>>> +Variable names are case insensitive.
>>>
>>> They cannot contain anything else than alphanumeric characters, in
>>> particular no whitespace.
>>
>> It is mentioned above "Syntax" section, but perhaps it should be repeated.
>> I haven't took a look at code to check what values for section names and
>> for key/variable names are allowed.
>> ...
>>> One thing that left me puzzled after reading the description was
>>> what a user can do with "subsection". It is unclear from the
>>> description if [section "sub.section"], [section "sub.sec=ti.on"]
>>> or worse yet, [section "sub\nsection with an embbedded LF"] are
>>> allowed. The rest seemed sane.
>>
>> I'm not sure what is allowed in section name, and in subsection name,
>> so for now I have left it as is. I can amend this commit, or add new
>> commit explaining this.
I hope that this is satisfactory.
I haven't wrote about current limits on the lengths: 256/2 for section
plus subsection name length, 256 for fully qualified variable name,
1024 for value length; I think this does not belong to end user
documentation.
Documentation/config.txt | 76 +++++++++++++++++++++++++++++++++++++++++----
1 files changed, 69 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index f1f409d..77a2b16 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -14,14 +14,72 @@ dot-separated segment and the section name is everything before the last
dot. The variable names are case-insensitive and only alphanumeric
characters are allowed. Some variables may appear multiple times.
+Syntax
+~~~~~~
+
The syntax is fairly flexible and permissive; whitespaces are mostly
-ignored. The '#' and ';' characters begin comments to the end of line,
-blank lines are ignored, lines containing strings enclosed in square
-brackets start sections and all the other lines are recognized
-as setting variables, in the form 'name = value'. If there is no equal
-sign on the line, the entire line is taken as 'name' and the variable
-is recognized as boolean "true". String values may be entirely or partially
-enclosed in double quotes; some variables may require special value format.
+ignored. The '#' and ';' characters begin comments to the end of line,
+blank lines are ignored.
+
+The file consists of sections and variables. A section begins with
+the name of the section in square brackets and continues until the next
+section begins. Section names are not case sensitive. Only alphanumeric
+characters, '`-`' and '`.`' are allowed in section names. Each variable
+must belong to some section, which means that there must be section
+header before first setting of a variable.
+
+Sections can be further divided into subsections. To begin a subsection
+put its name in double quotes, separated by space from the section name,
+in the section header, like in example below:
+
+--------
+ [section "subsection"]
+
+--------
+
+Subsection names can contain any characters (doublequote '`"`', backslash
+'`\`' and newline have to be entered escaped as '`\"`', '`\\`' and '`\n`',
+respecitvely) and are case sensitive. Section header cannot span multiple
+lines. Variables may belong directly to a section or to a given subsection.
+You can have `[section]` if you have `[section "subsection"]`, but you
+don't need to.
+
+There is also (case insensitive) alternative `[section.subsection]` syntax.
+In this syntax subsection names follow the same restrictions as for section
+name.
+
+All the other lines are recognized as setting variables, in the form
+'name = value'. If there is no equal sign on the line, the entire line
+is taken as 'name' and the variable is recognized as boolean "true".
+The variable names are case-insensitive and only alphanumeric
+characters and '`-`' are allowed. There can be more than one value
+for a given variable; we say then that variable is multivalued.
+
+Leading and trailing whitespace in a variable value is discarded.
+Internal whitespace within a variable value is retained verbatim.
+
+The values following the equals sign in variable assign are all either
+a string, an integer, or a boolean. Boolean values may be given as yes/no,
+0/1 or true/false. Case is not significant in boolean values, when
+converting value to the canonical form using '--bool' type specifier;
+`git-repo-config` will ensure that the output is "true" or "false".
+
+String values may be entirely or partially enclosed in double quotes.
+You need to enclose variable value in double quotes if you want to
+preserve leading or trailing whitespace, or if variable value contains
+beginning of comment characters (if it contains '#' or ';').
+Double quote '`"`' and backslash '`\`' characters in variable value must
+be escaped: use '`\"`' for '`"`' and '`\\`' for '`\`'.
+
+The following escape sequences (beside '`\"`' and '`\\`') are recognized:
+'`\n`' for newline character (NL), '`\t`' for horizontal tabulation (HT, TAB)
+and '`\b`' for backspace (BS). No other char escape sequence, nor octal
+char sequences are valid.
+
+Variable value ending in a '`\`' is continued on the next line in the
+customary UNIX fashion.
+
+Some variables may require special value format.
Example
~~~~~~~
@@ -40,6 +98,10 @@ Example
remote = origin
merge = refs/heads/devel
+ # Proxy settings
+ [core]
+ gitProxy="ssh" for "ssh://kernel.org/"
+ gitProxy=default-proxy ; for the rest
Variables
~~~~~~~~~
--
1.4.4.4
^ permalink raw reply related [relevance 7%]
* [PATCH 2/1] Documentation/config.txt: Correct info about subsection name
2007-01-22 15:25 7% ` Jakub Narebski
@ 2007-01-24 14:14 7% ` Jakub Narebski
0 siblings, 0 replies; 200+ results
From: Jakub Narebski @ 2007-01-24 14:14 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Contrary to variable values, in subsection names parsing character
escape codes (besides literal escaping of " as \", and \ as \\)
is not performed; subsection name cannot contain newlines.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Documentation/config.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 77a2b16..d8244b1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -37,8 +37,8 @@ in the section header, like in example below:
--------
-Subsection names can contain any characters (doublequote '`"`', backslash
-'`\`' and newline have to be entered escaped as '`\"`', '`\\`' and '`\n`',
+Subsection names can contain any characters except newline (doublequote
+'`"`' and backslash have to be escaped as '`\"`' and '`\\`',
respecitvely) and are case sensitive. Section header cannot span multiple
lines. Variables may belong directly to a section or to a given subsection.
You can have `[section]` if you have `[section "subsection"]`, but you
--
1.4.4.4
^ permalink raw reply related [relevance 7%]
* Re: [RFC] Git config file reader in Perl (WIP)
@ 2007-01-19 22:44 7% ` Jakub Narebski
0 siblings, 0 replies; 200+ results
From: Jakub Narebski @ 2007-01-19 22:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nikolai Weibull, Junio C Hamano, Eric Wong, git
Johannes Schindelin wrote:
>
> On Fri, 19 Jan 2007, Jakub Narebski wrote:
>
>> From a bit of testing, as documentation of config file format is
>> woefully incomplete, (yes, I know I should use the source) _some_ of C
>> escape sequences aka. character escape codes (CEC) are parsed:
>
> No, you should not just use the source. You should use the source _and_
> complete the documentation.
Something like the patch below? Untested! ("make doc" up to
git-repo-config.txt compiles, though).
I'm not sure how to tell that you can have [section] if you have
[section "subsection"], but you don't need to. And I probably forgot
to add some information.
And I'm not sure if some behavior should not be changed, for example
allowing _any_ line to be continued with `\`, or that other character
escape sequences and perhaps also octal character sequences should be
allowed (either that or `\b` should not be parsed).
I can send proper patch if requested, but I'd rather above issues
were resolved first.
diff --git a/Documentation/config.txt b/Documentation/config.txt
index da7fde5..9544308 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -14,14 +14,53 @@ dot-separated segment and the section name is everything before the last
dot. The variable names are case-insensitive and only alphanumeric
characters are allowed. Some variables may appear multiple times.
+Syntax
+~~~~~~
+
The syntax is fairly flexible and permissive; whitespaces are mostly
-ignored. The '#' and ';' characters begin comments to the end of line,
-blank lines are ignored, lines containing strings enclosed in square
-brackets start sections and all the other lines are recognized
-as setting variables, in the form 'name = value'. If there is no equal
-sign on the line, the entire line is taken as 'name' and the variable
-is recognized as boolean "true". String values may be entirely or partially
-enclosed in double quotes; some variables may require special value format.
+ignored. The '#' and ';' characters begin comments to the end of line,
+blank lines are ignored.
+
+The file consists of sections and variables. A section begins with
+the name of the section in square brackets and continues until the next
+section begins. Section names are not case sensitive. Each variable
+must belong to some section, which means that there must be section
+header before first setting of a variable.
+
+Sections can be further divided into subsections. To begin a subsection
+put it name in double quotes, separated by space from the section name,
+in the section header, like in example below
+
+ [section "subsection"]
+
+Subsection names can contain whitespace and are case sensitive. Variables
+may belong directly to a section, or to a given subsection.
+
+All the other lines are recognized as setting variables, in the form
+'name = value'. If there is no equal sign on the line, the entire line
+is taken as 'name' and the variable is recognized as boolean "true".
+Variable names are case insensitive. There can be more than one value
+for a given variable; we say then that variable is multivalued.
+
+Leading and trailing whitespace in a variable value is discarded.
+Internal whitespace within a variable value is retained verbatim.
+
+String values may be entirely or partially enclosed in double quotes.
+You need to enclose variable value in double quotes if you want to
+preserve leading or trailing whitespace, or if variable value contains
+beginning of comment characters, it means if it contains `#` or `;`.
+Double quote `"` and backslash `\` characters in variable value must
+be escaped: use `\"` for `"`, and `\\` for `\`.
+
+The following escape sequences (beside `\"` and `\\`) are recognized:
+`\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)
+and `\b` for backspace (BS). No other character escape codes, nor octal
+char sequences are valid.
+
+Variable value ending in a `\` is continued on the next line in the
+customary UNIX fashion.
+
+Some variables may require special value format.
Example
~~~~~~~
^ permalink raw reply related [relevance 7%]
* [PATCH] merge-recursive.c: Fix case-changing merge bug
@ 2014-05-02 0:21 7% ` David Turner
0 siblings, 0 replies; 200+ results
From: David Turner @ 2014-05-02 0:21 UTC (permalink / raw)
To: git
On a case-insensitive filesystem, when merging, a file would be
wrongly deleted from the working tree if an incoming commit had
renamed it changing only its case. When merging a rename, the file
with the old name would be deleted -- but since the filesystem
considers the old name to be the same as the new name, the new
file would in fact be deleted.
We avoid this by not deleting files that have a case-clone in the
index at stage 0.
Signed-off-by: David Turner <dturner@twitter.com>
---
merge-recursive.c | 6 ++++++
t/t7063-merge-ignorecase.sh | 32 ++++++++++++++++++++++++++++++++
2 files changed, 38 insertions(+)
create mode 100755 t/t7063-merge-ignorecase.sh
diff --git a/merge-recursive.c b/merge-recursive.c
index 4177092..cab16fa 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -589,6 +589,12 @@ static int remove_file(struct merge_options *o, int clean,
return -1;
}
if (update_working_directory) {
+ if (ignore_case) {
+ struct cache_entry *ce;
+ ce = cache_file_exists(path, strlen(path), ignore_case);
+ if (ce && ce_stage(ce) == 0)
+ return 0;
+ }
if (remove_path(path))
return -1;
}
diff --git a/t/t7063-merge-ignorecase.sh b/t/t7063-merge-ignorecase.sh
new file mode 100755
index 0000000..6d4959f
--- /dev/null
+++ b/t/t7063-merge-ignorecase.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+
+test_description='git-merge with case-changing rename on case-insensitive file system'
+
+. ./test-lib.sh
+
+if ! test_have_prereq CASE_INSENSITIVE_FS
+then
+ skip_all='skipping case insensitive tests - case sensitive file system'
+ test_done
+fi
+
+test_expect_success 'merge with case-changing rename with ignorecase=true' '
+ test $(git config core.ignorecase) = true &&
+ touch TestCase &&
+ git add TestCase &&
+ git commit -m "add TestCase" &&
+ git checkout -b with-camel &&
+ touch foo &&
+ git add foo &&
+ git commit -m "intervening commit" &&
+ git checkout master &&
+ git rm TestCase &&
+ touch testcase &&
+ git add testcase &&
+ git commit -m "rename to testcase" &&
+ git checkout with-camel &&
+ git merge master -m "merge" &&
+ test -e testcase
+'
+
+test_done
--
^ permalink raw reply related [relevance 7%]
* should config options be treated as case-sensitive?
@ 2018-05-22 7:57 7% Robert P. J. Day
2018-05-22 12:13 8% ` Ævar Arnfjörð Bjarmason
0 siblings, 1 reply; 200+ results
From: Robert P. J. Day @ 2018-05-22 7:57 UTC (permalink / raw)
To: Git Mailing list
in my wanderings, more oddities, such as this:
$ grep -ir blankboundary *
builtin/blame.c: if (!strcmp(var, "blame.blankboundary")) {
Documentation/config.txt:blame.blankBoundary::
Documentation/blame-options.txt: be controlled via the `blame.blankboundary` config option.
Documentation/RelNotes/2.15.1.txt: * Description of blame.{showroot,blankboundary,showemail,date}
Documentation/RelNotes/2.16.0.txt: * Description of blame.{showroot,blankboundary,showemail,date}
$
where you can see the single instance of "blankBoundary" in
Doc/config.txt (with the upper case 'B'), while the rest have no such
thing.
for fun, i checked another of blame's config settings, with similar
results:
builtin/blame.c: if (!strcmp(var, "blame.showemail")) {
Documentation/config.txt:blame.showEmail::
Documentation/RelNotes/2.15.1.txt: * Description of blame.{showroot,blankboundary,showemail,date}
Documentation/RelNotes/2.5.0.txt: * "git blame" learned blame.showEmail configuration variable.
Documentation/RelNotes/2.16.0.txt: * Description of blame.{showroot,blankboundary,showemail,date}
Documentation/git-blame.txt: This can also be controlled via the `blame.showEmail` config
t/t8002-blame.sh:test_expect_success 'setup showEmail tests' '
t/t8002-blame.sh:test_expect_success 'blame with showemail options' '
t/t8002-blame.sh:test_expect_success 'blame with showEmail config false' '
t/t8002-blame.sh: git config blame.showEmail false &&
t/t8002-blame.sh:test_expect_success 'blame with showEmail config true' '
t/t8002-blame.sh: git config blame.showEmail true &&
thoughts?
rday
p.s. i am not *trying* to be annoyingly pedantic, i am merely
succeeding.
^ permalink raw reply [relevance 7%]
* Re: [PATCH v3 7/7] wildmatch test: create & test files on disk in addition to in-memory
2017-12-28 23:28 8% ` [PATCH v3 7/7] wildmatch test: create & test files on disk in addition to in-memory Ævar Arnfjörð Bjarmason
@ 2017-12-29 0:16 7% ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2017-12-29 0:16 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy,
Anthony Ramine, Ramsay Jones, Johannes Sixt
On Thu, Dec 28 2017, Ævar Arnfjörð Bjarmason jotted:
> + pattern=$10
Junio, in lie of me spamming the list too much, do you mind squashing
this into this (if no further issues arise):
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index d7aa7eb5fe..f985139b6f 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -89,7 +89,7 @@ wildtest() {
match_f_w_pathmatch=$7
match_f_w_pathmatchi=$8
text=$9
- pattern=$10
+ pattern=${10}
fi
# $1: Case sensitive glob match: test-wildmatch
With this the tests pass on both bash & dash.
^ permalink raw reply related [relevance 7%]
* Re: [JGIT PATCH 10/12] Match config subsection names using case sensitive search
2009-07-21 20:19 12% ` [JGIT PATCH 10/12] Match config subsection names using case sensitive search Shawn O. Pearce
@ 2009-07-22 11:11 7% ` Constantine Plotnikov
2009-07-22 21:37 8% ` Robin Rosenberg
0 siblings, 1 reply; 200+ results
From: Constantine Plotnikov @ 2009-07-22 11:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Robin Rosenberg, git
This patch is incomplete. The method getRawEntry(...) and
setStringList(...) should be fixed as part of this patch too. There is
subsection is converted to lowercase. I was planning to submit it as
separate patch.
Also I'm somewhat bothered by usage of toLowerCase() without locale
specified and equalsIgnoreCase(). When turkish locale is default one
there could be surprising results with the letter "I". The program:
import java.util.Locale;
public class Test {
public static void main(String[] args) {
Locale tr_TR = new Locale("tr", "TR");
System.out.printf("i = U+%04x LC(I, tr_TR) = U+%04x\n", (int)'i',
(int)"I".toLowerCase(tr_TR).charAt(0));
System.out.printf("I = U+%04x UC(i, tr_TR) = U+%04x\n", (int)'I',
(int)"i".toUpperCase(tr_TR).charAt(0));
}
}
Gives the following output:
i = U+0069 LC(I, tr_TR) = U+0131
I = U+0049 UC(i, tr_TR) = U+0130
So I suggest to explicitly use Locale.US for all toLowerCase()
invocation in Config class just in case and to replace
equalsIgnoreCase() with something else. But this possibly should be
some other patch series. I do not know what C git doing in case
turkish locale and whether it is a bug or "feature".
Regards,
Constantine
On Wed, Jul 22, 2009 at 12:19 AM, Shawn O. Pearce<spearce@spearce.org> wrote:
> The subsection name is case sensitive, and should be matched as such.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> .../src/org/spearce/jgit/lib/Config.java | 19 ++++++++++++++-----
> 1 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Config.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Config.java
> index e379c37..974ffea 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/lib/Config.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Config.java
> @@ -4,6 +4,7 @@
> * Copyright (C) 2008, Shawn O. Pearce <spearce@spearce.org>
> * Copyright (C) 2008, Thad Hughes <thadh@thad.corp.google.com>
> * Copyright (C) 2009, JetBrains s.r.o.
> + * Copyright (C) 2009, Google, Inc.
> *
> * All rights reserved.
> *
> @@ -1024,17 +1025,25 @@ private static String readValue(final BufferedReader r, boolean quote,
>
> boolean match(final String aSection, final String aSubsection,
> final String aKey) {
> - return eq(section, aSection) && eq(subsection, aSubsection)
> - && eq(name, aKey);
> + return eqIgnoreCase(section, aSection)
> + && eqSameCase(subsection, aSubsection)
> + && eqIgnoreCase(name, aKey);
> }
>
> - private static boolean eq(final String a, final String b) {
> + private static boolean eqIgnoreCase(final String a, final String b) {
> if (a == null && b == null)
> return true;
> if (a == null || b == null)
> return false;
> return a.equalsIgnoreCase(b);
> }
> - }
>
> -}
> \ No newline at end of file
> + private static boolean eqSameCase(final String a, final String b) {
> + if (a == null && b == null)
> + return true;
> + if (a == null || b == null)
> + return false;
> + return a.equals(b);
> + }
> + }
> +}
> --
> 1.6.4.rc1.186.g60aa0c
>
> --
> 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
>
^ permalink raw reply [relevance 7%]
* [PATCH v7 12/49] completion: bash: do not modify COMP_WORDBREAKS
@ 2023-04-01 8:45 7% ` Felipe Contreras
0 siblings, 0 replies; 200+ results
From: Felipe Contreras @ 2023-04-01 8:45 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
There was no need for this once __git_reassemble_comp_words_by_ref() was
introduced. Now irrespective of the value of COMP_WORDBREAKS, words are
always joined together.
By default COMP_WORDBREAKS does contain a colon, and if it doesn't
somebody probably has a reason for it.
Completions are not supposed to modify COMP_WORDBREAKS and none of the
completions in the bash-completion project do.
We manually set it in Zsh so the Bash script is not confused.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.bash | 5 -----
contrib/completion/git-completion.zsh | 1 +
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index cf6ff0595f..fd2a43de38 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -65,11 +65,6 @@
# case insensitively, even on systems with case sensitive file systems
# (e.g., completing tag name "FOO" on "git checkout f<TAB>").
-case "$COMP_WORDBREAKS" in
-*:*) : great ;;
-*) COMP_WORDBREAKS="$COMP_WORDBREAKS:"
-esac
-
# Discovers the path to the git repository taking any '--git-dir=<path>' and
# '-C <path>' options into account and stores it in the $__git_repo_path
# variable.
diff --git a/contrib/completion/git-completion.zsh b/contrib/completion/git-completion.zsh
index 790879e319..186c49195b 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -46,6 +46,7 @@ fi
local old_complete="$functions[complete]"
functions[complete]=:
+COMP_WORDBREAKS=':'
GIT_SOURCING_ZSH_COMPLETION=y . "$script"
functions[complete]="$old_complete"
--
2.33.0
^ permalink raw reply related [relevance 7%]
* Re: [PATCH 0/3] config: fix case sensitive subsection names on writing
2018-07-30 23:04 12% ` [PATCH 0/3] " Stefan Beller
2018-07-30 23:04 24% ` [PATCH 2/3] " Stefan Beller
@ 2018-07-31 15:16 8% ` Junio C Hamano
2018-07-30 23:04 7% ` Stefan Beller
2 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2018-07-31 15:16 UTC (permalink / raw)
To: Stefan Beller; +Cc: johannes.schindelin, bmwill, git, peff
Stefan Beller <sbeller@google.com> writes:
> It turns out it doesn't quite do that;
> The parsing code takes the old notation into account and translates any
> [V.A]
> r = ...
> into a lower cased "v.a." for ease of comparison. That happens in
> get_base_var, which would call further into get_extended_base_var
> if the new notation is used.
>
> The code in store_aux_event however is written without the consideration
> of the old code and has no way of knowing the capitalization of the
> section or subsection (which were forced to lowercase in the old
> dot notation).
>
> So either we have to do some major surgery, or the old notation gets
> some regression while fixing the new notation.
As long as
- the regression is documented clearly (i.e. what unexpected thing
happens, just like you have a good description in the log message
of PATCH 2/3 for "[foo "Bar"] key = ..."),
- users are nudged to use the new style instead, and
- writing with "git config" (or "git init/clone" for that matter)
won't produce these old-style sections
I think it is OK to punt. I would expect, as Git's userbase is a
lot wider than 10 years ago, there is at least some people who did
exploit the fact that "[V.A] r = one" and "[v.a] r = two" give a
single "v.a.r" variable that is multi-valued, and it indeed would be
a regression to them, to which no good workaround exists.
But breaking '[V "a"] r = ...' is a more grave sin. Even though I
hate to rob Peter to pay Paul (or vice versa), in this case it is
justified to fix the more basic form sooner and wait for an actual
complaint before fixing the new and deliberate regression introduced
while fixing it to the old-style variable.
^ permalink raw reply [relevance 8%]
* [PATCH] t6131 - skip tests if on case-insensitive file system
@ 2013-07-17 13:22 8% Mark Levedahl
0 siblings, 0 replies; 200+ results
From: Mark Levedahl @ 2013-07-17 13:22 UTC (permalink / raw)
To: git; +Cc: Mark Levedahl
This test fails on Cygwin where the default system configuration does not
support case sensitivity (only case retention), so don't run the test on
such systems.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
t/t6131-pathspec-icase.sh | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/t/t6131-pathspec-icase.sh b/t/t6131-pathspec-icase.sh
index 3215eef..8d4a7fc 100755
--- a/t/t6131-pathspec-icase.sh
+++ b/t/t6131-pathspec-icase.sh
@@ -3,6 +3,12 @@
test_description='test case insensitive pathspec limiting'
. ./test-lib.sh
+if test_have_prereq CASE_INSENSITIVE_FS
+then
+ skip_all='skipping case sensitive tests - case insensitive file system'
+ test_done
+fi
+
test_expect_success 'create commits with glob characters' '
test_commit bar bar &&
test_commit bAr bAr &&
--
1.8.3.2.0.63
^ permalink raw reply related [relevance 8%]
* Re: [PATCH] t5533: make it pass on case-sensitive filesystems
2016-08-05 14:19 8% ` Johannes Schindelin
@ 2016-08-08 11:21 8% ` Jeff King
2016-08-08 11:49 8% ` Johannes Schindelin
0 siblings, 1 reply; 200+ results
From: Jeff King @ 2016-08-08 11:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, John Keeping, Lars Schneider
On Fri, Aug 05, 2016 at 04:19:08PM +0200, Johannes Schindelin wrote:
> > The fix is meant for jk/push-force-with-lease-creation topic, but I
> > had to find it out by the old fashioned way, i.e. running blame for
> > these lines in 'pu' to find eee98e74f9 is the culprit and then
> > running "git branch --with eee98e74f9". The only thing the line
> > made easier is I _could_ start the blame at the named commit (which
> > is on 'next') instead of 'pu'. When I took that "base-commit"
> > series, I was hoping that it would give us a lot more useful
> > information.
>
> Sorry for that. The way my mail-patch-series.sh script works is that it
> tries to determine which branch between `master`, `next` or `pu` is the
> base (and it then submits *all* commits that are on top of that branch).
>
> So my branch was indeed based on `next` for that reason, not on
> top of `jk/push-force-with-lease-creation`. Otherwise, I would have
> resubmitted John's patches because the script would have determined that
> my patch is on top of `master`, not on top of `next`.
Do you fetch from the main git.git repository, or Junio's gitster/git
workspace on GitHub?
I usually fetch the latter, and then you have all the information you
need. So to work on somebody else's existing topic, you can do[1]:
git checkout jk/push-force-with-lease-creation
which will check out the branch, tracking Junio's version of the topic
as your "upstream". Then things like "git rebase -i" just work, and you
can extract the patches as @{u}..HEAD.
It does get weird when he picks up your patch but you want to do further
work, because you would probably not want to "rebase -i" on top of it
(your version of the patch would become obsolete!).
-Peff
[1] I'm assuming you know the topic name. If not, then I usually find
the commit through the usual archaeology, and then run "git branch
a --contains" on it (or "for-each-ref" works for that these days,
and you can restrict it to a pattern matching topic branches).
^ permalink raw reply [relevance 8%]
* [PATCH] t5533: make it pass on case-sensitive filesystems
@ 2016-08-04 14:54 8% Johannes Schindelin
2016-08-04 17:18 8% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Johannes Schindelin @ 2016-08-04 14:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, John Keeping, Lars Schneider
The newly-added test case wants to commit a file "c.t" (note the lower
case) when a previous test case already committed a file "C.t". This
confuses Git to the point that it thinks "c.t" was not staged when "git
add c.t" was called.
Simply make the naming of the test commits consistent with the previous
test cases: use upper-case, and advance in the alphabet.
This came up in local work to rebase the Windows-specific patches to the
current `next` branch. An identical fix was suggested by John Keeping.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Published-As: https://github.com/dscho/git/releases/tag/t5533-case-insensitive-v1
Fetch-It-Via: git fetch https://github.com/dscho/git t5533-case-insensitive-v1
t/t5533-push-cas.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t5533-push-cas.sh b/t/t5533-push-cas.sh
index 09899af..a2c9e74 100755
--- a/t/t5533-push-cas.sh
+++ b/t/t5533-push-cas.sh
@@ -220,7 +220,7 @@ test_expect_success 'new branch already exists' '
(
cd src &&
git checkout -b branch master &&
- test_commit c
+ test_commit F
) &&
(
cd dst &&
--
2.9.0.281.g286a8d9
base-commit: 9813b109b4ec6630220e5f3d8aff275e23cba59e
^ permalink raw reply related [relevance 8%]
* [PATCH 3/4] git-gui: add regexp search mode to the searchbar
@ 2011-10-14 8:14 8% ` Bert Wesarg
0 siblings, 0 replies; 200+ results
From: Bert Wesarg @ 2011-10-14 8:14 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git, Bert Wesarg
It's off by default, but can be enabled via the config gui.search.regexp.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
lib/search.tcl | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/lib/search.tcl b/lib/search.tcl
index 461c66d..9268ec3 100644
--- a/lib/search.tcl
+++ b/lib/search.tcl
@@ -7,6 +7,8 @@ field w
field ctext
field searchstring {}
+field regexpsearch
+field default_regexpsearch
field casesensitive
field default_casesensitive
field searchdirn -forwards
@@ -19,6 +21,7 @@ constructor new {i_w i_text args} {
set w $i_w
set ctext $i_text
+ set default_regexpsearch [is_config_true gui.search.regexp]
if {[is_config_true gui.search.smartcase]} {
set default_casesensitive 0
} else {
@@ -30,10 +33,13 @@ constructor new {i_w i_text args} {
entry $w.ent -textvariable ${__this}::searchstring -background lightgreen
${NS}::button $w.bn -text [mc Next] -command [cb find_next]
${NS}::button $w.bp -text [mc Prev] -command [cb find_prev]
- ${NS}::checkbutton $w.cs -text [mc Case-Sensitive] \
+ ${NS}::checkbutton $w.re -text [mc RegExp] \
+ -variable ${__this}::regexpsearch -command [cb _incrsearch]
+ ${NS}::checkbutton $w.cs -text [mc Case] \
-variable ${__this}::casesensitive -command [cb _incrsearch]
pack $w.l -side left
pack $w.cs -side right
+ pack $w.re -side right
pack $w.bp -side right
pack $w.bn -side right
pack $w.ent -side left -expand 1 -fill x
@@ -52,6 +58,7 @@ constructor new {i_w i_text args} {
method show {} {
if {![visible $this]} {
grid $w
+ set regexpsearch $default_regexpsearch
set casesensitive $default_casesensitive
}
focus -force $w.ent
@@ -106,6 +113,9 @@ method _do_search {start {mlenvar {}} {dir {}} {endbound {}}} {
upvar $mlenvar mlen
lappend cmd -count mlen
}
+ if {$regexpsearch} {
+ lappend cmd -regexp
+ }
if {!$casesensitive} {
lappend cmd -nocase
}
--
1.7.6.789.gb4599
^ permalink raw reply related [relevance 8%]
* Re: [PATCH] config: fix case sensitive subsection names on writing
2018-07-28 1:01 8% ` Junio C Hamano
@ 2018-07-28 3:52 8% ` Stefan Beller
2018-07-28 10:53 7% ` Jeff King
0 siblings, 1 reply; 200+ results
From: Stefan Beller @ 2018-07-28 3:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brandon Williams, peff, Johannes Schindelin
On Fri, Jul 27, 2018 at 6:01 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Stefan Beller <sbeller@google.com> writes:
>
> > A use reported a submodule issue regarding strange case indentation
>
> s/use/&r/; Is this "indentation" issue?
eh case sensitivity*
> > + q_to_tab >testConfig_expect <<-EOF &&
> > + # insensitive:
> > + [V.A]
> > + Qr = value2
> > + EOF
>
> It is unfortunate that we hardcode the exact indentation
> in the test to make it care. Perhaps a wrapper around test_cmp that
> is used locally in this file to first strip the leading HT from both
> sides of the comparison would make it more robust?
I think this is valuable for the second test to see where it was replaced.
>
> > + for key in "v.a.r" "V.A.r" "v.A.r" "V.a.r"
> > + do
> > + cp testConfig testConfig_actual &&
> > + git config -f testConfig_actual v.a.r value2 &&
> > + test_cmp testConfig_expect testConfig_actual
> > + done
> > +'
>
> I think you meant to use "$key" when setting the variable to value2.
>
> When the test_cmp fails with "v.a.r" but later succeeds and most
> importantly succeeds with "V.a.r" (i.e. the last one), wouldn't the
> whole thing suceed? I think the common trick people use is to end
> the last one with "|| return 1" in a loop inside test_expect_success.
>
Hah, of course this patch is not as easy.
The problem is in git_parse_source (config.c, line 755) when we call
get_base_var it normalizes both styles, (and lower cases the dot style).
So in case of dot style, the strncasecmp is correct, but for the new
extended style we need to strncmp.
So this is correct for extended but not any more for the former dot style.
I wonder if we want to either (a) add another CONFIG_EVENT_SECTION
that indicates the difference between the two, or have a flag in 'cf' that
tells us what kind of section style we have, such that we can check
appropriately for the case.
Or we could encode it in the 'cf->var' value to distinguish the old
and new style.
Thanks,
Stefan
^ permalink raw reply [relevance 8%]
* [PATCH v4 7/7] wildmatch test: create & test files on disk in addition to in-memory
@ 2018-01-04 19:26 8% ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2018-01-04 19:26 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy,
Anthony Ramine, Johannes Sixt, Adam Dinwoodie,
Ævar Arnfjörð Bjarmason
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
As a result of doing this we can now see the cases where these two
ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1] above, where '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
t/t3070-wildmatch.sh | 301 +++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 290 insertions(+), 11 deletions(-)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index 06db053ae2..f606f91acb 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -4,14 +4,113 @@ test_description='wildmatch tests'
. ./test-lib.sh
+create_test_file() {
+ file=$1
+
+ case $file in
+ # `touch .` will succeed but obviously not do what we intend
+ # here.
+ ".")
+ return 1
+ ;;
+ # We cannot create a file with an empty filename.
+ "")
+ return 1
+ ;;
+ # The tests that are testing that e.g. foo//bar is matched by
+ # foo/*/bar can't be tested on filesystems since there's no
+ # way we're getting a double slash.
+ *//*)
+ return 1
+ ;;
+ # When testing the difference between foo/bar and foo/bar/ we
+ # can't test the latter.
+ */)
+ return 1
+ ;;
+ # On Windows, \ in paths is silently converted to /, which
+ # would result in the "touch" below working, but the test
+ # itself failing. See 6fd1106aa4 ("t3700: Skip a test with
+ # backslashes in pathspec", 2009-03-13) for prior art and
+ # details.
+ *\\*)
+ if ! test_have_prereq BSLASHPSPEC
+ then
+ return 1
+ fi
+ # NOTE: The ;;& bash extension is not portable, so
+ # this test needs to be at the end of the pattern
+ # list.
+ #
+ # If we want to add more conditional returns we either
+ # need a new case statement, or turn this whole thing
+ # into a series of "if" tests.
+ ;;
+ esac
+
+ # Turn foo/bar/baz into foo/bar to create foo/bar as a
+ # directory structure.
+ dirs=${file%/*}
+
+ # We touch "./$file" instead of "$file" because even an
+ # escaped "touch -- -" means get arguments from stdin.
+ if test "$file" != "$dirs"
+ then
+ mkdir -p -- "$dirs" &&
+ touch -- "./$file" &&
+ return 0
+ else
+ touch -- "./$file" &&
+ return 0
+ fi
+ return 1
+}
+
+wildtest_file_setup() {
+ test_when_finished "
+ rm -rf -- * &&
+ git reset
+ " &&
+ git add -A &&
+ >expect.err
+}
+
+wildtest_stdout_stderr_cmp() {
+ tr -d '\0' <actual.raw >actual &&
+ test_cmp expect.err actual.err &&
+ test_cmp expect actual
+}
+
wildtest() {
- match_w_glob=$1
- match_w_globi=$2
- match_w_pathmatch=$3
- match_w_pathmatchi=$4
- text=$5
- pattern=$6
+ if test "$#" = 6
+ then
+ # When test-wildmatch and git ls-files produce the same
+ # result.
+ match_w_glob=$1
+ match_f_w_glob=$match_w_glob
+ match_w_globi=$2
+ match_f_w_globi=$match_w_globi
+ match_w_pathmatch=$3
+ match_f_w_pathmatch=$match_w_pathmatch
+ match_w_pathmatchi=$4
+ match_f_w_pathmatchi=$match_w_pathmatchi
+ text=$5
+ pattern=$6
+ elif test "$#" = 10
+ then
+ match_w_glob=$1
+ match_w_globi=$2
+ match_w_pathmatch=$3
+ match_w_pathmatchi=$4
+ match_f_w_glob=$5
+ match_f_w_globi=$6
+ match_f_w_pathmatch=$7
+ match_f_w_pathmatchi=$8
+ text=$9
+ pattern=${10}
+ fi
+ # $1: Case sensitive glob match: test-wildmatch
if test "$match_w_glob" = 1
then
test_expect_success "wildmatch: match '$text' '$pattern'" "
@@ -26,6 +125,50 @@ wildtest() {
test_expect_success "PANIC: Test framework error. Unknown matches value $match_w_glob" 'false'
fi
+ # $1: Case sensitive glob match: ls-files
+ if test "$match_f_w_glob" = 'E'
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): match dies on '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ test_must_fail git --glob-pathspecs ls-files -z -- '$pattern'
+ "
+ else
+ test_expect_failure "wildmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_glob" = 1
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ git --glob-pathspecs ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "wildmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_glob" = 0
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): no match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ >expect &&
+ git --glob-pathspecs ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "wildmatch(ls): no match skip '$pattern' '$text'" 'false'
+ fi
+ else
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_f_w_glob" 'false'
+ fi
+
+ # $2: Case insensitive glob match: test-wildmatch
if test "$match_w_globi" = 1
then
test_expect_success "iwildmatch: match '$text' '$pattern'" "
@@ -40,6 +183,50 @@ wildtest() {
test_expect_success "PANIC: Test framework error. Unknown matches value $match_w_globi" 'false'
fi
+ # $2: Case insensitive glob match: ls-files
+ if test "$match_f_w_globi" = 'E'
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "iwildmatch(ls): match dies on '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ test_must_fail git --glob-pathspecs --icase-pathspecs ls-files -z -- '$pattern'
+ "
+ else
+ test_expect_failure "wildmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_globi" = 1
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "iwildmatch(ls): match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ git --glob-pathspecs --icase-pathspecs ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "iwildmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_globi" = 0
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "iwildmatch(ls): no match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ >expect &&
+ git --glob-pathspecs --icase-pathspecs ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "iwildmatch(ls): no match skip '$pattern' '$text'" 'false'
+ fi
+ else
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_f_w_globi" 'false'
+ fi
+
+ # $3: Case sensitive path match: test-wildmatch
if test "$match_w_pathmatch" = 1
then
test_expect_success "pathmatch: match '$text' '$pattern'" "
@@ -54,6 +241,50 @@ wildtest() {
test_expect_success "PANIC: Test framework error. Unknown matches value $match_w_pathmatch" 'false'
fi
+ # $4: Case sensitive path match: ls-files
+ if test "$match_f_w_pathmatch" = 'E'
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "pathmatch(ls): match dies on '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ test_must_fail git ls-files -z -- '$pattern'
+ "
+ else
+ test_expect_failure "pathmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_pathmatch" = 1
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "pathmatch(ls): match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ git ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "pathmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_pathmatch" = 0
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "pathmatch(ls): no match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ >expect &&
+ git ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "pathmatch(ls): no match skip '$pattern' '$text'" 'false'
+ fi
+ else
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_f_w_pathmatch" 'false'
+ fi
+
+ # $4: Case insensitive path match: test-wildmatch
if test "$match_w_pathmatchi" = 1
then
test_expect_success "ipathmatch: match '$text' '$pattern'" "
@@ -67,6 +298,49 @@ wildtest() {
else
test_expect_success "PANIC: Test framework error. Unknown matches value $match_w_pathmatchi" 'false'
fi
+
+ # $4: Case insensitive path match: ls-files
+ if test "$match_f_w_pathmatchi" = 'E'
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "ipathmatch(ls): match dies on '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ test_must_fail git --icase-pathspecs ls-files -z -- '$pattern'
+ "
+ else
+ test_expect_failure "pathmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_pathmatchi" = 1
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "ipathmatch(ls): match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ git --icase-pathspecs ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "ipathmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_pathmatchi" = 0
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "ipathmatch(ls): no match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ >expect &&
+ git ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "ipathmatch(ls): no match skip '$pattern' '$text'" 'false'
+ fi
+ else
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_f_w_pathmatchi" 'false'
+ fi
}
# Basic wildmatch features
@@ -135,7 +409,8 @@ wildtest 1 1 1 1 'acrt' 'a[c-c]rt'
wildtest 0 0 0 0 ']' '[!]-]'
wildtest 1 1 1 1 'a' '[!]-]'
wildtest 0 0 0 0 '' '\'
-wildtest 0 0 0 0 '\' '\'
+wildtest 0 0 0 0 \
+ 1 1 1 1 '\' '\'
wildtest 0 0 0 0 'XXX/\' '*/\'
wildtest 1 1 1 1 'XXX/\' '*/\\'
wildtest 1 1 1 1 'foo' 'foo'
@@ -149,7 +424,8 @@ wildtest 1 1 1 1 '[ab]' '[[:digit]ab]'
wildtest 1 1 1 1 '[ab]' '[\[:]ab]'
wildtest 1 1 1 1 '?a?b' '\??\?b'
wildtest 1 1 1 1 'abc' '\a\b\c'
-wildtest 0 0 0 0 'foo' ''
+wildtest 0 0 0 0 \
+ E E E E 'foo' ''
wildtest 1 1 1 1 'foo/bar/baz/to' '**/t[o]'
# Character class tests
@@ -179,8 +455,10 @@ wildtest 1 1 1 1 ']' '[\]]'
wildtest 0 0 0 0 '\]' '[\]]'
wildtest 0 0 0 0 '\' '[\]]'
wildtest 0 0 0 0 'ab' 'a[]b'
-wildtest 0 0 0 0 'a[]b' 'a[]b'
-wildtest 0 0 0 0 'ab[' 'ab['
+wildtest 0 0 0 0 \
+ 1 1 1 1 'a[]b' 'a[]b'
+wildtest 0 0 0 0 \
+ 1 1 1 1 'ab[' 'ab['
wildtest 0 0 0 0 'ab' '[!'
wildtest 0 0 0 0 'ab' '[-'
wildtest 1 1 1 1 '-' '[-]'
@@ -248,7 +526,8 @@ wildtest 1 1 1 1 foo/bar 'foo/*'
wildtest 0 0 1 1 foo/bba/arr 'foo/*'
wildtest 1 1 1 1 foo/bba/arr 'foo/**'
wildtest 0 0 1 1 foo/bba/arr 'foo*'
-wildtest 0 0 1 1 foo/bba/arr 'foo**'
+wildtest 0 0 1 1 \
+ 1 1 1 1 foo/bba/arr 'foo**'
wildtest 0 0 1 1 foo/bba/arr 'foo/*arr'
wildtest 0 0 1 1 foo/bba/arr 'foo/**arr'
wildtest 0 0 0 0 foo/bba/arr 'foo/*z'
--
2.15.1.424.g9478a66081
^ permalink raw reply related [relevance 8%]
* [PATCH v2 7/7] wildmatch test: create & test files on disk in addition to in-memory
@ 2017-12-25 0:28 8% ` Ævar Arnfjörð Bjarmason
2017-12-23 21:30 7% ` [PATCH 6/6] " Ævar Arnfjörð Bjarmason
1 sibling, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2017-12-25 0:28 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy,
Anthony Ramine, Ramsay Jones, Johannes Sixt,
Ævar Arnfjörð Bjarmason
There has never been any full roundtrip testing of what git-ls-files
and other functions that use wildmatch() actually do, rather we've
been satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two, and even when we test for those (as with
9e4e8a64c2 ("pathspec: die on empty strings as pathspec", 2017-06-06))
there was no one place where you can review how these two modes
differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
As a result of doing this we can now see the cases where these two
ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in 9e4e8a64c2 above, where '' is
now an error as far as ls-files is concerned, but wildmatch() itself
happily accepts it.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
t/t3070-wildmatch.sh | 285 ++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 273 insertions(+), 12 deletions(-)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index 593b25b278..80d13b5b60 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -4,14 +4,95 @@ test_description='wildmatch tests'
. ./test-lib.sh
+create_test_file() {
+ file=$1
+
+ case $file in
+ # `touch .` will succeed but obviously not do what we intend
+ # here.
+ ".")
+ return 1
+ ;;
+ # We cannot create a file with an empty filename.
+ "")
+ return 1
+ ;;
+ # The tests that are testing that e.g. foo//bar is matched by
+ # foo/*/bar can't be tested on filesystems since there's no
+ # way we're getting a double slash.
+ *//*)
+ return 1
+ ;;
+ # When testing the difference between foo/bar and foo/bar/ we
+ # can't test the latter.
+ */)
+ return 1
+ ;;
+ esac
+
+ # Turn foo/bar/baz into foo/bar to create foo/bar as a
+ # directory structure.
+ dirs=$(echo "$file" | sed -r 's!/[^/]+$!!')
+
+ # We touch "./$file" instead of "$file" because even an
+ # escaped "touch -- -" means get arguments from stdin.
+ if test "$file" != "$dirs"
+ then
+ mkdir -p -- "$dirs" &&
+ touch -- "./$file" &&
+ return 0
+ else
+ touch -- "./$file" &&
+ return 0
+ fi
+ return 1
+}
+
+wildtest_file_setup() {
+ test_when_finished "
+ rm -rf -- * &&
+ git reset
+ " &&
+ git add -A &&
+ >expect.err
+}
+
+wildtest_stdout_stderr_cmp() {
+ tr -d '\0' <actual.raw >actual &&
+ test_cmp expect.err actual.err &&
+ test_cmp expect actual
+}
+
wildtest() {
- match_w_glob=$1
- match_w_globi=$2
- match_w_pathmatch=$3
- match_w_pathmatchi=$4
- text=$5
- pattern=$6
+ if test "$#" = 6
+ then
+ # When test-wildmatch and git ls-files produce the same
+ # result.
+ match_w_glob=$1
+ match_f_w_glob=$match_w_glob
+ match_w_globi=$2
+ match_f_w_globi=$match_w_globi
+ match_w_pathmatch=$3
+ match_f_w_pathmatch=$match_w_pathmatch
+ match_w_pathmatchi=$4
+ match_f_w_pathmatchi=$match_w_pathmatchi
+ text=$5
+ pattern=$6
+ elif test "$#" = 10
+ then
+ match_w_glob=$1
+ match_w_globi=$2
+ match_w_pathmatch=$3
+ match_w_pathmatchi=$4
+ match_f_w_glob=$5
+ match_f_w_globi=$6
+ match_f_w_pathmatch=$7
+ match_f_w_pathmatchi=$8
+ text=$9
+ pattern=$10
+ fi
+ # $1: Case sensitive glob match: test-wildmatch
if test "$match_w_glob" = 1
then
test_expect_success "wildmatch: match '$text' '$pattern'" "
@@ -26,6 +107,50 @@ wildtest() {
test_expect_success "PANIC: Test framework error. Unknown matches value $match_w_glob" 'false'
fi
+ # $1: Case sensitive glob match: ls-files
+ if test "$match_f_w_glob" = 'E'
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): match dies on '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ test_must_fail git --glob-pathspecs ls-files -z -- '$pattern'
+ "
+ else
+ test_expect_failure "wildmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_glob" = 1
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ git --glob-pathspecs ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "wildmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_glob" = 0
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): no match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ >expect &&
+ git --glob-pathspecs ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "wildmatch(ls): no match skip '$pattern' '$text'" 'false'
+ fi
+ else
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_f_w_glob" 'false'
+ fi
+
+ # $2: Case insensitive glob match: test-wildmatch
if test "$match_w_globi" = 1
then
test_expect_success "iwildmatch: match '$text' '$pattern'" "
@@ -40,6 +165,50 @@ wildtest() {
test_expect_success "PANIC: Test framework error. Unknown matches value $match_w_globi" 'false'
fi
+ # $2: Case insensitive glob match: ls-files
+ if test "$match_f_w_globi" = 'E'
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): match dies on '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ test_must_fail git --glob-pathspecs --icase-pathspecs ls-files -z -- '$pattern'
+ "
+ else
+ test_expect_failure "wildmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_globi" = 1
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ git --glob-pathspecs --icase-pathspecs ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "wildmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_globi" = 0
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): no match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ >expect &&
+ git --glob-pathspecs --icase-pathspecs ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "wildmatch(ls): no match skip '$pattern' '$text'" 'false'
+ fi
+ else
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_f_w_globi" 'false'
+ fi
+
+ # $3: Case sensitive path match: test-wildmatch
if test "$match_w_pathmatch" = 1
then
test_expect_success "pathmatch: match '$text' '$pattern'" "
@@ -54,9 +223,53 @@ wildtest() {
test_expect_success "PANIC: Test framework error. Unknown matches value $match_w_pathmatch" 'false'
fi
+ # $4: Case sensitive path match: ls-files
+ if test "$match_f_w_pathmatch" = 'E'
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "pathmatch(ls): match dies on '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ test_must_fail git ls-files -z -- '$pattern'
+ "
+ else
+ test_expect_failure "pathmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_pathmatch" = 1
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "pathmatch(ls): match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ git ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "pathmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_pathmatch" = 0
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "pathmatch(ls): no match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ >expect &&
+ git ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "pathmatch(ls): no match skip '$pattern' '$text'" 'false'
+ fi
+ else
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_f_w_pathmatch" 'false'
+ fi
+
+ # $4: Case insensitive path match: test-wildmatch
if test "$match_w_pathmatchi" = 1
then
- test_expect_success "ipathmatch: match '$text' '$pattern'" "
+ test_expect_success "ipathmatch: match '$text' '$pattern'" "
test-wildmatch ipathmatch '$text' '$pattern'
"
elif test "$match_w_pathmatchi" = 0
@@ -67,6 +280,49 @@ wildtest() {
else
test_expect_success "PANIC: Test framework error. Unknown matches value $match_w_pathmatchi" 'false'
fi
+
+ # $4: Case insensitive path match: ls-files
+ if test "$match_f_w_pathmatchi" = 'E'
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "ipathmatch(ls): match dies on '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ test_must_fail git --icase-pathspecs ls-files -z -- '$pattern'
+ "
+ else
+ test_expect_failure "pathmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_pathmatchi" = 1
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "ipathmatch(ls): match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ git --icase-pathspecs ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "pathmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_pathmatchi" = 0
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "ipathmatch(ls): no match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ >expect &&
+ git ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "pathmatch(ls): no match skip '$pattern' '$text'" 'false'
+ fi
+ else
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_f_w_pathmatchi" 'false'
+ fi
}
# Basic wildmatch features
@@ -135,7 +391,8 @@ wildtest 1 1 1 1 'acrt' 'a[c-c]rt'
wildtest 0 0 0 0 ']' '[!]-]'
wildtest 1 1 1 1 'a' '[!]-]'
wildtest 0 0 0 0 '' '\'
-wildtest 0 0 0 0 '\' '\'
+wildtest 0 0 0 0 \
+ 1 1 1 1 '\' '\'
wildtest 0 0 0 0 'XXX/\' '*/\'
wildtest 1 1 1 1 'XXX/\' '*/\\'
wildtest 1 1 1 1 'foo' 'foo'
@@ -149,7 +406,8 @@ wildtest 1 1 1 1 '[ab]' '[[:digit]ab]'
wildtest 1 1 1 1 '[ab]' '[\[:]ab]'
wildtest 1 1 1 1 '?a?b' '\??\?b'
wildtest 1 1 1 1 'abc' '\a\b\c'
-wildtest 0 0 0 0 'foo' ''
+wildtest 0 0 0 0 \
+ E E E E 'foo' ''
wildtest 1 1 1 1 'foo/bar/baz/to' '**/t[o]'
# Character class tests
@@ -179,8 +437,10 @@ wildtest 1 1 1 1 ']' '[\]]'
wildtest 0 0 0 0 '\]' '[\]]'
wildtest 0 0 0 0 '\' '[\]]'
wildtest 0 0 0 0 'ab' 'a[]b'
-wildtest 0 0 0 0 'a[]b' 'a[]b'
-wildtest 0 0 0 0 'ab[' 'ab['
+wildtest 0 0 0 0 \
+ 1 1 1 1 'a[]b' 'a[]b'
+wildtest 0 0 0 0 \
+ 1 1 1 1 'ab[' 'ab['
wildtest 0 0 0 0 'ab' '[!'
wildtest 0 0 0 0 'ab' '[-'
wildtest 1 1 1 1 '-' '[-]'
@@ -248,7 +508,8 @@ wildtest 1 1 1 1 foo/bar 'foo/*'
wildtest 0 0 1 1 foo/bba/arr 'foo/*'
wildtest 1 1 1 1 foo/bba/arr 'foo/**'
wildtest 0 0 1 1 foo/bba/arr 'foo*'
-wildtest 0 0 1 1 foo/bba/arr 'foo**'
+wildtest 0 0 1 1 \
+ 1 1 1 1 foo/bba/arr 'foo**'
wildtest 0 0 1 1 foo/bba/arr 'foo/*arr'
wildtest 0 0 1 1 foo/bba/arr 'foo/**arr'
wildtest 0 0 0 0 foo/bba/arr 'foo/*z'
--
2.15.1.424.g9478a66081
^ permalink raw reply related [relevance 8%]
* [PATCH v3 7/7] wildmatch test: create & test files on disk in addition to in-memory
@ 2017-12-28 23:28 8% ` Ævar Arnfjörð Bjarmason
2017-12-29 0:16 7% ` Ævar Arnfjörð Bjarmason
1 sibling, 1 reply; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2017-12-28 23:28 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy,
Anthony Ramine, Ramsay Jones, Johannes Sixt,
Ævar Arnfjörð Bjarmason
There has never been any full roundtrip testing of what git-ls-files
and other functions that use wildmatch() actually do, rather we've
been satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two, and even when we test for those (as with
9e4e8a64c2 ("pathspec: die on empty strings as pathspec", 2017-06-06))
there was no one place where you can review how these two modes
differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
As a result of doing this we can now see the cases where these two
ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in 9e4e8a64c2 above, where '' is
now an error as far as ls-files is concerned, but wildmatch() itself
happily accepts it.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
t/t3070-wildmatch.sh | 283 +++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 272 insertions(+), 11 deletions(-)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index 06db053ae2..d7aa7eb5fe 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -4,14 +4,95 @@ test_description='wildmatch tests'
. ./test-lib.sh
+create_test_file() {
+ file=$1
+
+ case $file in
+ # `touch .` will succeed but obviously not do what we intend
+ # here.
+ ".")
+ return 1
+ ;;
+ # We cannot create a file with an empty filename.
+ "")
+ return 1
+ ;;
+ # The tests that are testing that e.g. foo//bar is matched by
+ # foo/*/bar can't be tested on filesystems since there's no
+ # way we're getting a double slash.
+ *//*)
+ return 1
+ ;;
+ # When testing the difference between foo/bar and foo/bar/ we
+ # can't test the latter.
+ */)
+ return 1
+ ;;
+ esac
+
+ # Turn foo/bar/baz into foo/bar to create foo/bar as a
+ # directory structure.
+ dirs=${file%/*}
+
+ # We touch "./$file" instead of "$file" because even an
+ # escaped "touch -- -" means get arguments from stdin.
+ if test "$file" != "$dirs"
+ then
+ mkdir -p -- "$dirs" &&
+ touch -- "./$file" &&
+ return 0
+ else
+ touch -- "./$file" &&
+ return 0
+ fi
+ return 1
+}
+
+wildtest_file_setup() {
+ test_when_finished "
+ rm -rf -- * &&
+ git reset
+ " &&
+ git add -A &&
+ >expect.err
+}
+
+wildtest_stdout_stderr_cmp() {
+ tr -d '\0' <actual.raw >actual &&
+ test_cmp expect.err actual.err &&
+ test_cmp expect actual
+}
+
wildtest() {
- match_w_glob=$1
- match_w_globi=$2
- match_w_pathmatch=$3
- match_w_pathmatchi=$4
- text=$5
- pattern=$6
+ if test "$#" = 6
+ then
+ # When test-wildmatch and git ls-files produce the same
+ # result.
+ match_w_glob=$1
+ match_f_w_glob=$match_w_glob
+ match_w_globi=$2
+ match_f_w_globi=$match_w_globi
+ match_w_pathmatch=$3
+ match_f_w_pathmatch=$match_w_pathmatch
+ match_w_pathmatchi=$4
+ match_f_w_pathmatchi=$match_w_pathmatchi
+ text=$5
+ pattern=$6
+ elif test "$#" = 10
+ then
+ match_w_glob=$1
+ match_w_globi=$2
+ match_w_pathmatch=$3
+ match_w_pathmatchi=$4
+ match_f_w_glob=$5
+ match_f_w_globi=$6
+ match_f_w_pathmatch=$7
+ match_f_w_pathmatchi=$8
+ text=$9
+ pattern=$10
+ fi
+ # $1: Case sensitive glob match: test-wildmatch
if test "$match_w_glob" = 1
then
test_expect_success "wildmatch: match '$text' '$pattern'" "
@@ -26,6 +107,50 @@ wildtest() {
test_expect_success "PANIC: Test framework error. Unknown matches value $match_w_glob" 'false'
fi
+ # $1: Case sensitive glob match: ls-files
+ if test "$match_f_w_glob" = 'E'
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): match dies on '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ test_must_fail git --glob-pathspecs ls-files -z -- '$pattern'
+ "
+ else
+ test_expect_failure "wildmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_glob" = 1
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ git --glob-pathspecs ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "wildmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_glob" = 0
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "wildmatch(ls): no match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ >expect &&
+ git --glob-pathspecs ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "wildmatch(ls): no match skip '$pattern' '$text'" 'false'
+ fi
+ else
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_f_w_glob" 'false'
+ fi
+
+ # $2: Case insensitive glob match: test-wildmatch
if test "$match_w_globi" = 1
then
test_expect_success "iwildmatch: match '$text' '$pattern'" "
@@ -40,6 +165,50 @@ wildtest() {
test_expect_success "PANIC: Test framework error. Unknown matches value $match_w_globi" 'false'
fi
+ # $2: Case insensitive glob match: ls-files
+ if test "$match_f_w_globi" = 'E'
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "iwildmatch(ls): match dies on '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ test_must_fail git --glob-pathspecs --icase-pathspecs ls-files -z -- '$pattern'
+ "
+ else
+ test_expect_failure "wildmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_globi" = 1
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "iwildmatch(ls): match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ git --glob-pathspecs --icase-pathspecs ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "iwildmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_globi" = 0
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "iwildmatch(ls): no match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ >expect &&
+ git --glob-pathspecs --icase-pathspecs ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "iwildmatch(ls): no match skip '$pattern' '$text'" 'false'
+ fi
+ else
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_f_w_globi" 'false'
+ fi
+
+ # $3: Case sensitive path match: test-wildmatch
if test "$match_w_pathmatch" = 1
then
test_expect_success "pathmatch: match '$text' '$pattern'" "
@@ -54,6 +223,50 @@ wildtest() {
test_expect_success "PANIC: Test framework error. Unknown matches value $match_w_pathmatch" 'false'
fi
+ # $4: Case sensitive path match: ls-files
+ if test "$match_f_w_pathmatch" = 'E'
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "pathmatch(ls): match dies on '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ test_must_fail git ls-files -z -- '$pattern'
+ "
+ else
+ test_expect_failure "pathmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_pathmatch" = 1
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "pathmatch(ls): match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ git ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "pathmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_pathmatch" = 0
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "pathmatch(ls): no match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ >expect &&
+ git ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "pathmatch(ls): no match skip '$pattern' '$text'" 'false'
+ fi
+ else
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_f_w_pathmatch" 'false'
+ fi
+
+ # $4: Case insensitive path match: test-wildmatch
if test "$match_w_pathmatchi" = 1
then
test_expect_success "ipathmatch: match '$text' '$pattern'" "
@@ -67,6 +280,49 @@ wildtest() {
else
test_expect_success "PANIC: Test framework error. Unknown matches value $match_w_pathmatchi" 'false'
fi
+
+ # $4: Case insensitive path match: ls-files
+ if test "$match_f_w_pathmatchi" = 'E'
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "ipathmatch(ls): match dies on '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ test_must_fail git --icase-pathspecs ls-files -z -- '$pattern'
+ "
+ else
+ test_expect_failure "pathmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_pathmatchi" = 1
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "ipathmatch(ls): match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ printf '%s' '$text' >expect &&
+ git --icase-pathspecs ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "ipathmatch(ls): match skip '$pattern' '$text'" 'false'
+ fi
+ elif test "$match_f_w_pathmatchi" = 0
+ then
+ if create_test_file "$text"
+ then
+ test_expect_success "ipathmatch(ls): no match '$pattern' '$text'" "
+ wildtest_file_setup &&
+ >expect &&
+ git ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
+ wildtest_stdout_stderr_cmp
+ "
+ else
+ test_expect_failure "ipathmatch(ls): no match skip '$pattern' '$text'" 'false'
+ fi
+ else
+ test_expect_success "PANIC: Test framework error. Unknown matches value $match_f_w_pathmatchi" 'false'
+ fi
}
# Basic wildmatch features
@@ -135,7 +391,8 @@ wildtest 1 1 1 1 'acrt' 'a[c-c]rt'
wildtest 0 0 0 0 ']' '[!]-]'
wildtest 1 1 1 1 'a' '[!]-]'
wildtest 0 0 0 0 '' '\'
-wildtest 0 0 0 0 '\' '\'
+wildtest 0 0 0 0 \
+ 1 1 1 1 '\' '\'
wildtest 0 0 0 0 'XXX/\' '*/\'
wildtest 1 1 1 1 'XXX/\' '*/\\'
wildtest 1 1 1 1 'foo' 'foo'
@@ -149,7 +406,8 @@ wildtest 1 1 1 1 '[ab]' '[[:digit]ab]'
wildtest 1 1 1 1 '[ab]' '[\[:]ab]'
wildtest 1 1 1 1 '?a?b' '\??\?b'
wildtest 1 1 1 1 'abc' '\a\b\c'
-wildtest 0 0 0 0 'foo' ''
+wildtest 0 0 0 0 \
+ E E E E 'foo' ''
wildtest 1 1 1 1 'foo/bar/baz/to' '**/t[o]'
# Character class tests
@@ -179,8 +437,10 @@ wildtest 1 1 1 1 ']' '[\]]'
wildtest 0 0 0 0 '\]' '[\]]'
wildtest 0 0 0 0 '\' '[\]]'
wildtest 0 0 0 0 'ab' 'a[]b'
-wildtest 0 0 0 0 'a[]b' 'a[]b'
-wildtest 0 0 0 0 'ab[' 'ab['
+wildtest 0 0 0 0 \
+ 1 1 1 1 'a[]b' 'a[]b'
+wildtest 0 0 0 0 \
+ 1 1 1 1 'ab[' 'ab['
wildtest 0 0 0 0 'ab' '[!'
wildtest 0 0 0 0 'ab' '[-'
wildtest 1 1 1 1 '-' '[-]'
@@ -248,7 +508,8 @@ wildtest 1 1 1 1 foo/bar 'foo/*'
wildtest 0 0 1 1 foo/bba/arr 'foo/*'
wildtest 1 1 1 1 foo/bba/arr 'foo/**'
wildtest 0 0 1 1 foo/bba/arr 'foo*'
-wildtest 0 0 1 1 foo/bba/arr 'foo**'
+wildtest 0 0 1 1 \
+ 1 1 1 1 foo/bba/arr 'foo**'
wildtest 0 0 1 1 foo/bba/arr 'foo/*arr'
wildtest 0 0 1 1 foo/bba/arr 'foo/**arr'
wildtest 0 0 0 0 foo/bba/arr 'foo/*z'
--
2.15.1.424.g9478a66081
^ permalink raw reply related [relevance 8%]
* Re: [PATCH v2 4/5] mailmap: use case-sensitive comparisons for local-parts and names
2021-01-06 0:46 8% ` Junio C Hamano
@ 2021-01-12 14:08 8% ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2021-01-12 14:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: brian m. carlson, git, Jeff King, Phillip Wood,
Johannes Schindelin
On Wed, Jan 06 2021, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> On Sun, Jan 03 2021, brian m. carlson wrote:
>>
>> We just have to worry about cases where you're not all of these people
>> in one project's commit metadata and/or .mailmap, and thus mailmap rules
>> would match too generously:
>>
>> "brian m. carlson" <sandals@crustytoothpaste.net>
>> "brian m. carlson" <SANDALS@crustytoothpaste.net>
>> "BRIAN M. CARLSON" <sandals@crustytoothpaste.net>
>> "BRIAN M. CARLSON" <SANDALS@crustytoothpaste.net>
>>
>> Is that really plausible? In any case, neither of these two patches make
>> reference to us already having changed this in the past in 1.6.2 and &
>> there being reports on the ML about the bug & us changing it back. See
>> https://lore.kernel.org/git/f182fb1700e8dea15459fd02ced2a6e5797bec99.1238458535u.git.johannes.schindelin@gmx.de/
>>
>> Maybe we should still do this, but I think for a v3 it makes sense to
>> summarize that discussion etc.
>
> After reading the old discussion again, I am not sure if this is
> worth doing. To many people, it is a promise we've made and kept
> that we treat addresses including the local part case-insensitively
> when summarising commits by ident strings.
>
> I'd really wish that this series were structured to have 5/5 early
> and 3&4/5 squashed into a single final patch.
Something that I only realized after I sent
<87czykvg19.fsf@evledraar.gmail.com>: Any problems .mailmap has with
Turkish "dotless I" we have already with "git log --author=<name> -i".
Not to say that there isn't some problem to solve here, just that if we
do it's a more general issue than mailmap.
As can be inferred from my upthread reply I thought that was ASCII-only,
but it turns out we do set LC_CTYPE based on the user's locale, and it
also applies for English-speakers. E.g. in LANG=en_US.UTF-8
"--author=ævar -i" will work.
Of course that doesn't address the point of whether we should be
DWYM-ing E-Mail addresses, just the sub-claim that one reason we
shouldn't is because of impossible-to-solve Unicode edge cases.
^ permalink raw reply [relevance 8%]
* Re: [PATCH] t5533: make it pass on case-sensitive filesystems
2016-08-04 14:54 8% [PATCH] t5533: make it pass on case-sensitive filesystems Johannes Schindelin
@ 2016-08-04 17:18 8% ` Junio C Hamano
2016-08-05 14:19 8% ` Johannes Schindelin
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2016-08-04 17:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, John Keeping, Lars Schneider
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> The newly-added test case wants to commit a file "c.t" (note the lower
> case) when a previous test case already committed a file "C.t". This
> confuses Git to the point that it thinks "c.t" was not staged when "git
> add c.t" was called.
>
> Simply make the naming of the test commits consistent with the previous
> test cases: use upper-case, and advance in the alphabet.
>
> This came up in local work to rebase the Windows-specific patches to the
> current `next` branch. An identical fix was suggested by John Keeping.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> Published-As: https://github.com/dscho/git/releases/tag/t5533-case-insensitive-v1
> Fetch-It-Via: git fetch https://github.com/dscho/git t5533-case-insensitive-v1
Thanks. It may make it easier to see to have a blank line here,
separating them from the diffstat.
> t/t5533-push-cas.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t5533-push-cas.sh b/t/t5533-push-cas.sh
> index 09899af..a2c9e74 100755
> --- a/t/t5533-push-cas.sh
> +++ b/t/t5533-push-cas.sh
> @@ -220,7 +220,7 @@ test_expect_success 'new branch already exists' '
> (
> cd src &&
> git checkout -b branch master &&
> - test_commit c
> + test_commit F
> ) &&
> (
> cd dst &&
Thanks.
> --
> 2.9.0.281.g286a8d9
>
> base-commit: 9813b109b4ec6630220e5f3d8aff275e23cba59e
A totally unrelated tangent.
This line turns out to be less than useful at least in this
particular case.
The fix is meant for jk/push-force-with-lease-creation topic, but I
had to find it out by the old fashioned way, i.e. running blame for
these lines in 'pu' to find eee98e74f9 is the culprit and then
running "git branch --with eee98e74f9". The only thing the line
made easier is I _could_ start the blame at the named commit (which
is on 'next') instead of 'pu'. When I took that "base-commit"
series, I was hoping that it would give us a lot more useful
information.
^ permalink raw reply [relevance 8%]
* Re: [cygwin] Re: Lack of case-sensitive filename handling with git 1.7.9-1 for Cygwin 64-bit
2013-08-16 11:54 8% ` [cygwin] Re: Lack of case-sensitive filename handling with git 1.7.9-1 for Cygwin 64-bit Jason Pyeron
@ 2013-08-16 13:21 8% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2013-08-16 13:21 UTC (permalink / raw)
To: Jason Pyeron; +Cc: 'Git List'
On Fri, Aug 16, 2013 at 07:54:57AM -0400, Jason Pyeron wrote:
> > The interesting thing here is, if you try this the other way
> > around, you'll see the exact same effect. If you created the
> > above git repo with 64 bit git, everything works exactly as
> > in the 32 bit version and the two files are correctly recognized.
> >
> > I assume the format of the git database files depends on the
> > architecture. Therefore it's probably not advisable to use a
> > git repo created under 32 bit git with a 64 bit git and vice versa.
>
> Is this the best explanation for this?
If it is, that is a bug. There should be nothing architecture-dependent
in the index file.
In the test described, it would be worth double-checking that
core.ignorecase is set properly. Git will detect and set that option
when creating the repository based on a test of the filesystem. But it's
possible that there is some weirdness in the packaging or defaults of
the two builds.
It's also worth seeing if newer versions of git behave differently.
There were a lot of bugs in the case-insensitivity code that were fixed
in the late v1.7.x range. Though if I understand the test correctly, we
_shouldn't_ be using the case-insensitive code in the first place.
-Peff
^ permalink raw reply [relevance 8%]
* Re: [PATCH] config: fix case sensitive subsection names on writing
2018-07-27 23:36 21% ` Stefan Beller
2018-07-27 23:37 8% ` Stefan Beller
@ 2018-07-28 1:01 8% ` Junio C Hamano
2018-07-28 3:52 8% ` Stefan Beller
2018-07-28 1:37 8% ` Junio C Hamano
2 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2018-07-28 1:01 UTC (permalink / raw)
To: Stefan Beller; +Cc: git, bmwill, peff, Johannes.Schindelin
Stefan Beller <sbeller@google.com> writes:
> A use reported a submodule issue regarding strange case indentation
s/use/&r/; Is this "indentation" issue?
> issues, but it could be boiled down to the following test case:
> ...
> +test_expect_success 'old-fashioned settings are case insensitive' '
> + test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
> +
> + cat >testConfig <<-EOF &&
> + # insensitive:
> + [V.A]
> + r = value1
> + EOF
> + q_to_tab >testConfig_expect <<-EOF &&
> + # insensitive:
> + [V.A]
> + Qr = value2
> + EOF
It is unfortunate that we hardcode the exact indentation
in the test to make it care. Perhaps a wrapper around test_cmp that
is used locally in this file to first strip the leading HT from both
sides of the comparison would make it more robust?
> + for key in "v.a.r" "V.A.r" "v.A.r" "V.a.r"
> + do
> + cp testConfig testConfig_actual &&
> + git config -f testConfig_actual v.a.r value2 &&
> + test_cmp testConfig_expect testConfig_actual
> + done
> +'
I think you meant to use "$key" when setting the variable to value2.
When the test_cmp fails with "v.a.r" but later succeeds and most
importantly succeeds with "V.a.r" (i.e. the last one), wouldn't the
whole thing suceed? I think the common trick people use is to end
the last one with "|| return 1" in a loop inside test_expect_success.
^ permalink raw reply [relevance 8%]
* Re: [PATCH] t5533: make it pass on case-sensitive filesystems
2016-08-04 17:18 8% ` Junio C Hamano
@ 2016-08-05 14:19 8% ` Johannes Schindelin
2016-08-08 11:21 8% ` Jeff King
0 siblings, 1 reply; 200+ results
From: Johannes Schindelin @ 2016-08-05 14:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, John Keeping, Lars Schneider
Hi Junio,
On Thu, 4 Aug 2016, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
> > The newly-added test case wants to commit a file "c.t" (note the lower
> > case) when a previous test case already committed a file "C.t". This
> > confuses Git to the point that it thinks "c.t" was not staged when "git
> > add c.t" was called.
> >
> > Simply make the naming of the test commits consistent with the previous
> > test cases: use upper-case, and advance in the alphabet.
> >
> > This came up in local work to rebase the Windows-specific patches to the
> > current `next` branch. An identical fix was suggested by John Keeping.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> > Published-As: https://github.com/dscho/git/releases/tag/t5533-case-insensitive-v1
> > Fetch-It-Via: git fetch https://github.com/dscho/git t5533-case-insensitive-v1
>
> Thanks. It may make it easier to see to have a blank line here,
> separating them from the diffstat.
Good suggestion! I made it so:
https://github.com/dscho/mail-patch-series/commit/1776cb18
> > base-commit: 9813b109b4ec6630220e5f3d8aff275e23cba59e
>
> A totally unrelated tangent.
>
> This line turns out to be less than useful at least in this
> particular case.
>
> The fix is meant for jk/push-force-with-lease-creation topic, but I
> had to find it out by the old fashioned way, i.e. running blame for
> these lines in 'pu' to find eee98e74f9 is the culprit and then
> running "git branch --with eee98e74f9". The only thing the line
> made easier is I _could_ start the blame at the named commit (which
> is on 'next') instead of 'pu'. When I took that "base-commit"
> series, I was hoping that it would give us a lot more useful
> information.
Sorry for that. The way my mail-patch-series.sh script works is that it
tries to determine which branch between `master`, `next` or `pu` is the
base (and it then submits *all* commits that are on top of that branch).
So my branch was indeed based on `next` for that reason, not on
top of `jk/push-force-with-lease-creation`. Otherwise, I would have
resubmitted John's patches because the script would have determined that
my patch is on top of `master`, not on top of `next`.
Will try to think of a better way,
Dscho
^ permalink raw reply [relevance 8%]
* Re: should config options be treated as case-sensitive?
2018-05-23 7:59 8% ` Robert P. J. Day
@ 2018-05-23 8:58 8% ` Junio C Hamano
2018-05-23 9:04 8% ` Robert P. J. Day
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2018-05-23 8:58 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Ævar Arnfjörð Bjarmason, Git Mailing list
"Robert P. J. Day" <rpjday@crashcourse.ca> writes:
>> If the documention does not make it clear, then we have
>> documentation bug ...
>
> personally, i would add a short, really emphatic note at the top of
> "man git-config" pointing this out -- i wouldn't require people to
> read all the way down to "Syntax" to learn this. an example just like
> the one you provide above would be perfect, with an extra line
> pointing out that the documentation uses "camel case" for nothing more
> than readability.
Unfortunately, that line of thinking leads us to madness, as you are
exhibiting the typical symptom of "my today's immediate itch is the
most important one in the world"-itis. Tomorrow you would start
saying that we must have a short, really emphatic note at the top
that says that the second level name can even have spaces, and on
the day after that, you would instead have a note that says that you
cannot use an underscore in the name, and continuing that line of
thought will lead us to fill the top part of the documentation with
47 different short and emphatic sentences. Let's not go there.
^ permalink raw reply [relevance 8%]
* Re: [PATCH 2/3] config: fix case sensitive subsection names on writing
2018-08-03 0:30 8% ` Stefan Beller
@ 2018-08-03 15:51 8% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2018-08-03 15:51 UTC (permalink / raw)
To: Stefan Beller; +Cc: Brandon Williams, git, Johannes Schindelin, peff
Stefan Beller <sbeller@google.com> writes:
> And *technically* the two level is old style, so I figured it's ok.
If we call the bit not after the recentness of the style but after
what it is about, e.g. "is the section name as a whole (including
its possible subsection part) case insensitive?", then yes, a
two-level name can be treated exactly the same way as the old style
names with a subsection. Perhaps we should do that rename to save
us from future confusion.
>> > - !strncasecmp(cf->var.buf, store->key, store->baselen);
>> > + !cmpfn(cf->var.buf, store->key, store->baselen);
>>
>> OK. Section names should still be case insensitive (only the case
>> sensitivity of subsection names is special), but presumably that's
>> already normalized by the caller so we do not have to worry when we
>> use strncmp()? Can we add a test to demonstrate that it works
>> correctly?
>
> That was already demonstrated (but not tested) in
> https://public-inbox.org/git/20180730230443.74416-4-sbeller@google.com/
Yeah, I also manually tried when I was playing with the old-style
names to see how well it works. We would want to make sure this
won't get broken in the future, still.
Thanks.
^ permalink raw reply [relevance 8%]
* Re: [PATCH] In perforce, RCS keywords are case-sensitive
2008-07-22 16:48 12% [PATCH] In perforce, RCS keywords are case-sensitive Daniel Barkalow
@ 2008-07-24 7:05 8% ` Simon Hausmann
0 siblings, 0 replies; 200+ results
From: Simon Hausmann @ 2008-07-24 7:05 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
On Tuesday 22 July 2008 18:48:57 Daniel Barkalow wrote:
> At least, this is true in 2007.2, according to the documentation.
>
> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Acked-By: Simon Hausmann <simon@lst.de>
Thanks,
Simon
> A line of perl with the variable $file in a string followed by a different
> variable not in the string, for example, doesn't get mangled by p4 and may
> therefore appear in a p4 depot.
>
> I don't know if the "old-style keyword expansion" is case-sensitive,
> though, so I'm leaving that alone.
>
> contrib/fast-import/git-p4 | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index d8de9f6..1ee612e 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -902,7 +902,7 @@ class P4Sync(Command):
> if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
> text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
> elif stat['type'] in ('text+k', 'ktext', 'kxtext',
> 'unicode+k', 'binary+k'): - text =
> re.sub(r'(?i)\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\
>$',r'$\1$', text) + text =
> re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r
>'$\1$', text)
>
> contents[stat['depotFile']] = text
^ permalink raw reply [relevance 8%]
* Re: [JGIT PATCH 10/12] Match config subsection names using case sensitive search
2009-07-22 11:11 7% ` Constantine Plotnikov
@ 2009-07-22 21:37 8% ` Robin Rosenberg
0 siblings, 0 replies; 200+ results
From: Robin Rosenberg @ 2009-07-22 21:37 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: Shawn O. Pearce, git
onsdag 22 juli 2009 13:11:07 skrev Constantine Plotnikov <constantine.plotnikov@gmail.com>:
> This patch is incomplete. The method getRawEntry(...) and
> setStringList(...) should be fixed as part of this patch too. There is
> subsection is converted to lowercase. I was planning to submit it as
> separate patch.
>
> Also I'm somewhat bothered by usage of toLowerCase() without locale
> specified and equalsIgnoreCase(). When turkish locale is default one
> there could be surprising results with the letter "I". The program:
>
> import java.util.Locale;
> public class Test {
> public static void main(String[] args) {
> Locale tr_TR = new Locale("tr", "TR");
> System.out.printf("i = U+%04x LC(I, tr_TR) = U+%04x\n", (int)'i',
> (int)"I".toLowerCase(tr_TR).charAt(0));
> System.out.printf("I = U+%04x UC(i, tr_TR) = U+%04x\n", (int)'I',
> (int)"i".toUpperCase(tr_TR).charAt(0));
> }
> }
>
> Gives the following output:
>
> i = U+0069 LC(I, tr_TR) = U+0131
> I = U+0049 UC(i, tr_TR) = U+0130
>
> So I suggest to explicitly use Locale.US for all toLowerCase()
> invocation in Config class just in case and to replace
> equalsIgnoreCase() with something else. But this possibly should be
> some other patch series. I do not know what C git doing in case
> turkish locale and whether it is a bug or "feature".
Good catch. C Git operates in "C" locale (default for C/C++) so it should
not be a problem. We might have other places where this could be a problem.
Using Locale.US should be the right choice here since unicode is not allowed
in sections and keys anyway. (Btw, java.lang.String.regionMatches has some info
on case insensitive matching for those interested, serving a reminder for
why home-brewed logic isn't always the best.)
As you say we should make this a separate patch.
-- robin
^ permalink raw reply [relevance 8%]
* Re: Deletion of git repo causes incorrect block count on HFS+ case-sensitive
2013-03-13 18:45 14% Deletion of git repo causes incorrect block count on HFS+ case-sensitive Ismail Tabtabai
@ 2013-03-13 22:14 8% ` David Aguilar
0 siblings, 0 replies; 200+ results
From: David Aguilar @ 2013-03-13 22:14 UTC (permalink / raw)
To: Ismail Tabtabai; +Cc: git
On Wed, Mar 13, 2013 at 11:45 AM, Ismail Tabtabai <itabtabai@me.com> wrote:
> Hello,
>
> When I delete a git repo that I have cloned on my machine using 'rm -rf repo-name' I get an incorrect block count when I attempt a Disk Repair.
>
> I am running OS X 10.8.2 on a user installed SSD. The git version is 1.8.1.5.
This is not a git issue.
I would recommend inspecting your hardware; this could be a disk going bad.
There's not much git can do to fix a broken HFS+ filesystem or faulty
hardware. If anything, it's an HFS+ / Apple bug, though that is less
likely than a bad disk.
If you haven't already, you should probably start doing backups.
I hope that helps.
> Checking file systemChecking Journaled HFS Plus volume.
> Detected a case-sensitive volume.
> Checking extents overflow file.
> Checking catalog file.
> Incorrect block count for file pack-8c0dc1a398a22c58ea1eba09de3ee9d935ad1ea3.pack
> (It should be 4865 instead of 12244)
> Incorrect block count for file pack-db61a037ad0e043e801d8ba1db98b1af14d466af.pack
> (It should be 5889 instead of 12245)
> Incorrect block count for file pack-db61a037ad0e043e801d8ba1db98b1af14d466af.pack
> (It should be 6220 instead of 12245)
> Incorrect block count for file pack-286c1444bc32ee2ed0af1d15070e0e31f22ba0a8.pack
> (It should be 7937 instead of 12246)
> Checking multi-linked files.
> Checking catalog hierarchy.
> Checking extended attributes file.
> Checking volume bitmap.
> Volume bitmap needs minor repair for orphaned blocks
> Checking volume information.
> Invalid volume free block count
> (It should be 85306183 instead of 85282114)
> Repairing volume.
> Rechecking volume.
> Checking Journaled HFS Plus volume.
> Detected a case-sensitive volume.
> Checking extents overflow file.
> Checking catalog file.
> Checking multi-linked files.
> Checking catalog hierarchy.
> Checking extended attributes file.
> Checking volume bitmap.
> Checking volume information.
> The volume avicenna was repaired successfully.
> Volume repair complete.Updating boot support partitions for the volume as required.
It looks like it repaired itself. bad blocks?
--
David
^ permalink raw reply [relevance 8%]
* RE: [cygwin] Re: Lack of case-sensitive filename handling with git 1.7.9-1 for Cygwin 64-bit
[not found] ` <20130816081743.GC2562@calimero.vinschen.de>
@ 2013-08-16 11:54 8% ` Jason Pyeron
2013-08-16 13:21 8% ` Jeff King
0 siblings, 1 reply; 200+ results
From: Jason Pyeron @ 2013-08-16 11:54 UTC (permalink / raw)
To: 'Git List'
I just saw this on the cygwin list.
> -----Original Message-----
> From: Corinna Vinschen
> Sent: Friday, August 16, 2013 4:18
> To: cygwin@cygwin.com
> Subject: [cygwin] Re: Lack of case-sensitive filename
> handling with git 1.7.9-1 for Cygwin 64-bit
>
> On Aug 16 10:32, Kal Sze wrote:
> > I have been using Cygwin 32-bit on Windows 7 Profession
> 64-bit. I had
> > the HKLM\SYSTEM\CurrentControlSet\Control\Session
> > Manager\kernel\ObCaseInsensitive registry key set to DWORD
> 0x00000000
> > and case-sensitive filename handling has been fully working
> in Cygwin
> > 32-bit (as far as I can tell from my usage anyway).
> >
> > Now that Cygwin 64-bit has been released, I want to try it.
> I notice
> > that git in Cygwin 64-bit does not seem to correctly handle
> filesname
> > that differ only by case.
> >
> > To reproduce, create a repository in Cygwin 32-bit *with the
> > aforementioned registry key set*:
> >
> > $ git init case_sensitivity_test; cd case_sensitivity_test
> >
> > Create two files of different content with similar filenames that
> > differ only by case:
> >
> > $ echo 'FOO' > FOO.TXT; echo 'foo' > foo.txt
> >
> > Commit them into the repository:
> >
> > $ git add .; git commit -m 'Initial commit'
> > [master (root-commit) 16d1b59] Initial commit
> > 2 files changed, 2 insertions(+), 0 deletions(-)
> > create mode 100644 FOO.TXT
> > create mode 100644 foo.txt
> >
> > In Cygwin 32-bit, this looks all green:
> >
> > $ git status
> > # On branch master
> > nothing to commit (working directory clean)
> > $ ls
> > FOO.TXT foo.txt
> >
> > Now, fire up the Cygwin64 terminal and browse to the
> repository, then:
> >
> > $ ls
> > FOO.TXT foo.txt
> > $ cat FOO.TXT
> > FOO
> > $ cat foo.txt
> > foo
> >
> > So `ls` and `cat` both recognize the two different files. However:
> >
> > $ git status
> > # On branch master
> > # Changes not staged for commit:
> > # (use "git add <file>..." to update what will be committed)
> > # (use "git checkout -- <file>..." to discard changes
> in working
> > directory)
> > #
> > # modified: foo.txt
> > #
> > no changes added to commit (use "git add" and/or "git
> commit -a")
> >
> > "Oops."
>
> The interesting thing here is, if you try this the other way
> around, you'll see the exact same effect. If you created the
> above git repo with 64 bit git, everything works exactly as
> in the 32 bit version and the two files are correctly recognized.
>
> I assume the format of the git database files depends on the
> architecture. Therefore it's probably not advisable to use a
> git repo created under 32 bit git with a 64 bit git and vice versa.
Is this the best explanation for this?
>
>
> Corinna
>
> --
> Corinna Vinschen Please, send mails
> regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat
>
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
^ permalink raw reply [relevance 8%]
* Re: [issue?]'git branch -D' case sensitive issue
2016-01-14 7:52 12% [issue?]'git branch -D' case sensitive issue 郭腾飞
@ 2016-01-14 11:51 8% ` Torsten Bögershausen
2016-01-14 13:28 14% ` 郭腾飞
0 siblings, 1 reply; 200+ results
From: Torsten Bögershausen @ 2016-01-14 11:51 UTC (permalink / raw)
To: 郭腾飞, git
On 01/14/2016 08:52 AM, 郭腾飞 wrote:
> Hi All,
> I encountered some issues when using 'git branch -D'.
> It's strange, the command 'git branch -D' is case sensitive.
> Here is the operated log.
>
> ➜ my-emacs-conf git:(NIce) git branch -avv
> * NIce fed5d9c Update js2-mode $ js-beautify.
> master fed5d9c [origin/master] Update js2-mode $ js-beautify.
> remotes/origin/HEAD -> origin/master
> remotes/origin/fake 8ec9cad fake.
> remotes/origin/mac13 13ae483 mac pro 13's config.
> remotes/origin/master fed5d9c Update js2-mode $ js-beautify.
> ➜ my-emacs-conf git:(NIce)
> ➜ my-emacs-conf git:(NIce) git branch -D NIce
> error: Cannot delete the branch 'NIce' which you are currently on.
> ➜ my-emacs-conf git:(NIce)
> ➜ my-emacs-conf git:(NIce) git branch -D NICe
> Deleted branch NICe (was fed5d9c).
> ➜ my-emacs-conf git:(NIce) ✗ git branch -avv
> master fed5d9c [origin/master] Update js2-mode $ js-beautify.
> remotes/origin/HEAD -> origin/master
> remotes/origin/fake 8ec9cad fake.
> remotes/origin/mac13 13ae483 mac pro 13's config.
> remotes/origin/master fed5d9c Update js2-mode $ js-beautify.
>
> Hope someone can give me a hint.
>
> ➜ my-emacs-conf git:(NIce) ✗ git --version
> git version 2.6.3
> ➜ my-emacs-conf git:(NIce) ✗ sw_vers -productVersion
> 10.11 OSX
>
> BRs,
> terry3
> --
If you can give us a hint, under which OS you are working ?
I assume that you are on Windows or Mac OS ?
In this case the file system is part of the problem,
which treats NIce and NICe the same.
^ permalink raw reply [relevance 8%]
* Re: [issue?]'git branch -D' case sensitive issue
2016-01-14 13:28 14% ` 郭腾飞
@ 2016-01-14 16:42 8% ` Torsten Bögershausen
2016-01-14 17:21 8% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Torsten Bögershausen @ 2016-01-14 16:42 UTC (permalink / raw)
To: 郭腾飞, Torsten Bögershausen; +Cc: git
On 14.01.16 14:28, 郭腾飞 wrote:
Please no top-posting on this list.
> Hi Torsten Bögershausen, thank you for the quick reply.
> I'm working on Mac OS as I have mentioned in the previous email.
>
> ➜ my-emacs-conf git:(NIce) ✗ sw_vers -productVersion
> 10.11 OSX
>
> And besides, I use a case sensitive file system in OSX through the command
> 'hdiutil create -volname 'case_fs' -type SPARSE -fs 'Case-sensitive
> Journaled HFS+' -size 100g ~/case_fs.sparseimage'
> Is this a known issue?
> Thank you!
>
> BRs
> terry3
No, this is typically what we observe on a case insensitive FS.
And that make me wonder what
git config core.ignorecase
says ?
^ permalink raw reply [relevance 8%]
* Re: [issue?]'git branch -D' case sensitive issue
2016-01-14 16:42 8% ` Torsten Bögershausen
@ 2016-01-14 17:21 8% ` Junio C Hamano
2016-01-15 22:28 8% ` Jeff King
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2016-01-14 17:21 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: 郭腾飞, git
Torsten Bögershausen <tboegi@web.de> writes:
> No, this is typically what we observe on a case insensitive FS.
There is an interesting bit in delete_branches::builtin/branch.c
if (kinds == FILTER_REFS_BRANCHES && !strcmp(head, bname.buf)) {
error(_("Cannot delete the branch '%s' "
"which you are currently on."), bname.buf);
ret = 1;
continue;
}
The strcmp() does not protect you from attempting to remove "FrOtZ"
branch when you are on (and more importantly, Git thinks you are on)
"frotz" branch. A case-insensitive system then can tell Git that
the request to remove "refs/heads/FrOtZ" succeeded, even though in
reality it didn't have such file, and silently "refs/heads/frotz"
gets removed instead. You can end up removing your current branch
that way.
^ permalink raw reply [relevance 8%]
* Re: [issue?]'git branch -D' case sensitive issue
2016-01-14 17:21 8% ` Junio C Hamano
@ 2016-01-15 22:28 8% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2016-01-15 22:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Torsten Bögershausen, 郭腾飞, git
On Thu, Jan 14, 2016 at 09:21:46AM -0800, Junio C Hamano wrote:
> Torsten Bögershausen <tboegi@web.de> writes:
>
> > No, this is typically what we observe on a case insensitive FS.
>
> There is an interesting bit in delete_branches::builtin/branch.c
>
> if (kinds == FILTER_REFS_BRANCHES && !strcmp(head, bname.buf)) {
> error(_("Cannot delete the branch '%s' "
> "which you are currently on."), bname.buf);
> ret = 1;
> continue;
> }
>
> The strcmp() does not protect you from attempting to remove "FrOtZ"
> branch when you are on (and more importantly, Git thinks you are on)
> "frotz" branch. A case-insensitive system then can tell Git that
> the request to remove "refs/heads/FrOtZ" succeeded, even though in
> reality it didn't have such file, and silently "refs/heads/frotz"
> gets removed instead. You can end up removing your current branch
> that way.
This seemed eerily familiar. And indeed, there's some discussion in:
http://article.gmane.org/gmane.comp.version-control.git/276506
Changing that strcmp to strcmp_icase() is still wrong, though I suspect
it's less wrong in practice (and errs on the side of caution). But I
think there are probably a lot of similar problems lurking.
-Peff
^ permalink raw reply [relevance 8%]
* Re: [PATCH] t5533: make it pass on case-sensitive filesystems
2016-08-08 11:21 8% ` Jeff King
@ 2016-08-08 11:49 8% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2016-08-08 11:49 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, John Keeping, Lars Schneider
Hi Peff,
On Mon, 8 Aug 2016, Jeff King wrote:
> On Fri, Aug 05, 2016 at 04:19:08PM +0200, Johannes Schindelin wrote:
>
> > > The fix is meant for jk/push-force-with-lease-creation topic, but I
> > > had to find it out by the old fashioned way, i.e. running blame for
> > > these lines in 'pu' to find eee98e74f9 is the culprit and then
> > > running "git branch --with eee98e74f9". The only thing the line
> > > made easier is I _could_ start the blame at the named commit (which
> > > is on 'next') instead of 'pu'. When I took that "base-commit"
> > > series, I was hoping that it would give us a lot more useful
> > > information.
> >
> > Sorry for that. The way my mail-patch-series.sh script works is that
> > it tries to determine which branch between `master`, `next` or `pu` is
> > the base (and it then submits *all* commits that are on top of that
> > branch).
> >
> > So my branch was indeed based on `next` for that reason, not on top of
> > `jk/push-force-with-lease-creation`. Otherwise, I would have
> > resubmitted John's patches because the script would have determined
> > that my patch is on top of `master`, not on top of `next`.
>
> Do you fetch from the main git.git repository, or Junio's gitster/git
> workspace on GitHub?
Neither. I typically fetch from https://github.com/git/git.
Even so, I can in general find out relatively easily what commit is the
tip of the branch I am looking for.
In this here case, I was just too lazy (or too busy with other stuff,
depending on your point of view), is all ;-)
Ciao,
Dscho
^ permalink raw reply [relevance 8%]
* git-send-email smtpEncryption option is case sensitive (silently fails if "TLS" is specified)
@ 2017-05-15 12:02 8% Benjamin Berg
0 siblings, 0 replies; 200+ results
From: Benjamin Berg @ 2017-05-15 12:02 UTC (permalink / raw)
To: git
Hi,
I just spend some time figuring out that my newly written git-send-
email configuration didn't work because setting
[sendemail]
smtpEncryption = TLS
has no effect. This is because the option has to be specified as "tls".
Unfortunately there is no warning that "TLS" is unsupported making it
hard to see why authentication is failing in the end.
I think it would be helpful to have a warning. Additionally one could
also normalize the option to lowercase automatically.
Regards,
Benjamin
^ permalink raw reply [relevance 8%]
* Re: should config options be treated as case-sensitive?
2018-05-22 7:57 7% should config options be treated as case-sensitive? Robert P. J. Day
@ 2018-05-22 12:13 8% ` Ævar Arnfjörð Bjarmason
2018-05-23 1:55 13% ` Junio C Hamano
2018-05-22 16:33 8% ` Robert P. J. Day
0 siblings, 2 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2018-05-22 12:13 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Git Mailing list
On Tue, May 22 2018, Robert P. J. Day wrote:
> in my wanderings, more oddities, such as this:
>
> $ grep -ir blankboundary *
> builtin/blame.c: if (!strcmp(var, "blame.blankboundary")) {
> Documentation/config.txt:blame.blankBoundary::
> Documentation/blame-options.txt: be controlled via the `blame.blankboundary` config option.
> Documentation/RelNotes/2.15.1.txt: * Description of blame.{showroot,blankboundary,showemail,date}
> Documentation/RelNotes/2.16.0.txt: * Description of blame.{showroot,blankboundary,showemail,date}
> $
>
> where you can see the single instance of "blankBoundary" in
> Doc/config.txt (with the upper case 'B'), while the rest have no such
> thing.
>
> for fun, i checked another of blame's config settings, with similar
> results:
>
> builtin/blame.c: if (!strcmp(var, "blame.showemail")) {
> Documentation/config.txt:blame.showEmail::
> Documentation/RelNotes/2.15.1.txt: * Description of blame.{showroot,blankboundary,showemail,date}
> Documentation/RelNotes/2.5.0.txt: * "git blame" learned blame.showEmail configuration variable.
> Documentation/RelNotes/2.16.0.txt: * Description of blame.{showroot,blankboundary,showemail,date}
> Documentation/git-blame.txt: This can also be controlled via the `blame.showEmail` config
> t/t8002-blame.sh:test_expect_success 'setup showEmail tests' '
> t/t8002-blame.sh:test_expect_success 'blame with showemail options' '
> t/t8002-blame.sh:test_expect_success 'blame with showEmail config false' '
> t/t8002-blame.sh: git config blame.showEmail false &&
> t/t8002-blame.sh:test_expect_success 'blame with showEmail config true' '
> t/t8002-blame.sh: git config blame.showEmail true &&
>
> thoughts?
>
> rday
>
> p.s. i am not *trying* to be annoyingly pedantic, i am merely
> succeeding.
The issues you note about the docs using foo.barbaz instead of
foo.barBaz should be fixed, but as noted in the "Syntax" section of
"git-config" we already document that the config keys are all
case-insensitive. We just like talking about them as foo.barBaz because
it makes for easier reading.
^ permalink raw reply [relevance 8%]
* Re: should config options be treated as case-sensitive?
2018-05-22 12:13 8% ` Ævar Arnfjörð Bjarmason
2018-05-23 1:55 13% ` Junio C Hamano
@ 2018-05-22 16:33 8% ` Robert P. J. Day
1 sibling, 0 replies; 200+ results
From: Robert P. J. Day @ 2018-05-22 16:33 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git Mailing list
[-- Attachment #1: Type: text/plain, Size: 2340 bytes --]
On Tue, 22 May 2018, Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, May 22 2018, Robert P. J. Day wrote:
>
> > in my wanderings, more oddities, such as this:
> >
> > $ grep -ir blankboundary *
> > builtin/blame.c: if (!strcmp(var, "blame.blankboundary")) {
> > Documentation/config.txt:blame.blankBoundary::
> > Documentation/blame-options.txt: be controlled via the `blame.blankboundary` config option.
> > Documentation/RelNotes/2.15.1.txt: * Description of blame.{showroot,blankboundary,showemail,date}
> > Documentation/RelNotes/2.16.0.txt: * Description of blame.{showroot,blankboundary,showemail,date}
> > $
> >
> > where you can see the single instance of "blankBoundary" in
> > Doc/config.txt (with the upper case 'B'), while the rest have no such
> > thing.
> >
> > for fun, i checked another of blame's config settings, with similar
> > results:
> >
> > builtin/blame.c: if (!strcmp(var, "blame.showemail")) {
> > Documentation/config.txt:blame.showEmail::
> > Documentation/RelNotes/2.15.1.txt: * Description of blame.{showroot,blankboundary,showemail,date}
> > Documentation/RelNotes/2.5.0.txt: * "git blame" learned blame.showEmail configuration variable.
> > Documentation/RelNotes/2.16.0.txt: * Description of blame.{showroot,blankboundary,showemail,date}
> > Documentation/git-blame.txt: This can also be controlled via the `blame.showEmail` config
> > t/t8002-blame.sh:test_expect_success 'setup showEmail tests' '
> > t/t8002-blame.sh:test_expect_success 'blame with showemail options' '
> > t/t8002-blame.sh:test_expect_success 'blame with showEmail config false' '
> > t/t8002-blame.sh: git config blame.showEmail false &&
> > t/t8002-blame.sh:test_expect_success 'blame with showEmail config true' '
> > t/t8002-blame.sh: git config blame.showEmail true &&
> >
> > thoughts?
>
> The issues you note about the docs using foo.barbaz instead of
> foo.barBaz should be fixed, but as noted in the "Syntax" section of
> "git-config" we already document that the config keys are all
> case-insensitive. We just like talking about them as foo.barBaz
> because it makes for easier reading.
ah, got it, so really, the only example above that would merit
tweaking would be:
blame-options.txt: be controlled via the `blame.blankboundary` config option.
i'll collect those in my travels and submit them all at once.
rday
^ permalink raw reply [relevance 8%]
* Re: should config options be treated as case-sensitive?
2018-05-23 1:55 13% ` Junio C Hamano
@ 2018-05-23 7:59 8% ` Robert P. J. Day
2018-05-23 8:58 8% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Robert P. J. Day @ 2018-05-23 7:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ævar Arnfjörð Bjarmason, Git Mailing list
[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]
On Wed, 23 May 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
> > The issues you note about the docs using foo.barbaz instead of
> > foo.barBaz should be fixed, but as noted in the "Syntax" section
> > of "git-config" we already document that the config keys are all
> > case-insensitive. We just like talking about them as foo.barBaz
> > because it makes for easier reading.
>
> The first and the last level of configuration variable names are
> case insensitive.
>
> I said "first and last", as there are variables with 2-level and
> 3-level names. "foo.barBaz" is two-level and it is the same
> variable as "Foo.barbaz". "remote.origin.url" is three-level, and
> it is the same variable as "Remote.origin.URL", but it is not the
> same variable as "remote.ORIGIN.url".
>
> If the documention does not make it clear, then we have
> documentation bug ...
personally, i would add a short, really emphatic note at the top of
"man git-config" pointing this out -- i wouldn't require people to
read all the way down to "Syntax" to learn this. an example just like
the one you provide above would be perfect, with an extra line
pointing out that the documentation uses "camel case" for nothing more
than readability.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply [relevance 8%]
* Re: should config options be treated as case-sensitive?
2018-05-23 8:58 8% ` Junio C Hamano
@ 2018-05-23 9:04 8% ` Robert P. J. Day
2018-05-23 23:33 7% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Robert P. J. Day @ 2018-05-23 9:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ævar Arnfjörð Bjarmason, Git Mailing list
On Wed, 23 May 2018, Junio C Hamano wrote:
> "Robert P. J. Day" <rpjday@crashcourse.ca> writes:
>
> >> If the documention does not make it clear, then we have
> >> documentation bug ...
> >
> > personally, i would add a short, really emphatic note at the top of
> > "man git-config" pointing this out -- i wouldn't require people to
> > read all the way down to "Syntax" to learn this. an example just like
> > the one you provide above would be perfect, with an extra line
> > pointing out that the documentation uses "camel case" for nothing more
> > than readability.
>
> Unfortunately, that line of thinking leads us to madness, as you are
> exhibiting the typical symptom of "my today's immediate itch is the
> most important one in the world"-itis. Tomorrow you would start
> saying that we must have a short, really emphatic note at the top
> that says that the second level name can even have spaces, and on
> the day after that, you would instead have a note that says that you
> cannot use an underscore in the name, and continuing that line of
> thought will lead us to fill the top part of the documentation with
> 47 different short and emphatic sentences. Let's not go there.
fair enough, point taken.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply [relevance 8%]
* Re: [PATCH] config: fix case sensitive subsection names on writing
2018-07-27 20:51 20% [PATCH] config: fix case sensitive subsection names on writing Stefan Beller
2018-07-27 21:21 15% ` Brandon Williams
@ 2018-07-27 21:37 8% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2018-07-27 21:37 UTC (permalink / raw)
To: Stefan Beller; +Cc: git
Stefan Beller <sbeller@google.com> writes:
> A use reported a submodule issue regarding strange case indentation
> issues, but it could be boiled down to the following test case:
>
> $ git init test && cd test
> $ git config foo."Bar".key test
> $ git config foo."bar".key test
> $ tail -n 3 .git/config
> [foo "Bar"]
> key = test
> key = test
>
> Sub sections are case sensitive and we have a test for correctly reading
> them. However we do not have a test for writing out config correctly with
> case sensitive subsection names, which is why this went unnoticed in
> 6ae996f2acf (git_config_set: make use of the config parser's event
> stream, 2018-04-09)
Thanks for finding this bug and fixing it; yes it would have been
even nicer if we caught it before it hit 'master', but we can only
do what we can X-<.
> diff --git a/config.c b/config.c
> index 3aacddfec4b..3ded92b678b 100644
> --- a/config.c
> +++ b/config.c
> @@ -2374,7 +2374,7 @@ static int store_aux_event(enum config_event_t type,
> store->is_keys_section =
> store->parsed[store->parsed_nr].is_keys_section =
> cf->var.len - 1 == store->baselen &&
> - !strncasecmp(cf->var.buf, store->key, store->baselen);
> + !strncmp(cf->var.buf, store->key, store->baselen);
> if (store->is_keys_section) {
> store->section_seen = 1;
> ALLOC_GROW(store->seen, store->seen_nr + 1,
> diff --git a/t/t1300-config.sh b/t/t1300-config.sh
> index 03c223708eb..8325d4495f4 100755
> --- a/t/t1300-config.sh
> +++ b/t/t1300-config.sh
> @@ -1218,6 +1218,24 @@ test_expect_success 'last one wins: three level vars' '
> test_cmp expect actual
> '
>
> +test_expect_success 'setting different case subsections ' '
> + test_when_finished "rm -f caseSens caseSens_actual caseSens_expect" &&
> +
> + # v.a.r and v.A.r are not the same variable, as the middle
> + # level of a three-level configuration variable name is
> + # case sensitive.
> + git config -f caseSens v."A".r VAL &&
> + git config -f caseSens v."a".r val &&
It probably is easier to read to write these as "v.A.r" and "v.a.r"
respectively.
> +
> + echo VAL >caseSens_expect &&
> + git config -f caseSens v."A".r >caseSens_actual &&
> + test_cmp caseSens_expect caseSens_actual &&
> +
> + echo val >caseSens_expect &&
> + git config -f caseSens v."a".r >caseSens_actual &&
> + test_cmp caseSens_expect caseSens_actual
> +'
> +
> for VAR in a .a a. a.0b a."b c". a."b c".0d
> do
> test_expect_success "git -c $VAR=VAL rejects invalid '$VAR'" '
^ permalink raw reply [relevance 8%]
* Re: [PATCH] config: fix case sensitive subsection names on writing
2018-07-27 21:21 15% ` Brandon Williams
@ 2018-07-27 21:39 8% ` Junio C Hamano
2018-07-27 23:35 8% ` Stefan Beller
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2018-07-27 21:39 UTC (permalink / raw)
To: Brandon Williams; +Cc: Stefan Beller, git
Brandon Williams <bmwill@google.com> writes:
> Either way you're probably going to need to be careful about how you do
> string comparison against the different parts.
Good suggestion.
>> diff --git a/t/t1300-config.sh b/t/t1300-config.sh
>> index 03c223708eb..8325d4495f4 100755
>> --- a/t/t1300-config.sh
>> +++ b/t/t1300-config.sh
>> @@ -1218,6 +1218,24 @@ test_expect_success 'last one wins: three level vars' '
>> test_cmp expect actual
>> '
>>
>> +test_expect_success 'setting different case subsections ' '
>> + test_when_finished "rm -f caseSens caseSens_actual caseSens_expect" &&
>> +
>> + # v.a.r and v.A.r are not the same variable, as the middle
>> + # level of a three-level configuration variable name is
>> + # case sensitive.
In other words, perhaps add
# "V.a.r" and "v.a.R" are the same variable, though
and corresponding test here?
>> + git config -f caseSens v."A".r VAL &&
>> + git config -f caseSens v."a".r val &&
>> +
>> + echo VAL >caseSens_expect &&
>> + git config -f caseSens v."A".r >caseSens_actual &&
>> + test_cmp caseSens_expect caseSens_actual &&
>> +
>> + echo val >caseSens_expect &&
>> + git config -f caseSens v."a".r >caseSens_actual &&
>> + test_cmp caseSens_expect caseSens_actual
>> +'
>> +
>> for VAR in a .a a. a.0b a."b c". a."b c".0d
>> do
>> test_expect_success "git -c $VAR=VAL rejects invalid '$VAR'" '
>> --
>> 2.18.0.345.g5c9ce644c3-goog
>>
^ permalink raw reply [relevance 8%]
* Re: [PATCH] config: fix case sensitive subsection names on writing
2018-07-27 21:39 8% ` Junio C Hamano
@ 2018-07-27 23:35 8% ` Stefan Beller
2018-07-27 23:36 21% ` Stefan Beller
0 siblings, 1 reply; 200+ results
From: Stefan Beller @ 2018-07-27 23:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Williams, git
On Fri, Jul 27, 2018 at 2:39 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Brandon Williams <bmwill@google.com> writes:
>
> > Either way you're probably going to need to be careful about how you do
> > string comparison against the different parts.
>
> Good suggestion.
The suggestion is a rabit hole and was a waste of time.
However I did some more manual testing and inspected the code
with trace_printf debugging, and it turns out the strings compared
are brought into the correct form already.
> >> + # v.a.r and v.A.r are not the same variable, as the middle
> >> + # level of a three-level configuration variable name is
> >> + # case sensitive.
>
> In other words, perhaps add
>
> # "V.a.r" and "v.a.R" are the same variable, though
>
> and corresponding test here?
I removed that section and went for a shorter,
more concise expression.
patch to follow.
^ permalink raw reply [relevance 8%]
* Re: [PATCH] config: fix case sensitive subsection names on writing
2018-07-27 23:36 21% ` Stefan Beller
@ 2018-07-27 23:37 8% ` Stefan Beller
2018-07-28 1:01 8% ` Junio C Hamano
2018-07-28 1:37 8% ` Junio C Hamano
2 siblings, 0 replies; 200+ results
From: Stefan Beller @ 2018-07-27 23:37 UTC (permalink / raw)
To: git, Jeff King; +Cc: Brandon Williams, Johannes Schindelin, Junio C Hamano
I cc'd the wrong peff. Sorry about that.
On Fri, Jul 27, 2018 at 4:36 PM Stefan Beller <sbeller@google.com> wrote:
....
^ permalink raw reply [relevance 8%]
* Re: [PATCH] config: fix case sensitive subsection names on writing
2018-07-27 23:36 21% ` Stefan Beller
2018-07-27 23:37 8% ` Stefan Beller
2018-07-28 1:01 8% ` Junio C Hamano
@ 2018-07-28 1:37 8% ` Junio C Hamano
2018-07-30 12:49 14% ` Johannes Schindelin
2 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2018-07-28 1:37 UTC (permalink / raw)
To: Stefan Beller; +Cc: git, bmwill, peff, Johannes.Schindelin
Stefan Beller <sbeller@google.com> writes:
> I really appreciate the work by DScho (and Peff as I recall him as an active
> reviewer there) on 4f4d0b42bae (Merge branch 'js/empty-config-section-fix',
> 2018-05-08), as the corner cases are all correct, modulo the one line fix
> in this patch.
Amen to the early part of that ;--) Even though it was merely
cosmetic, and did not affect correctness, that longstandng bug was
very annoying bug to a lot of people. I too am very happy to see it
disappear.
I would still hold the judgment on "all except only this one"
myself. That's a bit too early in my mind.
^ permalink raw reply [relevance 8%]
* Re: [PATCH 2/3] config: fix case sensitive subsection names on writing
2018-07-30 23:04 24% ` [PATCH 2/3] " Stefan Beller
@ 2018-07-31 20:16 8% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2018-07-31 20:16 UTC (permalink / raw)
To: Stefan Beller; +Cc: johannes.schindelin, bmwill, git, peff
Stefan Beller <sbeller@google.com> writes:
> A use reported a submodule issue regarding strange case indentation
> issues, but it could be boiled down to the following test case:
>
> $ git init test && cd test
> $ git config foo."Bar".key test
> $ git config foo."bar".key test
> $ tail -n 3 .git/config
> [foo "Bar"]
> key = test
> key = test
>
> Sub sections are case sensitive and we have a test for correctly reading
> them. However we do not have a test for writing out config correctly with
> case sensitive subsection names, which is why this went unnoticed in
> 6ae996f2acf (git_config_set: make use of the config parser's event
> stream, 2018-04-09)
Am I correct to understand that this patch is a "FIX" for breakage
introduced by that commit? The phrasing is not helping me to pick
a good base to queue these patches on.
Thanks.
^ permalink raw reply [relevance 8%]
* Re: [PATCH 2/3] config: fix case sensitive subsection names on writing
2018-08-01 19:34 20% ` [PATCH 2/3] config: fix case sensitive subsection names on writing Stefan Beller
@ 2018-08-01 21:01 8% ` Ramsay Jones
2018-08-01 22:26 8% ` Junio C Hamano
2018-08-01 22:51 7% ` Junio C Hamano
1 sibling, 1 reply; 200+ results
From: Ramsay Jones @ 2018-08-01 21:01 UTC (permalink / raw)
To: Stefan Beller, gitster; +Cc: bmwill, git, johannes.schindelin, peff
On 01/08/18 20:34, Stefan Beller wrote:
> A use reported a submodule issue regarding strange case indentation
s/use/user/ ?
ATB,
Ramsay Jones
^ permalink raw reply [relevance 8%]
* Re: [PATCH 2/3] config: fix case sensitive subsection names on writing
2018-08-01 21:01 8% ` Ramsay Jones
@ 2018-08-01 22:26 8% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2018-08-01 22:26 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Stefan Beller, bmwill, git, johannes.schindelin, peff
Ramsay Jones <ramsay@ramsayjones.plus.com> writes:
> On 01/08/18 20:34, Stefan Beller wrote:
>> A use reported a submodule issue regarding strange case indentation
>
> s/use/user/ ?
True. Also s/indentation/something else/ ?
Insufficient proofreading, perhaps?
^ permalink raw reply [relevance 8%]
* Re: [PATCH 2/3] config: fix case sensitive subsection names on writing
2018-08-01 22:51 7% ` Junio C Hamano
@ 2018-08-03 0:30 8% ` Stefan Beller
2018-08-03 15:51 8% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Stefan Beller @ 2018-08-03 0:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Williams, git, Johannes Schindelin, peff
On Wed, Aug 1, 2018 at 3:51 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Stefan Beller <sbeller@google.com> writes:
>
> > A use reported a submodule issue regarding strange case indentation
> > issues, but it could be boiled down to the following test case:
>
> Perhaps
>
> s/use/user/
> s/case indentation issues/section mix-up/
will be fixed in a reroll
>
> > ... However we do not have a test for writing out config correctly with
> > case sensitive subsection names, which is why this went unnoticed in
> > 6ae996f2acf (git_config_set: make use of the config parser's event
> > stream, 2018-04-09)
>
> s/unnoticed in \(.*04-09)\)/unnoticed when \1 broke it./
>
> This is why I asked if the patch is a "FIX" for an issue introduced
> by the cited commit.
I did not check further down the history if it was a recent brakage.
> > static int get_base_var(struct strbuf *name)
> > {
> > + cf->section_name_old_dot_style = 1;
> > for (;;) {
> > int c = get_next_char();
> > if (cf->eof)
>
> OK, let me rephrase. The basic parse structure is that
>
> * upon seeing '[', we call get_base_var(), which stuffs the
> "section" (including subsection, if exists) in the strbuf.
>
> * get_base_var() upon seeing a space after "[section ", calls
> get_extended_base_var(). This space can never exist in an
> old-style three-level names, where it is spelled as
> "[section.subsection]". This space cannot exist in two-level
> names, either. The closing ']' is eaten by this function before
> it returns.
>
> * get_extended_base_var() grabs the "double quoted" subsection name
> and eats the closing ']' before it returns.
>
> So you set the new bit (section_name_old_dot_style) at the beginning
> of get_base_var(), i.e. declare that you assume we are reading old
> style, but upon entering get_extended_base_var(), unset it, because
> now you know we are parsing a modern style three-level name(s).
>
> Feels quite sensible way to keep track of old/new styles.
>
> When parsing two-level names, old-style bit is set, which we may
> need to be careful, thoguh.
I considered setting it only when seeing the dot, but then we'd have
to make sure it is properly initialized.
And *technically* the two level is old style, so I figured it's ok.
> > - !strncasecmp(cf->var.buf, store->key, store->baselen);
> > + !cmpfn(cf->var.buf, store->key, store->baselen);
>
> OK. Section names should still be case insensitive (only the case
> sensitivity of subsection names is special), but presumably that's
> already normalized by the caller so we do not have to worry when we
> use strncmp()? Can we add a test to demonstrate that it works
> correctly?
That was already demonstrated (but not tested) in
https://public-inbox.org/git/20180730230443.74416-4-sbeller@google.com/
^ permalink raw reply [relevance 8%]
* Re: [PATCH v2 4/5] mailmap: use case-sensitive comparisons for local-parts and names
2021-01-04 16:10 11% ` Ævar Arnfjörð Bjarmason
@ 2021-01-06 0:46 8% ` Junio C Hamano
2021-01-12 14:08 8% ` Ævar Arnfjörð Bjarmason
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2021-01-06 0:46 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: brian m. carlson, git, Jeff King, Phillip Wood,
Johannes Schindelin
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> On Sun, Jan 03 2021, brian m. carlson wrote:
>
> We just have to worry about cases where you're not all of these people
> in one project's commit metadata and/or .mailmap, and thus mailmap rules
> would match too generously:
>
> "brian m. carlson" <sandals@crustytoothpaste.net>
> "brian m. carlson" <SANDALS@crustytoothpaste.net>
> "BRIAN M. CARLSON" <sandals@crustytoothpaste.net>
> "BRIAN M. CARLSON" <SANDALS@crustytoothpaste.net>
>
> Is that really plausible? In any case, neither of these two patches make
> reference to us already having changed this in the past in 1.6.2 and &
> there being reports on the ML about the bug & us changing it back. See
> https://lore.kernel.org/git/f182fb1700e8dea15459fd02ced2a6e5797bec99.1238458535u.git.johannes.schindelin@gmx.de/
>
> Maybe we should still do this, but I think for a v3 it makes sense to
> summarize that discussion etc.
After reading the old discussion again, I am not sure if this is
worth doing. To many people, it is a promise we've made and kept
that we treat addresses including the local part case-insensitively
when summarising commits by ident strings.
I'd really wish that this series were structured to have 5/5 early
and 3&4/5 squashed into a single final patch.
^ permalink raw reply [relevance 8%]
* fast-import fails with case sensitive tags due to case insensitive lock files
@ 2019-03-01 6:19 8% Wendeborn, Jonathan
2019-03-03 0:25 15% ` brian m. carlson
0 siblings, 1 reply; 200+ results
From: Wendeborn, Jonathan @ 2019-03-01 6:19 UTC (permalink / raw)
To: git@vger.kernel.org
Hi,
I have a problem with fast-import on an NTFS drive: If I try to import tags which are identical apart from their casing a failure due to identical lock file names occurs.
I am running git for windows 2.15.1.2 x64 on a Windows 10 machine (10.0.15063):
$ git --version --build-options
git version 2.15.1.windows.2
built from commit: 5d5baf91824ec7750b103c8b7c4827ffac202feb
sizeof-long: 4
machine: x86_64
MCVE:
(echo "commit refs/heads/master" &&
echo "mark :1" &&
echo "committer me <> 0 +0000" &&
echo "data 0" &&
echo "" &&
echo "tag tag_A" &&
echo "from :1" &&
echo "tagger me <> 0 +0000" &&
echo "data 0" &&
echo "" &&
echo "tag tag_a" &&
echo "from :1" &&
echo "tagger me <> 0 +0000" &&
echo "data 0" &&
echo "") | git fast-import
Instead of having 1 commit with two tags ("tag_A" and "tag_a") I get his error message:
Unpacking objects: 100% (4/4), done.
error: cannot lock ref 'refs/tags/tag_a': Unable to create 'C:/tmp/.git/refs/tags/tag_a.lock': File exists.
Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.
Best regards,
Jonathan
^ permalink raw reply [relevance 8%]
* Git filesystem case-insensitive to case-sensitive system broken
@ 2017-01-06 21:56 9% Steven Robertson
2017-01-07 13:48 9% ` Torsten Bögershausen
0 siblings, 1 reply; 200+ results
From: Steven Robertson @ 2017-01-06 21:56 UTC (permalink / raw)
To: git
Hello,
I was doing development on a linux box on AWS, when we found a code
bug that had me switching to running the code on a Mac instead. We
discovered that we had accidentally named two files the same when
looked at case-insensitively, which made git commands afterwards
display the wrong thing. It looked like this (ignoring some things
that aren't relevant):
$ git status
modified: tests/test_system/show_19_L.txt
no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout tests/test_system/show_19_L.txt
$ git status
modified: tests/test_system/show_19_l.txt
no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout tests/test_system/show_19_l.txt
$ git status
modified: tests/test_system/show_19_L.txt
no changes added to commit (use "git add" and/or "git commit -a")
$ diff tests/test_system/show_19_L.txt tests/test_system/show_19_l.txt
$
Those two files are different in our repo, and as such git thinks that
we modified one of them when we try and pull it down from github
again.
Thanks for looking at this!
-- Steven
^ permalink raw reply [relevance 9%]
* Re: [PATCH v5] clone: report duplicate entries on case-insensitive filesystems
@ 2018-08-17 18:00 9% ` Duy Nguyen
0 siblings, 0 replies; 200+ results
From: Duy Nguyen @ 2018-08-17 18:00 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, git, newren, pawelparuzel95, peff, sandals, szeder.dev,
tboegi
On Fri, Aug 17, 2018 at 10:20:36AM -0700, Junio C Hamano wrote:
> I highly suspect that the above was written in that way to reduce
> the indentation level, but the right way to reduce the indentation
> level, if it bothers readers too much, is to make the whole thing
> inside the above if (o->clone) into a dedicated helper function
> "void report_collided_checkout(void)", I would think.
I read my mind. I thought of separating into a helper function too,
but was not happy that the clearing CE_MATCHED in preparation for this
test is in check_updates(), but the cleaning up CE_MATCHED() is in the
helper function.
So here is the version that separates _both_ phases into helper
functions.
-- 8< --
Subject: [PATCH v6] clone: report duplicate entries on case-insensitive filesystems
Paths that only differ in case work fine in a case-sensitive
filesystems, but if those repos are cloned in a case-insensitive one,
you'll get problems. The first thing to notice is "git status" will
never be clean with no indication what exactly is "dirty".
This patch helps the situation a bit by pointing out the problem at
clone time. Even though this patch talks about case sensitivity, the
patch makes no assumption about folding rules by the filesystem. It
simply observes that if an entry has been already checked out at clone
time when we're about to write a new path, some folding rules are
behind this.
In the case that we can't rely on filesystem (via inode number) to do
this check, fall back to fspathcmp() which is not perfect but should
not give false positives.
This patch is tested with vim-colorschemes and Sublime-Gitignore
repositories on a JFS partition with case insensitive support on
Linux.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/clone.c | 1 +
cache.h | 1 +
entry.c | 31 +++++++++++++++++++++++++++++++
t/t5601-clone.sh | 8 +++++++-
unpack-trees.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
unpack-trees.h | 1 +
6 files changed, 88 insertions(+), 1 deletion(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 5c439f1394..0702b0e9d0 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -747,6 +747,7 @@ static int checkout(int submodule_progress)
memset(&opts, 0, sizeof opts);
opts.update = 1;
opts.merge = 1;
+ opts.clone = 1;
opts.fn = oneway_merge;
opts.verbose_update = (option_verbosity >= 0);
opts.src_index = &the_index;
diff --git a/cache.h b/cache.h
index 8b447652a7..6d6138f4f1 100644
--- a/cache.h
+++ b/cache.h
@@ -1455,6 +1455,7 @@ struct checkout {
unsigned force:1,
quiet:1,
not_new:1,
+ clone:1,
refresh_cache:1;
};
#define CHECKOUT_INIT { NULL, "" }
diff --git a/entry.c b/entry.c
index b5d1d3cf23..8766e27255 100644
--- a/entry.c
+++ b/entry.c
@@ -399,6 +399,34 @@ static int check_path(const char *path, int len, struct stat *st, int skiplen)
return lstat(path, st);
}
+static void mark_colliding_entries(const struct checkout *state,
+ struct cache_entry *ce, struct stat *st)
+{
+ int i, trust_ino = check_stat;
+
+#if defined(GIT_WINDOWS_NATIVE)
+ trust_ino = 0;
+#endif
+
+ ce->ce_flags |= CE_MATCHED;
+
+ for (i = 0; i < state->istate->cache_nr; i++) {
+ struct cache_entry *dup = state->istate->cache[i];
+
+ if (dup == ce)
+ break;
+
+ if (dup->ce_flags & (CE_MATCHED | CE_VALID | CE_SKIP_WORKTREE))
+ continue;
+
+ if ((trust_ino && dup->ce_stat_data.sd_ino == st->st_ino) ||
+ (!trust_ino && !fspathcmp(ce->name, dup->name))) {
+ dup->ce_flags |= CE_MATCHED;
+ break;
+ }
+ }
+}
+
/*
* Write the contents from ce out to the working tree.
*
@@ -455,6 +483,9 @@ int checkout_entry(struct cache_entry *ce,
return -1;
}
+ if (state->clone)
+ mark_colliding_entries(state, ce, &st);
+
/*
* We unlink the old file, to get the new one with the
* right permissions (including umask, which is nasty
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 0b62037744..f2eb73bc74 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -624,10 +624,16 @@ test_expect_success 'clone on case-insensitive fs' '
git hash-object -w -t tree --stdin) &&
c=$(git commit-tree -m bogus $t) &&
git update-ref refs/heads/bogus $c &&
- git clone -b bogus . bogus
+ git clone -b bogus . bogus 2>warning
)
'
+test_expect_success !MINGW,!CYGWIN,CASE_INSENSITIVE_FS 'colliding file detection' '
+ grep X icasefs/warning &&
+ grep x icasefs/warning &&
+ test_i18ngrep "the following paths have collided" icasefs/warning
+'
+
partial_clone () {
SERVER="$1" &&
URL="$2" &&
diff --git a/unpack-trees.c b/unpack-trees.c
index cd0680f11e..213da8bbb4 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -345,6 +345,46 @@ static struct progress *get_progress(struct unpack_trees_options *o)
return start_delayed_progress(_("Checking out files"), total);
}
+static void setup_collided_checkout_detection(struct checkout *state,
+ struct index_state *index)
+{
+ int i;
+
+ state->clone = 1;
+ for (i = 0; i < index->cache_nr; i++)
+ index->cache[i]->ce_flags &= ~CE_MATCHED;
+}
+
+static void report_collided_checkout(struct index_state *index)
+{
+ struct string_list list = STRING_LIST_INIT_NODUP;
+ int i;
+
+ for (i = 0; i < index->cache_nr; i++) {
+ struct cache_entry *ce = index->cache[i];
+
+ if (!(ce->ce_flags & CE_MATCHED))
+ continue;
+
+ string_list_append(&list, ce->name);
+ ce->ce_flags &= ~CE_MATCHED;
+ }
+
+ list.cmp = fspathcmp;
+ string_list_sort(&list);
+
+ if (list.nr) {
+ warning(_("the following paths have collided (e.g. case-sensitive paths\n"
+ "on a case-insensitive filesystem) and only one from the same\n"
+ "colliding group is in the working tree:\n"));
+
+ for (i = 0; i < list.nr; i++)
+ fprintf(stderr, " '%s'\n", list.items[i].string);
+ }
+
+ string_list_clear(&list, 0);
+}
+
static int check_updates(struct unpack_trees_options *o)
{
unsigned cnt = 0;
@@ -359,6 +399,9 @@ static int check_updates(struct unpack_trees_options *o)
state.refresh_cache = 1;
state.istate = index;
+ if (o->clone)
+ setup_collided_checkout_detection(&state, index);
+
progress = get_progress(o);
if (o->update)
@@ -423,6 +466,10 @@ static int check_updates(struct unpack_trees_options *o)
errs |= finish_delayed_checkout(&state);
if (o->update)
git_attr_set_direction(GIT_ATTR_CHECKIN, NULL);
+
+ if (o->clone)
+ report_collided_checkout(index);
+
return errs != 0;
}
diff --git a/unpack-trees.h b/unpack-trees.h
index c2b434c606..d940f1c5c2 100644
--- a/unpack-trees.h
+++ b/unpack-trees.h
@@ -42,6 +42,7 @@ struct unpack_trees_options {
unsigned int reset,
merge,
update,
+ clone,
index_only,
nontrivial_merge,
trivial_merges_only,
--
2.18.0.1004.g6639190530
-- 8< --
--
Duy
^ permalink raw reply related [relevance 9%]
* [PATCH v5] clone: report duplicate entries on case-insensitive filesystems
2018-08-12 9:07 9% ` [PATCH v4] clone: report duplicate entries on case-insensitive filesystems Nguyễn Thái Ngọc Duy
@ 2018-08-17 16:16 9% ` Nguyễn Thái Ngọc Duy
0 siblings, 1 reply; 200+ results
From: Nguyễn Thái Ngọc Duy @ 2018-08-17 16:16 UTC (permalink / raw)
To: pclouds
Cc: git, git, gitster, newren, pawelparuzel95, peff, sandals,
szeder.dev, tboegi
Paths that only differ in case work fine in a case-sensitive
filesystems, but if those repos are cloned in a case-insensitive one,
you'll get problems. The first thing to notice is "git status" will
never be clean with no indication what exactly is "dirty".
This patch helps the situation a bit by pointing out the problem at
clone time. Even though this patch talks about case sensitivity, the
patch makes no assumption about folding rules by the filesystem. It
simply observes that if an entry has been already checked out at clone
time when we're about to write a new path, some folding rules are
behind this.
In the case that we can't rely on filesystem (via inode number) to do
this check, fall back to fspathcmp() which is not perfect but should
not give false positives.
This patch is tested with vim-colorschemes and Sublime-Gitignore
repositories on a JFS partition with case insensitive support on
Linux.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
v5 respects core.checkStat and sorts the output case-insensitively.
I still don't trust magic st_ino zero, or core.checkStat being zero
on Windows, so the #if condition still remains but it covers smallest
area possible and I tested it by manually make it "#if 1"
The fallback with fspathcmp() is only done when inode can't be
trusted because strcmp is more expensive and when fspathcmp() learns
more about real world in the future, it could become even more
expensive.
The output sorting is the result of Sublime-Gitignore repo being
reported recently. It's not perfect but it should help seeing the
groups in normal case.
builtin/clone.c | 1 +
cache.h | 1 +
entry.c | 31 +++++++++++++++++++++++++++++++
t/t5601-clone.sh | 8 +++++++-
unpack-trees.c | 35 +++++++++++++++++++++++++++++++++++
unpack-trees.h | 1 +
6 files changed, 76 insertions(+), 1 deletion(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 5c439f1394..0702b0e9d0 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -747,6 +747,7 @@ static int checkout(int submodule_progress)
memset(&opts, 0, sizeof opts);
opts.update = 1;
opts.merge = 1;
+ opts.clone = 1;
opts.fn = oneway_merge;
opts.verbose_update = (option_verbosity >= 0);
opts.src_index = &the_index;
diff --git a/cache.h b/cache.h
index 8b447652a7..6d6138f4f1 100644
--- a/cache.h
+++ b/cache.h
@@ -1455,6 +1455,7 @@ struct checkout {
unsigned force:1,
quiet:1,
not_new:1,
+ clone:1,
refresh_cache:1;
};
#define CHECKOUT_INIT { NULL, "" }
diff --git a/entry.c b/entry.c
index b5d1d3cf23..8766e27255 100644
--- a/entry.c
+++ b/entry.c
@@ -399,6 +399,34 @@ static int check_path(const char *path, int len, struct stat *st, int skiplen)
return lstat(path, st);
}
+static void mark_colliding_entries(const struct checkout *state,
+ struct cache_entry *ce, struct stat *st)
+{
+ int i, trust_ino = check_stat;
+
+#if defined(GIT_WINDOWS_NATIVE)
+ trust_ino = 0;
+#endif
+
+ ce->ce_flags |= CE_MATCHED;
+
+ for (i = 0; i < state->istate->cache_nr; i++) {
+ struct cache_entry *dup = state->istate->cache[i];
+
+ if (dup == ce)
+ break;
+
+ if (dup->ce_flags & (CE_MATCHED | CE_VALID | CE_SKIP_WORKTREE))
+ continue;
+
+ if ((trust_ino && dup->ce_stat_data.sd_ino == st->st_ino) ||
+ (!trust_ino && !fspathcmp(ce->name, dup->name))) {
+ dup->ce_flags |= CE_MATCHED;
+ break;
+ }
+ }
+}
+
/*
* Write the contents from ce out to the working tree.
*
@@ -455,6 +483,9 @@ int checkout_entry(struct cache_entry *ce,
return -1;
}
+ if (state->clone)
+ mark_colliding_entries(state, ce, &st);
+
/*
* We unlink the old file, to get the new one with the
* right permissions (including umask, which is nasty
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 0b62037744..f2eb73bc74 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -624,10 +624,16 @@ test_expect_success 'clone on case-insensitive fs' '
git hash-object -w -t tree --stdin) &&
c=$(git commit-tree -m bogus $t) &&
git update-ref refs/heads/bogus $c &&
- git clone -b bogus . bogus
+ git clone -b bogus . bogus 2>warning
)
'
+test_expect_success !MINGW,!CYGWIN,CASE_INSENSITIVE_FS 'colliding file detection' '
+ grep X icasefs/warning &&
+ grep x icasefs/warning &&
+ test_i18ngrep "the following paths have collided" icasefs/warning
+'
+
partial_clone () {
SERVER="$1" &&
URL="$2" &&
diff --git a/unpack-trees.c b/unpack-trees.c
index cd0680f11e..4338fee3b7 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -359,6 +359,12 @@ static int check_updates(struct unpack_trees_options *o)
state.refresh_cache = 1;
state.istate = index;
+ if (o->clone) {
+ state.clone = 1;
+ for (i = 0; i < index->cache_nr; i++)
+ index->cache[i]->ce_flags &= ~CE_MATCHED;
+ }
+
progress = get_progress(o);
if (o->update)
@@ -423,6 +429,35 @@ static int check_updates(struct unpack_trees_options *o)
errs |= finish_delayed_checkout(&state);
if (o->update)
git_attr_set_direction(GIT_ATTR_CHECKIN, NULL);
+
+ if (o->clone) {
+ struct string_list list = STRING_LIST_INIT_NODUP;
+ int i;
+
+ for (i = 0; i < index->cache_nr; i++) {
+ struct cache_entry *ce = index->cache[i];
+
+ if (!(ce->ce_flags & CE_MATCHED))
+ continue;
+
+ string_list_append(&list, ce->name);
+ ce->ce_flags &= ~CE_MATCHED;
+ }
+
+ list.cmp = fspathcmp;
+ string_list_sort(&list);
+
+ if (list.nr)
+ warning(_("the following paths have collided (e.g. case-sensitive paths\n"
+ "on a case-insensitive filesystem) and only one from the same\n"
+ "colliding group is in the working tree:\n"));
+
+ for (i = 0; i < list.nr; i++)
+ fprintf(stderr, " '%s'\n", list.items[i].string);
+
+ string_list_clear(&list, 0);
+ }
+
return errs != 0;
}
diff --git a/unpack-trees.h b/unpack-trees.h
index c2b434c606..d940f1c5c2 100644
--- a/unpack-trees.h
+++ b/unpack-trees.h
@@ -42,6 +42,7 @@ struct unpack_trees_options {
unsigned int reset,
merge,
update,
+ clone,
index_only,
nontrivial_merge,
trivial_merges_only,
--
2.18.0.1004.g6639190530
^ permalink raw reply related [relevance 9%]
* Re: Git filesystem case-insensitive to case-sensitive system broken
2017-01-06 21:56 9% Git filesystem case-insensitive to case-sensitive system broken Steven Robertson
@ 2017-01-07 13:48 9% ` Torsten Bögershausen
0 siblings, 0 replies; 200+ results
From: Torsten Bögershausen @ 2017-01-07 13:48 UTC (permalink / raw)
To: Steven Robertson; +Cc: git
On Fri, Jan 06, 2017 at 01:56:36PM -0800, Steven Robertson wrote:
> Hello,
>
> I was doing development on a linux box on AWS, when we found a code
> bug that had me switching to running the code on a Mac instead. We
> discovered that we had accidentally named two files the same when
> looked at case-insensitively, which made git commands afterwards
> display the wrong thing. It looked like this (ignoring some things
> that aren't relevant):
>
> $ git status
>
>
> modified: tests/test_system/show_19_L.txt
>
>
> no changes added to commit (use "git add" and/or "git commit -a")
>
> $ git checkout tests/test_system/show_19_L.txt
>
> $ git status
>
>
> modified: tests/test_system/show_19_l.txt
>
>
> no changes added to commit (use "git add" and/or "git commit -a")
>
> $ git checkout tests/test_system/show_19_l.txt
>
> $ git status
>
>
> modified: tests/test_system/show_19_L.txt
>
>
> no changes added to commit (use "git add" and/or "git commit -a")
>
> $ diff tests/test_system/show_19_L.txt tests/test_system/show_19_l.txt
>
> $
>
>
> Those two files are different in our repo, and as such git thinks that
> we modified one of them when we try and pull it down from github
> again.
>
>
> Thanks for looking at this!
> -- Steven
I assume that you are on Mac OS ?
This is what I would have done:
- find the twin of your file:
$ git ls-files | grep -i tests/test_system/show_19_L.txt
- Let's assume it is the little brother:
"tests/test_system/show_19_l.txt"
$ git mv tests/test_system/show_19_l.txt tests/test_system/show_19_l2.txt
- Check out the original:
$ git checkout tests/test_system/show_19_L.txt
- check:
$ git status
^ permalink raw reply [relevance 9%]
* Re: [Bug Report] [includeIf] does not parse case insensitive -> case sensitive symlink gitdir
2017-10-27 13:55 15% [Bug Report] [includeIf] does not parse case insensitive -> case sensitive symlink gitdir Adrian Kappel
@ 2017-10-27 15:33 9% ` Torsten Bögershausen
0 siblings, 0 replies; 200+ results
From: Torsten Bögershausen @ 2017-10-27 15:33 UTC (permalink / raw)
To: Adrian Kappel; +Cc: git
On Fri, Oct 27, 2017 at 09:55:58AM -0400, Adrian Kappel wrote:
> Hello all, not sure if the issue I've come across is a known bug or
> addressable, but wanted to report it just in-case.
Thanks for the detailed description - my question is inline
>
>
> ** Summary
> ------------------------------------------------------------------
> Using the [includeIf] configuration statement with a symlink'd gitdir
> will not work if the symlink is on a case insensitive volume and the
> location it references is on a case sensitive volume.
>
> ** Steps to reproduce
> ------------------------------------------------------------------
> 1. Create symlink (case insensitive -> case sensitive):
> /Users/usera/dev -> /Volumes/CaseSensitive/dev
> 2. Create two files: .gitignore and .gitignore-work, both stored in
> /Users/usera/
>
> .gitconfig
> -------------
> [user]
> name = First Last
>
> [includeIf "gitdir:~/dev/work"]
> path = .gitconfig-work
>
> .gitconfig-work
> --------------------
> [user]
> email = email@address.com
>
> 3. cd into a subfolder of ~/dev/work that has been git initialized.
> Let's say ~/dev/work/repo
> 4. Run git config --includes user.email
> 5. See that nothing is output from the command
> 6. Update the [includeIf] statement in .gitconfig to be the real
> location i.e. "gitdir:/Volumes/CaseSensitive/dev/work/repo"
Didn't you set it up pointing do the real location ?
That is what is written above:
> 1. Create symlink (case insensitive -> case sensitive):
> /Users/usera/dev -> /Volumes/CaseSensitive/dev
(I suspect that people use something like this:
/Users/usera/dev -> /Volumes/casesensitive/dev
And in this case it would be the file system which says
casesensitive != CaseSensitive and Git can't do much about it)
> 7. Rerun the command from [4]
> 8. See that email@address.com is output from the command
>
> ** Other variations that were not tested
> ------------------------------------------------------------------
> - symlink on case sensitive volume referencing a location on a case
> insensitive volume
>
> ** Environment Information
> ------------------------------------------------------------------
> git --version: 2.14.1
> OS: macOS Sierra 10.12.6
>
>
> If a fix is not feasible or likely to be implemented, I would
> recommend that we update the git site's documentation to reflect this
> gotcha. After verification of course.
>
> Best,
> Adrian Kappel
> akappel <https://github.com/akappel/>
^ permalink raw reply [relevance 9%]
* AW: fast-import fails with case sensitive tags due to case insensitive lock files
2019-03-03 0:25 15% ` brian m. carlson
@ 2019-03-04 7:55 9% ` Wendeborn, Jonathan
2019-03-04 15:29 9% ` Johannes Schindelin
0 siblings, 1 reply; 200+ results
From: Wendeborn, Jonathan @ 2019-03-04 7:55 UTC (permalink / raw)
To: brian m. carlson; +Cc: git@vger.kernel.org
> Right now, you have some choices:
> • Volunteer to implement reftable.
> • Since you're on Windows 10, set your Git repository directory as
> case-sensitive.
> • Use Windows Subsystem for Linux, which is case sensitive and creates
> directories with that flag (even on NTFS), to do your import.
> • If you control the fast-export output, adjust the arguments you pass
> such that the output does not contain one of the offending tags.
Hi Brian,
Thank you very much for your answer!
Unfortunately I am stuck with Windows 10 1703 which neither supports case-sensitivity nor any Linux subsystem from the Microsoft Store :( Also, my employer unfortunately doesn’t allow me to invest the time to implement reftable, so I guess I go with manually leaving out the one conflicting label I found and tagging it manually afterward.
One thing I still would like to encourage to is to improve the error message which is really misleading in this case.
Best regards and thanks again,
Jonathan
^ permalink raw reply [relevance 9%]
* Re: AW: fast-import fails with case sensitive tags due to case insensitive lock files
2019-03-04 7:55 9% ` AW: " Wendeborn, Jonathan
@ 2019-03-04 15:29 9% ` Johannes Schindelin
2019-03-05 6:25 14% ` AW: " Wendeborn, Jonathan
0 siblings, 1 reply; 200+ results
From: Johannes Schindelin @ 2019-03-04 15:29 UTC (permalink / raw)
To: Wendeborn, Jonathan; +Cc: brian m. carlson, git@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]
Hi Jonathan,
On Mon, 4 Mar 2019, Wendeborn, Jonathan wrote:
> > Right now, you have some choices:
> > • Volunteer to implement reftable.
> > • Since you're on Windows 10, set your Git repository directory as
> > case-sensitive.
> > • Use Windows Subsystem for Linux, which is case sensitive and creates
> > directories with that flag (even on NTFS), to do your import.
> > • If you control the fast-export output, adjust the arguments you pass
> > such that the output does not contain one of the offending tags.
>
> Hi Brian,
>
> Thank you very much for your answer!
>
> Unfortunately I am stuck with Windows 10 1703 which neither supports
> case-sensitivity nor any Linux subsystem from the Microsoft Store :(
Too bad.
> Also, my employer unfortunately doesn’t allow me to invest the time to
> implement reftable,
Even worse!
> so I guess I go with manually leaving out the one conflicting label I
> found and tagging it manually afterward.
That is a valid workaround.
> One thing I still would like to encourage to is to improve the error
> message which is really misleading in this case.
Well, that is at least something you could do. After all, you use a
volunteer-driven project, so you could at least volunteer a little time to
improving it yourself.
Ciao,
Johannes
^ permalink raw reply [relevance 9%]
* [PATCH v4] clone: report duplicate entries on case-insensitive filesystems
@ 2018-08-12 9:07 9% ` Nguyễn Thái Ngọc Duy
2018-08-17 16:16 9% ` [PATCH v5] " Nguyễn Thái Ngọc Duy
0 siblings, 1 reply; 200+ results
From: Nguyễn Thái Ngọc Duy @ 2018-08-12 9:07 UTC (permalink / raw)
To: pclouds
Cc: git, git, gitster, newren, pawelparuzel95, peff, sandals, tboegi,
SZEDER Gábor
Paths that only differ in case work fine in a case-sensitive
filesystems, but if those repos are cloned in a case-insensitive one,
you'll get problems. The first thing to notice is "git status" will
never be clean with no indication what exactly is "dirty".
This patch helps the situation a bit by pointing out the problem at
clone time. Even though this patch talks about case sensitivity, the
patch makes no assumption about folding rules by the filesystem. It
simply observes that if an entry has been already checked out at clone
time when we're about to write a new path, some folding rules are
behind this.
This patch is tested with vim-colorschemes repository on a JFS partition
with case insensitive support on Linux. This repository has two files
darkBlue.vim and darkblue.vim.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
v4 removes nr_duplicates (and fixes that false warning Szeder
reported). It also hints about case insensitivity as a cause of
problem because it's most likely the case when this warning shows up.
builtin/clone.c | 1 +
cache.h | 1 +
entry.c | 28 ++++++++++++++++++++++++++++
t/t5601-clone.sh | 8 +++++++-
unpack-trees.c | 28 ++++++++++++++++++++++++++++
unpack-trees.h | 1 +
6 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 5c439f1394..0702b0e9d0 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -747,6 +747,7 @@ static int checkout(int submodule_progress)
memset(&opts, 0, sizeof opts);
opts.update = 1;
opts.merge = 1;
+ opts.clone = 1;
opts.fn = oneway_merge;
opts.verbose_update = (option_verbosity >= 0);
opts.src_index = &the_index;
diff --git a/cache.h b/cache.h
index 8b447652a7..6d6138f4f1 100644
--- a/cache.h
+++ b/cache.h
@@ -1455,6 +1455,7 @@ struct checkout {
unsigned force:1,
quiet:1,
not_new:1,
+ clone:1,
refresh_cache:1;
};
#define CHECKOUT_INIT { NULL, "" }
diff --git a/entry.c b/entry.c
index b5d1d3cf23..c70340df8e 100644
--- a/entry.c
+++ b/entry.c
@@ -399,6 +399,31 @@ static int check_path(const char *path, int len, struct stat *st, int skiplen)
return lstat(path, st);
}
+static void mark_colliding_entries(const struct checkout *state,
+ struct cache_entry *ce, struct stat *st)
+{
+ int i;
+
+ ce->ce_flags |= CE_MATCHED;
+
+#if !defined(GIT_WINDOWS_NATIVE) /* inode is always zero on Windows */
+ for (i = 0; i < state->istate->cache_nr; i++) {
+ struct cache_entry *dup = state->istate->cache[i];
+
+ if (dup == ce)
+ break;
+
+ if (dup->ce_flags & (CE_MATCHED | CE_VALID | CE_SKIP_WORKTREE))
+ continue;
+
+ if (dup->ce_stat_data.sd_ino == st->st_ino) {
+ dup->ce_flags |= CE_MATCHED;
+ break;
+ }
+ }
+#endif
+}
+
/*
* Write the contents from ce out to the working tree.
*
@@ -455,6 +480,9 @@ int checkout_entry(struct cache_entry *ce,
return -1;
}
+ if (state->clone)
+ mark_colliding_entries(state, ce, &st);
+
/*
* We unlink the old file, to get the new one with the
* right permissions (including umask, which is nasty
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 0b62037744..f2eb73bc74 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -624,10 +624,16 @@ test_expect_success 'clone on case-insensitive fs' '
git hash-object -w -t tree --stdin) &&
c=$(git commit-tree -m bogus $t) &&
git update-ref refs/heads/bogus $c &&
- git clone -b bogus . bogus
+ git clone -b bogus . bogus 2>warning
)
'
+test_expect_success !MINGW,!CYGWIN,CASE_INSENSITIVE_FS 'colliding file detection' '
+ grep X icasefs/warning &&
+ grep x icasefs/warning &&
+ test_i18ngrep "the following paths have collided" icasefs/warning
+'
+
partial_clone () {
SERVER="$1" &&
URL="$2" &&
diff --git a/unpack-trees.c b/unpack-trees.c
index cd0680f11e..443df048ef 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -359,6 +359,12 @@ static int check_updates(struct unpack_trees_options *o)
state.refresh_cache = 1;
state.istate = index;
+ if (o->clone) {
+ state.clone = 1;
+ for (i = 0; i < index->cache_nr; i++)
+ index->cache[i]->ce_flags &= ~CE_MATCHED;
+ }
+
progress = get_progress(o);
if (o->update)
@@ -423,6 +429,28 @@ static int check_updates(struct unpack_trees_options *o)
errs |= finish_delayed_checkout(&state);
if (o->update)
git_attr_set_direction(GIT_ATTR_CHECKIN, NULL);
+
+ if (o->clone) {
+ int printed_warning = 0;
+
+ for (i = 0; i < index->cache_nr; i++) {
+ struct cache_entry *ce = index->cache[i];
+
+ if (!(ce->ce_flags & CE_MATCHED))
+ continue;
+
+ if (!printed_warning) {
+ warning(_("the following paths have collided (e.g. case-sensitive paths\n"
+ "on a case-insensitive filesystem) and only one from the same\n"
+ "colliding group is in the working tree:\n"));
+ printed_warning = 1;
+ }
+
+ fprintf(stderr, " '%s'\n", ce->name);
+ ce->ce_flags &= ~CE_MATCHED;
+ }
+ }
+
return errs != 0;
}
diff --git a/unpack-trees.h b/unpack-trees.h
index c2b434c606..d940f1c5c2 100644
--- a/unpack-trees.h
+++ b/unpack-trees.h
@@ -42,6 +42,7 @@ struct unpack_trees_options {
unsigned int reset,
merge,
update,
+ clone,
index_only,
nontrivial_merge,
trivial_merges_only,
--
2.18.0.1004.g6639190530
^ permalink raw reply related [relevance 9%]
* [PATCH] config.txt: add missing period
@ 2021-03-16 14:40 10% Kyle Meyer
0 siblings, 0 replies; 200+ results
From: Kyle Meyer @ 2021-03-16 14:40 UTC (permalink / raw)
To: git
Signed-off-by: Kyle Meyer <kyle@kyleam.com>
---
Documentation/config.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6ba50b1104..06615d840b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -46,7 +46,7 @@ Subsection names are case sensitive and can contain any characters except
newline and the null byte. Doublequote `"` and backslash can be included
by escaping them as `\"` and `\\`, respectively. Backslashes preceding
other characters are dropped when reading; for example, `\t` is read as
-`t` and `\0` is read as `0` Section headers cannot span multiple lines.
+`t` and `\0` is read as `0`. Section headers cannot span multiple lines.
Variables may belong directly to a section or to a given subsection. You
can have `[section]` if you have `[section "subsection"]`, but you don't
need to.
--
2.31.0.rc2.327.gc8bc67eb22
^ permalink raw reply related [relevance 10%]
* [PATCH] gitweb: Clearly distinguish regexp / exact match searches
2007-08-25 22:18 10% ` [PATCH 2/2] gitweb: Clearly distinguish regexp / exact match searches Petr Baudis
@ 2007-08-26 1:38 10% ` Petr Baudis
0 siblings, 0 replies; 200+ results
From: Petr Baudis @ 2007-08-26 1:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch does a couple of things:
* Makes commit/author/committer search case insensitive
To be consistent with the grep search; I see no convincing
reason for the search to be case sensitive, and you might
get in trouble especially with contributors e.g. from Japan
or France where they sometimes like to uppercase their last
name.
* Makes grep search by default grep for fixed strings
Since we will have a checkbox.
* Introduces 're' checkbox that enables POSIX extended regexp searches
This works for all the search types. The idea comes from Jakub.
It does not make much sense (and is not easy at all) to untangle most of
these changes from each other, thus they all go in a single patch.
Cc: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Sorry, previous version kept git_feed() the user of parse_commits() with
unchanged usage.
---
gitweb/gitweb.perl | 52 ++++++++++++++++++++++++++++++++++------------------
1 files changed, 34 insertions(+), 18 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1ac4523..bdb0b1f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -473,13 +473,15 @@ if (defined $searchtype) {
}
}
+our $search_use_regexp = $cgi->param('sr');
+
our $searchtext = $cgi->param('s');
our $search_regexp;
if (defined $searchtext) {
if (length($searchtext) < 2) {
die_error(undef, "At least two characters are required for search parameter");
}
- $search_regexp = quotemeta $searchtext;
+ $search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
}
# now read PATH_INFO and use it as alternative to parameters
@@ -609,6 +611,7 @@ sub href(%) {
searchtype => "st",
snapshot_format => "sf",
extra_options => "opt",
+ search_use_regexp => "sr",
);
my %mapping = @mapping;
@@ -1937,7 +1940,7 @@ sub parse_commit {
}
sub parse_commits {
- my ($commit_id, $maxcount, $skip, $arg, $filename) = @_;
+ my ($commit_id, $maxcount, $skip, $filename, @args) = @_;
my @cos;
$maxcount ||= 1;
@@ -1947,7 +1950,7 @@ sub parse_commits {
open my $fd, "-|", git_cmd(), "rev-list",
"--header",
- ($arg ? ($arg) : ()),
+ @args,
("--max-count=" . $maxcount),
("--skip=" . $skip),
@extra_options,
@@ -2422,6 +2425,9 @@ EOF
$cgi->sup($cgi->a({-href => href(action=>"search_help")}, "?")) .
" search:\n",
$cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
+ "<span title=\"Extended regular expression\">" .
+ $cgi->checkbox(-name => 'sr', -value => 1, -checked => $search_use_regexp, -label => 're') .
+ "</span>" .
"</div>" .
$cgi->end_form() . "\n";
}
@@ -5095,7 +5101,7 @@ sub git_history {
$ftype = git_get_type($hash);
}
- my @commitlist = parse_commits($hash_base, 101, (100 * $page), "--full-history", $file_name);
+ my @commitlist = parse_commits($hash_base, 101, (100 * $page), $file_name, "--full-history");
my $paging_nav = '';
if ($page > 0) {
@@ -5185,7 +5191,9 @@ sub git_search {
$greptype = "--committer=";
}
$greptype .= $search_regexp;
- my @commitlist = parse_commits($hash, 101, (100 * $page), $greptype);
+ my @commitlist = parse_commits($hash, 101, (100 * $page), undef,
+ $greptype, $search_use_regexp ? ('--extended-regexp') : (),
+ '--regexp-ignore-case');
my $paging_nav = '';
if ($page > 0) {
@@ -5235,8 +5243,9 @@ sub git_search {
my $git_command = git_cmd_str();
my $searchqtext = $searchtext;
$searchqtext =~ s/'/'\\''/;
+ my $pickaxe_flags = $search_use_regexp ? '--pickaxe-regex' : '';
open my $fd, "-|", "$git_command rev-list $hash | " .
- "$git_command diff-tree -r --stdin -S\'$searchqtext\'";
+ "$git_command diff-tree -r --stdin -S\'$searchqtext\' $pickaxe_flags";
undef %co;
my @files;
while (my $line = <$fd>) {
@@ -5299,7 +5308,9 @@ sub git_search {
my $alternate = 1;
my $matches = 0;
$/ = "\n";
- open my $fd, "-|", git_cmd(), 'grep', '-n', '-i', '-E', $searchtext, $co{'tree'};
+ open my $fd, "-|", git_cmd(), 'grep', '-n',
+ $search_use_regexp ? ('-E', '-i') : '-F',
+ $searchtext, $co{'tree'};
my $lastfile = '';
while (my $line = <$fd>) {
chomp $line;
@@ -5329,7 +5340,7 @@ sub git_search {
print "<div class=\"binary\">Binary file</div>\n";
} else {
$ltext = untabify($ltext);
- if ($ltext =~ m/^(.*)($searchtext)(.*)$/i) {
+ if ($ltext =~ m/^(.*)($search_regexp)(.*)$/i) {
$ltext = esc_html($1, -nbsp=>1);
$ltext .= '<span class="match">';
$ltext .= esc_html($2, -nbsp=>1);
@@ -5364,27 +5375,31 @@ sub git_search_help {
git_header_html();
git_print_page_nav('','', $hash,$hash,$hash);
print <<EOT;
+<p><strong>Pattern</strong> is by default a normal string that is matched precisely (but without
+regard to case, except in the case of pickaxe). However, when you check the <em>re</em> checkbox,
+the pattern entered is recognized as the POSIX extended
+<a href="http://en.wikipedia.org/wiki/Regular_expression">regular expression</a> (also case
+insensitive).</p>
<dl>
<dt><b>commit</b></dt>
-<dd>The commit messages and authorship information will be scanned for the given string.</dd>
+<dd>The commit messages and authorship information will be scanned for the given pattern.</dd>
EOT
my ($have_grep) = gitweb_check_feature('grep');
if ($have_grep) {
print <<EOT;
<dt><b>grep</b></dt>
<dd>All files in the currently selected tree (HEAD unless you are explicitly browsing
- a different one) are searched for the given
-<a href="http://en.wikipedia.org/wiki/Regular_expression">regular expression</a>
-(POSIX extended) and the matches are listed. On large
-trees, this search can take a while and put some strain on the server, so please use it with
-some consideration.</dd>
+ a different one) are searched for the given pattern. On large trees, this search can take
+a while and put some strain on the server, so please use it with some consideration. Note that
+due to git-grep peculiarity, currently if regexp mode is turned off, the matches are
+case-sensitive.</dd>
EOT
}
print <<EOT;
<dt><b>author</b></dt>
-<dd>Name and e-mail of the change author and date of birth of the patch will be scanned for the given string.</dd>
+<dd>Name and e-mail of the change author and date of birth of the patch will be scanned for the given pattern.</dd>
<dt><b>committer</b></dt>
-<dd>Name and e-mail of the committer and date of commit will be scanned for the given string.</dd>
+<dd>Name and e-mail of the committer and date of commit will be scanned for the given pattern.</dd>
EOT
my ($have_pickaxe) = gitweb_check_feature('pickaxe');
if ($have_pickaxe) {
@@ -5392,7 +5407,8 @@ EOT
<dt><b>pickaxe</b></dt>
<dd>All commits that caused the string to appear or disappear from any file (changes that
added, removed or "modified" the string) will be listed. This search can take a while and
-takes a lot of strain on the server, so please use it wisely.</dd>
+takes a lot of strain on the server, so please use it wisely. Note that since you may be
+interested even in changes just changing the case as well, this search is case sensitive.</dd>
EOT
}
print "</dl>\n";
@@ -5443,7 +5459,7 @@ sub git_feed {
# log/feed of current (HEAD) branch, log of given branch, history of file/directory
my $head = $hash || 'HEAD';
- my @commitlist = parse_commits($head, 150, 0, undef, $file_name);
+ my @commitlist = parse_commits($head, 150, 0, $file_name);
my %latest_commit;
my %latest_date;
^ permalink raw reply related [relevance 10%]
* Re: git cvsimport and case-insensitive config
@ 2010-03-30 17:29 10% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2010-03-30 17:29 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> git cvsimport looks for cvsimport.* single-letter keys that match the
> command-line option (e.g. cvsimport.r for -r). However, since there are some
> single-letter options which only differ by case (a vs A, r vs R) if you set
> either you get annoying messages (and potentially also odd results, although
> I haven't come across these yet).
Ouch.
The only sensible solution in the longer term is to eventually rename them
to spell them out e.g. cvsimport.remote vs cvsimport.userevisionmap.
The transition cost would be the same for either approach.
(1) Introduce long options for cvsimport; the code already uses
Getopt::Long, so this shouldn't be too bad.
(2) Add case-sensitive variant of "git config -l" that shows the config
variable names in the original case.
(3) Upon startup, use "git config -l -f $GIT_DIR/config" to check for
historical short name (e.g. "cvsimport.a" or "cvsimport.A"). If
there are, map them to longer name, remove the short keys and write
the conversion back to the configuration file. You might want to do
the same for "$HOME/.gitconfig" as well.
(4) Then the rest of the code can stay the same.
Step (2) may look like this. Note that I made this "list with case"
hidden and inaccessible on purpose, as this is primarily to write a tool
to recover from mistakes like this.
builtin/config.c | 10 +++++++++-
cache.h | 1 +
config.c | 12 +++++++++---
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index 4bc46b1..3684c3a 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -41,6 +41,7 @@ static int end_null;
#define ACTION_SET_ALL (1<<12)
#define ACTION_GET_COLOR (1<<13)
#define ACTION_GET_COLORBOOL (1<<14)
+#define ACTION_LIST_KEYS_WITH_CASE (1<<15)
#define TYPE_BOOL (1<<0)
#define TYPE_INT (1<<1)
@@ -73,6 +74,11 @@ static struct option builtin_config_options[] = {
OPT_BIT(0, "path", &types, "value is a path (file or directory name)", TYPE_PATH),
OPT_GROUP("Other"),
OPT_BOOLEAN('z', "null", &end_null, "terminate values with NUL byte"),
+ {
+ OPTION_BIT, 0, "list-keys-with-case", &actions,
+ NULL, "list for conversion", PARSE_OPT_NOARG|PARSE_OPT_HIDDEN,
+ NULL, ACTION_LIST_KEYS_WITH_CASE,
+ },
OPT_END(),
};
@@ -397,7 +403,9 @@ int cmd_config(int argc, const char **argv, const char *unused_prefix)
usage_with_options(builtin_config_usage, builtin_config_options);
}
- if (actions == ACTION_LIST) {
+ if (actions == ACTION_LIST || actions == ACTION_LIST_KEYS_WITH_CASE) {
+ if (actions == ACTION_LIST_KEYS_WITH_CASE)
+ config_return_keys_with_case = 1;
check_argc(argc, 0, 0);
if (git_config(show_all_config, NULL) < 0) {
if (config_exclusive_filename)
diff --git a/cache.h b/cache.h
index 6dcb100..4320288 100644
--- a/cache.h
+++ b/cache.h
@@ -953,6 +953,7 @@ extern int git_config_system(void);
extern int git_config_global(void);
extern int config_error_nonbool(const char *);
extern const char *config_exclusive_filename;
+extern int config_return_keys_with_case;
#define MAX_GITNAME (1000)
extern char git_default_email[MAX_GITNAME];
diff --git a/config.c b/config.c
index 6963fbe..c548cec 100644
--- a/config.c
+++ b/config.c
@@ -17,6 +17,11 @@ static int config_file_eof;
static int zlib_compression_seen;
const char *config_exclusive_filename = NULL;
+/*
+ * only used for config --list-case-sensitive-keys for recovering
+ * from mistakes.
+ */
+int config_return_keys_with_case;
static int get_next_char(void)
{
@@ -123,7 +128,7 @@ static int get_value(config_fn_t fn, void *data, char *name, unsigned int len)
break;
if (!iskeychar(c))
break;
- name[len++] = tolower(c);
+ name[len++] = config_return_keys_with_case ? c : tolower(c);
if (len >= MAXNAME)
return -1;
}
@@ -193,7 +198,8 @@ static int get_base_var(char *name)
return -1;
if (baselen > MAXNAME / 2)
return -1;
- name[baselen++] = tolower(c);
+ name[baselen++] = config_return_keys_with_case
+ ? c : tolower(c);
}
}
@@ -246,7 +252,7 @@ static int git_parse_file(config_fn_t fn, void *data)
}
if (!isalpha(c))
break;
- var[baselen] = tolower(c);
+ var[baselen] = config_return_keys_with_case ? c : tolower(c);
if (get_value(fn, data, var, baselen+1) < 0)
break;
}
^ permalink raw reply related [relevance 10%]
* [PATCH 3/3] gitweb: Clearly distinguish regexp / exact match searches
@ 2007-05-19 0:13 10% ` Petr Baudis
0 siblings, 0 replies; 200+ results
From: Petr Baudis @ 2007-05-19 0:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski, Petr Baudis
This patch does a couple of things:
* Makes commit/author/committer search case insensitive
To be consistent with the grep search; I see no convincing
reason for the search to be case sensitive, and you might
get in trouble especially with contributors e.g. from Japan
or France where they sometimes like to uppercase their last
name.
* Makes grep search by default grep for fixed strings
Since we will have a checkbox.
* Introduces 're' checkbox that enables POSIX extended regexp searches
This works for all the search types. The idea comes from Jakub.
It does not make much sense (and is not easy at all) to untangle most of
these changes from each other, thus they all go in a single patch.
Cc: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 50 +++++++++++++++++++++++++++++++++-----------------
1 files changed, 33 insertions(+), 17 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4ccb4e3..846392e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -401,13 +401,15 @@ if (defined $searchtype) {
}
}
+our $search_use_regexp = $cgi->param('sr');
+
our $searchtext = $cgi->param('s');
our $search_regexp;
if (defined $searchtext) {
if (length($searchtext) < 2) {
die_error(undef, "At least two characters are required for search parameter");
}
- $search_regexp = quotemeta $searchtext;
+ $search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
}
# now read PATH_INFO and use it as alternative to parameters
@@ -535,6 +537,7 @@ sub href(%) {
order => "o",
searchtext => "s",
searchtype => "st",
+ search_use_regexp => "sr",
);
my %mapping = @mapping;
@@ -1579,7 +1582,7 @@ sub parse_commit {
}
sub parse_commits {
- my ($commit_id, $maxcount, $skip, $arg, $filename) = @_;
+ my ($commit_id, $maxcount, $skip, $filename, @args) = @_;
my @cos;
$maxcount ||= 1;
@@ -1589,7 +1592,7 @@ sub parse_commits {
open my $fd, "-|", git_cmd(), "rev-list",
"--header",
- ($arg ? ($arg) : ()),
+ @args,
("--max-count=" . $maxcount),
("--skip=" . $skip),
$commit_id,
@@ -2007,6 +2010,9 @@ EOF
$cgi->sup($cgi->a({-href => href(action=>"search_help")}, "?")) .
" search:\n",
$cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
+ "<span title=\"Extended regular expression\">" .
+ $cgi->checkbox(-name => 'sr', -value => 1, -checked => $search_use_regexp, -label => 're') .
+ "</span>" .
"</div>" .
$cgi->end_form() . "\n";
}
@@ -4655,7 +4661,7 @@ sub git_history {
$ftype = git_get_type($hash);
}
- my @commitlist = parse_commits($hash_base, 101, (100 * $page), "--full-history", $file_name);
+ my @commitlist = parse_commits($hash_base, 101, (100 * $page), $file_name, "--full-history");
my $paging_nav = '';
if ($page > 0) {
@@ -4745,7 +4751,9 @@ sub git_search {
$greptype = "--committer=";
}
$greptype .= $search_regexp;
- my @commitlist = parse_commits($hash, 101, (100 * $page), $greptype);
+ my @commitlist = parse_commits($hash, 101, (100 * $page), undef,
+ $greptype, $search_use_regexp ? ('--extended-regexp') : (),
+ '--regexp-ignore-case');
my $paging_nav = '';
if ($page > 0) {
@@ -4795,8 +4803,9 @@ sub git_search {
my $git_command = git_cmd_str();
my $searchqtext = $searchtext;
$searchqtext =~ s/'/'\\''/;
+ my $pickaxe_flags = $search_use_regexp ? '--pickaxe-regex' : '';
open my $fd, "-|", "$git_command rev-list $hash | " .
- "$git_command diff-tree -r --stdin -S\'$searchqtext\'";
+ "$git_command diff-tree -r --stdin -S\'$searchqtext\' $pickaxe_flags";
undef %co;
my @files;
while (my $line = <$fd>) {
@@ -4859,7 +4868,9 @@ sub git_search {
my $alternate = 1;
my $matches = 0;
$/ = "\n";
- open my $fd, "-|", git_cmd(), 'grep', '-n', '-i', '-E', $searchtext, $co{'tree'};
+ open my $fd, "-|", git_cmd(), 'grep', '-n',
+ $search_use_regexp ? ('-E', '-i') : '-F',
+ $searchtext, $co{'tree'};
my $lastfile = '';
while (my $line = <$fd>) {
chomp $line;
@@ -4889,7 +4900,7 @@ sub git_search {
print "<div class=\"binary\">Binary file</div>\n";
} else {
$ltext = untabify($ltext);
- if ($ltext =~ m/^(.*)($searchtext)(.*)$/i) {
+ if ($ltext =~ m/^(.*)($search_regexp)(.*)$/i) {
$ltext = esc_html($1, -nbsp=>1);
$ltext .= '<span class="match">';
$ltext .= esc_html($2, -nbsp=>1);
@@ -4924,27 +4935,31 @@ sub git_search_help {
git_header_html();
git_print_page_nav('','', $hash,$hash,$hash);
print <<EOT;
+<p><strong>Pattern</strong> is by default a normal string that is matched precisely (but without
+regard to case, except in the case of pickaxe). However, when you check the <em>re</em> checkbox,
+the pattern entered is recognized as the POSIX extended
+<a href="http://en.wikipedia.org/wiki/Regular_expression">regular expression</a> (also case
+insensitive).</p>
<dl>
<dt><b>commit</b></dt>
-<dd>The commit messages and authorship information will be scanned for the given string.</dd>
+<dd>The commit messages and authorship information will be scanned for the given pattern.</dd>
EOT
my ($have_grep) = gitweb_check_feature('grep');
if ($have_grep) {
print <<EOT;
<dt><b>grep</b></dt>
<dd>All files in the currently selected tree (HEAD unless you are explicitly browsing
- a different one) are searched for the given
-<a href="http://en.wikipedia.org/wiki/Regular_expression">regular expression</a>
-(POSIX extended) and the matches are listed. On large
-trees, this search can take a while and put some strain on the server, so please use it with
-some consideration.</dd>
+ a different one) are searched for the given pattern. On large trees, this search can take
+a while and put some strain on the server, so please use it with some consideration. Note that
+due to git-grep peculiarity, currently if regexp mode is turned off, the matches are
+case-sensitive.</dd>
EOT
}
print <<EOT;
<dt><b>author</b></dt>
-<dd>Name and e-mail of the change author and date of birth of the patch will be scanned for the given string.</dd>
+<dd>Name and e-mail of the change author and date of birth of the patch will be scanned for the given pattern.</dd>
<dt><b>committer</b></dt>
-<dd>Name and e-mail of the committer and date of commit will be scanned for the given string.</dd>
+<dd>Name and e-mail of the committer and date of commit will be scanned for the given pattern.</dd>
EOT
my ($have_pickaxe) = gitweb_check_feature('pickaxe');
if ($have_pickaxe) {
@@ -4952,7 +4967,8 @@ EOT
<dt><b>pickaxe</b></dt>
<dd>All commits that caused the string to appear or disappear from any file (changes that
added, removed or "modified" the string) will be listed. This search can take a while and
-takes a lot of strain on the server, so please use it wisely.</dd>
+takes a lot of strain on the server, so please use it wisely. Note that since you may be
+interested even in changes just changing the case as well, this search is case sensitive.</dd>
EOT
}
print "</dl>\n";
^ permalink raw reply related [relevance 10%]
* [PATCH 2/2] gitweb: Clearly distinguish regexp / exact match searches
@ 2007-08-25 22:18 10% ` Petr Baudis
2007-08-26 1:38 10% ` [PATCH] " Petr Baudis
0 siblings, 1 reply; 200+ results
From: Petr Baudis @ 2007-08-25 22:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch does a couple of things:
* Makes commit/author/committer search case insensitive
To be consistent with the grep search; I see no convincing
reason for the search to be case sensitive, and you might
get in trouble especially with contributors e.g. from Japan
or France where they sometimes like to uppercase their last
name.
* Makes grep search by default grep for fixed strings
Since we will have a checkbox.
* Introduces 're' checkbox that enables POSIX extended regexp searches
This works for all the search types. The idea comes from Jakub.
It does not make much sense (and is not easy at all) to untangle most of
these changes from each other, thus they all go in a single patch.
Cc: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 50 +++++++++++++++++++++++++++++++++-----------------
1 files changed, 33 insertions(+), 17 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1ac4523..f7b5b4c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -473,13 +473,15 @@ if (defined $searchtype) {
}
}
+our $search_use_regexp = $cgi->param('sr');
+
our $searchtext = $cgi->param('s');
our $search_regexp;
if (defined $searchtext) {
if (length($searchtext) < 2) {
die_error(undef, "At least two characters are required for search parameter");
}
- $search_regexp = quotemeta $searchtext;
+ $search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
}
# now read PATH_INFO and use it as alternative to parameters
@@ -609,6 +611,7 @@ sub href(%) {
searchtype => "st",
snapshot_format => "sf",
extra_options => "opt",
+ search_use_regexp => "sr",
);
my %mapping = @mapping;
@@ -1937,7 +1940,7 @@ sub parse_commit {
}
sub parse_commits {
- my ($commit_id, $maxcount, $skip, $arg, $filename) = @_;
+ my ($commit_id, $maxcount, $skip, $filename, @args) = @_;
my @cos;
$maxcount ||= 1;
@@ -1947,7 +1950,7 @@ sub parse_commits {
open my $fd, "-|", git_cmd(), "rev-list",
"--header",
- ($arg ? ($arg) : ()),
+ @args,
("--max-count=" . $maxcount),
("--skip=" . $skip),
@extra_options,
@@ -2422,6 +2425,9 @@ EOF
$cgi->sup($cgi->a({-href => href(action=>"search_help")}, "?")) .
" search:\n",
$cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
+ "<span title=\"Extended regular expression\">" .
+ $cgi->checkbox(-name => 'sr', -value => 1, -checked => $search_use_regexp, -label => 're') .
+ "</span>" .
"</div>" .
$cgi->end_form() . "\n";
}
@@ -5095,7 +5101,7 @@ sub git_history {
$ftype = git_get_type($hash);
}
- my @commitlist = parse_commits($hash_base, 101, (100 * $page), "--full-history", $file_name);
+ my @commitlist = parse_commits($hash_base, 101, (100 * $page), $file_name, "--full-history");
my $paging_nav = '';
if ($page > 0) {
@@ -5185,7 +5191,9 @@ sub git_search {
$greptype = "--committer=";
}
$greptype .= $search_regexp;
- my @commitlist = parse_commits($hash, 101, (100 * $page), $greptype);
+ my @commitlist = parse_commits($hash, 101, (100 * $page), undef,
+ $greptype, $search_use_regexp ? ('--extended-regexp') : (),
+ '--regexp-ignore-case');
my $paging_nav = '';
if ($page > 0) {
@@ -5235,8 +5243,9 @@ sub git_search {
my $git_command = git_cmd_str();
my $searchqtext = $searchtext;
$searchqtext =~ s/'/'\\''/;
+ my $pickaxe_flags = $search_use_regexp ? '--pickaxe-regex' : '';
open my $fd, "-|", "$git_command rev-list $hash | " .
- "$git_command diff-tree -r --stdin -S\'$searchqtext\'";
+ "$git_command diff-tree -r --stdin -S\'$searchqtext\' $pickaxe_flags";
undef %co;
my @files;
while (my $line = <$fd>) {
@@ -5299,7 +5308,9 @@ sub git_search {
my $alternate = 1;
my $matches = 0;
$/ = "\n";
- open my $fd, "-|", git_cmd(), 'grep', '-n', '-i', '-E', $searchtext, $co{'tree'};
+ open my $fd, "-|", git_cmd(), 'grep', '-n',
+ $search_use_regexp ? ('-E', '-i') : '-F',
+ $searchtext, $co{'tree'};
my $lastfile = '';
while (my $line = <$fd>) {
chomp $line;
@@ -5329,7 +5340,7 @@ sub git_search {
print "<div class=\"binary\">Binary file</div>\n";
} else {
$ltext = untabify($ltext);
- if ($ltext =~ m/^(.*)($searchtext)(.*)$/i) {
+ if ($ltext =~ m/^(.*)($search_regexp)(.*)$/i) {
$ltext = esc_html($1, -nbsp=>1);
$ltext .= '<span class="match">';
$ltext .= esc_html($2, -nbsp=>1);
@@ -5364,27 +5375,31 @@ sub git_search_help {
git_header_html();
git_print_page_nav('','', $hash,$hash,$hash);
print <<EOT;
+<p><strong>Pattern</strong> is by default a normal string that is matched precisely (but without
+regard to case, except in the case of pickaxe). However, when you check the <em>re</em> checkbox,
+the pattern entered is recognized as the POSIX extended
+<a href="http://en.wikipedia.org/wiki/Regular_expression">regular expression</a> (also case
+insensitive).</p>
<dl>
<dt><b>commit</b></dt>
-<dd>The commit messages and authorship information will be scanned for the given string.</dd>
+<dd>The commit messages and authorship information will be scanned for the given pattern.</dd>
EOT
my ($have_grep) = gitweb_check_feature('grep');
if ($have_grep) {
print <<EOT;
<dt><b>grep</b></dt>
<dd>All files in the currently selected tree (HEAD unless you are explicitly browsing
- a different one) are searched for the given
-<a href="http://en.wikipedia.org/wiki/Regular_expression">regular expression</a>
-(POSIX extended) and the matches are listed. On large
-trees, this search can take a while and put some strain on the server, so please use it with
-some consideration.</dd>
+ a different one) are searched for the given pattern. On large trees, this search can take
+a while and put some strain on the server, so please use it with some consideration. Note that
+due to git-grep peculiarity, currently if regexp mode is turned off, the matches are
+case-sensitive.</dd>
EOT
}
print <<EOT;
<dt><b>author</b></dt>
-<dd>Name and e-mail of the change author and date of birth of the patch will be scanned for the given string.</dd>
+<dd>Name and e-mail of the change author and date of birth of the patch will be scanned for the given pattern.</dd>
<dt><b>committer</b></dt>
-<dd>Name and e-mail of the committer and date of commit will be scanned for the given string.</dd>
+<dd>Name and e-mail of the committer and date of commit will be scanned for the given pattern.</dd>
EOT
my ($have_pickaxe) = gitweb_check_feature('pickaxe');
if ($have_pickaxe) {
@@ -5392,7 +5407,8 @@ EOT
<dt><b>pickaxe</b></dt>
<dd>All commits that caused the string to appear or disappear from any file (changes that
added, removed or "modified" the string) will be listed. This search can take a while and
-takes a lot of strain on the server, so please use it wisely.</dd>
+takes a lot of strain on the server, so please use it wisely. Note that since you may be
+interested even in changes just changing the case as well, this search is case sensitive.</dd>
EOT
}
print "</dl>\n";
^ permalink raw reply related [relevance 10%]
* [PATCH 4/4] gitweb: Clearly distinguish regexp / exact match searches
@ 2008-02-26 12:22 11% ` Jakub Narebski
0 siblings, 0 replies; 200+ results
From: Jakub Narebski @ 2008-02-26 12:22 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Petr Baudis, Jakub Narebski
From: Petr Baudis <pasky@ucw.cz>
This patch does a couple of things:
* Makes commit/author/committer search case insensitive
To be consistent with the grep search; I see no convincing
reason for the search to be case sensitive, and you might
get in trouble especially with contributors e.g. from Japan
or France where they sometimes like to uppercase their last
name.
* Makes grep search by default search for fixed strings
Since we will have a checkbox.
* Introduces 're' checkbox that enables POSIX extended regexp searches
This works for all the search types. The idea comes from Jakub.
It does not make much sense (and is not easy at all) to untangle most
of these changes from each other, thus they all go in a single patch.
[jn: Cherry-picked from Pasky's http://repo.or.cz/git/gitweb.git]
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Cherry-picked, and resolved conflict.
gitweb/gitweb.perl | 44 ++++++++++++++++++++++++++++++--------------
1 files changed, 30 insertions(+), 14 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 90cf78e..20dc5d5 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -472,13 +472,15 @@ if (defined $searchtype) {
}
}
+our $search_use_regexp = $cgi->param('sr');
+
our $searchtext = $cgi->param('s');
our $search_regexp;
if (defined $searchtext) {
if (length($searchtext) < 2) {
die_error(undef, "At least two characters are required for search parameter");
}
- $search_regexp = quotemeta $searchtext;
+ $search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
}
# now read PATH_INFO and use it as alternative to parameters
@@ -608,6 +610,7 @@ sub href(%) {
searchtype => "st",
snapshot_format => "sf",
extra_options => "opt",
+ search_use_regexp => "sr",
);
my %mapping = @mapping;
@@ -2584,6 +2587,10 @@ EOF
$cgi->sup($cgi->a({-href => href(action=>"search_help")}, "?")) .
" search:\n",
$cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
+ "<span title=\"Extended regular expression\">" .
+ $cgi->checkbox(-name => 'sr', -value => 1, -label => 're',
+ -checked => $search_use_regexp) .
+ "</span>" .
"</div>" .
$cgi->end_form() . "\n";
}
@@ -5256,7 +5263,8 @@ sub git_search {
}
$greptype .= $searchtext;
my @commitlist = parse_commits($hash, 101, (100 * $page), undef,
- $greptype, '--fixed-strings');
+ $greptype, '--regexp-ignore-case',
+ $search_use_regexp ? '--extended-regexp' : '--fixed-strings');
my $paging_nav = '';
if ($page > 0) {
@@ -5300,8 +5308,9 @@ sub git_search {
my $git_command = git_cmd_str();
my $searchqtext = $searchtext;
$searchqtext =~ s/'/'\\''/;
+ my $pickaxe_flags = $search_use_regexp ? '--pickaxe-regex' : '';
open my $fd, "-|", "$git_command rev-list $hash | " .
- "$git_command diff-tree -r --stdin -S\'$searchqtext\'";
+ "$git_command diff-tree -r --stdin -S\'$searchqtext\' $pickaxe_flags";
undef %co;
my @files;
while (my $line = <$fd>) {
@@ -5365,7 +5374,9 @@ sub git_search {
my $alternate = 1;
my $matches = 0;
$/ = "\n";
- open my $fd, "-|", git_cmd(), 'grep', '-n', '-i', '-E', $searchtext, $co{'tree'};
+ open my $fd, "-|", git_cmd(), 'grep', '-n',
+ $search_use_regexp ? ('-E', '-i') : '-F',
+ $searchtext, $co{'tree'};
my $lastfile = '';
while (my $line = <$fd>) {
chomp $line;
@@ -5395,7 +5406,7 @@ sub git_search {
print "<div class=\"binary\">Binary file</div>\n";
} else {
$ltext = untabify($ltext);
- if ($ltext =~ m/^(.*)($searchtext)(.*)$/i) {
+ if ($ltext =~ m/^(.*)($search_regexp)(.*)$/i) {
$ltext = esc_html($1, -nbsp=>1);
$ltext .= '<span class="match">';
$ltext .= esc_html($2, -nbsp=>1);
@@ -5430,27 +5441,31 @@ sub git_search_help {
git_header_html();
git_print_page_nav('','', $hash,$hash,$hash);
print <<EOT;
+<p><strong>Pattern</strong> is by default a normal string that is matched precisely (but without
+regard to case, except in the case of pickaxe). However, when you check the <em>re</em> checkbox,
+the pattern entered is recognized as the POSIX extended
+<a href="http://en.wikipedia.org/wiki/Regular_expression">regular expression</a> (also case
+insensitive).</p>
<dl>
<dt><b>commit</b></dt>
-<dd>The commit messages and authorship information will be scanned for the given string.</dd>
+<dd>The commit messages and authorship information will be scanned for the given pattern.</dd>
EOT
my ($have_grep) = gitweb_check_feature('grep');
if ($have_grep) {
print <<EOT;
<dt><b>grep</b></dt>
<dd>All files in the currently selected tree (HEAD unless you are explicitly browsing
- a different one) are searched for the given
-<a href="http://en.wikipedia.org/wiki/Regular_expression">regular expression</a>
-(POSIX extended) and the matches are listed. On large
-trees, this search can take a while and put some strain on the server, so please use it with
-some consideration.</dd>
+ a different one) are searched for the given pattern. On large trees, this search can take
+a while and put some strain on the server, so please use it with some consideration. Note that
+due to git-grep peculiarity, currently if regexp mode is turned off, the matches are
+case-sensitive.</dd>
EOT
}
print <<EOT;
<dt><b>author</b></dt>
-<dd>Name and e-mail of the change author and date of birth of the patch will be scanned for the given string.</dd>
+<dd>Name and e-mail of the change author and date of birth of the patch will be scanned for the given pattern.</dd>
<dt><b>committer</b></dt>
-<dd>Name and e-mail of the committer and date of commit will be scanned for the given string.</dd>
+<dd>Name and e-mail of the committer and date of commit will be scanned for the given pattern.</dd>
EOT
my ($have_pickaxe) = gitweb_check_feature('pickaxe');
if ($have_pickaxe) {
@@ -5458,7 +5473,8 @@ EOT
<dt><b>pickaxe</b></dt>
<dd>All commits that caused the string to appear or disappear from any file (changes that
added, removed or "modified" the string) will be listed. This search can take a while and
-takes a lot of strain on the server, so please use it wisely.</dd>
+takes a lot of strain on the server, so please use it wisely. Note that since you may be
+interested even in changes just changing the case as well, this search is case sensitive.</dd>
EOT
}
print "</dl>\n";
--
1.5.4.2
^ permalink raw reply related [relevance 11%]
* [PATCH v3 3/3] apply: support case-only renames in case-insensitive filesystems
@ 2023-05-28 9:59 11% ` Tao Klerks via GitGitGadget
0 siblings, 0 replies; 200+ results
From: Tao Klerks via GitGitGadget @ 2023-05-28 9:59 UTC (permalink / raw)
To: git; +Cc: Tao Klerks, Junio C Hamano, Johannes Schindelin, Tao Klerks,
Tao Klerks
From: Tao Klerks <tao@klerks.biz>
"git apply" checks, when validating a patch, to ensure that any files
being added aren't already in the worktree.
When this check runs on a case-only rename, in a case-insensitive
filesystem, this leads to a false positive - the command fails with an
error like:
error: File1: already exists in working directory
There is a mechanism to ensure that "seemingly conflicting" files are
handled correctly - for example overlapping rename pairs or swaps -
this mechanism treats renames as add/remove pairs, and would end up
treating a case-only rename as a "self-swap"... Except it does not
account for case-insensitive filesystems yet.
Because the index is inherently case-sensitive even on a
case-insensitive filesystem, we actually need this mechanism to
handle both requirements, lest we fail to account for conflicting
files only in the index.
Fix the "rename chain" existence exemption mechanism to account for
case-insensitive config, fixing case-only-rename-handling as a
"self-swap" and also fixing less-common "case-insensitive rename
pairs" when config core.ignorecase is set, but keep the index checks
file-sensitive.
Also add test cases around these behaviors - verifying that conflicting
file conditions are still caught correctly, including case-only
conflicts on case-sensitive filesystems, and edge cases around
case-sensitive index behaviors on a case-insensitive filesystem.
Signed-off-by: Tao Klerks <tao@klerks.biz>
---
apply.c | 81 ++++++++++++++++------
apply.h | 5 +-
t/t4142-apply-icase.sh | 154 +++++++++++++++++++++++++++++++++++++----
3 files changed, 207 insertions(+), 33 deletions(-)
diff --git a/apply.c b/apply.c
index 6212ab3a1b3..a2e2f6b531d 100644
--- a/apply.c
+++ b/apply.c
@@ -113,7 +113,9 @@ int init_apply_state(struct apply_state *state,
state->ws_error_action = warn_on_ws_error;
state->ws_ignore_action = ignore_ws_none;
state->linenr = 1;
- string_list_init_nodup(&state->fn_table);
+ string_list_init_nodup(&state->fs_fn_table);
+ state->fs_fn_table.cmp = fspathcmp;
+ string_list_init_nodup(&state->index_fn_table);
string_list_init_nodup(&state->limit_by_name);
strset_init(&state->removed_symlinks);
strset_init(&state->kept_symlinks);
@@ -134,7 +136,10 @@ void clear_apply_state(struct apply_state *state)
strset_clear(&state->kept_symlinks);
strbuf_release(&state->root);
- /* &state->fn_table is cleared at the end of apply_patch() */
+ /*
+ * &state->fs_fn_table and &state->index_fn_table are cleared at the
+ * end of apply_patch()
+ */
}
static void mute_routine(const char *msg UNUSED, va_list params UNUSED)
@@ -3294,14 +3299,28 @@ static int read_file_or_gitlink(const struct cache_entry *ce, struct strbuf *buf
return read_blob_object(buf, &ce->oid, ce->ce_mode);
}
-static struct patch *in_fn_table(struct apply_state *state, const char *name)
+static struct patch *in_fs_fn_table(struct apply_state *state, const char *name)
{
struct string_list_item *item;
if (!name)
return NULL;
- item = string_list_lookup(&state->fn_table, name);
+ item = string_list_lookup(&state->fs_fn_table, name);
+ if (item)
+ return (struct patch *)item->util;
+
+ return NULL;
+}
+
+static struct patch *in_index_fn_table(struct apply_state *state, const char *name)
+{
+ struct string_list_item *item;
+
+ if (!name)
+ return NULL;
+
+ item = string_list_lookup(&state->index_fn_table, name);
if (item)
return (struct patch *)item->util;
@@ -3333,7 +3352,7 @@ static int was_deleted(struct patch *patch)
return patch == PATH_WAS_DELETED;
}
-static void add_to_fn_table(struct apply_state *state, struct patch *patch)
+static void add_to_fn_tables(struct apply_state *state, struct patch *patch)
{
struct string_list_item *item;
@@ -3343,7 +3362,9 @@ static void add_to_fn_table(struct apply_state *state, struct patch *patch)
* file creations and copies
*/
if (patch->new_name) {
- item = string_list_insert(&state->fn_table, patch->new_name);
+ item = string_list_insert(&state->fs_fn_table, patch->new_name);
+ item->util = patch;
+ item = string_list_insert(&state->index_fn_table, patch->new_name);
item->util = patch;
}
@@ -3352,7 +3373,9 @@ static void add_to_fn_table(struct apply_state *state, struct patch *patch)
* later chunks shouldn't patch old names
*/
if ((patch->new_name == NULL) || (patch->is_rename)) {
- item = string_list_insert(&state->fn_table, patch->old_name);
+ item = string_list_insert(&state->fs_fn_table, patch->old_name);
+ item->util = PATH_WAS_DELETED;
+ item = string_list_insert(&state->index_fn_table, patch->old_name);
item->util = PATH_WAS_DELETED;
}
}
@@ -3365,7 +3388,9 @@ static void prepare_fn_table(struct apply_state *state, struct patch *patch)
while (patch) {
if ((patch->new_name == NULL) || (patch->is_rename)) {
struct string_list_item *item;
- item = string_list_insert(&state->fn_table, patch->old_name);
+ item = string_list_insert(&state->fs_fn_table, patch->old_name);
+ item->util = PATH_TO_BE_DELETED;
+ item = string_list_insert(&state->index_fn_table, patch->old_name);
item->util = PATH_TO_BE_DELETED;
}
patch = patch->next;
@@ -3395,7 +3420,7 @@ static struct patch *previous_patch(struct apply_state *state,
if (patch->is_copy || patch->is_rename)
return NULL; /* "git" patches do not depend on the order */
- previous = in_fn_table(state, patch->old_name);
+ previous = in_index_fn_table(state, patch->old_name);
if (!previous)
return NULL;
@@ -3706,7 +3731,7 @@ static int apply_data(struct apply_state *state, struct patch *patch,
}
patch->result = image.buf;
patch->resultsize = image.len;
- add_to_fn_table(state, patch);
+ add_to_fn_tables(state, patch);
free(image.line_allocated);
if (0 < patch->is_delete && patch->resultsize)
@@ -3805,11 +3830,12 @@ static int check_preimage(struct apply_state *state,
static int check_to_create(struct apply_state *state,
const char *new_name,
- int ok_if_exists)
+ int ok_if_exists_in_fs,
+ int ok_if_exists_in_index)
{
struct stat nst;
- if (state->check_index && (!ok_if_exists || !state->cached)) {
+ if (state->check_index && (!ok_if_exists_in_index || !state->cached)) {
int pos;
pos = index_name_pos(state->repo->index, new_name, strlen(new_name));
@@ -3817,7 +3843,7 @@ static int check_to_create(struct apply_state *state,
struct cache_entry *ce = state->repo->index->cache[pos];
/* allow ITA, as they do not yet exist in the index */
- if (!ok_if_exists && !(ce->ce_flags & CE_INTENT_TO_ADD))
+ if (!ok_if_exists_in_index && !(ce->ce_flags & CE_INTENT_TO_ADD))
return EXISTS_IN_INDEX;
/* ITA entries can never match working tree files */
@@ -3830,7 +3856,7 @@ static int check_to_create(struct apply_state *state,
return 0;
if (!lstat(new_name, &nst)) {
- if (S_ISDIR(nst.st_mode) || ok_if_exists)
+ if (S_ISDIR(nst.st_mode) || ok_if_exists_in_fs)
return 0;
/*
* A leading component of new_name might be a symlink
@@ -3940,7 +3966,8 @@ static int check_patch(struct apply_state *state, struct patch *patch)
const char *name = old_name ? old_name : new_name;
struct cache_entry *ce = NULL;
struct patch *tpatch;
- int ok_if_exists;
+ int ok_if_exists_in_fs;
+ int ok_if_exists_in_index;
int status;
patch->rejected = 1; /* we will drop this after we succeed */
@@ -3963,16 +3990,29 @@ static int check_patch(struct apply_state *state, struct patch *patch)
* B; ask to_be_deleted() about the later rename. Removal of
* B and rename from A to B is handled the same way by asking
* was_deleted().
+ *
+ * These exemptions account for the core.ignorecase config -
+ * a file that differs only by case is also considered "deleted"
+ * if git is configured to ignore case. This means a case-only
+ * rename, in a case-insensitive filesystem, is treated here as
+ * a "self-swap" or mode change.
*/
- if ((tpatch = in_fn_table(state, new_name)) &&
+ if ((tpatch = in_fs_fn_table(state, new_name)) &&
+ (was_deleted(tpatch) || to_be_deleted(tpatch)))
+ ok_if_exists_in_fs = 1;
+ else
+ ok_if_exists_in_fs = 0;
+
+ if ((tpatch = in_index_fn_table(state, new_name)) &&
(was_deleted(tpatch) || to_be_deleted(tpatch)))
- ok_if_exists = 1;
+ ok_if_exists_in_index = 1;
else
- ok_if_exists = 0;
+ ok_if_exists_in_index = 0;
if (new_name &&
((0 < patch->is_new) || patch->is_rename || patch->is_copy)) {
- int err = check_to_create(state, new_name, ok_if_exists);
+ int err = check_to_create(state, new_name, ok_if_exists_in_fs,
+ ok_if_exists_in_index);
if (err && state->threeway) {
patch->direct_to_threeway = 1;
@@ -4870,7 +4910,8 @@ static int apply_patch(struct apply_state *state,
end:
free_patch_list(list);
strbuf_release(&buf);
- string_list_clear(&state->fn_table, 0);
+ string_list_clear(&state->fs_fn_table, 0);
+ string_list_clear(&state->index_fn_table, 0);
return res;
}
diff --git a/apply.h b/apply.h
index 7cd38b1443c..a1419672507 100644
--- a/apply.h
+++ b/apply.h
@@ -95,8 +95,11 @@ struct apply_state {
/*
* Records filenames that have been touched, in order to handle
* the case where more than one patches touch the same file.
+ * Two separate structures because with ignorecase, one of them
+ * needs to be case-insensitive and the other not.
*/
- struct string_list fn_table;
+ struct string_list fs_fn_table;
+ struct string_list index_fn_table;
/*
* This is to save reporting routines before using
diff --git a/t/t4142-apply-icase.sh b/t/t4142-apply-icase.sh
index 17eb023a437..1c785133d16 100755
--- a/t/t4142-apply-icase.sh
+++ b/t/t4142-apply-icase.sh
@@ -30,7 +30,16 @@ test_expect_success setup '
git diff HEAD HEAD^ -- file1 >deletion-patch &&
git diff --cached HEAD -- file1 file2 >rename-file1-to-file2-patch &&
git diff --cached HEAD -- file1 File1 >rename-file1-to-File1-patch &&
- git diff --cached HEAD -- file0 >modify-file0-patch
+ git diff --cached HEAD -- file0 >modify-file0-patch &&
+
+ # then set up for swap
+ git reset --hard current &&
+ test_commit "swappable" file3 "different content for file3" swappable &&
+ file3blob=$(git rev-parse :file3) &&
+ git rm --cached file1 file3 &&
+ git update-index --add --cacheinfo 100644,$file1blob,File3 &&
+ git update-index --add --cacheinfo 100644,$file3blob,File1 &&
+ git diff --cached HEAD -- file1 file3 File1 File3 >swap-file1-and-file3-to-File3-and-File1-patch
'
# Basic creation, deletion, modification and renaming.
@@ -53,7 +62,7 @@ test_expect_success 'creation and deletion' '
test_must_fail git rev-parse --verify :file1
'
-test_expect_success 'modificaiton' '
+test_expect_success 'modification (index-only)' '
# start at "initial" with file0 only
git reset --hard initial &&
@@ -70,7 +79,7 @@ test_expect_success 'modificaiton' '
test_cmp_rev :file0 "$file0blob"
'
-test_expect_success 'rename file1 to file2' '
+test_expect_success 'rename file1 to file2 (index-only)' '
# start from file0 and file1
git reset --hard current &&
@@ -91,7 +100,7 @@ test_expect_success 'rename file1 to file2' '
test_cmp_rev :file1 "$file1blob"
'
-test_expect_success 'rename file1 to file2' '
+test_expect_success 'rename file1 to File1 (index-only)' '
# start from file0 and file1
git reset --hard current &&
@@ -112,17 +121,138 @@ test_expect_success 'rename file1 to file2' '
test_cmp_rev :file1 "$file1blob"
'
-# We may want to add tests with working tree here, without "--cached" and
-# with and without "--index" here. For example, should modify-file0-patch
-# apply cleanly if we have File0 with $file0blob in the index and the working
-# tree if core.icase is set?
+# involve filesystem on renames
+test_expect_success 'rename file1 to File1 (with ignorecase, working tree)' '
+ # start from file0 and file1
+ git reset --hard current &&
+
+ # do the same with ignorecase
+ git -c core.ignorecase=true apply --index rename-file1-to-File1-patch &&
+ test_must_fail git rev-parse --verify :file1 &&
+ test_cmp_rev :File1 "$file1blob" &&
+ git -c core.ignorecase=true apply --index -R rename-file1-to-File1-patch &&
+ test_must_fail git rev-parse --verify :File1 &&
+ test_cmp_rev :file1 "$file1blob"
+'
+
+test_expect_success CASE_INSENSITIVE_FS 'rename file1 to File1 (without ignorecase, case-insensitive FS)' '
+ # start from file0 and file1
+ git reset --hard current &&
+
+ # rename file1 to File1 without ignorecase (fails as expected)
+ test_must_fail git -c core.ignorecase=false apply --index rename-file1-to-File1-patch &&
+ git rev-parse --verify :file1 &&
+ test_cmp_rev :file1 "$file1blob"
+'
+
+test_expect_success !CASE_INSENSITIVE_FS 'rename file1 to File1 (without ignorecase, case-sensitive FS)' '
+ # start from file0 and file1
+ git reset --hard current &&
+
+ # rename file1 to File1 without ignorecase
+ git -c core.ignorecase=false apply --index rename-file1-to-File1-patch &&
+ test_must_fail git rev-parse --verify :file1 &&
+ test_cmp_rev :File1 "$file1blob" &&
+ git -c core.ignorecase=false apply --index -R rename-file1-to-File1-patch &&
+ test_must_fail git rev-parse --verify :File1 &&
+ test_cmp_rev :file1 "$file1blob"
+'
+
+test_expect_success 'rename file1 to file2 with working tree conflict' '
+ # start from file0 and file1, and file2 untracked
+ git reset --hard current &&
+ test_when_finished "rm file2" &&
+ touch file2 &&
+
+ # rename file1 to file2 with conflict
+ test_must_fail git -c core.ignorecase=false apply --index rename-file1-to-file2-patch &&
+ git rev-parse --verify :file1 &&
+ test_cmp_rev :file1 "$file1blob" &&
-test_expect_success CASE_INSENSITIVE_FS 'a test only for icase fs' '
- : sample
+ # do the same with ignorecase
+ test_must_fail git -c core.ignorecase=true apply --index rename-file1-to-file2-patch &&
+ git rev-parse --verify :file1 &&
+ test_cmp_rev :file1 "$file1blob"
'
-test_expect_success !CASE_INSENSITIVE_FS 'a test only for !icase fs' '
- : sample
+test_expect_success 'rename file1 to file2 with case-insensitive conflict (index-only - ignorecase disabled)' '
+ # start from file0 and file1, and File2 in index
+ git reset --hard current &&
+ git update-index --add --cacheinfo 100644,$file3blob,File2 &&
+
+ # rename file1 to file2 without ignorecase
+ git -c core.ignorecase=false apply --cached rename-file1-to-file2-patch &&
+ test_must_fail git rev-parse --verify :file1 &&
+ test_cmp_rev :file2 "$file1blob" &&
+ git -c core.ignorecase=false apply --cached -R rename-file1-to-file2-patch &&
+ test_must_fail git rev-parse --verify :file2 &&
+ test_cmp_rev :file1 "$file1blob" &&
+ test_cmp_rev :File2 "$file3blob"
+'
+
+test_expect_failure 'rename file1 to file2 with case-insensitive conflict (index-only - ignorecase enabled)' '
+ # start from file0 and file1, and File2 in index
+ git reset --hard current &&
+ git update-index --add --cacheinfo 100644,$file3blob,File2 &&
+
+ # rename file1 to file2 with ignorecase, with a "File2" conflicting file in place - expect failure.
+ # instead of failure, we get success with "File1" and "file1" both existing in the index, despite
+ # the ignorecase configuration.
+ test_must_fail git -c core.ignorecase=true apply --cached rename-file1-to-file2-patch &&
+ git rev-parse --verify :file1 &&
+ test_cmp_rev :file1 "$file1blob" &&
+ test_cmp_rev :File2 "$file3blob"
+'
+
+test_expect_success 'rename file1 to File1 with case-sensitive conflict (index-only)' '
+ # start from file0 and file1, and File1 in index
+ git reset --hard current &&
+ git update-index --add --cacheinfo 100644,$file3blob,File1 &&
+
+ # On a case-insensitive filesystem with core.ignorecase on, a single git
+ # "reset --hard" will actually leave things wrong because of the
+ # index-to-working-tree discrepancy - see "reset --hard handles
+ # index-only case-insensitive duplicate" under t7104-reset-hard.sh.
+ # We are creating this unexpected state, so we should explicitly queue
+ # an extra reset. If reset ever starts to handle this case, this will
+ # become unnecessary but also not harmful.
+ test_when_finished "git reset --hard" &&
+
+ # rename file1 to File1 when File1 is already in index (fails with conflict)
+ test_must_fail git -c core.ignorecase=false apply --cached rename-file1-to-File1-patch &&
+ git rev-parse --verify :file1 &&
+ test_cmp_rev :file1 "$file1blob" &&
+ test_cmp_rev :File1 "$file3blob" &&
+
+ # do the same with ignorecase
+ test_must_fail git -c core.ignorecase=true apply --cached rename-file1-to-File1-patch &&
+ git rev-parse --verify :file1 &&
+ test_cmp_rev :file1 "$file1blob" &&
+ test_cmp_rev :File1 "$file3blob"
+'
+
+test_expect_success CASE_INSENSITIVE_FS 'case-insensitive swap - file1 to File2 and file2 to File1 (working tree)' '
+ # start from file0, file1, and file3
+ git reset --hard swappable &&
+
+ # "swap" file1 and file3 to case-insensitive versions without ignorecase on case-insensitive FS (fails as expected)
+ test_must_fail git -c core.ignorecase=false apply --index swap-file1-and-file3-to-File3-and-File1-patch &&
+ git rev-parse --verify :file1 &&
+ git rev-parse --verify :file3 &&
+ test_cmp_rev :file1 "$file1blob" &&
+ test_cmp_rev :file3 "$file3blob" &&
+
+ # do the same with ignorecase
+ git -c core.ignorecase=true apply --index swap-file1-and-file3-to-File3-and-File1-patch &&
+ test_must_fail git rev-parse --verify :file1 &&
+ test_must_fail git rev-parse --verify :file3 &&
+ test_cmp_rev :File3 "$file1blob" &&
+ test_cmp_rev :File1 "$file3blob" &&
+ git -c core.ignorecase=true apply --index -R swap-file1-and-file3-to-File3-and-File1-patch &&
+ test_must_fail git rev-parse --verify :File1 &&
+ test_must_fail git rev-parse --verify :File3 &&
+ test_cmp_rev :file1 "$file1blob" &&
+ test_cmp_rev :file3 "$file3blob"
'
test_done
--
gitgitgadget
^ permalink raw reply related [relevance 11%]
* [PATCH v2 3/3] apply: support case-only renames in case-insensitive filesystems
2022-06-19 16:10 6% ` [PATCH v2 0/3] RFC: " Tao Klerks via GitGitGadget
@ 2022-06-19 16:10 11% ` Tao Klerks via GitGitGadget
1 sibling, 0 replies; 200+ results
From: Tao Klerks via GitGitGadget @ 2022-06-19 16:10 UTC (permalink / raw)
To: git; +Cc: Tao Klerks, Junio C Hamano, Tao Klerks, Tao Klerks
From: Tao Klerks <tao@klerks.biz>
"git apply" checks, when validating a patch, to ensure that any files
being added aren't already in the worktree.
When this check runs on a case-only rename, in a case-insensitive
filesystem, this leads to a false positive - the command fails with an
error like:
error: File1: already exists in working directory
There is a mechanism to ensure that "seemingly conflicting" files are
handled correctly - for example overlapping rename pairs or swaps -
this mechanism treats renames as add/remove pairs, and would end up
treating a case-only rename as a "self-swap"... Except it does not
account for case-insensitive filesystems yet.
Because the index is inherently case-sensitive even on a
case-insensitive filesystem, we actually need this mechanism to be
handle both requirements, lest we fail to account for conflicting
files only in the index.
Fix the "rename chain" existence exemption mechanism to account for
case-insensitive config, fixing case-only-rename-handling as a
"self-swap" and also fixing less-common "case-insensitive rename
pairs" when config core.ignorecase is set, but keep the index checks
file-sensitive.
Also add test cases around these behaviors - verifying that conflicting
file conditions are still caught correctly, including case-only
conflicts on case-sensitive filesystems, and edge cases around
case-sensitive index behaviors on a case-insensitive filesystem.
Signed-off-by: Tao Klerks <tao@klerks.biz>
---
apply.c | 81 ++++++++++++++++------
apply.h | 5 +-
t/t4141-apply-icase.sh | 154 +++++++++++++++++++++++++++++++++++++----
3 files changed, 207 insertions(+), 33 deletions(-)
diff --git a/apply.c b/apply.c
index 2b7cd930efa..2bd59b63edd 100644
--- a/apply.c
+++ b/apply.c
@@ -101,7 +101,9 @@ int init_apply_state(struct apply_state *state,
state->ws_error_action = warn_on_ws_error;
state->ws_ignore_action = ignore_ws_none;
state->linenr = 1;
- string_list_init_nodup(&state->fn_table);
+ string_list_init_nodup(&state->fs_fn_table);
+ state->fs_fn_table.cmp = fspathcmp;
+ string_list_init_nodup(&state->index_fn_table);
string_list_init_nodup(&state->limit_by_name);
strset_init(&state->removed_symlinks);
strset_init(&state->kept_symlinks);
@@ -122,7 +124,10 @@ void clear_apply_state(struct apply_state *state)
strset_clear(&state->kept_symlinks);
strbuf_release(&state->root);
- /* &state->fn_table is cleared at the end of apply_patch() */
+ /*
+ * &state->fs_fn_table and &state->index_fn_table are cleared at the
+ * end of apply_patch()
+ */
}
static void mute_routine(const char *msg, va_list params)
@@ -3270,14 +3275,28 @@ static int read_file_or_gitlink(const struct cache_entry *ce, struct strbuf *buf
return read_blob_object(buf, &ce->oid, ce->ce_mode);
}
-static struct patch *in_fn_table(struct apply_state *state, const char *name)
+static struct patch *in_fs_fn_table(struct apply_state *state, const char *name)
{
struct string_list_item *item;
if (!name)
return NULL;
- item = string_list_lookup(&state->fn_table, name);
+ item = string_list_lookup(&state->fs_fn_table, name);
+ if (item)
+ return (struct patch *)item->util;
+
+ return NULL;
+}
+
+static struct patch *in_index_fn_table(struct apply_state *state, const char *name)
+{
+ struct string_list_item *item;
+
+ if (!name)
+ return NULL;
+
+ item = string_list_lookup(&state->index_fn_table, name);
if (item)
return (struct patch *)item->util;
@@ -3309,7 +3328,7 @@ static int was_deleted(struct patch *patch)
return patch == PATH_WAS_DELETED;
}
-static void add_to_fn_table(struct apply_state *state, struct patch *patch)
+static void add_to_fn_tables(struct apply_state *state, struct patch *patch)
{
struct string_list_item *item;
@@ -3319,7 +3338,9 @@ static void add_to_fn_table(struct apply_state *state, struct patch *patch)
* file creations and copies
*/
if (patch->new_name) {
- item = string_list_insert(&state->fn_table, patch->new_name);
+ item = string_list_insert(&state->fs_fn_table, patch->new_name);
+ item->util = patch;
+ item = string_list_insert(&state->index_fn_table, patch->new_name);
item->util = patch;
}
@@ -3328,7 +3349,9 @@ static void add_to_fn_table(struct apply_state *state, struct patch *patch)
* later chunks shouldn't patch old names
*/
if ((patch->new_name == NULL) || (patch->is_rename)) {
- item = string_list_insert(&state->fn_table, patch->old_name);
+ item = string_list_insert(&state->fs_fn_table, patch->old_name);
+ item->util = PATH_WAS_DELETED;
+ item = string_list_insert(&state->index_fn_table, patch->old_name);
item->util = PATH_WAS_DELETED;
}
}
@@ -3341,7 +3364,9 @@ static void prepare_fn_table(struct apply_state *state, struct patch *patch)
while (patch) {
if ((patch->new_name == NULL) || (patch->is_rename)) {
struct string_list_item *item;
- item = string_list_insert(&state->fn_table, patch->old_name);
+ item = string_list_insert(&state->fs_fn_table, patch->old_name);
+ item->util = PATH_TO_BE_DELETED;
+ item = string_list_insert(&state->index_fn_table, patch->old_name);
item->util = PATH_TO_BE_DELETED;
}
patch = patch->next;
@@ -3371,7 +3396,7 @@ static struct patch *previous_patch(struct apply_state *state,
if (patch->is_copy || patch->is_rename)
return NULL; /* "git" patches do not depend on the order */
- previous = in_fn_table(state, patch->old_name);
+ previous = in_index_fn_table(state, patch->old_name);
if (!previous)
return NULL;
@@ -3681,7 +3706,7 @@ static int apply_data(struct apply_state *state, struct patch *patch,
}
patch->result = image.buf;
patch->resultsize = image.len;
- add_to_fn_table(state, patch);
+ add_to_fn_tables(state, patch);
free(image.line_allocated);
if (0 < patch->is_delete && patch->resultsize)
@@ -3780,11 +3805,12 @@ static int check_preimage(struct apply_state *state,
static int check_to_create(struct apply_state *state,
const char *new_name,
- int ok_if_exists)
+ int ok_if_exists_in_fs,
+ int ok_if_exists_in_index)
{
struct stat nst;
- if (state->check_index && (!ok_if_exists || !state->cached)) {
+ if (state->check_index && (!ok_if_exists_in_index || !state->cached)) {
int pos;
pos = index_name_pos(state->repo->index, new_name, strlen(new_name));
@@ -3792,7 +3818,7 @@ static int check_to_create(struct apply_state *state,
struct cache_entry *ce = state->repo->index->cache[pos];
/* allow ITA, as they do not yet exist in the index */
- if (!ok_if_exists && !(ce->ce_flags & CE_INTENT_TO_ADD))
+ if (!ok_if_exists_in_index && !(ce->ce_flags & CE_INTENT_TO_ADD))
return EXISTS_IN_INDEX;
/* ITA entries can never match working tree files */
@@ -3805,7 +3831,7 @@ static int check_to_create(struct apply_state *state,
return 0;
if (!lstat(new_name, &nst)) {
- if (S_ISDIR(nst.st_mode) || ok_if_exists)
+ if (S_ISDIR(nst.st_mode) || ok_if_exists_in_fs)
return 0;
/*
* A leading component of new_name might be a symlink
@@ -3915,7 +3941,8 @@ static int check_patch(struct apply_state *state, struct patch *patch)
const char *name = old_name ? old_name : new_name;
struct cache_entry *ce = NULL;
struct patch *tpatch;
- int ok_if_exists;
+ int ok_if_exists_in_fs;
+ int ok_if_exists_in_index;
int status;
patch->rejected = 1; /* we will drop this after we succeed */
@@ -3938,16 +3965,29 @@ static int check_patch(struct apply_state *state, struct patch *patch)
* B; ask to_be_deleted() about the later rename. Removal of
* B and rename from A to B is handled the same way by asking
* was_deleted().
+ *
+ * These exemptions account for the core.ignorecase config -
+ * a file that differs only by case is also considered "deleted"
+ * if git is configured to ignore case. This means a case-only
+ * rename, in a case-insensitive filesystem, is treated here as
+ * a "self-swap" or mode change.
*/
- if ((tpatch = in_fn_table(state, new_name)) &&
+ if ((tpatch = in_fs_fn_table(state, new_name)) &&
+ (was_deleted(tpatch) || to_be_deleted(tpatch)))
+ ok_if_exists_in_fs = 1;
+ else
+ ok_if_exists_in_fs = 0;
+
+ if ((tpatch = in_index_fn_table(state, new_name)) &&
(was_deleted(tpatch) || to_be_deleted(tpatch)))
- ok_if_exists = 1;
+ ok_if_exists_in_index = 1;
else
- ok_if_exists = 0;
+ ok_if_exists_in_index = 0;
if (new_name &&
((0 < patch->is_new) || patch->is_rename || patch->is_copy)) {
- int err = check_to_create(state, new_name, ok_if_exists);
+ int err = check_to_create(state, new_name, ok_if_exists_in_fs,
+ ok_if_exists_in_index);
if (err && state->threeway) {
patch->direct_to_threeway = 1;
@@ -4808,7 +4848,8 @@ static int apply_patch(struct apply_state *state,
end:
free_patch_list(list);
strbuf_release(&buf);
- string_list_clear(&state->fn_table, 0);
+ string_list_clear(&state->fs_fn_table, 0);
+ string_list_clear(&state->index_fn_table, 0);
return res;
}
diff --git a/apply.h b/apply.h
index b9f18ce87d1..b520ce8c40a 100644
--- a/apply.h
+++ b/apply.h
@@ -95,8 +95,11 @@ struct apply_state {
/*
* Records filenames that have been touched, in order to handle
* the case where more than one patches touch the same file.
+ * Two separate structures because with ignorecase, one of them
+ * needs to be case-insensitive and the other not.
*/
- struct string_list fn_table;
+ struct string_list fs_fn_table;
+ struct string_list index_fn_table;
/*
* This is to save reporting routines before using
diff --git a/t/t4141-apply-icase.sh b/t/t4141-apply-icase.sh
index 17eb023a437..1c785133d16 100755
--- a/t/t4141-apply-icase.sh
+++ b/t/t4141-apply-icase.sh
@@ -30,7 +30,16 @@ test_expect_success setup '
git diff HEAD HEAD^ -- file1 >deletion-patch &&
git diff --cached HEAD -- file1 file2 >rename-file1-to-file2-patch &&
git diff --cached HEAD -- file1 File1 >rename-file1-to-File1-patch &&
- git diff --cached HEAD -- file0 >modify-file0-patch
+ git diff --cached HEAD -- file0 >modify-file0-patch &&
+
+ # then set up for swap
+ git reset --hard current &&
+ test_commit "swappable" file3 "different content for file3" swappable &&
+ file3blob=$(git rev-parse :file3) &&
+ git rm --cached file1 file3 &&
+ git update-index --add --cacheinfo 100644,$file1blob,File3 &&
+ git update-index --add --cacheinfo 100644,$file3blob,File1 &&
+ git diff --cached HEAD -- file1 file3 File1 File3 >swap-file1-and-file3-to-File3-and-File1-patch
'
# Basic creation, deletion, modification and renaming.
@@ -53,7 +62,7 @@ test_expect_success 'creation and deletion' '
test_must_fail git rev-parse --verify :file1
'
-test_expect_success 'modificaiton' '
+test_expect_success 'modification (index-only)' '
# start at "initial" with file0 only
git reset --hard initial &&
@@ -70,7 +79,7 @@ test_expect_success 'modificaiton' '
test_cmp_rev :file0 "$file0blob"
'
-test_expect_success 'rename file1 to file2' '
+test_expect_success 'rename file1 to file2 (index-only)' '
# start from file0 and file1
git reset --hard current &&
@@ -91,7 +100,7 @@ test_expect_success 'rename file1 to file2' '
test_cmp_rev :file1 "$file1blob"
'
-test_expect_success 'rename file1 to file2' '
+test_expect_success 'rename file1 to File1 (index-only)' '
# start from file0 and file1
git reset --hard current &&
@@ -112,17 +121,138 @@ test_expect_success 'rename file1 to file2' '
test_cmp_rev :file1 "$file1blob"
'
-# We may want to add tests with working tree here, without "--cached" and
-# with and without "--index" here. For example, should modify-file0-patch
-# apply cleanly if we have File0 with $file0blob in the index and the working
-# tree if core.icase is set?
+# involve filesystem on renames
+test_expect_success 'rename file1 to File1 (with ignorecase, working tree)' '
+ # start from file0 and file1
+ git reset --hard current &&
+
+ # do the same with ignorecase
+ git -c core.ignorecase=true apply --index rename-file1-to-File1-patch &&
+ test_must_fail git rev-parse --verify :file1 &&
+ test_cmp_rev :File1 "$file1blob" &&
+ git -c core.ignorecase=true apply --index -R rename-file1-to-File1-patch &&
+ test_must_fail git rev-parse --verify :File1 &&
+ test_cmp_rev :file1 "$file1blob"
+'
+
+test_expect_success CASE_INSENSITIVE_FS 'rename file1 to File1 (without ignorecase, case-insensitive FS)' '
+ # start from file0 and file1
+ git reset --hard current &&
+
+ # rename file1 to File1 without ignorecase (fails as expected)
+ test_must_fail git -c core.ignorecase=false apply --index rename-file1-to-File1-patch &&
+ git rev-parse --verify :file1 &&
+ test_cmp_rev :file1 "$file1blob"
+'
+
+test_expect_success !CASE_INSENSITIVE_FS 'rename file1 to File1 (without ignorecase, case-sensitive FS)' '
+ # start from file0 and file1
+ git reset --hard current &&
+
+ # rename file1 to File1 without ignorecase
+ git -c core.ignorecase=false apply --index rename-file1-to-File1-patch &&
+ test_must_fail git rev-parse --verify :file1 &&
+ test_cmp_rev :File1 "$file1blob" &&
+ git -c core.ignorecase=false apply --index -R rename-file1-to-File1-patch &&
+ test_must_fail git rev-parse --verify :File1 &&
+ test_cmp_rev :file1 "$file1blob"
+'
+
+test_expect_success 'rename file1 to file2 with working tree conflict' '
+ # start from file0 and file1, and file2 untracked
+ git reset --hard current &&
+ test_when_finished "rm file2" &&
+ touch file2 &&
+
+ # rename file1 to file2 with conflict
+ test_must_fail git -c core.ignorecase=false apply --index rename-file1-to-file2-patch &&
+ git rev-parse --verify :file1 &&
+ test_cmp_rev :file1 "$file1blob" &&
-test_expect_success CASE_INSENSITIVE_FS 'a test only for icase fs' '
- : sample
+ # do the same with ignorecase
+ test_must_fail git -c core.ignorecase=true apply --index rename-file1-to-file2-patch &&
+ git rev-parse --verify :file1 &&
+ test_cmp_rev :file1 "$file1blob"
'
-test_expect_success !CASE_INSENSITIVE_FS 'a test only for !icase fs' '
- : sample
+test_expect_success 'rename file1 to file2 with case-insensitive conflict (index-only - ignorecase disabled)' '
+ # start from file0 and file1, and File2 in index
+ git reset --hard current &&
+ git update-index --add --cacheinfo 100644,$file3blob,File2 &&
+
+ # rename file1 to file2 without ignorecase
+ git -c core.ignorecase=false apply --cached rename-file1-to-file2-patch &&
+ test_must_fail git rev-parse --verify :file1 &&
+ test_cmp_rev :file2 "$file1blob" &&
+ git -c core.ignorecase=false apply --cached -R rename-file1-to-file2-patch &&
+ test_must_fail git rev-parse --verify :file2 &&
+ test_cmp_rev :file1 "$file1blob" &&
+ test_cmp_rev :File2 "$file3blob"
+'
+
+test_expect_failure 'rename file1 to file2 with case-insensitive conflict (index-only - ignorecase enabled)' '
+ # start from file0 and file1, and File2 in index
+ git reset --hard current &&
+ git update-index --add --cacheinfo 100644,$file3blob,File2 &&
+
+ # rename file1 to file2 with ignorecase, with a "File2" conflicting file in place - expect failure.
+ # instead of failure, we get success with "File1" and "file1" both existing in the index, despite
+ # the ignorecase configuration.
+ test_must_fail git -c core.ignorecase=true apply --cached rename-file1-to-file2-patch &&
+ git rev-parse --verify :file1 &&
+ test_cmp_rev :file1 "$file1blob" &&
+ test_cmp_rev :File2 "$file3blob"
+'
+
+test_expect_success 'rename file1 to File1 with case-sensitive conflict (index-only)' '
+ # start from file0 and file1, and File1 in index
+ git reset --hard current &&
+ git update-index --add --cacheinfo 100644,$file3blob,File1 &&
+
+ # On a case-insensitive filesystem with core.ignorecase on, a single git
+ # "reset --hard" will actually leave things wrong because of the
+ # index-to-working-tree discrepancy - see "reset --hard handles
+ # index-only case-insensitive duplicate" under t7104-reset-hard.sh.
+ # We are creating this unexpected state, so we should explicitly queue
+ # an extra reset. If reset ever starts to handle this case, this will
+ # become unnecessary but also not harmful.
+ test_when_finished "git reset --hard" &&
+
+ # rename file1 to File1 when File1 is already in index (fails with conflict)
+ test_must_fail git -c core.ignorecase=false apply --cached rename-file1-to-File1-patch &&
+ git rev-parse --verify :file1 &&
+ test_cmp_rev :file1 "$file1blob" &&
+ test_cmp_rev :File1 "$file3blob" &&
+
+ # do the same with ignorecase
+ test_must_fail git -c core.ignorecase=true apply --cached rename-file1-to-File1-patch &&
+ git rev-parse --verify :file1 &&
+ test_cmp_rev :file1 "$file1blob" &&
+ test_cmp_rev :File1 "$file3blob"
+'
+
+test_expect_success CASE_INSENSITIVE_FS 'case-insensitive swap - file1 to File2 and file2 to File1 (working tree)' '
+ # start from file0, file1, and file3
+ git reset --hard swappable &&
+
+ # "swap" file1 and file3 to case-insensitive versions without ignorecase on case-insensitive FS (fails as expected)
+ test_must_fail git -c core.ignorecase=false apply --index swap-file1-and-file3-to-File3-and-File1-patch &&
+ git rev-parse --verify :file1 &&
+ git rev-parse --verify :file3 &&
+ test_cmp_rev :file1 "$file1blob" &&
+ test_cmp_rev :file3 "$file3blob" &&
+
+ # do the same with ignorecase
+ git -c core.ignorecase=true apply --index swap-file1-and-file3-to-File3-and-File1-patch &&
+ test_must_fail git rev-parse --verify :file1 &&
+ test_must_fail git rev-parse --verify :file3 &&
+ test_cmp_rev :File3 "$file1blob" &&
+ test_cmp_rev :File1 "$file3blob" &&
+ git -c core.ignorecase=true apply --index -R swap-file1-and-file3-to-File3-and-File1-patch &&
+ test_must_fail git rev-parse --verify :File1 &&
+ test_must_fail git rev-parse --verify :File3 &&
+ test_cmp_rev :file1 "$file1blob" &&
+ test_cmp_rev :file3 "$file3blob"
'
test_done
--
gitgitgadget
^ permalink raw reply related [relevance 11%]
* Re: [PATCH v2 4/5] mailmap: use case-sensitive comparisons for local-parts and names
2021-01-03 21:18 35% ` [PATCH v2 4/5] mailmap: use case-sensitive comparisons for local-parts and names brian m. carlson
@ 2021-01-04 16:10 11% ` Ævar Arnfjörð Bjarmason
2021-01-06 0:46 8% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2021-01-04 16:10 UTC (permalink / raw)
To: brian m. carlson; +Cc: git, Jeff King, Phillip Wood, Johannes Schindelin
On Sun, Jan 03 2021, brian m. carlson wrote:
[For the purposes of this reply I'm also replying to your commit message
in 3/5, which I think makes things less confusing than two E-Mails]
> Currently, Git always looks up entries in the mailmap in a
> case-insensitive way, both for names and addresses, which is, as
> explained below, suboptimal.
>
> First, for email addresses, RFC 5321 is clear that only domains are case
> insensitive; local-parts (the portion before the at sign) are not. It
> states this:
>
> The local-part of a mailbox MUST BE treated as case sensitive.
> Therefore, SMTP implementations MUST take care to preserve the case of
> mailbox local-parts.
It seems better to quote the part of this where it goes on to say:
However, exploiting the case sensitivity of mailbox local-parts
impedes interoperability and is discouraged. Mailbox domains follow
normal DNS rules and are hence not case sensitive.
And also that RFC 5321 says earlier
"a host that expects to receive mail SHOULD avoid defining mailboxes
where the Local-part requires (or uses) the Quoted-string form or
where the Local-part is case- sensitive. For any purposes that
require generating or comparing Local-parts (e.g., to specific
mailbox names), all quoted forms MUST be treated as equivalent,".
So if we're taking RFC 5321 MUST requirements as something we've got to
do we're still not following it. But as I'll go on to note I think
rationale by RFC 5321 is perhaps not the best thing to do here...
> There exist systems today where local-parts remain case sensitive (and
> this author has one), and as such, it's incorrect for us to case fold
> them in any way. Let's add a failing test that indicates this is a
> problem, while still keeping the test for case-insensitive domains.
I don't really care much about this feature of mailmap, but I'm
struggling a bit to understand this part.
We're not an SMTP server or SMTP server library, so we don't have to
worry about mail mis-routing or whatever.
We just have to worry about cases where you're not all of these people
in one project's commit metadata and/or .mailmap, and thus mailmap rules
would match too generously:
"brian m. carlson" <sandals@crustytoothpaste.net>
"brian m. carlson" <SANDALS@crustytoothpaste.net>
"BRIAN M. CARLSON" <sandals@crustytoothpaste.net>
"BRIAN M. CARLSON" <SANDALS@crustytoothpaste.net>
Is that really plausible? In any case, neither of these two patches make
reference to us already having changed this in the past in 1.6.2 and &
there being reports on the ML about the bug & us changing it back. See
https://lore.kernel.org/git/f182fb1700e8dea15459fd02ced2a6e5797bec99.1238458535u.git.johannes.schindelin@gmx.de/
Maybe we should still do this, but I think for a v3 it makes sense to
summarize that discussion etc.
> Note that it's also incorrect for us to case-fold names because we don't
> guarantee that we're using the locale of the author, and it's impossible
> to case-fold names in a locale-insensitive way. Turkish and Azeri
> contain both a dotted and dotless I, and the uppercase ASCII I folds not
> to the lowercase ASCII I, but to a dotless version, and vice versa with
> the lowercase I. There are many words in Turkish which differ only in
> the dottedness of the I, so it is likely that there are also personal
> names which differ in the same way.
>
> That would be a problem even if our implementation were perfect, which
> it is not. We currently fold only ASCII characters, so this feature has
> never worked correctly for the vast majority of the users on the planet,
> regardless of the locale. For example, on Linux, even in a Spanish
> locale, we don't handle "Simón" properly. Even if we did handle that,
> we'd probably also want to implement Unicode normalization, which we
> don't.
As one of those people, aren't you confusing two things here. I daresay
that almost everyone with a non-ASCII name doesn't have a non-ASCII
E-Mail address, sure some do, but treating those as one and the same
doesn't seem to make sense.
Yes you can have non-ASCII on the LHS of @ in an E-Mail address, it just
seems to me that's very rare.
Do we have known cases where we're making use of this case-insensitive
matching of the *name* part? Showing some of those non-ASCII cases in
the tests in 3/5 would be nice.
> IN general, case-folding text is extremely language- and locale-specific
> and requires intimacy with the spelling and grammar of the language in
> question and careful attention to the Unicode details in order to
> produce a result that is meaningful to humans and conforms with
> linguistic and societal norms.
>
> Because we do not have any of the required context with a plain personal
> name, we cannot hope to possibly case-fold personal names correctly. We
> should stop trying to do so and just treat them as a series of bytes, so
> let's add a test that we don't case-fold personal names as well.
[... end <snip> of commit 3/5 ...]
> RFC 5321 is clear that the local-part of an email address (the part
> before the at sign) is case sensitive, and this has been the case since
> the original RFC 821. It directs us that "the local-part MUST be
> interpreted and assigned semantics only by the host specified in the
> domain part of the address."
>
> Since we are not that party, it's not correct for us to compare them
> case insensitively. However, we do still want to compare the domain
> parts case insensitively, so let's add a helper that downcases the
> domain and then compare byte by byte.
>
> Similarly, it's not possible for us to correctly case-fold text in a
> locale-insensitive way, so our handling of personal names has also been
> subject to bugs. Additionally, we've never handled non-ASCII characters
> correctly, which means that our previous comparisons really only worked
> well for a fraction of the people on the planet. Since our code wasn't
> right and it's basically impossible to compare personal names without
> regard to case, let's also switch our matching of names to be byte by
> byte.
I'm still undecided about whether we should be calling strcasecmp() to
begin with, but I don't really find this convincing. Just because we
only support brian@ and BRIAN@ being the same but not ævar@ and ÆVAR@ we
should break the existing behavior for everyone?
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> ---
> mailmap.c | 27 ++++++++++++++++++++++++---
> t/t4203-mailmap.sh | 4 ++--
> 2 files changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/mailmap.c b/mailmap.c
> index d3287b409a..5c52dbb7e0 100644
> --- a/mailmap.c
> +++ b/mailmap.c
> @@ -64,7 +64,22 @@ static void free_mailmap_entry(void *p, const char *s)
> */
> static int namemap_cmp(const char *a, const char *b)
> {
> - return strcasecmp(a, b);
> + return strcmp(a, b);
> +}
It seems to me if we're not going to use strcasecmp() we can get rid of
this whole namemap_cmp() function. See the comment just above it &
de2f95ebed2 (mailmap: work around implementations with pure inline
strcasecmp, 2013-09-12). I.e. we had a wrapper function here just
because we were using strcasecmp().
> +/*
> + * Lowercases the domain (and only the domain) part of an email address. The
> + * local-part, which is defined by RFC 5321 to be case sensitive, is not
> + * affected.
> + */
> +static char *lowercase_email(char *s)
> +{
> + char *end = strchrnul(s, '@');
Speaking of pedantic readings of RFC 5321, aren't we closing the door
here to proper DQUOTE handling? I.e. the local-part containing a @
within quotes :)
^ permalink raw reply [relevance 11%]
* [PATCH] Documentation fixes in git-config
@ 2011-01-19 14:14 11% ` Libor Pechacek
0 siblings, 1 reply; 200+ results
From: Libor Pechacek @ 2011-01-19 14:14 UTC (permalink / raw)
To: git; +Cc: Jeff King
Variable names must start with an alphabetic character, regexp config key
matching is case sensitive.
Signed-off-by: Libor Pechacek <lpechacek@suse.cz>
Cc: Jeff King <peff@peff.net>
---
Documentation/config.txt | 12 +++++++-----
Documentation/git-config.txt | 4 +++-
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ff7c225..0f23bc7 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -12,8 +12,9 @@ The configuration variables are used by both the git plumbing
and the porcelains. The variables are divided into sections, wherein
the fully qualified variable name of the variable itself is the last
dot-separated segment and the section name is everything before the last
-dot. The variable names are case-insensitive and only alphanumeric
-characters are allowed. Some variables may appear multiple times.
+dot. The variable names are case-insensitive, only alphanumeric
+characters and '-' are allowed and must start with an alphabetic character.
+Some variables may appear multiple times.
Syntax
~~~~~~
@@ -53,9 +54,10 @@ All the other lines (and the remainder of the line after the section
header) are recognized as setting variables, in the form
'name = value'. If there is no equal sign on the line, the entire line
is taken as 'name' and the variable is recognized as boolean "true".
-The variable names are case-insensitive and only alphanumeric
-characters and `-` are allowed. There can be more than one value
-for a given variable; we say then that variable is multivalued.
+The variable names are case-insensitive, only alphanumeric
+characters and `-` are allowed and must start with an alphabetic character.
+There can be more than one value for a given variable; we say then that
+variable is multivalued.
Leading and trailing whitespace in a variable value is discarded.
Internal whitespace within a variable value is retained verbatim.
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 543dd64..6966ed6 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -84,7 +84,9 @@ OPTIONS
--get-regexp::
Like --get-all, but interprets the name as a regular expression.
- Also outputs the key names.
+ Regular expression matching is case sensitive in all parts of the key,
+ therefore make sure your pattern matches lower case letters in section
+ and variable names. Also outputs the key names.
--global::
For writing options: write to global ~/.gitconfig file rather than
--
1.7.4.rc2.2.gb4f4f
^ permalink raw reply related [relevance 11%]
* [PATCH v2 1/2] completion: add optional ignore-case when matching refs
@ 2022-11-21 0:26 12% ` Alison Winters via GitGitGadget
0 siblings, 0 replies; 200+ results
From: Alison Winters via GitGitGadget @ 2022-11-21 0:26 UTC (permalink / raw)
To: git; +Cc: Taylor Blau, SZEDER Gábor, Alison Winters, Alison Winters
From: Alison Winters <alisonatwork@outlook.com>
If GIT_COMPLETION_IGNORE_CASE is set, --ignore-case will be added to
git for-each-ref calls so that refs can be matched case insensitively,
even when running on case sensitive filesystems.
Signed-off-by: Alison Winters <alisonatwork@outlook.com>
---
contrib/completion/git-completion.bash | 12 ++++++++++++
t/t9902-completion.sh | 15 +++++++++++++++
2 files changed, 27 insertions(+)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index ba5c395d2d8..7dcf4b63562 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -58,6 +58,12 @@
#
# When set to "1" suggest all options, including options which are
# typically hidden (e.g. '--allow-empty' for 'git commit').
+#
+# GIT_COMPLETION_IGNORE_CASE
+#
+# When set, uses for-each-ref '--ignore-case' to find refs that match
+# case insensitively, even on systems with case sensitive file systems
+# (e.g., completing tag name "FOO" on "git checkout f<TAB>").
case "$COMP_WORDBREAKS" in
*:*) : great ;;
@@ -646,6 +652,7 @@ __git_heads ()
local pfx="${1-}" cur_="${2-}" sfx="${3-}"
__git for-each-ref --format="${pfx//\%/%%}%(refname:strip=2)$sfx" \
+ ${GIT_COMPLETION_IGNORE_CASE+--ignore-case} \
"refs/heads/$cur_*" "refs/heads/$cur_*/**"
}
@@ -659,6 +666,7 @@ __git_remote_heads ()
local pfx="${1-}" cur_="${2-}" sfx="${3-}"
__git for-each-ref --format="${pfx//\%/%%}%(refname:strip=2)$sfx" \
+ ${GIT_COMPLETION_IGNORE_CASE+--ignore-case} \
"refs/remotes/$cur_*" "refs/remotes/$cur_*/**"
}
@@ -669,6 +677,7 @@ __git_tags ()
local pfx="${1-}" cur_="${2-}" sfx="${3-}"
__git for-each-ref --format="${pfx//\%/%%}%(refname:strip=2)$sfx" \
+ ${GIT_COMPLETION_IGNORE_CASE+--ignore-case} \
"refs/tags/$cur_*" "refs/tags/$cur_*/**"
}
@@ -688,6 +697,7 @@ __git_dwim_remote_heads ()
# but only output if the branch name is unique
__git for-each-ref --format="$fer_pfx%(refname:strip=3)$sfx" \
--sort="refname:strip=3" \
+ ${GIT_COMPLETION_IGNORE_CASE+--ignore-case} \
"refs/remotes/*/$cur_*" "refs/remotes/*/$cur_*/**" | \
uniq -u
}
@@ -765,6 +775,7 @@ __git_refs ()
;;
esac
__git_dir="$dir" __git for-each-ref --format="$fer_pfx%($format)$sfx" \
+ ${GIT_COMPLETION_IGNORE_CASE+--ignore-case} \
"${refs[@]}"
if [ -n "$track" ]; then
__git_dwim_remote_heads "$pfx" "$match" "$sfx"
@@ -787,6 +798,7 @@ __git_refs ()
$match*) echo "${pfx}HEAD$sfx" ;;
esac
__git for-each-ref --format="$fer_pfx%(refname:strip=3)$sfx" \
+ ${GIT_COMPLETION_IGNORE_CASE+--ignore-case} \
"refs/remotes/$remote/$match*" \
"refs/remotes/$remote/$match*/**"
else
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 43de868b800..d89d0a93a2a 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -2255,6 +2255,21 @@ test_expect_success 'checkout completes ref names' '
EOF
'
+test_expect_success 'checkout does not match ref names of a different case' '
+ test_completion "git checkout M" ""
+'
+
+test_expect_success 'checkout matches case insensitively with GIT_COMPLETION_IGNORE_CASE' '
+ (
+ GIT_COMPLETION_IGNORE_CASE=1 &&
+ test_completion "git checkout M" <<-\EOF
+ main Z
+ mybranch Z
+ mytag Z
+ EOF
+ )
+'
+
test_expect_success 'git -C <path> checkout uses the right repo' '
test_completion "git -C subdir -C subsubdir -C .. -C ../otherrepo checkout b" <<-\EOF
branch-in-other Z
--
gitgitgadget
^ permalink raw reply related [relevance 12%]
* [JGIT PATCH 10/12] Match config subsection names using case sensitive search
@ 2009-07-21 20:19 12% ` Shawn O. Pearce
2009-07-22 11:11 7% ` Constantine Plotnikov
0 siblings, 1 reply; 200+ results
From: Shawn O. Pearce @ 2009-07-21 20:19 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
The subsection name is case sensitive, and should be matched as such.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/lib/Config.java | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Config.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Config.java
index e379c37..974ffea 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Config.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Config.java
@@ -4,6 +4,7 @@
* Copyright (C) 2008, Shawn O. Pearce <spearce@spearce.org>
* Copyright (C) 2008, Thad Hughes <thadh@thad.corp.google.com>
* Copyright (C) 2009, JetBrains s.r.o.
+ * Copyright (C) 2009, Google, Inc.
*
* All rights reserved.
*
@@ -1024,17 +1025,25 @@ private static String readValue(final BufferedReader r, boolean quote,
boolean match(final String aSection, final String aSubsection,
final String aKey) {
- return eq(section, aSection) && eq(subsection, aSubsection)
- && eq(name, aKey);
+ return eqIgnoreCase(section, aSection)
+ && eqSameCase(subsection, aSubsection)
+ && eqIgnoreCase(name, aKey);
}
- private static boolean eq(final String a, final String b) {
+ private static boolean eqIgnoreCase(final String a, final String b) {
if (a == null && b == null)
return true;
if (a == null || b == null)
return false;
return a.equalsIgnoreCase(b);
}
- }
-}
\ No newline at end of file
+ private static boolean eqSameCase(final String a, final String b) {
+ if (a == null && b == null)
+ return true;
+ if (a == null || b == null)
+ return false;
+ return a.equals(b);
+ }
+ }
+}
--
1.6.4.rc1.186.g60aa0c
^ permalink raw reply related [relevance 12%]
* [PATCH 0/3] config: fix case sensitive subsection names on writing
2018-07-30 12:49 14% ` Johannes Schindelin
@ 2018-07-30 23:04 12% ` Stefan Beller
2018-07-30 23:04 24% ` [PATCH 2/3] " Stefan Beller
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Stefan Beller @ 2018-07-30 23:04 UTC (permalink / raw)
To: johannes.schindelin; +Cc: bmwill, git, gitster, peff, sbeller
On Mon, Jul 30, 2018 at 5:50 AM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Thanks for the patch!
>
> The only thing that was not clear to me from the patch and from the commit
> message was: the first part *is* case insensitive, right?
right.
> How does the
> patch take care of that? Is it relying on `git_config_parse_key()` to do
> that? If so, I don't see it...
It turns out it doesn't quite do that;
The parsing code takes the old notation into account and translates any
[V.A]
r = ...
into a lower cased "v.a." for ease of comparison. That happens in
get_base_var, which would call further into get_extended_base_var
if the new notation is used.
The code in store_aux_event however is written without the consideration
of the old code and has no way of knowing the capitalization of the
section or subsection (which were forced to lowercase in the old
dot notation).
So either we have to do some major surgery, or the old notation gets
some regression while fixing the new notation.
> > I would still hold the judgment on "all except only this one"
> > myself. That's a bit too early in my mind.
>
> Agreed. I seem to remember that I had a funny problem "in the reverse",
> where http.<url>.* is case-sensitive, but in an unexpected way: if the URL
> contains upper-case characters, the <url> part of the config key needs to
> be downcased, otherwise the setting won't be picked up.
I wrote some patches that show more of what is happening.
I suggest to drop the last patch and only take the first two,
or if we decide we want to be fully correct, we'd want to discuss
how to make it happen. (where to store the information that we are
dealing with an old notation)
Thanks,
Stefan
Stefan Beller (3):
t1300: document current behavior of setting options
config: fix case sensitive subsection names on writing
config: treat section case insensitive in store_aux_event
config.c | 16 ++++++++-
t/t1300-config.sh | 89 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 104 insertions(+), 1 deletion(-)
--
2.18.0.132.g195c49a2227
^ permalink raw reply [relevance 12%]
* [issue?]'git branch -D' case sensitive issue
@ 2016-01-14 7:52 12% 郭腾飞
2016-01-14 11:51 8% ` Torsten Bögershausen
0 siblings, 1 reply; 200+ results
From: 郭腾飞 @ 2016-01-14 7:52 UTC (permalink / raw)
To: git
Hi All,
I encountered some issues when using 'git branch -D'.
It's strange, the command 'git branch -D' is case sensitive.
Here is the operated log.
➜ my-emacs-conf git:(NIce) git branch -avv
* NIce fed5d9c Update js2-mode $ js-beautify.
master fed5d9c [origin/master] Update js2-mode $ js-beautify.
remotes/origin/HEAD -> origin/master
remotes/origin/fake 8ec9cad fake.
remotes/origin/mac13 13ae483 mac pro 13's config.
remotes/origin/master fed5d9c Update js2-mode $ js-beautify.
➜ my-emacs-conf git:(NIce)
➜ my-emacs-conf git:(NIce) git branch -D NIce
error: Cannot delete the branch 'NIce' which you are currently on.
➜ my-emacs-conf git:(NIce)
➜ my-emacs-conf git:(NIce) git branch -D NICe
Deleted branch NICe (was fed5d9c).
➜ my-emacs-conf git:(NIce) ✗ git branch -avv
master fed5d9c [origin/master] Update js2-mode $ js-beautify.
remotes/origin/HEAD -> origin/master
remotes/origin/fake 8ec9cad fake.
remotes/origin/mac13 13ae483 mac pro 13's config.
remotes/origin/master fed5d9c Update js2-mode $ js-beautify.
Hope someone can give me a hint.
➜ my-emacs-conf git:(NIce) ✗ git --version
git version 2.6.3
➜ my-emacs-conf git:(NIce) ✗ sw_vers -productVersion
10.11 OSX
BRs,
terry3
^ permalink raw reply [relevance 12%]
* [PATCH] In perforce, RCS keywords are case-sensitive
@ 2008-07-22 16:48 12% Daniel Barkalow
2008-07-24 7:05 8% ` Simon Hausmann
0 siblings, 1 reply; 200+ results
From: Daniel Barkalow @ 2008-07-22 16:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
At least, this is true in 2007.2, according to the documentation.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
A line of perl with the variable $file in a string followed by a different
variable not in the string, for example, doesn't get mangled by p4 and may
therefore appear in a p4 depot.
I don't know if the "old-style keyword expansion" is case-sensitive,
though, so I'm leaving that alone.
contrib/fast-import/git-p4 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index d8de9f6..1ee612e 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -902,7 +902,7 @@ class P4Sync(Command):
if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k', 'binary+k'):
- text = re.sub(r'(?i)\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$', text)
+ text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$', text)
contents[stat['depotFile']] = text
--
1.5.6.rc2.26.g8c37.dirty
^ permalink raw reply related [relevance 12%]
* [PATCH] apply: support case-only renames in case-insensitive filesystems
@ 2022-06-11 17:03 13% Tao Klerks via GitGitGadget
2022-06-12 23:30 6% ` Junio C Hamano
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Tao Klerks via GitGitGadget @ 2022-06-11 17:03 UTC (permalink / raw)
To: git; +Cc: Tao Klerks, Tao Klerks
From: Tao Klerks <tao@klerks.biz>
"git apply" checks, when validating a patch, to ensure that any files
being added aren't already in the worktree.
When this check runs on a case-only rename, in a case-insensitive
filesystem, this leads to a false positive - the command fails with an
error like:
error: File1: already exists in working directory
Fix this existence check to allow the file to exist, for a case-only
rename when config core.ignorecase is set.
Also add a test for this case, while verifying that conflicting file
conditions are still caught correctly, including case-only conflicts on
case-sensitive filesystems.
Signed-off-by: Tao Klerks <tao@klerks.biz>
---
apply: support case-only renames in case-insensitive filesystems
As suggested recently in thread
CAPMMpojwV+f=z9sgc_GaUOTFBCUVdbrGW8WjatWWmC3WTcsoXw@mail.gmail.com,
proposing a fix to git-apply for case-only renames on case-insensitive
filesystems.
Also including tests to check both the corrected behavior and the
corresponding legitimate errors.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1257%2FTaoK%2Ftao-apply-case-insensitive-renames-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1257/TaoK/tao-apply-case-insensitive-renames-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1257
apply.c | 2 +
t/t4141-apply-case-insensitive-rename.sh | 50 ++++++++++++++++++++++++
2 files changed, 52 insertions(+)
create mode 100755 t/t4141-apply-case-insensitive-rename.sh
diff --git a/apply.c b/apply.c
index 2b7cd930efa..ccba7f90393 100644
--- a/apply.c
+++ b/apply.c
@@ -3942,6 +3942,8 @@ static int check_patch(struct apply_state *state, struct patch *patch)
if ((tpatch = in_fn_table(state, new_name)) &&
(was_deleted(tpatch) || to_be_deleted(tpatch)))
ok_if_exists = 1;
+ else if (ignore_case && !strcasecmp(old_name, new_name))
+ ok_if_exists = 1;
else
ok_if_exists = 0;
diff --git a/t/t4141-apply-case-insensitive-rename.sh b/t/t4141-apply-case-insensitive-rename.sh
new file mode 100755
index 00000000000..6b394252ff8
--- /dev/null
+++ b/t/t4141-apply-case-insensitive-rename.sh
@@ -0,0 +1,50 @@
+#!/bin/sh
+
+test_description='git apply should handle case-only renames on case-insensitive filesystems'
+
+TEST_PASSES_SANITIZE_LEAK=true
+. ./test-lib.sh
+
+# Please note, this test assumes that core.ignorecase is set appropriately for the filesystem,
+# as tested in t0050. Case-only rename conflicts are only tested in case-sensitive filesystems.
+
+if ! test_have_prereq CASE_INSENSITIVE_FS
+then
+ test_set_prereq CASE_SENSITIVE_FS
+ echo nuts
+fi
+
+test_expect_success setup '
+ echo "This is some content in the file." > file1 &&
+ echo "A completely different file." > file2 &&
+ git update-index --add file1 &&
+ git update-index --add file2 &&
+ cat >case_only_rename_patch <<-\EOF
+ diff --git a/file1 b/File1
+ similarity index 100%
+ rename from file1
+ rename to File1
+ EOF
+'
+
+test_expect_success 'refuse to apply rename patch with conflict' '
+ cat >conflict_patch <<-\EOF &&
+ diff --git a/file1 b/file2
+ similarity index 100%
+ rename from file1
+ rename to file2
+ EOF
+ test_must_fail git apply --index conflict_patch
+'
+
+test_expect_success CASE_SENSITIVE_FS 'refuse to apply case-only rename patch with conflict, in case-sensitive FS' '
+ test_when_finished "git mv File1 file2" &&
+ git mv file2 File1 &&
+ test_must_fail git apply --index case_only_rename_patch
+'
+
+test_expect_success 'apply case-only rename patch without conflict' '
+ git apply --index case_only_rename_patch
+'
+
+test_done
base-commit: 1e59178e3f65880188caedb965e70db5ceeb2d64
--
gitgitgadget
^ permalink raw reply related [relevance 13%]
* Re: should config options be treated as case-sensitive?
2018-05-22 12:13 8% ` Ævar Arnfjörð Bjarmason
@ 2018-05-23 1:55 13% ` Junio C Hamano
2018-05-23 7:59 8% ` Robert P. J. Day
2018-05-22 16:33 8% ` Robert P. J. Day
1 sibling, 1 reply; 200+ results
From: Junio C Hamano @ 2018-05-23 1:55 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Robert P. J. Day, Git Mailing list
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> The issues you note about the docs using foo.barbaz instead of
> foo.barBaz should be fixed, but as noted in the "Syntax" section of
> "git-config" we already document that the config keys are all
> case-insensitive. We just like talking about them as foo.barBaz because
> it makes for easier reading.
The first and the last level of configuration variable names are
case insensitive.
I said "first and last", as there are variables with 2-level and
3-level names. "foo.barBaz" is two-level and it is the same
variable as "Foo.barbaz". "remote.origin.url" is three-level, and
it is the same variable as "Remote.origin.URL", but it is not the
same variable as "remote.ORIGIN.url".
If the documention does not make it clear, then we have
documentation bug. As you said, I think we are OK in the sense that
we do say a section or a variable name is icase and a subsection, if
exist, is case sensitive, but there might be a better way to convey
that fact without having the reader read the whole three paragraphs.
^ permalink raw reply [relevance 13%]
* [PATCH 0/3] sh-i18n--envsubst; case-sensitive getenv on Windows
@ 2011-06-06 6:57 13% Johannes Sixt
2011-06-06 7:08 20% ` [PATCH 3/3] Windows: teach getenv to do a case-sensitive search Johannes Sixt
0 siblings, 1 reply; 200+ results
From: Johannes Sixt @ 2011-06-06 6:57 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Junio C Hamano, Git Mailing List
From: Johannes Sixt <j6t@kdbg.org>
Here are the fixes needed on Windows for the ab/i18n-scripts topic.
Johannes Sixt (3):
sh-i18n--envsubst: do not crash when no arguments are given
mingw.c: move definition of mingw_getenv down
Windows: teach getenv to do a case-sensitive search
compat/mingw.c | 47 ++++++++++++++++++++++++++++++++---------------
sh-i18n--envsubst.c | 1 +
2 files changed, 33 insertions(+), 15 deletions(-)
--
1.7.6.rc0.1186.gfb4fd
^ permalink raw reply [relevance 13%]
* Deletion of git repo causes incorrect block count on HFS+ case-sensitive
@ 2013-03-13 18:45 14% Ismail Tabtabai
2013-03-13 22:14 8% ` David Aguilar
0 siblings, 1 reply; 200+ results
From: Ismail Tabtabai @ 2013-03-13 18:45 UTC (permalink / raw)
To: git
Hello,
When I delete a git repo that I have cloned on my machine using 'rm -rf repo-name' I get an incorrect block count when I attempt a Disk Repair.
I am running OS X 10.8.2 on a user installed SSD. The git version is 1.8.1.5.
Checking file systemChecking Journaled HFS Plus volume.
Detected a case-sensitive volume.
Checking extents overflow file.
Checking catalog file.
Incorrect block count for file pack-8c0dc1a398a22c58ea1eba09de3ee9d935ad1ea3.pack
(It should be 4865 instead of 12244)
Incorrect block count for file pack-db61a037ad0e043e801d8ba1db98b1af14d466af.pack
(It should be 5889 instead of 12245)
Incorrect block count for file pack-db61a037ad0e043e801d8ba1db98b1af14d466af.pack
(It should be 6220 instead of 12245)
Incorrect block count for file pack-286c1444bc32ee2ed0af1d15070e0e31f22ba0a8.pack
(It should be 7937 instead of 12246)
Checking multi-linked files.
Checking catalog hierarchy.
Checking extended attributes file.
Checking volume bitmap.
Volume bitmap needs minor repair for orphaned blocks
Checking volume information.
Invalid volume free block count
(It should be 85306183 instead of 85282114)
Repairing volume.
Rechecking volume.
Checking Journaled HFS Plus volume.
Detected a case-sensitive volume.
Checking extents overflow file.
Checking catalog file.
Checking multi-linked files.
Checking catalog hierarchy.
Checking extended attributes file.
Checking volume bitmap.
Checking volume information.
The volume avicenna was repaired successfully.
Volume repair complete.Updating boot support partitions for the volume as required.
^ permalink raw reply [relevance 14%]
* Re: [PATCH] config: fix case sensitive subsection names on writing
2018-07-28 1:37 8% ` Junio C Hamano
@ 2018-07-30 12:49 14% ` Johannes Schindelin
2018-07-30 23:04 12% ` [PATCH 0/3] " Stefan Beller
0 siblings, 1 reply; 200+ results
From: Johannes Schindelin @ 2018-07-30 12:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stefan Beller, git, bmwill, peff
Hi,
On Fri, 27 Jul 2018, Junio C Hamano wrote:
> Stefan Beller <sbeller@google.com> writes:
>
> [...]
Thanks for the patch!
The only thing that was not clear to me from the patch and from the commit
message was: the first part *is* case insensitive, right? How does the
patch take care of that? Is it relying on `git_config_parse_key()` to do
that? If so, I don't see it...
> I would still hold the judgment on "all except only this one"
> myself. That's a bit too early in my mind.
Agreed. I seem to remember that I had a funny problem "in the reverse",
where http.<url>.* is case-sensitive, but in an unexpected way: if the URL
contains upper-case characters, the <url> part of the config key needs to
be downcased, otherwise the setting won't be picked up.
Ciao,
Dscho
^ permalink raw reply [relevance 14%]
* [PATCH 7/8] config.txt: clarify sentences in the configuration and syntax sections
2009-04-23 9:38 18% ` [PATCH 6/8] config.txt: add missing 'the's and make words plural Stephen Boyd
@ 2009-04-23 9:38 14% ` Stephen Boyd
0 siblings, 0 replies; 200+ results
From: Stephen Boyd @ 2009-04-23 9:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Documentation/config.txt | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1f17e7a..acd9b31 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -8,9 +8,9 @@ is used to store the information for that repository, and
fallback values for the `.git/config` file. The file `/etc/gitconfig`
can be used to store system-wide defaults.
-They can be used by both the git plumbing
-and the porcelains. The variables are divided into sections, where
-in the fully qualified variable name the variable itself is the last
+The configuration variables are used by both the git plumbing
+and the porcelains. The variables are divided into sections, wherein
+the fully qualified variable name of the variable itself is the last
dot-separated segment and the section name is everything before the last
dot. The variable names are case-insensitive and only alphanumeric
characters are allowed. Some variables may appear multiple times.
@@ -38,9 +38,9 @@ in the section header, like in the example below:
--------
-Subsection names can contain any character except newline (doublequote
-`"` and backslash have to be escaped as `\"` and `\\`,
-respectively) and are case sensitive. Section headers cannot span multiple
+Subsection names are case sensitive and can contain any characters except
+newline (doublequote `"` and backslash have to be escaped as `\"` and `\\`,
+respectively). Section headers cannot span multiple
lines. Variables may belong directly to a section or to a given subsection.
You can have `[section]` if you have `[section "subsection"]`, but you
don't need to.
--
1.6.2.3
^ permalink raw reply related [relevance 14%]
* Re: [PATCH 3/3] Windows: teach getenv to do a case-sensitive search
2011-06-06 7:08 20% ` [PATCH 3/3] Windows: teach getenv to do a case-sensitive search Johannes Sixt
@ 2011-10-05 16:21 14% ` Karsten Blees
0 siblings, 0 replies; 200+ results
From: Karsten Blees @ 2011-10-05 16:21 UTC (permalink / raw)
To: git
Hmm...this looks like a pretty fragile solution to me. Wouldn't it be simpler
and safer to just fix the conflicting variables, instead of inventing entirely
new environment semantics for Windows?
I looked at the eval_gettext occurences, and only found '$path' in
git-submodule.sh to obviously conflict with existing environment variables. So
the straightforward solution IMO would be to fix the variable in that script.
Small solution (only affects gettext): in git-submodule.sh, replace all
'eval_gettext...$path' with 'modulepath=$path eval_gettext...$modulepath'
Big solution (enables git-submodule-foreach scripts on Windows, but is a
breaking change for existing foreach scripts on Unix): in git-submodule.sh,
t/t7407-submodule-foreach.sh, Documentation/git-submodule.txt, replace all
'$path' with '$modulepath' (also a few 'path=...' and 'while read...path')
Just a few failure scenarios that come to mind with the current solution:
- Given environment variables "Path" and "path", the 'case-sensitive first'
approach works fine for 'getenv("path")', but 'getenv("PATH")' still has a 50%
chance of failure.
- The other environment functions have not been changed to reflect the
'case-sensitive first' logic: setenv("path"...) and setenv("PATH"...) both have
a chance of overwriting the wrong entry, same for putenv.
- Windows applications generally don't support case-sensitive environment
variables, e.g. all MSYS and Cygwin programs convert environment variable names
to upper case on startup, eliminating duplicates in the process. With git.exe
beeing the only case-sensitive tool, any change to git-sh-i18n.sh (e.g.
replacing git-envsubst with a real gettext-envsubst) is likely to break again.
- As you already mentioned, Windows doesn't support case-sensitive environment
variable names, MSDN is pretty clear on that. Expressly violating this
documentation may cease to work with any new Windows version or patch.
Cheers,
Karsten
^ permalink raw reply [relevance 14%]
* Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'
2012-03-22 11:25 6% ` Zbigniew Jędrzejewski-Szmek
@ 2012-03-22 14:12 14% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2012-03-22 14:12 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek
Cc: Johannes Sixt, Peter J. Weisberg, git, Junio C Hamano
On Thu, Mar 22, 2012 at 12:25:50PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> >What am I missing?
>
> The OP meant a case-sensitive fs, not an insensitive one.
> "On a filesystem that *is* case-sensitive, ..."
>
> This is a question about core.ignorecase=true. The description in
> git-config(1) is so vague, that it's hard to say what behaviour is
> expected.
I don't know. It says:
If true, this option enables various workarounds to enable git to work
better on filesystems that are not case sensitive, like FAT. For
example, if a directory listing finds "makefile" when git expects
"Makefile", git will assume it is really the same file, and continue
to remember it as "Makefile".
which seems pretty clear to me that this is "let git work better on
case-insensitive filesystems", not "make git magically case-insensitive
on case sensitive filesystem". But maybe we could add be more explicit,
like:
-- >8 --
Subject: docs: clarify core.ignorecase on case-sensitive filesystems
core.ignorecase is about handling case-insensitive
filesystems, not making git magically case-insensitive on a
case-sensitive filesystem. That's implied by the current
text, but let's add an explicit note.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/config.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c081657..abbab91 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -191,6 +191,10 @@ core.ignorecase::
The default is false, except linkgit:git-clone[1] or linkgit:git-init[1]
will probe and set core.ignorecase true if appropriate when the repository
is created.
++
+Note that this is about making git work well on a case-insensitive
+filesystem. It will not make git case-insensitive when used on a
+case-sensitive filesystem.
core.trustctime::
If false, the ctime differences between the index and the
--
1.7.10.rc0.9.gdcbe9
^ permalink raw reply related [relevance 14%]
* AW: AW: fast-import fails with case sensitive tags due to case insensitive lock files
2019-03-04 15:29 9% ` Johannes Schindelin
@ 2019-03-05 6:25 14% ` Wendeborn, Jonathan
0 siblings, 0 replies; 200+ results
From: Wendeborn, Jonathan @ 2019-03-05 6:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: brian m. carlson, git@vger.kernel.org
Hi Johannes,
>> One thing I still would like to encourage to is to improve the error
>> message which is really misleading in this case.
> Well, that is at least something you could do. After all, you use a volunteer-driven project, so you could at least volunteer a little time to improving it yourself.
That's true :)
Thank you!
Jonathan
-----Ursprüngliche Nachricht-----
Von: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Gesendet: Montag, 4. März 2019 16:29
An: Wendeborn, Jonathan <Jonathan.Wendeborn@bruker.com>
Cc: brian m. carlson <sandals@crustytoothpaste.net>; git@vger.kernel.org
Betreff: Re: AW: fast-import fails with case sensitive tags due to case insensitive lock files
Hi Jonathan,
On Mon, 4 Mar 2019, Wendeborn, Jonathan wrote:
> > Right now, you have some choices:
> > • Volunteer to implement reftable.
> > • Since you're on Windows 10, set your Git repository directory as
> > case-sensitive.
> > • Use Windows Subsystem for Linux, which is case sensitive and
> > creates
> > directories with that flag (even on NTFS), to do your import.
> > • If you control the fast-export output, adjust the arguments you
> > pass
> > such that the output does not contain one of the offending tags.
>
> Hi Brian,
>
> Thank you very much for your answer!
>
> Unfortunately I am stuck with Windows 10 1703 which neither supports
> case-sensitivity nor any Linux subsystem from the Microsoft Store :(
Too bad.
> Also, my employer unfortunately doesn’t allow me to invest the time to
> implement reftable,
Even worse!
> so I guess I go with manually leaving out the one conflicting label I
> found and tagging it manually afterward.
That is a valid workaround.
> One thing I still would like to encourage to is to improve the error
> message which is really misleading in this case.
Well, that is at least something you could do. After all, you use a volunteer-driven project, so you could at least volunteer a little time to improving it yourself.
Ciao,
Johannes
^ permalink raw reply [relevance 14%]
* Re: [issue?]'git branch -D' case sensitive issue
2016-01-14 11:51 8% ` Torsten Bögershausen
@ 2016-01-14 13:28 14% ` 郭腾飞
2016-01-14 16:42 8% ` Torsten Bögershausen
0 siblings, 1 reply; 200+ results
From: 郭腾飞 @ 2016-01-14 13:28 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git
Hi Torsten Bögershausen, thank you for the quick reply.
I'm working on Mac OS as I have mentioned in the previous email.
➜ my-emacs-conf git:(NIce) ✗ sw_vers -productVersion
10.11 OSX
And besides, I use a case sensitive file system in OSX through the command
'hdiutil create -volname 'case_fs' -type SPARSE -fs 'Case-sensitive
Journaled HFS+' -size 100g ~/case_fs.sparseimage'
Is this a known issue?
Thank you!
BRs
terry3
2016-01-14 19:51 GMT+08:00 Torsten Bögershausen <tboegi@web.de>:
> On 01/14/2016 08:52 AM, 郭腾飞 wrote:
>>
>> Hi All,
>> I encountered some issues when using 'git branch -D'.
>> It's strange, the command 'git branch -D' is case sensitive.
>> Here is the operated log.
>>
>> ➜ my-emacs-conf git:(NIce) git branch -avv
>> * NIce fed5d9c Update js2-mode $ js-beautify.
>> master fed5d9c [origin/master] Update js2-mode $
>> js-beautify.
>> remotes/origin/HEAD -> origin/master
>> remotes/origin/fake 8ec9cad fake.
>> remotes/origin/mac13 13ae483 mac pro 13's config.
>> remotes/origin/master fed5d9c Update js2-mode $ js-beautify.
>> ➜ my-emacs-conf git:(NIce)
>> ➜ my-emacs-conf git:(NIce) git branch -D NIce
>> error: Cannot delete the branch 'NIce' which you are currently on.
>> ➜ my-emacs-conf git:(NIce)
>> ➜ my-emacs-conf git:(NIce) git branch -D NICe
>> Deleted branch NICe (was fed5d9c).
>> ➜ my-emacs-conf git:(NIce) ✗ git branch -avv
>> master fed5d9c [origin/master] Update js2-mode $
>> js-beautify.
>> remotes/origin/HEAD -> origin/master
>> remotes/origin/fake 8ec9cad fake.
>> remotes/origin/mac13 13ae483 mac pro 13's config.
>> remotes/origin/master fed5d9c Update js2-mode $ js-beautify.
>>
>> Hope someone can give me a hint.
>>
>> ➜ my-emacs-conf git:(NIce) ✗ git --version
>> git version 2.6.3
>> ➜ my-emacs-conf git:(NIce) ✗ sw_vers -productVersion
>> 10.11 OSX
>>
>> BRs,
>> terry3
>> --
>
> If you can give us a hint, under which OS you are working ?
>
> I assume that you are on Windows or Mac OS ?
> In this case the file system is part of the problem,
> which treats NIce and NICe the same.
>
--
________________________________
Guo Tengfei
^ permalink raw reply [relevance 14%]
* [PATCH 2/3] fixup! git rebase -i: warn about removed commits
@ 2015-06-30 9:19 15% ` Matthieu Moy
0 siblings, 0 replies; 200+ results
From: Matthieu Moy @ 2015-06-30 9:19 UTC (permalink / raw)
To: gitster
Cc: git, remi.lespinet, guillaume.pages, louis--alexandre.stuber,
antoine.delaite, sunshine, Matthieu Moy
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
git-rebase--interactive.sh | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 9041d15..0117791 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -156,8 +156,17 @@ Commands:
These lines can be re-ordered; they are executed from top to bottom.
+EOF
+ if test $(get_missing_commit_check_level) = error
+ then
+ git stripspace --comment-lines >>"$todo" <<\EOF
+Do not remove any line. Use 'drop' explicitly to remove a commit.
+EOF
+ else
+ git stripspace --comment-lines >>"$todo" <<\EOF
If you remove a line here THAT COMMIT WILL BE LOST.
EOF
+ fi
}
make_patch () {
@@ -931,6 +940,13 @@ checkout_onto () {
git update-ref ORIG_HEAD $orig_head
}
+get_missing_commit_check_level () {
+ check_level=$(git config --get rebase.missingCommitsCheck)
+ check_level=${check_level:-ignore}
+ # Don't be case sensitive
+ printf '%s' "$check_level" | tr 'A-Z' 'a-z'
+}
+
# Check if the user dropped some commits by mistake
# Behaviour determined by rebase.missingCommitsCheck.
# Check if there is an unrecognized command or a
@@ -938,10 +954,7 @@ checkout_onto () {
check_todo_list () {
raise_error=f
- check_level=$(git config --get rebase.missingCommitsCheck)
- check_level=${check_level:-ignore}
- # Don't be case sensitive
- check_level=$(printf '%s' "$check_level" | tr 'A-Z' 'a-z')
+ check_level=$(get_missing_commit_check_level)
case "$check_level" in
warn|error)
--
2.5.0.rc0.10.g7792c2a
^ permalink raw reply related [relevance 15%]
* Re: fast-import fails with case sensitive tags due to case insensitive lock files
2019-03-01 6:19 8% fast-import fails with case sensitive tags due to case insensitive lock files Wendeborn, Jonathan
@ 2019-03-03 0:25 15% ` brian m. carlson
2019-03-04 7:55 9% ` AW: " Wendeborn, Jonathan
0 siblings, 1 reply; 200+ results
From: brian m. carlson @ 2019-03-03 0:25 UTC (permalink / raw)
To: Wendeborn, Jonathan; +Cc: git@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]
On Fri, Mar 01, 2019 at 06:19:48AM +0000, Wendeborn, Jonathan wrote:
> Hi,
>
> I have a problem with fast-import on an NTFS drive: If I try to import tags which are identical apart from their casing a failure due to identical lock file names occurs.
>
> I am running git for windows 2.15.1.2 x64 on a Windows 10 machine (10.0.15063):
> $ git --version --build-options
> git version 2.15.1.windows.2
> built from commit: 5d5baf91824ec7750b103c8b7c4827ffac202feb
> sizeof-long: 4
> machine: x86_64
>
> MCVE:
> (echo "commit refs/heads/master" &&
> echo "mark :1" &&
> echo "committer me <> 0 +0000" &&
> echo "data 0" &&
> echo "" &&
> echo "tag tag_A" &&
> echo "from :1" &&
> echo "tagger me <> 0 +0000" &&
> echo "data 0" &&
> echo "" &&
> echo "tag tag_a" &&
> echo "from :1" &&
> echo "tagger me <> 0 +0000" &&
> echo "data 0" &&
> echo "") | git fast-import
>
> Instead of having 1 commit with two tags ("tag_A" and "tag_a") I get his error message:
> Unpacking objects: 100% (4/4), done.
> error: cannot lock ref 'refs/tags/tag_a': Unable to create 'C:/tmp/.git/refs/tags/tag_a.lock': File exists.
The reason you're seeing this error is because refs can be stored in the
file system. In order to update a reference, Git takes a lock on it, and
as you've seen, Git can't take a lock on the same reference twice.
It's known that multiple references that differ only in case can't be
stored in a case-insensitive file system, and there is a design for a
different system (reftable) which nobody has yet implemented in Git but
does not have this problem.
Even if we accepted this situation in fast-import, we'd destroy one of
your tags, which would be undesirable.
Sometimes this happens to work because when we pack references, we store
them in a file instead, which does not suffer from case-sensitivity
problems.
Right now, you have some choices:
• Volunteer to implement reftable.
• Since you're on Windows 10, set your Git repository directory as
case-sensitive.
• Use Windows Subsystem for Linux, which is case sensitive and creates
directories with that flag (even on NTFS), to do your import.
• If you control the fast-export output, adjust the arguments you pass
such that the output does not contain one of the offending tags.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
^ permalink raw reply [relevance 15%]
* Re: [PATCH] config: fix case sensitive subsection names on writing
2018-07-27 20:51 20% [PATCH] config: fix case sensitive subsection names on writing Stefan Beller
@ 2018-07-27 21:21 15% ` Brandon Williams
2018-07-27 21:39 8% ` Junio C Hamano
2018-07-27 21:37 8% ` [PATCH] config: fix case sensitive subsection names on writing Junio C Hamano
1 sibling, 1 reply; 200+ results
From: Brandon Williams @ 2018-07-27 21:21 UTC (permalink / raw)
To: Stefan Beller; +Cc: git
On 07/27, Stefan Beller wrote:
> A use reported a submodule issue regarding strange case indentation
> issues, but it could be boiled down to the following test case:
>
> $ git init test && cd test
> $ git config foo."Bar".key test
> $ git config foo."bar".key test
> $ tail -n 3 .git/config
> [foo "Bar"]
> key = test
> key = test
>
> Sub sections are case sensitive and we have a test for correctly reading
> them. However we do not have a test for writing out config correctly with
> case sensitive subsection names, which is why this went unnoticed in
> 6ae996f2acf (git_config_set: make use of the config parser's event
> stream, 2018-04-09)
>
> Make the subsection case sensitive and provide a test for both reading
> and writing.
>
> Reported-by: JP Sugarbroad <jpsugar@google.com>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
> config.c | 2 +-
> t/t1300-config.sh | 18 ++++++++++++++++++
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/config.c b/config.c
> index 3aacddfec4b..3ded92b678b 100644
> --- a/config.c
> +++ b/config.c
> @@ -2374,7 +2374,7 @@ static int store_aux_event(enum config_event_t type,
> store->is_keys_section =
> store->parsed[store->parsed_nr].is_keys_section =
> cf->var.len - 1 == store->baselen &&
> - !strncasecmp(cf->var.buf, store->key, store->baselen);
> + !strncmp(cf->var.buf, store->key, store->baselen);
I've done some work in the config part of our codebase but I don't
really know whats going on here due to two things: this is a callback
function and it relies on global state...
I can say though that we might want to be careful about completely
converting this to a case sensitive compare. Our config is a key
value store with the following format: 'section.subsection.key'. IIRC
both section and key are always compared case insensitively. The
subsection can be case sensitive or insensitive based on how its
stored in the config files itself:
# Case insensitive
[section.subsection]
key = value
# Case sensitive
[section "subsection"]
key = value
But I don't know how you distinguish between these cases when a config
is specified on a single line (section.subsection.key). Do we always
assume the sensitive version because the insensitive version is
documented to be deprecated?
Either way you're probably going to need to be careful about how you do
string comparison against the different parts.
> if (store->is_keys_section) {
> store->section_seen = 1;
> ALLOC_GROW(store->seen, store->seen_nr + 1,
> diff --git a/t/t1300-config.sh b/t/t1300-config.sh
> index 03c223708eb..8325d4495f4 100755
> --- a/t/t1300-config.sh
> +++ b/t/t1300-config.sh
> @@ -1218,6 +1218,24 @@ test_expect_success 'last one wins: three level vars' '
> test_cmp expect actual
> '
>
> +test_expect_success 'setting different case subsections ' '
> + test_when_finished "rm -f caseSens caseSens_actual caseSens_expect" &&
> +
> + # v.a.r and v.A.r are not the same variable, as the middle
> + # level of a three-level configuration variable name is
> + # case sensitive.
> + git config -f caseSens v."A".r VAL &&
> + git config -f caseSens v."a".r val &&
> +
> + echo VAL >caseSens_expect &&
> + git config -f caseSens v."A".r >caseSens_actual &&
> + test_cmp caseSens_expect caseSens_actual &&
> +
> + echo val >caseSens_expect &&
> + git config -f caseSens v."a".r >caseSens_actual &&
> + test_cmp caseSens_expect caseSens_actual
> +'
> +
> for VAR in a .a a. a.0b a."b c". a."b c".0d
> do
> test_expect_success "git -c $VAR=VAL rejects invalid '$VAR'" '
> --
> 2.18.0.345.g5c9ce644c3-goog
>
--
Brandon Williams
^ permalink raw reply [relevance 15%]
* [Bug Report] [includeIf] does not parse case insensitive -> case sensitive symlink gitdir
@ 2017-10-27 13:55 15% Adrian Kappel
2017-10-27 15:33 9% ` Torsten Bögershausen
0 siblings, 1 reply; 200+ results
From: Adrian Kappel @ 2017-10-27 13:55 UTC (permalink / raw)
To: git
Hello all, not sure if the issue I've come across is a known bug or
addressable, but wanted to report it just in-case.
** Summary
------------------------------------------------------------------
Using the [includeIf] configuration statement with a symlink'd gitdir
will not work if the symlink is on a case insensitive volume and the
location it references is on a case sensitive volume.
** Steps to reproduce
------------------------------------------------------------------
1. Create symlink (case insensitive -> case sensitive):
/Users/usera/dev -> /Volumes/CaseSensitive/dev
2. Create two files: .gitignore and .gitignore-work, both stored in
/Users/usera/
.gitconfig
-------------
[user]
name = First Last
[includeIf "gitdir:~/dev/work"]
path = .gitconfig-work
.gitconfig-work
--------------------
[user]
email = email@address.com
3. cd into a subfolder of ~/dev/work that has been git initialized.
Let's say ~/dev/work/repo
4. Run git config --includes user.email
5. See that nothing is output from the command
6. Update the [includeIf] statement in .gitconfig to be the real
location i.e. "gitdir:/Volumes/CaseSensitive/dev/work/repo"
7. Rerun the command from [4]
8. See that email@address.com is output from the command
** Other variations that were not tested
------------------------------------------------------------------
- symlink on case sensitive volume referencing a location on a case
insensitive volume
** Environment Information
------------------------------------------------------------------
git --version: 2.14.1
OS: macOS Sierra 10.12.6
If a fix is not feasible or likely to be implemented, I would
recommend that we update the git site's documentation to reflect this
gotcha. After verification of course.
Best,
Adrian Kappel
akappel <https://github.com/akappel/>
^ permalink raw reply [relevance 15%]
* [PATCH v2 35/36] t/helper: merge test-wildmatch into test-tool
@ 2018-03-24 7:45 18% ` Nguyễn Thái Ngọc Duy
0 siblings, 0 replies; 200+ results
From: Nguyễn Thái Ngọc Duy @ 2018-03-24 7:45 UTC (permalink / raw)
To: pclouds; +Cc: git, Eric Sunshine, Jeff Hostetler, Junio C Hamano
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Makefile | 2 +-
t/helper/test-tool.c | 1 +
t/helper/test-tool.h | 1 +
t/helper/test-wildmatch.c | 3 ++-
t/t3070-wildmatch.sh | 14 +++++++-------
5 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/Makefile b/Makefile
index 7923ec3747..2ab76c6838 100644
--- a/Makefile
+++ b/Makefile
@@ -685,6 +685,7 @@ TEST_BUILTINS_OBJS += test-string-list.o
TEST_BUILTINS_OBJS += test-submodule-config.o
TEST_BUILTINS_OBJS += test-subprocess.o
TEST_BUILTINS_OBJS += test-urlmatch-normalization.o
+TEST_BUILTINS_OBJS += test-wildmatch.o
TEST_PROGRAMS_NEED_X += test-dump-fsmonitor
TEST_PROGRAMS_NEED_X += test-dump-untracked-cache
@@ -694,7 +695,6 @@ TEST_PROGRAMS_NEED_X += test-parse-options
TEST_PROGRAMS_NEED_X += test-write-cache
TEST_PROGRAMS_NEED_X += test-svn-fe
TEST_PROGRAMS_NEED_X += test-tool
-TEST_PROGRAMS_NEED_X += test-wildmatch
TEST_PROGRAMS = $(patsubst %,t/helper/%$X,$(TEST_PROGRAMS_NEED_X))
diff --git a/t/helper/test-tool.c b/t/helper/test-tool.c
index b3d84fdac9..a804e64048 100644
--- a/t/helper/test-tool.c
+++ b/t/helper/test-tool.c
@@ -40,6 +40,7 @@ static struct test_cmd cmds[] = {
{ "submodule-config", cmd__submodule_config },
{ "subprocess", cmd__subprocess },
{ "urlmatch-normalization", cmd__urlmatch_normalization },
+ { "wildmatch", cmd__wildmatch },
};
int cmd_main(int argc, const char **argv)
diff --git a/t/helper/test-tool.h b/t/helper/test-tool.h
index fa53c82659..84c583e68f 100644
--- a/t/helper/test-tool.h
+++ b/t/helper/test-tool.h
@@ -34,5 +34,6 @@ int cmd__string_list(int argc, const char **argv);
int cmd__submodule_config(int argc, const char **argv);
int cmd__subprocess(int argc, const char **argv);
int cmd__urlmatch_normalization(int argc, const char **argv);
+int cmd__wildmatch(int argc, const char **argv);
#endif
diff --git a/t/helper/test-wildmatch.c b/t/helper/test-wildmatch.c
index 66d33dfcfd..2c103d1824 100644
--- a/t/helper/test-wildmatch.c
+++ b/t/helper/test-wildmatch.c
@@ -1,6 +1,7 @@
+#include "test-tool.h"
#include "cache.h"
-int cmd_main(int argc, const char **argv)
+int cmd__wildmatch(int argc, const char **argv)
{
int i;
for (i = 2; i < argc; i++) {
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index c1fc6ca730..dce102130f 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -79,12 +79,12 @@ match_with_function() {
if test "$match_expect" = 1
then
test_expect_success "$match_function: match '$text' '$pattern'" "
- test-wildmatch $match_function '$text' '$pattern'
+ test-tool wildmatch $match_function '$text' '$pattern'
"
elif test "$match_expect" = 0
then
test_expect_success "$match_function: no match '$text' '$pattern'" "
- test_must_fail test-wildmatch $match_function '$text' '$pattern'
+ test_must_fail test-tool wildmatch $match_function '$text' '$pattern'
"
else
test_expect_success "PANIC: Test framework error. Unknown matches value $match_expect" 'false'
@@ -148,7 +148,7 @@ match_with_ls_files() {
match() {
if test "$#" = 6
then
- # When test-wildmatch and git ls-files produce the same
+ # When test-tool wildmatch and git ls-files produce the same
# result.
match_glob=$1
match_file_glob=$match_glob
@@ -204,19 +204,19 @@ match() {
fi
'
- # $1: Case sensitive glob match: test-wildmatch & ls-files
+ # $1: Case sensitive glob match: test-tool wildmatch & ls-files
match_with_function "$text" "$pattern" $match_glob "wildmatch"
match_with_ls_files "$text" "$pattern" $match_file_glob "wildmatch" " --glob-pathspecs"
- # $2: Case insensitive glob match: test-wildmatch & ls-files
+ # $2: Case insensitive glob match: test-tool wildmatch & ls-files
match_with_function "$text" "$pattern" $match_iglob "iwildmatch"
match_with_ls_files "$text" "$pattern" $match_file_iglob "iwildmatch" " --glob-pathspecs --icase-pathspecs"
- # $3: Case sensitive path match: test-wildmatch & ls-files
+ # $3: Case sensitive path match: test-tool wildmatch & ls-files
match_with_function "$text" "$pattern" $match_pathmatch "pathmatch"
match_with_ls_files "$text" "$pattern" $match_file_pathmatch "pathmatch" ""
- # $4: Case insensitive path match: test-wildmatch & ls-files
+ # $4: Case insensitive path match: test-tool wildmatch & ls-files
match_with_function "$text" "$pattern" $match_pathmatchi "ipathmatch"
match_with_ls_files "$text" "$pattern" $match_file_pathmatchi "ipathmatch" " --icase-pathspecs"
}
--
2.17.0.rc0.348.gd5a49e0b6f
^ permalink raw reply related [relevance 18%]
* [PATCH 6/8] config.txt: add missing 'the's and make words plural
@ 2009-04-23 9:38 18% ` Stephen Boyd
2009-04-23 9:38 14% ` [PATCH 7/8] config.txt: clarify sentences in the configuration and syntax sections Stephen Boyd
0 siblings, 1 reply; 200+ results
From: Stephen Boyd @ 2009-04-23 9:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Documentation/config.txt | 34 +++++++++++++++++-----------------
1 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index cabac97..1f17e7a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2,10 +2,10 @@ CONFIGURATION FILE
------------------
The git configuration file contains a number of variables that affect
-the git command's behavior. `.git/config` file for each repository
+the git command's behavior. The `.git/config` file in each repository
is used to store the information for that repository, and
-`$HOME/.gitconfig` is used to store per user information to give
-fallback values for `.git/config` file. The file `/etc/gitconfig`
+`$HOME/.gitconfig` is used to store per user information as
+fallback values for the `.git/config` file. The file `/etc/gitconfig`
can be used to store system-wide defaults.
They can be used by both the git plumbing
@@ -26,28 +26,28 @@ The file consists of sections and variables. A section begins with
the name of the section in square brackets and continues until the next
section begins. Section names are not case sensitive. Only alphanumeric
characters, `-` and `.` are allowed in section names. Each variable
-must belong to some section, which means that there must be section
-header before first setting of a variable.
+must belong to some section, which means that there must be a section
+header before the first setting of a variable.
Sections can be further divided into subsections. To begin a subsection
put its name in double quotes, separated by space from the section name,
-in the section header, like in example below:
+in the section header, like in the example below:
--------
[section "subsection"]
--------
-Subsection names can contain any characters except newline (doublequote
+Subsection names can contain any character except newline (doublequote
`"` and backslash have to be escaped as `\"` and `\\`,
-respectively) and are case sensitive. Section header cannot span multiple
+respectively) and are case sensitive. Section headers cannot span multiple
lines. Variables may belong directly to a section or to a given subsection.
You can have `[section]` if you have `[section "subsection"]`, but you
don't need to.
-There is also (case insensitive) alternative `[section.subsection]` syntax.
-In this syntax subsection names follow the same restrictions as for section
-name.
+There is also a case insensitive alternative `[section.subsection]` syntax.
+In this syntax, subsection names follow the same restrictions as for section
+names.
All the other lines are recognized as setting variables, in the form
'name = value'. If there is no equal sign on the line, the entire line
@@ -66,10 +66,10 @@ converting value to the canonical form using '--bool' type specifier;
'git-config' will ensure that the output is "true" or "false".
String values may be entirely or partially enclosed in double quotes.
-You need to enclose variable value in double quotes if you want to
-preserve leading or trailing whitespace, or if variable value contains
-beginning of comment characters (if it contains '#' or ';').
-Double quote `"` and backslash `\` characters in variable value must
+You need to enclose variable values in double quotes if you want to
+preserve leading or trailing whitespace, or if the variable value contains
+comment characters (i.e. it contains '#' or ';').
+Double quote `"` and backslash `\` characters in variable values must
be escaped: use `\"` for `"` and `\\` for `\`.
The following escape sequences (beside `\"` and `\\`) are recognized:
@@ -77,10 +77,10 @@ The following escape sequences (beside `\"` and `\\`) are recognized:
and `\b` for backspace (BS). No other char escape sequence, nor octal
char sequences are valid.
-Variable value ending in a `\` is continued on the next line in the
+Variable values ending in a `\` are continued on the next line in the
customary UNIX fashion.
-Some variables may require special value format.
+Some variables may require a special value format.
Example
~~~~~~~
--
1.6.2.3
^ permalink raw reply related [relevance 18%]
* [PATCH 35/36] t/helper: merge test-wildmatch into test-tool
@ 2018-03-17 7:54 18% ` Nguyễn Thái Ngọc Duy
1 sibling, 0 replies; 200+ results
From: Nguyễn Thái Ngọc Duy @ 2018-03-17 7:54 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Makefile | 2 +-
t/helper/test-tool.c | 1 +
t/helper/test-tool.h | 1 +
t/helper/test-wildmatch.c | 3 ++-
t/t3070-wildmatch.sh | 14 +++++++-------
5 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/Makefile b/Makefile
index 7923ec3747..2ab76c6838 100644
--- a/Makefile
+++ b/Makefile
@@ -685,6 +685,7 @@ TEST_BUILTINS_OBJS += test-string-list.o
TEST_BUILTINS_OBJS += test-submodule-config.o
TEST_BUILTINS_OBJS += test-subprocess.o
TEST_BUILTINS_OBJS += test-urlmatch-normalization.o
+TEST_BUILTINS_OBJS += test-wildmatch.o
TEST_PROGRAMS_NEED_X += test-dump-fsmonitor
TEST_PROGRAMS_NEED_X += test-dump-untracked-cache
@@ -694,7 +695,6 @@ TEST_PROGRAMS_NEED_X += test-parse-options
TEST_PROGRAMS_NEED_X += test-write-cache
TEST_PROGRAMS_NEED_X += test-svn-fe
TEST_PROGRAMS_NEED_X += test-tool
-TEST_PROGRAMS_NEED_X += test-wildmatch
TEST_PROGRAMS = $(patsubst %,t/helper/%$X,$(TEST_PROGRAMS_NEED_X))
diff --git a/t/helper/test-tool.c b/t/helper/test-tool.c
index f2d60af898..ebf28859b4 100644
--- a/t/helper/test-tool.c
+++ b/t/helper/test-tool.c
@@ -40,6 +40,7 @@ static struct test_cmd cmds[] = {
{ "submodule-config", test_submodule_config },
{ "subprocess", test_subprocess },
{ "urlmatch-normalization", test_urlmatch_normalization },
+ { "wildmatch", test_wildmatch },
};
int cmd_main(int argc, const char **argv)
diff --git a/t/helper/test-tool.h b/t/helper/test-tool.h
index 704ac9df35..b7c8272689 100644
--- a/t/helper/test-tool.h
+++ b/t/helper/test-tool.h
@@ -34,5 +34,6 @@ int test_string_list(int argc, const char **argv);
int test_submodule_config(int argc, const char **argv);
int test_subprocess(int argc, const char **argv);
int test_urlmatch_normalization(int argc, const char **argv);
+int test_wildmatch(int argc, const char **argv);
#endif
diff --git a/t/helper/test-wildmatch.c b/t/helper/test-wildmatch.c
index 66d33dfcfd..b5c6d10b5e 100644
--- a/t/helper/test-wildmatch.c
+++ b/t/helper/test-wildmatch.c
@@ -1,6 +1,7 @@
+#include "test-tool.h"
#include "cache.h"
-int cmd_main(int argc, const char **argv)
+int test_wildmatch(int argc, const char **argv)
{
int i;
for (i = 2; i < argc; i++) {
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index c1fc6ca730..dce102130f 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -79,12 +79,12 @@ match_with_function() {
if test "$match_expect" = 1
then
test_expect_success "$match_function: match '$text' '$pattern'" "
- test-wildmatch $match_function '$text' '$pattern'
+ test-tool wildmatch $match_function '$text' '$pattern'
"
elif test "$match_expect" = 0
then
test_expect_success "$match_function: no match '$text' '$pattern'" "
- test_must_fail test-wildmatch $match_function '$text' '$pattern'
+ test_must_fail test-tool wildmatch $match_function '$text' '$pattern'
"
else
test_expect_success "PANIC: Test framework error. Unknown matches value $match_expect" 'false'
@@ -148,7 +148,7 @@ match_with_ls_files() {
match() {
if test "$#" = 6
then
- # When test-wildmatch and git ls-files produce the same
+ # When test-tool wildmatch and git ls-files produce the same
# result.
match_glob=$1
match_file_glob=$match_glob
@@ -204,19 +204,19 @@ match() {
fi
'
- # $1: Case sensitive glob match: test-wildmatch & ls-files
+ # $1: Case sensitive glob match: test-tool wildmatch & ls-files
match_with_function "$text" "$pattern" $match_glob "wildmatch"
match_with_ls_files "$text" "$pattern" $match_file_glob "wildmatch" " --glob-pathspecs"
- # $2: Case insensitive glob match: test-wildmatch & ls-files
+ # $2: Case insensitive glob match: test-tool wildmatch & ls-files
match_with_function "$text" "$pattern" $match_iglob "iwildmatch"
match_with_ls_files "$text" "$pattern" $match_file_iglob "iwildmatch" " --glob-pathspecs --icase-pathspecs"
- # $3: Case sensitive path match: test-wildmatch & ls-files
+ # $3: Case sensitive path match: test-tool wildmatch & ls-files
match_with_function "$text" "$pattern" $match_pathmatch "pathmatch"
match_with_ls_files "$text" "$pattern" $match_file_pathmatch "pathmatch" ""
- # $4: Case insensitive path match: test-wildmatch & ls-files
+ # $4: Case insensitive path match: test-tool wildmatch & ls-files
match_with_function "$text" "$pattern" $match_pathmatchi "ipathmatch"
match_with_ls_files "$text" "$pattern" $match_file_pathmatchi "ipathmatch" " --icase-pathspecs"
}
--
2.16.2.903.gd04caf5039
^ permalink raw reply related [relevance 18%]
* [PATCH v2 3/5] t4203: add failing test for case-sensitive local-parts and names
2021-01-03 21:18 35% ` [PATCH v2 4/5] mailmap: use case-sensitive comparisons for local-parts and names brian m. carlson
@ 2021-01-03 21:18 19% ` brian m. carlson
1 sibling, 0 replies; 200+ results
From: brian m. carlson @ 2021-01-03 21:18 UTC (permalink / raw)
To: git; +Cc: Jeff King, Ævar Arnfjörð Bjarmason, Phillip Wood
Currently, Git always looks up entries in the mailmap in a
case-insensitive way, both for names and addresses, which is, as
explained below, suboptimal.
First, for email addresses, RFC 5321 is clear that only domains are case
insensitive; local-parts (the portion before the at sign) are not. It
states this:
The local-part of a mailbox MUST BE treated as case sensitive.
Therefore, SMTP implementations MUST take care to preserve the case of
mailbox local-parts.
There exist systems today where local-parts remain case sensitive (and
this author has one), and as such, it's incorrect for us to case fold
them in any way. Let's add a failing test that indicates this is a
problem, while still keeping the test for case-insensitive domains.
Note that it's also incorrect for us to case-fold names because we don't
guarantee that we're using the locale of the author, and it's impossible
to case-fold names in a locale-insensitive way. Turkish and Azeri
contain both a dotted and dotless I, and the uppercase ASCII I folds not
to the lowercase ASCII I, but to a dotless version, and vice versa with
the lowercase I. There are many words in Turkish which differ only in
the dottedness of the I, so it is likely that there are also personal
names which differ in the same way.
That would be a problem even if our implementation were perfect, which
it is not. We currently fold only ASCII characters, so this feature has
never worked correctly for the vast majority of the users on the planet,
regardless of the locale. For example, on Linux, even in a Spanish
locale, we don't handle "Simón" properly. Even if we did handle that,
we'd probably also want to implement Unicode normalization, which we
don't.
In general, case-folding text is extremely language- and locale-specific
and requires intimacy with the spelling and grammar of the language in
question and careful attention to the Unicode details in order to
produce a result that is meaningful to humans and conforms with
linguistic and societal norms.
Because we do not have any of the required context with a plain personal
name, we cannot hope to possibly case-fold personal names correctly. We
should stop trying to do so and just treat them as a series of bytes, so
let's add a test that we don't case-fold personal names as well.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
t/t4203-mailmap.sh | 29 +++++++++++++++++++++++++++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index 586c3a86b1..32e849504c 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -170,10 +170,35 @@ Repo Guy (1):
EOF
-test_expect_success 'name entry after email entry, case-insensitive' '
+test_expect_success 'name entry after email entry, case-insensitive domain' '
mkdir -p internal_mailmap &&
echo "<bugs@company.xy> <bugs@company.xx>" >internal_mailmap/.mailmap &&
- echo "Internal Guy <BUGS@Company.xx>" >>internal_mailmap/.mailmap &&
+ echo "Internal Guy <bugs@Company.xx>" >>internal_mailmap/.mailmap &&
+ git shortlog HEAD >actual &&
+ test_cmp expect actual
+'
+
+cat >expect <<\EOF
+Repo Guy (1):
+ initial
+
+nick1 (1):
+ second
+
+EOF
+
+test_expect_failure 'name entry after email entry, case-sensitive local-part' '
+ mkdir -p internal_mailmap &&
+ echo "<bugs@company.xy> <bugs@company.xx>" >internal_mailmap/.mailmap &&
+ echo "Internal Guy <BUGS@company.xx>" >>internal_mailmap/.mailmap &&
+ git shortlog HEAD >actual &&
+ test_cmp expect actual
+'
+
+test_expect_failure 'name entry after email entry, case-sensitive personal name' '
+ mkdir -p internal_mailmap &&
+ echo "<bugs@company.xy> <bugs@company.xx>" >internal_mailmap/.mailmap &&
+ echo "Nick1 <bugs@company.xx> NICK1 <bugs@company.xx>" >internal_mailmap/.mailmap &&
git shortlog HEAD >actual &&
test_cmp expect actual
'
^ permalink raw reply related [relevance 19%]
* [PATCH 01/13] Revert "Windows: teach getenv to do a case-sensitive search"
@ 2014-07-17 15:37 19% ` Stepan Kasal
0 siblings, 0 replies; 200+ results
From: Stepan Kasal @ 2014-07-17 15:37 UTC (permalink / raw)
To: GIT Mailing-list; +Cc: Karsten Blees, msysGit, Karsten Blees, Stepan Kasal
From: Karsten Blees <blees@dcon.de>
This reverts commit df599e9612788b728ce43a03159b85f1fe624d6a.
As of 5e9637c6 "i18n: add infrastructure for translating Git with gettext",
eval_gettext uses MinGW envsubst.exe instead of git-sh-i18n--envsubst.exe
for variable substitution. This breaks git-submodule.sh messages and tests,
as envsubst.exe doesn't support case-sensitive environment lookup (the same
is true for almost everything on Windows, including MSys and Cygwin tools).
30a615ac "Windows/i18n: rename $path to prevent clashes with $PATH" renames
the conflicting variable in git-submodule.sh, so that it works on Windows
(i.e. with case-insensitive environment, regardless of the toolset).
Revert to the documented behaviour of case-insensitive environment on
Windows.
Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Stepan Kasal <kasal@ucw.cz>
---
compat/mingw.c | 23 +++--------------------
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index c19e3d9..ca1b6bd 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1245,31 +1245,14 @@ char **make_augmented_environ(const char *const *vars)
}
#undef getenv
-
-/*
- * The system's getenv looks up the name in a case-insensitive manner.
- * This version tries a case-sensitive lookup and falls back to
- * case-insensitive if nothing was found. This is necessary because,
- * as a prominent example, CMD sets 'Path', but not 'PATH'.
- * Warning: not thread-safe.
- */
-static char *getenv_cs(const char *name)
-{
- size_t len = strlen(name);
- int i = lookup_env(environ, name, len);
- if (i >= 0)
- return environ[i] + len + 1; /* skip past name and '=' */
- return getenv(name);
-}
-
char *mingw_getenv(const char *name)
{
- char *result = getenv_cs(name);
+ char *result = getenv(name);
if (!result && !strcmp(name, "TMPDIR")) {
/* on Windows it is TMP and TEMP */
- result = getenv_cs("TMP");
+ result = getenv("TMP");
if (!result)
- result = getenv_cs("TEMP");
+ result = getenv("TEMP");
}
return result;
}
--
2.0.0.9635.g0be03cb
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply related [relevance 19%]
* [PATCH 3/3] Windows: teach getenv to do a case-sensitive search
2011-06-06 6:57 13% [PATCH 0/3] sh-i18n--envsubst; case-sensitive getenv on Windows Johannes Sixt
@ 2011-06-06 7:08 20% ` Johannes Sixt
2011-10-05 16:21 14% ` Karsten Blees
0 siblings, 1 reply; 200+ results
From: Johannes Sixt @ 2011-06-06 7:08 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Junio C Hamano, Git Mailing List, Erik Faye-Lund,
Johannes Schindelin
From: Johannes Sixt <j6t@kdbg.org>
getenv() on Windows looks up environment variables in a case-insensitive
manner. Even though all documentations claim that the environment is
case-insensitive, it is possible for applications to pass an environment
to child processes that has variables that differ only in case. Bash on
Windows does this, for example, and sh-i18n--envsubst depends on this
behavior.
With this patch environment variables are first looked up in a
case-sensitive manner; only if this finds nothing, the system's getenv() is
used as a fallback.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
compat/mingw.c | 23 ++++++++++++++++++++---
1 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index ee480f9..6e5af32 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1116,14 +1116,31 @@ char **make_augmented_environ(const char *const *vars)
}
#undef getenv
+
+/*
+ * The system's getenv looks up the name in a case-insensitive manner.
+ * This version tries a case-sensitive lookup and falls back to
+ * case-insensitive if nothing was found. This is necessary because,
+ * as a prominent example, CMD sets 'Path', but not 'PATH'.
+ * Warning: not thread-safe.
+ */
+static char *getenv_cs(const char *name)
+{
+ size_t len = strlen(name);
+ int i = lookup_env(environ, name, len);
+ if (i >= 0)
+ return environ[i] + len + 1; /* skip past name and '=' */
+ return getenv(name);
+}
+
char *mingw_getenv(const char *name)
{
- char *result = getenv(name);
+ char *result = getenv_cs(name);
if (!result && !strcmp(name, "TMPDIR")) {
/* on Windows it is TMP and TEMP */
- result = getenv("TMP");
+ result = getenv_cs("TMP");
if (!result)
- result = getenv("TEMP");
+ result = getenv_cs("TEMP");
}
return result;
}
--
1.7.6.rc0.1186.gfb4fd
^ permalink raw reply related [relevance 20%]
* [PATCH v2 1/7] Documentation/config.txt: avoid unnecessary negation
@ 2015-03-04 21:33 20% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2015-03-04 21:33 UTC (permalink / raw)
To: git
Section names and variable names are both case-insensitive, but one
is described as "not case sensitive". Use "case-insensitive" for
both.
Instead of saying "... have to be escaped" without telling what that
escaping achieves, state it in a more positive way, i.e. "... can be
included by escaping".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 097fdd4..dbe7035 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -25,7 +25,7 @@ blank lines are ignored.
The file consists of sections and variables. A section begins with
the name of the section in square brackets and continues until the next
-section begins. Section names are not case sensitive. Only alphanumeric
+section begins. Section names are case-insensitive. Only alphanumeric
characters, `-` and `.` are allowed in section names. Each variable
must belong to some section, which means that there must be a section
header before the first setting of a variable.
@@ -40,8 +40,8 @@ in the section header, like in the example below:
--------
Subsection names are case sensitive and can contain any characters except
-newline (doublequote `"` and backslash have to be escaped as `\"` and `\\`,
-respectively). Section headers cannot span multiple
+newline (doublequote `"` and backslash can be included by escaping them
+as `\"` and `\\`, respectively). Section headers cannot span multiple
lines. Variables may belong directly to a section or to a given subsection.
You can have `[section]` if you have `[section "subsection"]`, but you
don't need to.
--
2.3.1-316-g7c93423
^ permalink raw reply related [relevance 20%]
* [PATCH 2/3] config: fix case sensitive subsection names on writing
2018-08-03 0:34 7% ` [PATCH 0/3] Reroll of sb/config-write-fix Stefan Beller
@ 2018-08-03 0:34 20% ` Stefan Beller
2018-08-03 0:34 7% ` [PATCH 1/3] t1300: document current behavior of setting options Stefan Beller
1 sibling, 0 replies; 200+ results
From: Stefan Beller @ 2018-08-03 0:34 UTC (permalink / raw)
To: sbeller; +Cc: bmwill, git, gitster, johannes.schindelin, peff
A user reported a submodule issue regarding a section mix-up,
but it could be boiled down to the following test case:
$ git init test && cd test
$ git config foo."Bar".key test
$ git config foo."bar".key test
$ tail -n 3 .git/config
[foo "Bar"]
key = test
key = test
Sub sections are case sensitive and we have a test for correctly reading
them. However we do not have a test for writing out config correctly with
case sensitive subsection names, which is why this went unnoticed in
6ae996f2acf (git_config_set: make use of the config parser's event
stream, 2018-04-09)
Unfortunately we have to make a distinction between old style configuration
that looks like
[foo.Bar]
key = test
and the new quoted style as seen above. The old style is documented as
case-agnostic, hence we need to keep 'strncasecmp'; although the
resulting setting for the old style config differs from the configuration.
That will be fixed in a follow up patch.
Reported-by: JP Sugarbroad <jpsugar@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
---
config.c | 12 +++++++++++-
t/t1300-config.sh | 1 +
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/config.c b/config.c
index 66645047eb3..ffc2ffeafeb 100644
--- a/config.c
+++ b/config.c
@@ -37,6 +37,7 @@ struct config_source {
int eof;
struct strbuf value;
struct strbuf var;
+ unsigned section_name_old_dot_style : 1;
int (*do_fgetc)(struct config_source *c);
int (*do_ungetc)(int c, struct config_source *conf);
@@ -605,6 +606,7 @@ static int get_value(config_fn_t fn, void *data, struct strbuf *name)
static int get_extended_base_var(struct strbuf *name, int c)
{
+ cf->section_name_old_dot_style = 0;
do {
if (c == '\n')
goto error_incomplete_line;
@@ -641,6 +643,7 @@ static int get_extended_base_var(struct strbuf *name, int c)
static int get_base_var(struct strbuf *name)
{
+ cf->section_name_old_dot_style = 1;
for (;;) {
int c = get_next_char();
if (cf->eof)
@@ -2364,14 +2367,21 @@ static int store_aux_event(enum config_event_t type,
store->parsed[store->parsed_nr].type = type;
if (type == CONFIG_EVENT_SECTION) {
+ int (*cmpfn)(const char *, const char *, size_t);
+
if (cf->var.len < 2 || cf->var.buf[cf->var.len - 1] != '.')
return error("invalid section name '%s'", cf->var.buf);
+ if (cf->section_name_old_dot_style)
+ cmpfn = strncasecmp;
+ else
+ cmpfn = strncmp;
+
/* Is this the section we were looking for? */
store->is_keys_section =
store->parsed[store->parsed_nr].is_keys_section =
cf->var.len - 1 == store->baselen &&
- !strncasecmp(cf->var.buf, store->key, store->baselen);
+ !cmpfn(cf->var.buf, store->key, store->baselen);
if (store->is_keys_section) {
store->section_seen = 1;
ALLOC_GROW(store->seen, store->seen_nr + 1,
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index e87cfc1804f..4976e2fcd3f 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -1290,6 +1290,7 @@ test_expect_success 'setting different case sensitive subsections ' '
Qc = v2
[d "e"]
f = v1
+ [d "E"]
Qf = v2
EOF
# exact match
--
2.18.0.132.g195c49a2227
^ permalink raw reply related [relevance 20%]
* [PATCH] config: fix case sensitive subsection names on writing
@ 2018-07-27 20:51 20% Stefan Beller
2018-07-27 21:21 15% ` Brandon Williams
2018-07-27 21:37 8% ` [PATCH] config: fix case sensitive subsection names on writing Junio C Hamano
0 siblings, 2 replies; 200+ results
From: Stefan Beller @ 2018-07-27 20:51 UTC (permalink / raw)
To: git; +Cc: Stefan Beller
A use reported a submodule issue regarding strange case indentation
issues, but it could be boiled down to the following test case:
$ git init test && cd test
$ git config foo."Bar".key test
$ git config foo."bar".key test
$ tail -n 3 .git/config
[foo "Bar"]
key = test
key = test
Sub sections are case sensitive and we have a test for correctly reading
them. However we do not have a test for writing out config correctly with
case sensitive subsection names, which is why this went unnoticed in
6ae996f2acf (git_config_set: make use of the config parser's event
stream, 2018-04-09)
Make the subsection case sensitive and provide a test for both reading
and writing.
Reported-by: JP Sugarbroad <jpsugar@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
---
config.c | 2 +-
t/t1300-config.sh | 18 ++++++++++++++++++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/config.c b/config.c
index 3aacddfec4b..3ded92b678b 100644
--- a/config.c
+++ b/config.c
@@ -2374,7 +2374,7 @@ static int store_aux_event(enum config_event_t type,
store->is_keys_section =
store->parsed[store->parsed_nr].is_keys_section =
cf->var.len - 1 == store->baselen &&
- !strncasecmp(cf->var.buf, store->key, store->baselen);
+ !strncmp(cf->var.buf, store->key, store->baselen);
if (store->is_keys_section) {
store->section_seen = 1;
ALLOC_GROW(store->seen, store->seen_nr + 1,
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index 03c223708eb..8325d4495f4 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -1218,6 +1218,24 @@ test_expect_success 'last one wins: three level vars' '
test_cmp expect actual
'
+test_expect_success 'setting different case subsections ' '
+ test_when_finished "rm -f caseSens caseSens_actual caseSens_expect" &&
+
+ # v.a.r and v.A.r are not the same variable, as the middle
+ # level of a three-level configuration variable name is
+ # case sensitive.
+ git config -f caseSens v."A".r VAL &&
+ git config -f caseSens v."a".r val &&
+
+ echo VAL >caseSens_expect &&
+ git config -f caseSens v."A".r >caseSens_actual &&
+ test_cmp caseSens_expect caseSens_actual &&
+
+ echo val >caseSens_expect &&
+ git config -f caseSens v."a".r >caseSens_actual &&
+ test_cmp caseSens_expect caseSens_actual
+'
+
for VAR in a .a a. a.0b a."b c". a."b c".0d
do
test_expect_success "git -c $VAR=VAL rejects invalid '$VAR'" '
--
2.18.0.345.g5c9ce644c3-goog
^ permalink raw reply related [relevance 20%]
* [PATCH 2/3] config: fix case sensitive subsection names on writing
@ 2018-08-01 19:34 20% ` Stefan Beller
2018-08-01 21:01 8% ` Ramsay Jones
2018-08-01 22:51 7% ` Junio C Hamano
2018-08-01 19:34 7% ` [PATCH 1/3] t1300: document current behavior of setting options Stefan Beller
2018-08-03 0:34 7% ` [PATCH 0/3] Reroll of sb/config-write-fix Stefan Beller
2 siblings, 2 replies; 200+ results
From: Stefan Beller @ 2018-08-01 19:34 UTC (permalink / raw)
To: gitster; +Cc: bmwill, git, johannes.schindelin, peff, sbeller
A use reported a submodule issue regarding strange case indentation
issues, but it could be boiled down to the following test case:
$ git init test && cd test
$ git config foo."Bar".key test
$ git config foo."bar".key test
$ tail -n 3 .git/config
[foo "Bar"]
key = test
key = test
Sub sections are case sensitive and we have a test for correctly reading
them. However we do not have a test for writing out config correctly with
case sensitive subsection names, which is why this went unnoticed in
6ae996f2acf (git_config_set: make use of the config parser's event
stream, 2018-04-09)
Unfortunately we have to make a distinction between old style configuration
that looks like
[foo.Bar]
key = test
and the new quoted style as seen above. The old style is documented as
case-agnostic, hence we need to keep 'strncasecmp'; although the
resulting setting for the old style config differs from the configuration.
That will be fixed in a follow up patch.
Reported-by: JP Sugarbroad <jpsugar@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
---
config.c | 12 +++++++++++-
t/t1300-config.sh | 1 +
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/config.c b/config.c
index 7968ef7566a..1d3bf9b5fc0 100644
--- a/config.c
+++ b/config.c
@@ -37,6 +37,7 @@ struct config_source {
int eof;
struct strbuf value;
struct strbuf var;
+ unsigned section_name_old_dot_style : 1;
int (*do_fgetc)(struct config_source *c);
int (*do_ungetc)(int c, struct config_source *conf);
@@ -605,6 +606,7 @@ static int get_value(config_fn_t fn, void *data, struct strbuf *name)
static int get_extended_base_var(struct strbuf *name, int c)
{
+ cf->section_name_old_dot_style = 0;
do {
if (c == '\n')
goto error_incomplete_line;
@@ -641,6 +643,7 @@ static int get_extended_base_var(struct strbuf *name, int c)
static int get_base_var(struct strbuf *name)
{
+ cf->section_name_old_dot_style = 1;
for (;;) {
int c = get_next_char();
if (cf->eof)
@@ -2355,14 +2358,21 @@ static int store_aux_event(enum config_event_t type,
store->parsed[store->parsed_nr].type = type;
if (type == CONFIG_EVENT_SECTION) {
+ int (*cmpfn)(const char *, const char *, size_t);
+
if (cf->var.len < 2 || cf->var.buf[cf->var.len - 1] != '.')
return error("invalid section name '%s'", cf->var.buf);
+ if (cf->section_name_old_dot_style)
+ cmpfn = strncasecmp;
+ else
+ cmpfn = strncmp;
+
/* Is this the section we were looking for? */
store->is_keys_section =
store->parsed[store->parsed_nr].is_keys_section =
cf->var.len - 1 == store->baselen &&
- !strncasecmp(cf->var.buf, store->key, store->baselen);
+ !cmpfn(cf->var.buf, store->key, store->baselen);
if (store->is_keys_section) {
store->section_seen = 1;
ALLOC_GROW(store->seen, store->seen_nr + 1,
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index ced13012409..a93f966f128 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -1290,6 +1290,7 @@ test_expect_success 'setting different case sensitive subsections ' '
Qc = v2
[d "e"]
f = v1
+ [d "E"]
Qf = v2
EOF
# exact match
--
2.18.0.132.g195c49a2227
^ permalink raw reply related [relevance 20%]
* [PATCH 2/3] config: fix case sensitive subsection names on writing
2018-08-08 19:50 6% [PATCH 0/3] Resending sb/config-write-fix Stefan Beller
@ 2018-08-08 19:50 20% ` Stefan Beller
2018-08-08 19:50 7% ` [PATCH 1/3] t1300: document current behavior of setting options Stefan Beller
1 sibling, 0 replies; 200+ results
From: Stefan Beller @ 2018-08-08 19:50 UTC (permalink / raw)
To: gitster; +Cc: git, Stefan Beller
A user reported a submodule issue regarding a section mix-up,
but it could be boiled down to the following test case:
$ git init test && cd test
$ git config foo."Bar".key test
$ git config foo."bar".key test
$ tail -n 3 .git/config
[foo "Bar"]
key = test
key = test
Sub sections are case sensitive and we have a test for correctly reading
them. However we do not have a test for writing out config correctly with
case sensitive subsection names, which is why this went unnoticed in
6ae996f2acf (git_config_set: make use of the config parser's event
stream, 2018-04-09)
Unfortunately we have to make a distinction between old style configuration
that looks like
[foo.Bar]
key = test
and the new quoted style as seen above. The old style is documented as
case-agnostic, hence we need to keep 'strncasecmp'; although the
resulting setting for the old style config differs from the configuration.
That will be fixed in a follow up patch.
Reported-by: JP Sugarbroad <jpsugar@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
---
config.c | 12 +++++++++++-
t/t1300-config.sh | 1 +
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/config.c b/config.c
index 02050529788..27e800c7ce8 100644
--- a/config.c
+++ b/config.c
@@ -35,6 +35,7 @@ struct config_source {
int eof;
struct strbuf value;
struct strbuf var;
+ unsigned subsection_case_sensitive : 1;
int (*do_fgetc)(struct config_source *c);
int (*do_ungetc)(int c, struct config_source *conf);
@@ -603,6 +604,7 @@ static int get_value(config_fn_t fn, void *data, struct strbuf *name)
static int get_extended_base_var(struct strbuf *name, int c)
{
+ cf->subsection_case_sensitive = 0;
do {
if (c == '\n')
goto error_incomplete_line;
@@ -639,6 +641,7 @@ static int get_extended_base_var(struct strbuf *name, int c)
static int get_base_var(struct strbuf *name)
{
+ cf->subsection_case_sensitive = 1;
for (;;) {
int c = get_next_char();
if (cf->eof)
@@ -2328,14 +2331,21 @@ static int store_aux_event(enum config_event_t type,
store->parsed[store->parsed_nr].type = type;
if (type == CONFIG_EVENT_SECTION) {
+ int (*cmpfn)(const char *, const char *, size_t);
+
if (cf->var.len < 2 || cf->var.buf[cf->var.len - 1] != '.')
return error("invalid section name '%s'", cf->var.buf);
+ if (cf->subsection_case_sensitive)
+ cmpfn = strncasecmp;
+ else
+ cmpfn = strncmp;
+
/* Is this the section we were looking for? */
store->is_keys_section =
store->parsed[store->parsed_nr].is_keys_section =
cf->var.len - 1 == store->baselen &&
- !strncasecmp(cf->var.buf, store->key, store->baselen);
+ !cmpfn(cf->var.buf, store->key, store->baselen);
if (store->is_keys_section) {
store->section_seen = 1;
ALLOC_GROW(store->seen, store->seen_nr + 1,
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index c15c19bf78d..77c5899d000 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -1260,6 +1260,7 @@ test_expect_success 'setting different case sensitive subsections ' '
Qc = v2
[d "e"]
f = v1
+ [d "E"]
Qf = v2
EOF
# exact match
--
2.18.0.597.ga71716f1ad-goog
^ permalink raw reply related [relevance 20%]
* [PATCH] config: fix case sensitive subsection names on writing
2018-07-27 23:35 8% ` Stefan Beller
@ 2018-07-27 23:36 21% ` Stefan Beller
2018-07-27 23:37 8% ` Stefan Beller
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Stefan Beller @ 2018-07-27 23:36 UTC (permalink / raw)
To: git; +Cc: bmwill, peff, Johannes.Schindelin, gitster, Stefan Beller
A use reported a submodule issue regarding strange case indentation
issues, but it could be boiled down to the following test case:
$ git init test && cd test
$ git config foo."Bar".key test
$ git config foo."bar".key test
$ tail -n 3 .git/config
[foo "Bar"]
key = test
key = test
Sub sections are case sensitive and we have a test for correctly reading
them. However we do not have a test for writing out config correctly with
case sensitive subsection names, which is why this went unnoticed in
6ae996f2acf (git_config_set: make use of the config parser's event
stream, 2018-04-09)
Make the subsection case sensitive and provide a test for writing.
The test for reading is just above this test.
Reported-by: JP Sugarbroad <jpsugar@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
---
I really appreciate the work by DScho (and Peff as I recall him as an active
reviewer there) on 4f4d0b42bae (Merge branch 'js/empty-config-section-fix',
2018-05-08), as the corner cases are all correct, modulo the one line fix
in this patch.
Thanks,
Stefan
config.c | 2 +-
t/t1300-config.sh | 57 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/config.c b/config.c
index 7968ef7566a..de646d2c56f 100644
--- a/config.c
+++ b/config.c
@@ -2362,7 +2362,7 @@ static int store_aux_event(enum config_event_t type,
store->is_keys_section =
store->parsed[store->parsed_nr].is_keys_section =
cf->var.len - 1 == store->baselen &&
- !strncasecmp(cf->var.buf, store->key, store->baselen);
+ !strncmp(cf->var.buf, store->key, store->baselen);
if (store->is_keys_section) {
store->section_seen = 1;
ALLOC_GROW(store->seen, store->seen_nr + 1,
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index 03c223708eb..710e2b04ad8 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -1218,6 +1218,63 @@ test_expect_success 'last one wins: three level vars' '
test_cmp expect actual
'
+test_expect_success 'old-fashioned settings are case insensitive' '
+ test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
+
+ cat >testConfig <<-EOF &&
+ # insensitive:
+ [V.A]
+ r = value1
+ EOF
+ q_to_tab >testConfig_expect <<-EOF &&
+ # insensitive:
+ [V.A]
+ Qr = value2
+ EOF
+
+ for key in "v.a.r" "V.A.r" "v.A.r" "V.a.r"
+ do
+ cp testConfig testConfig_actual &&
+ git config -f testConfig_actual v.a.r value2 &&
+ test_cmp testConfig_expect testConfig_actual
+ done
+'
+
+test_expect_success 'setting different case sensitive subsections ' '
+ test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
+
+ cat >testConfig <<-EOF &&
+ # V insensitive A sensitive:
+ [V "A"]
+ r = value1
+ # same as above:
+ [V "a"]
+ r = value2
+ EOF
+
+ git config -f testConfig v.a.r value3 &&
+ q_to_tab >testConfig_expect <<-EOF &&
+ # V insensitive A sensitive:
+ [V "A"]
+ r = value1
+ # same as above:
+ [V "a"]
+ Qr = value3
+ EOF
+ test_cmp testConfig_expect testConfig &&
+
+ git config -f testConfig v.A.r value4 &&
+ q_to_tab >testConfig_expect <<-EOF &&
+ # V insensitive A sensitive:
+ [V "A"]
+ Qr = value4
+ # same as above:
+ [V "a"]
+ Qr = value3
+ EOF
+ test_cmp testConfig_expect testConfig
+'
+
for VAR in a .a a. a.0b a."b c". a."b c".0d
do
test_expect_success "git -c $VAR=VAL rejects invalid '$VAR'" '
--
2.18.0.345.g5c9ce644c3-goog
^ permalink raw reply related [relevance 21%]
* [PATCH 2/3] config: fix case sensitive subsection names on writing
2018-07-30 23:04 12% ` [PATCH 0/3] " Stefan Beller
@ 2018-07-30 23:04 24% ` Stefan Beller
2018-07-31 20:16 8% ` Junio C Hamano
2018-07-31 15:16 8% ` [PATCH 0/3] " Junio C Hamano
2018-07-30 23:04 7% ` Stefan Beller
2 siblings, 1 reply; 200+ results
From: Stefan Beller @ 2018-07-30 23:04 UTC (permalink / raw)
To: johannes.schindelin; +Cc: bmwill, git, gitster, peff, sbeller
A use reported a submodule issue regarding strange case indentation
issues, but it could be boiled down to the following test case:
$ git init test && cd test
$ git config foo."Bar".key test
$ git config foo."bar".key test
$ tail -n 3 .git/config
[foo "Bar"]
key = test
key = test
Sub sections are case sensitive and we have a test for correctly reading
them. However we do not have a test for writing out config correctly with
case sensitive subsection names, which is why this went unnoticed in
6ae996f2acf (git_config_set: make use of the config parser's event
stream, 2018-04-09)
Make the subsection case sensitive and provide a test for writing.
The test for reading is just above this test.
Reported-by: JP Sugarbroad <jpsugar@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
---
config.c | 2 +-
t/t1300-config.sh | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/config.c b/config.c
index 7968ef7566a..de646d2c56f 100644
--- a/config.c
+++ b/config.c
@@ -2362,7 +2362,7 @@ static int store_aux_event(enum config_event_t type,
store->is_keys_section =
store->parsed[store->parsed_nr].is_keys_section =
cf->var.len - 1 == store->baselen &&
- !strncasecmp(cf->var.buf, store->key, store->baselen);
+ !strncmp(cf->var.buf, store->key, store->baselen);
if (store->is_keys_section) {
store->section_seen = 1;
ALLOC_GROW(store->seen, store->seen_nr + 1,
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index ced13012409..e5d16f53ee1 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -1250,6 +1250,7 @@ test_expect_success 'old-fashioned settings are case insensitive' '
q_to_tab >testConfig_expect <<-EOF &&
[V.A]
r = value1
+ [V "A"]
Qr = value2
EOF
git config -f testConfig_actual "V.A.r" value2 &&
@@ -1262,6 +1263,7 @@ test_expect_success 'old-fashioned settings are case insensitive' '
q_to_tab >testConfig_expect <<-EOF &&
[V.A]
r = value1
+ [v "A"]
Qr = value2
EOF
git config -f testConfig_actual "v.A.r" value2 &&
@@ -1290,6 +1292,7 @@ test_expect_success 'setting different case sensitive subsections ' '
Qc = v2
[d "e"]
f = v1
+ [d "E"]
Qf = v2
EOF
# exact match
--
2.18.0.132.g195c49a2227
^ permalink raw reply related [relevance 24%]
* [PATCH v2 4/5] mailmap: use case-sensitive comparisons for local-parts and names
@ 2021-01-03 21:18 35% ` brian m. carlson
2021-01-04 16:10 11% ` Ævar Arnfjörð Bjarmason
2021-01-03 21:18 19% ` [PATCH v2 3/5] t4203: add failing test for case-sensitive " brian m. carlson
1 sibling, 1 reply; 200+ results
From: brian m. carlson @ 2021-01-03 21:18 UTC (permalink / raw)
To: git; +Cc: Jeff King, Ævar Arnfjörð Bjarmason, Phillip Wood
RFC 5321 is clear that the local-part of an email address (the part
before the at sign) is case sensitive, and this has been the case since
the original RFC 821. It directs us that "the local-part MUST be
interpreted and assigned semantics only by the host specified in the
domain part of the address."
Since we are not that party, it's not correct for us to compare them
case insensitively. However, we do still want to compare the domain
parts case insensitively, so let's add a helper that downcases the
domain and then compare byte by byte.
Similarly, it's not possible for us to correctly case-fold text in a
locale-insensitive way, so our handling of personal names has also been
subject to bugs. Additionally, we've never handled non-ASCII characters
correctly, which means that our previous comparisons really only worked
well for a fraction of the people on the planet. Since our code wasn't
right and it's basically impossible to compare personal names without
regard to case, let's also switch our matching of names to be byte by
byte.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
mailmap.c | 27 ++++++++++++++++++++++++---
t/t4203-mailmap.sh | 4 ++--
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/mailmap.c b/mailmap.c
index d3287b409a..5c52dbb7e0 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -64,7 +64,22 @@ static void free_mailmap_entry(void *p, const char *s)
*/
static int namemap_cmp(const char *a, const char *b)
{
- return strcasecmp(a, b);
+ return strcmp(a, b);
+}
+
+/*
+ * Lowercases the domain (and only the domain) part of an email address. The
+ * local-part, which is defined by RFC 5321 to be case sensitive, is not
+ * affected.
+ */
+static char *lowercase_email(char *s)
+{
+ char *end = strchrnul(s, '@');
+ while (*end) {
+ *end = tolower(*end);
+ end++;
+ }
+ return s;
}
static void add_mapping(struct string_list *map,
@@ -74,9 +89,13 @@ static void add_mapping(struct string_list *map,
struct mailmap_entry *me;
struct string_list_item *item;
+ lowercase_email(new_email);
+
if (old_email == NULL) {
old_email = new_email;
new_email = NULL;
+ } else {
+ lowercase_email(old_email);
}
item = string_list_insert(map, old_email);
@@ -300,7 +319,7 @@ static struct string_list_item *lookup_prefix(struct string_list *map,
* real location of the key if one exists.
*/
while (0 <= --i && i < map->nr) {
- int cmp = strncasecmp(map->items[i].string, string, len);
+ int cmp = strncmp(map->items[i].string, string, len);
if (cmp < 0)
/*
* "i" points at a key definitely below the prefix;
@@ -323,6 +342,7 @@ int map_user(struct mailmap *map,
const char **email, size_t *emaillen,
const char **name, size_t *namelen)
{
+ char *searchable_email = xstrndup(*email, *emaillen);
struct string_list_item *item;
struct mailmap_entry *me;
@@ -330,7 +350,8 @@ int map_user(struct mailmap *map,
(int)*namelen, debug_str(*name),
(int)*emaillen, debug_str(*email));
- item = lookup_prefix(map->mailmap, *email, *emaillen);
+ item = lookup_prefix(map->mailmap, searchable_email, *emaillen);
+ free(searchable_email);
if (item != NULL) {
me = (struct mailmap_entry *)item->util;
if (me->namemap.nr) {
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index 32e849504c..df4a0e03cc 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -187,7 +187,7 @@ nick1 (1):
EOF
-test_expect_failure 'name entry after email entry, case-sensitive local-part' '
+test_expect_success 'name entry after email entry, case-sensitive local-part' '
mkdir -p internal_mailmap &&
echo "<bugs@company.xy> <bugs@company.xx>" >internal_mailmap/.mailmap &&
echo "Internal Guy <BUGS@company.xx>" >>internal_mailmap/.mailmap &&
@@ -195,7 +195,7 @@ test_expect_failure 'name entry after email entry, case-sensitive local-part' '
test_cmp expect actual
'
-test_expect_failure 'name entry after email entry, case-sensitive personal name' '
+test_expect_success 'name entry after email entry, case-sensitive personal name' '
mkdir -p internal_mailmap &&
echo "<bugs@company.xy> <bugs@company.xx>" >internal_mailmap/.mailmap &&
echo "Nick1 <bugs@company.xx> NICK1 <bugs@company.xx>" >internal_mailmap/.mailmap &&
^ permalink raw reply related [relevance 35%]
Results 1-200 of ~600 next [<= 6%] | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2018-07-27 20:51 20% [PATCH] config: fix case sensitive subsection names on writing Stefan Beller
2018-07-27 21:21 15% ` Brandon Williams
2018-07-27 21:39 8% ` Junio C Hamano
2018-07-27 23:35 8% ` Stefan Beller
2018-07-27 23:36 21% ` Stefan Beller
2018-07-27 23:37 8% ` Stefan Beller
2018-07-28 1:01 8% ` Junio C Hamano
2018-07-28 3:52 8% ` Stefan Beller
2018-07-28 10:53 7% ` Jeff King
2018-07-28 1:37 8% ` Junio C Hamano
2018-07-30 12:49 14% ` Johannes Schindelin
2018-07-30 23:04 12% ` [PATCH 0/3] " Stefan Beller
2018-07-30 23:04 24% ` [PATCH 2/3] " Stefan Beller
2018-07-31 20:16 8% ` Junio C Hamano
2018-07-31 15:16 8% ` [PATCH 0/3] " Junio C Hamano
2018-08-01 19:34 ` [PATCH 0/3] sb/config-write-fix done without robbing Peter Stefan Beller
2018-08-01 19:34 20% ` [PATCH 2/3] config: fix case sensitive subsection names on writing Stefan Beller
2018-08-01 21:01 8% ` Ramsay Jones
2018-08-01 22:26 8% ` Junio C Hamano
2018-08-01 22:51 7% ` Junio C Hamano
2018-08-03 0:30 8% ` Stefan Beller
2018-08-03 15:51 8% ` Junio C Hamano
2018-08-01 19:34 7% ` [PATCH 1/3] t1300: document current behavior of setting options Stefan Beller
2018-08-03 0:34 7% ` [PATCH 0/3] Reroll of sb/config-write-fix Stefan Beller
2018-08-03 0:34 20% ` [PATCH 2/3] config: fix case sensitive subsection names on writing Stefan Beller
2018-08-03 0:34 7% ` [PATCH 1/3] t1300: document current behavior of setting options Stefan Beller
2018-07-30 23:04 7% ` Stefan Beller
2018-07-27 21:37 8% ` [PATCH] config: fix case sensitive subsection names on writing Junio C Hamano
2017-10-27 13:55 15% [Bug Report] [includeIf] does not parse case insensitive -> case sensitive symlink gitdir Adrian Kappel
2017-10-27 15:33 9% ` Torsten Bögershausen
2013-03-13 18:45 14% Deletion of git repo causes incorrect block count on HFS+ case-sensitive Ismail Tabtabai
2013-03-13 22:14 8% ` David Aguilar
2011-06-06 6:57 13% [PATCH 0/3] sh-i18n--envsubst; case-sensitive getenv on Windows Johannes Sixt
2011-06-06 7:08 20% ` [PATCH 3/3] Windows: teach getenv to do a case-sensitive search Johannes Sixt
2011-10-05 16:21 14% ` Karsten Blees
2022-06-11 17:03 13% [PATCH] apply: support case-only renames in case-insensitive filesystems Tao Klerks via GitGitGadget
2022-06-12 23:30 6% ` Junio C Hamano
2022-06-14 6:16 7% ` Tao Klerks
2022-06-19 16:10 6% ` [PATCH v2 0/3] RFC: " Tao Klerks via GitGitGadget
2022-06-19 16:10 11% ` [PATCH v2 3/3] " Tao Klerks via GitGitGadget
2023-05-28 9:59 ` [PATCH v3 0/3] " Tao Klerks via GitGitGadget
2023-05-28 9:59 11% ` [PATCH v3 3/3] " Tao Klerks via GitGitGadget
2022-06-11 19:17 ` [PATCH] " Junio C Hamano
2022-06-14 5:13 6% ` Tao Klerks
2022-06-18 0:45 6% ` Junio C Hamano
2008-07-22 16:48 12% [PATCH] In perforce, RCS keywords are case-sensitive Daniel Barkalow
2008-07-24 7:05 8% ` Simon Hausmann
2016-01-14 7:52 12% [issue?]'git branch -D' case sensitive issue 郭腾飞
2016-01-14 11:51 8% ` Torsten Bögershausen
2016-01-14 13:28 14% ` 郭腾飞
2016-01-14 16:42 8% ` Torsten Bögershausen
2016-01-14 17:21 8% ` Junio C Hamano
2016-01-15 22:28 8% ` Jeff King
2021-03-16 14:40 10% [PATCH] config.txt: add missing period Kyle Meyer
2017-01-06 21:56 9% Git filesystem case-insensitive to case-sensitive system broken Steven Robertson
2017-01-07 13:48 9% ` Torsten Bögershausen
2016-08-04 14:54 8% [PATCH] t5533: make it pass on case-sensitive filesystems Johannes Schindelin
2016-08-04 17:18 8% ` Junio C Hamano
2016-08-05 14:19 8% ` Johannes Schindelin
2016-08-08 11:21 8% ` Jeff King
2016-08-08 11:49 8% ` Johannes Schindelin
2017-05-15 12:02 8% git-send-email smtpEncryption option is case sensitive (silently fails if "TLS" is specified) Benjamin Berg
2019-03-01 6:19 8% fast-import fails with case sensitive tags due to case insensitive lock files Wendeborn, Jonathan
2019-03-03 0:25 15% ` brian m. carlson
2019-03-04 7:55 9% ` AW: " Wendeborn, Jonathan
2019-03-04 15:29 9% ` Johannes Schindelin
2019-03-05 6:25 14% ` AW: " Wendeborn, Jonathan
[not found] <CAGZiy71u1Ci_2Uw6jgAw3-9gCgwVrS1ae2Bpz9HCbnj2+EZexA@mail.gmail.com>
[not found] ` <20130816081743.GC2562@calimero.vinschen.de>
2013-08-16 11:54 8% ` [cygwin] Re: Lack of case-sensitive filename handling with git 1.7.9-1 for Cygwin 64-bit Jason Pyeron
2013-08-16 13:21 8% ` Jeff King
2013-07-17 13:22 8% [PATCH] t6131 - skip tests if on case-insensitive file system Mark Levedahl
2017-12-21 13:10 7% [PATCH] config.txt: Document behavior of backslashes in subsections Dave Borowitz
2018-05-22 7:57 7% should config options be treated as case-sensitive? Robert P. J. Day
2018-05-22 12:13 8% ` Ævar Arnfjörð Bjarmason
2018-05-23 1:55 13% ` Junio C Hamano
2018-05-23 7:59 8% ` Robert P. J. Day
2018-05-23 8:58 8% ` Junio C Hamano
2018-05-23 9:04 8% ` Robert P. J. Day
2018-05-23 23:33 7% ` Junio C Hamano
2018-05-22 16:33 8% ` Robert P. J. Day
[not found] <EEA65ED1-2BE0-41AD-84CC-780A9F4D9215@strongestfamilies.com>
2020-07-23 15:20 ` BUG FOLLOWUP: Case insensitivity in worktrees Casey Meijer
2020-07-24 1:19 ` brian m. carlson
2020-07-24 18:14 ` Casey Meijer
2020-07-24 21:09 7% ` brian m. carlson
[not found] <DA41ECC7-D5D4-4E85-A4C3-C55CC2A73D53@hxcore.ol>
[not found] ` <27608194-0D85-4D71-8D88-C1278D8DA173@hxcore.ol>
2020-08-12 19:58 ` Files 'Test.txt' and 'test.txt' are different in Git database, but are the same on Windows file system issue Viktor Hozhyi
2020-08-12 23:02 7% ` brian m. carlson
2016-10-17 1:04 7% [RFC] Case insensitive Git attributes Lars Schneider
2018-06-24 10:05 7% [PATCH] Documentation: declare "core.ignorecase" as internal variable Marc Strapetz
2018-06-26 21:50 6% ` [PATCH v3] " Marc Strapetz
2018-06-24 10:44 6% ` [PATCH v2] " Marc Strapetz
2018-06-28 11:21 6% ` [PATCH v4] Documentation: declare "core.ignoreCase" " Marc Strapetz
2010-08-28 22:21 7% Problems with extra files on git filter-branch when core.ignorecase is true Simeon Maxein
2015-12-11 13:45 6% [RFC] Case insensitive URL rewrite Lars Schneider
2018-08-08 19:50 6% [PATCH 0/3] Resending sb/config-write-fix Stefan Beller
2018-08-08 19:50 20% ` [PATCH 2/3] config: fix case sensitive subsection names on writing Stefan Beller
2018-08-08 19:50 7% ` [PATCH 1/3] t1300: document current behavior of setting options Stefan Beller
2013-01-19 7:19 6% [PATCH 2/3] t0050: honor CASE_INSENSITIVE_FS in add (with different case) Torsten Bögershausen
[not found] <d304880b0812101019ufe85095h46ff0fe00d32bbd0@mail.gmail.com>
2008-12-10 18:22 ` after first git clone of linux kernel repository there are changed files in working dir rdkrsr
2008-12-10 20:20 ` Brett Simmers
[not found] ` <d304880b0812110142g41b80745ic09a7200e02dcdb0@mail.gmail.com>
2008-12-11 17:15 ` Fwd: " rdkrsr
2008-12-11 17:41 6% ` Linus Torvalds
2009-01-19 13:36 ` Hannu Koivisto
2009-01-19 23:52 ` An idea: maybe Git should use a lock/unlock file mode for problematic files? [Was: Re: after first git clone of linux kernel repository there are changed files in working dir] thestar
2009-01-20 20:11 ` Daniel Barkalow
2009-01-20 21:28 ` John Chapman
2009-01-20 22:08 ` Daniel Barkalow
2009-01-20 23:25 ` Alex Riesen
2009-01-21 0:03 6% ` Daniel Barkalow
2014-05-27 22:56 6% RFC: optionally reject case-clone branch names David Turner
2007-04-06 5:42 6% [PATCH] Distinguish branches by more than case in tests Brian Gernhardt
[not found] <alpine.LFD.1.00.0!801211407130.2957@woody.linux-foundation.org>
2008-01-21 22:46 ` git on MacOSX and files with decomposed utf-8 file names Kevin Ballard
2008-01-21 23:44 ` Linus Torvalds
2008-01-22 0:47 ` Kevin Ballard
2008-01-22 1:01 ` Linus Torvalds
[not found] ` <alpine.LFD.1.00.0801211702050.2957@woody.linux-foundati!on.org>
2008-01-22 2:33 ` Kevin Ballard
2008-01-22 2:50 ` Linus Torvalds
2008-01-22 3:04 ` Kevin Ballard
[not found] ` <20080122133427.GB17804@mit.edu>
2008-01-23 0:08 ` Theodore Tso
2008-01-23 0:38 6% ` Kevin Ballard
2008-11-09 15:36 6% [PATCH (GIT-GUI)] git-gui: Fix focus transition in the blame viewer Alexander Gavrilov
2018-07-27 9:59 6% Git clone and case sensitivity Paweł Paruzel
[not found] <5XXEFw0WjtXKd9dpXSxpkskCcgVyG9Db1_zzVSEBNey-kpXSBbmQfYaxZ2Szg6Pbck6hZZTQ5hHzBwG4rhKYXshrdmveEFLPZ9W0V8P_lw@cipher.nrlssc.navy.mil>
2011-09-15 1:59 ` [PATCH 0/4] Honor core.ignorecase for attribute patterns Brandon Casey
2011-09-15 18:12 6% ` Jeff King
2007-08-25 22:18 [PATCH 1/2] gitweb: Lift any characters restriction on searched strings Petr Baudis
2007-08-25 22:18 10% ` [PATCH 2/2] gitweb: Clearly distinguish regexp / exact match searches Petr Baudis
2007-08-26 1:38 10% ` [PATCH] " Petr Baudis
2011-11-19 20:08 Possible bug with branch names and case sensitivity Gerd Knops
2011-11-21 19:18 ` Jay Soffian
2011-11-22 5:21 ` Michael Haggerty
2011-11-22 18:01 6% ` Junio C Hamano
2018-03-17 7:53 [PATCH 00/36] Combine t/helper binaries into a single one Nguyễn Thái Ngọc Duy
2018-03-17 7:54 18% ` [PATCH 35/36] t/helper: merge test-wildmatch into test-tool Nguyễn Thái Ngọc Duy
2018-03-24 7:44 ` [PATCH v2 00/36] Combine t/helper binaries into a single one Nguyễn Thái Ngọc Duy
2018-03-24 7:45 18% ` [PATCH v2 35/36] t/helper: merge test-wildmatch into test-tool Nguyễn Thái Ngọc Duy
2023-01-19 21:13 Race condition on `git checkout -c` Arthur Milchior
2023-01-19 22:55 7% ` Chris Torek
2012-09-09 17:01 [PATCH/RFC] blame: respect "core.ignorecase" Ralf Thielow
2012-09-09 19:24 ` Junio C Hamano
2012-09-10 16:13 6% ` Jeff King
2010-08-27 15:46 Does changing filename case breaks git's rename heuristic? Michael J Gruber
2010-08-27 16:22 6% ` Stephen Bash
2012-03-21 22:50 [PATCH] Demonstrate failure of 'core.ignorecase = true' Peter J. Weisberg
2012-03-22 6:49 ` Johannes Sixt
2012-03-22 11:25 6% ` Zbigniew Jędrzejewski-Szmek
2012-03-22 14:12 14% ` Jeff King
2012-03-21 23:58 ` Junio C Hamano
2012-03-22 20:40 ` PJ Weisberg
2012-03-22 21:08 6% ` Junio C Hamano
2007-05-19 0:13 [PATCH 1/3] git-rev-list: Add regexp tuning options Petr Baudis
2007-05-19 0:13 10% ` [PATCH 3/3] gitweb: Clearly distinguish regexp / exact match searches Petr Baudis
2023-04-01 8:45 [PATCH v7 00/49] completion: git-completion 2.0 patches Felipe Contreras
2023-04-01 8:45 7% ` [PATCH v7 12/49] completion: bash: do not modify COMP_WORDBREAKS Felipe Contreras
2011-03-19 14:28 [PATCH v2] Allow git mv FileA fILEa on case ignore file systems Torsten Bögershausen
2011-03-20 5:50 ` Junio C Hamano
2011-04-10 5:48 7% ` Torsten Bögershausen
2014-07-02 22:18 [PATCH v1 0/4] hashmap improvements Karsten Blees
2014-07-02 22:21 7% ` [PATCH v1 2/4] hashmap: improve struct hashmap member documentation Karsten Blees
2009-05-12 21:29 Request for detailed documentation of git pack protocol Jakub Narebski
2009-06-03 21:20 ` Jakub Narebski
2009-06-03 21:53 ` Tony Finch
2009-06-04 8:45 6% ` Jakub Narebski
2009-06-04 18:41 6% ` Shawn O. Pearce
2009-05-14 13:55 ` Scott Chacon
2009-06-02 21:39 ` Jakub Narebski
2009-06-03 12:29 6% ` Jakub Narebski
2012-11-05 23:50 [PATCH] gitweb: make remote_heads config setting work Phil Pennock
2012-11-09 4:40 ` Junio C Hamano
2012-11-09 16:37 ` Jeff King
2012-11-20 22:21 7% ` Re* " Junio C Hamano
2022-11-05 17:28 [PATCH 0/2] add case insensitivity option to bash completion Alison Winters via GitGitGadget
2022-11-21 0:26 ` [PATCH v2 " Alison Winters via GitGitGadget
2022-11-21 0:26 12% ` [PATCH v2 1/2] completion: add optional ignore-case when matching refs Alison Winters via GitGitGadget
2009-12-14 14:27 Can't handle renamed resources on case insensitive filesystems Lhunath (Maarten B.)
2009-12-14 14:52 7% ` Tomas Carnecky
2018-07-10 8:52 [PATCH v2 0/9] X509 (gpgsm) commit signing support Henning Schild
2018-07-10 8:52 ` [PATCH v2 7/9] gpg-interface: introduce new config to select per gpg format program Henning Schild
2018-07-10 16:54 ` Jeff King
2018-07-10 16:56 ` Jeff King
2018-07-14 18:13 ` brian m. carlson
2018-07-16 21:35 6% ` Jeff King
2011-12-06 21:43 Odd issue - The Diffs That WILL NOT DIE Chris Patti
2011-12-06 21:51 ` Carlos Martín Nieto
2011-12-07 16:54 ` Chris Patti
2011-12-07 22:03 ` Jeff King
2011-12-07 22:24 ` Chris Patti
2011-12-07 22:30 ` Chris Patti
2011-12-07 22:58 6% ` Carlos Martín Nieto
2011-12-07 23:06 6% ` Jeff King
2011-01-08 14:46 git-config does not check validity of variable names Libor Pechacek
2011-01-11 5:59 ` Jeff King
2011-01-19 10:01 ` Libor Pechacek
2011-01-19 14:14 11% ` [PATCH] Documentation fixes in git-config Libor Pechacek
2011-01-21 0:27 ` Jeff King
2011-01-21 10:20 ` Libor Pechacek
2011-01-21 10:25 6% ` [PATCH v2] " Libor Pechacek
2012-03-01 8:19 6% ` [PATCH v3] " Libor Pechacek
2012-03-01 10:59 6% ` [PATCH v4] " Libor Pechacek
2014-05-06 19:46 [PATCH] merge-recursive.c: Fix case-changing merge bug Junio C Hamano
2014-05-06 22:59 7% ` [PATCH 1/2] merge-recursive.c: Fix case-changing merge dturner
2009-07-21 20:19 [JGIT PATCH 00/12] Cleanup Config class Shawn O. Pearce
2009-07-21 20:19 ` [JGIT PATCH 01/12] Use NB.readFully(File) to slurp complete file contents Shawn O. Pearce
2009-07-21 20:19 ` [JGIT PATCH 02/12] Correct name of fileRead member of Config class Shawn O. Pearce
2009-07-21 20:19 ` [JGIT PATCH 03/12] Add setLong to Config Shawn O. Pearce
2009-07-21 20:19 ` [JGIT PATCH 04/12] Fix Config setInt(..., 0) to store "0" not "0 g" Shawn O. Pearce
2009-07-21 20:19 ` [JGIT PATCH 05/12] Rename Config.unsetString to just unset() Shawn O. Pearce
2009-07-21 20:19 ` [JGIT PATCH 06/12] Remove pointless null assignments in Config Shawn O. Pearce
2009-07-21 20:19 ` [JGIT PATCH 07/12] Clarify section and subsection values in Config code Shawn O. Pearce
2009-07-21 20:19 ` [JGIT PATCH 08/12] Don't subclass PrintWriter when writing the Config Shawn O. Pearce
2009-07-21 20:19 ` [JGIT PATCH 09/12] Use a Java 5 style iteration over the Config entries list Shawn O. Pearce
2009-07-21 20:19 12% ` [JGIT PATCH 10/12] Match config subsection names using case sensitive search Shawn O. Pearce
2009-07-22 11:11 7% ` Constantine Plotnikov
2009-07-22 21:37 8% ` Robin Rosenberg
2008-01-16 15:17 git on MacOSX and files with decomposed utf-8 file names Mark Junker
2008-01-16 16:46 ` Jakub Narebski
2008-01-16 20:39 ` Kevin Ballard
2008-01-16 21:51 ` Jakub Narebski
2008-01-16 22:06 ` Kevin Ballard
2008-01-16 22:32 ` Linus Torvalds
2008-01-16 23:11 ` Kevin Ballard
2008-01-16 23:38 ` Linus Torvalds
2008-01-17 0:09 ` Kevin Ballard
2008-01-17 1:16 ` Linus Torvalds
2008-01-17 3:52 ` Kevin Ballard
2008-01-17 4:08 ` Linus Torvalds
2008-01-17 10:08 ` Wincent Colaiuta
2008-01-17 16:43 ` Linus Torvalds
2008-01-17 18:09 ` Mark Junker
2008-01-17 18:12 ` Pedro Melo
[not found] ` <alpine.LSU. 1.00.0801171817340.5731@racer.site>
2008-01-17 18:18 ` Johannes Schindelin
2008-01-17 18:38 6% ` Pedro Melo
2022-11-07 18:35 [PATCH 00/30] [RFC] extensions.refFormat and packed-refs v2 file format Derrick Stolee via GitGitGadget
2022-11-11 23:28 ` Elijah Newren
2022-11-14 0:07 ` Derrick Stolee
2022-11-15 2:47 ` Elijah Newren
2022-11-16 14:45 6% ` Derrick Stolee
2008-01-11 20:19 Re-casing directories on case-insensitive systems Kevin Ballard
2008-01-11 21:29 ` Johannes Schindelin
2008-01-11 21:44 ` Kevin Ballard
2008-01-11 22:08 ` Linus Torvalds
2008-01-11 23:10 ` David Kastrup
2008-01-11 23:12 6% ` Kevin Ballard
2008-01-11 23:26 ` Robin Rosenberg
2008-01-12 0:03 ` Kevin Ballard
2008-01-12 0:15 ` Robin Rosenberg
2008-01-12 0:25 ` Kevin Ballard
2008-01-12 0:27 ` Junio C Hamano
2008-01-12 0:40 ` Johannes Schindelin
2008-01-12 1:16 ` Kevin Ballard
2008-01-12 1:30 ` Junio C Hamano
2008-01-12 1:43 ` Kevin Ballard
2008-01-12 15:03 6% ` Dmitry Potapov
2017-01-22 19:25 [RFC] Case insensitive Git attributes Dakota Hawkins
2017-01-23 18:35 ` Junio C Hamano
2017-01-23 18:42 6% ` Lars Schneider
2017-01-23 19:25 6% ` Junio C Hamano
2013-08-03 17:14 Don't print status output with submodule.<name>.ignore=all brian m. carlson
2013-08-03 17:14 ` [PATCH 1/2] submodule: fix confusing variable name brian m. carlson
2013-08-03 18:14 ` Jonathan Nieder
2013-08-04 17:34 ` Jens Lehmann
2013-08-04 21:29 ` Fredrik Gustafsson
2013-08-08 17:44 ` Ramsay Jones
2013-08-11 19:53 6% ` Mark Levedahl
2020-01-17 15:31 [PATCH v3 0/4] config: allow user to know scope of config options Matthew Rogers via GitGitGadget
2020-01-24 0:21 ` [PATCH v4 0/6] " Matthew Rogers via GitGitGadget
2020-01-24 0:21 6% ` [PATCH v4 2/6] t1300: fix over-indented HERE-DOCs Matthew Rogers via GitGitGadget
2020-01-25 0:39 ` [PATCH v5 0/6] config: allow user to know scope of config options Matthew Rogers via GitGitGadget
2020-01-25 0:39 6% ` [PATCH v5 2/6] t1300: fix over-indented HERE-DOCs Matthew Rogers via GitGitGadget
2020-01-29 3:34 ` [PATCH v6 0/6] config: allow user to know scope of config options Matthew Rogers via GitGitGadget
2020-01-29 3:34 6% ` [PATCH v6 2/6] t1300: fix over-indented HERE-DOCs Matthew Rogers via GitGitGadget
2020-02-10 0:30 ` [PATCH v7 00/10] config: allow user to know scope of config options Matthew Rogers via GitGitGadget
2020-02-10 0:30 6% ` [PATCH v7 02/10] t1300: fix over-indented HERE-DOCs Matthew Rogers via GitGitGadget
2007-10-10 9:40 [BUG] git-filter-branch and filename case changes on insensitive file systems Jonathan del Strother
2007-10-10 13:39 ` Johannes Schindelin
2007-10-10 13:49 6% ` Jonathan del Strother
2008-03-09 10:46 What's cooking in git.git (topics) Junio C Hamano
2008-03-12 7:50 ` Junio C Hamano
2008-03-14 9:00 ` Junio C Hamano
2008-03-23 10:08 ` Junio C Hamano
2008-03-28 1:45 ` Junio C Hamano
2008-03-31 8:40 ` Junio C Hamano
2008-04-04 18:24 ` Junio C Hamano
2008-04-09 9:43 ` Junio C Hamano
2008-04-14 7:00 ` Junio C Hamano
2008-04-19 8:19 ` Junio C Hamano
2008-04-22 10:03 ` Junio C Hamano
2008-04-27 6:04 ` Junio C Hamano
2008-05-06 6:38 ` Junio C Hamano
2008-05-14 22:30 ` Junio C Hamano
2008-05-15 5:51 6% ` Steffen Prohaska
2009-04-23 9:37 [PATCH 0/8] Doc updates to config, format-patch, show-branch Stephen Boyd
2009-04-23 9:37 ` [PATCH 1/8] config.txt: remove pointer to SubmittingPatches Stephen Boyd
2009-04-23 9:37 ` [PATCH 2/8] config.txt: add missing format.{subjectprefix,cc,attach} variables Stephen Boyd
2009-04-23 9:37 ` [PATCH 3/8] Documentation: use lowercase for shallow and deep threading Stephen Boyd
2009-04-23 9:37 ` [PATCH 4/8] git-show-branch.txt: cleanup example description Stephen Boyd
2009-04-23 9:37 ` [PATCH 5/8] git-format-patch.txt: general rewordings and cleanups Stephen Boyd
2009-04-23 9:38 18% ` [PATCH 6/8] config.txt: add missing 'the's and make words plural Stephen Boyd
2009-04-23 9:38 14% ` [PATCH 7/8] config.txt: clarify sentences in the configuration and syntax sections Stephen Boyd
2019-12-17 12:01 [PATCH 00/15] t: replace incorrect test_must_fail usage (part 1) Denton Liu
2019-12-17 12:01 6% ` [PATCH 06/15] t0003: don't use `test_must_fail attr_check` Denton Liu
2019-12-19 22:22 ` [PATCH v2 00/16] t: replace incorrect test_must_fail usage (part 1) Denton Liu
2019-12-19 22:22 6% ` [PATCH v2 06/16] t0003: don't use `test_must_fail attr_check` Denton Liu
2019-12-20 18:15 ` [PATCH v3 00/15] t: replace incorrect test_must_fail usage (part 1) Denton Liu
2019-12-20 18:15 6% ` [PATCH v3 05/15] t0003: don't use `test_must_fail attr_check` Denton Liu
2018-06-22 12:04 Unexpected ignorecase=false behavior on Windows Marc Strapetz
2018-06-22 17:36 ` Johannes Sixt
2018-06-22 20:45 ` Marc Strapetz
2018-06-22 20:58 ` Bryan Turner
2018-06-25 16:34 6% ` Junio C Hamano
2018-06-25 17:38 6% ` Bryan Turner
2006-12-06 6:49 how to revert changes in working tree? Liu Yubao
2006-12-06 8:43 ` Alex Riesen
2006-12-06 9:57 ` Liu Yubao
2006-12-06 10:20 ` Alex Riesen
2006-12-06 11:14 ` Liu Yubao
2006-12-06 18:13 6% ` Shawn Pearce
2022-11-21 13:39 [PATCH] config: introduce an Operating System-specific `includeIf` condition Johannes Schindelin via GitGitGadget
2022-11-21 19:19 ` [PATCH v2] " Johannes Schindelin via GitGitGadget
2022-11-22 14:01 ` Ævar Arnfjörð Bjarmason
2022-11-22 14:31 6% ` Phillip Wood
2022-11-21 13:51 ` [PATCH] " Ævar Arnfjörð Bjarmason
2022-11-21 15:51 6% ` Phillip Wood
2014-02-26 21:06 Branch Name Case Sensitivity Lee Hopkins
2014-02-27 19:50 ` Junio C Hamano
2014-02-27 20:32 ` Torsten Bögershausen
2014-02-27 22:24 ` Karsten Blees
2014-02-27 23:38 ` Lee Hopkins
2014-02-28 6:41 ` Johannes Sixt
2014-02-28 13:56 6% ` Karsten Blees
2014-05-08 8:55 [PATCH 2/2] ignorecase: Fix git mv on insensitive filesystems Torsten Bögershausen
2014-05-08 17:23 ` [PATCH 0/2] " dturner
2014-05-08 17:23 7% ` [PATCH 1/2] merge-recursive.c: Fix case-changing merge dturner
2017-12-28 23:28 [PATCH v3 0/7] increase wildmatch test coverage Ævar Arnfjörð Bjarmason
2017-12-25 0:28 ` [PATCH v2 " Ævar Arnfjörð Bjarmason
2017-12-28 23:28 8% ` [PATCH v3 7/7] wildmatch test: create & test files on disk in addition to in-memory Ævar Arnfjörð Bjarmason
2017-12-29 0:16 7% ` Ævar Arnfjörð Bjarmason
2017-12-23 21:30 ` [PATCH 0/6] increase wildmatch test coverage Ævar Arnfjörð Bjarmason
2017-12-25 0:28 8% ` [PATCH v2 7/7] wildmatch test: create & test files on disk in addition to in-memory Ævar Arnfjörð Bjarmason
2017-12-23 21:30 7% ` [PATCH 6/6] " Ævar Arnfjörð Bjarmason
2014-07-17 15:37 [PATCH 00/13] mingw unicode environment Stepan Kasal
2014-07-17 15:37 19% ` [PATCH 01/13] Revert "Windows: teach getenv to do a case-sensitive search" Stepan Kasal
2007-01-15 0:44 [RFC] Git config file reader in Perl (WIP) Jakub Narebski
2007-01-19 12:10 ` Jakub Narebski
2007-01-19 13:20 ` Johannes Schindelin
2007-01-19 22:44 7% ` Jakub Narebski
2010-03-09 20:26 Modified files directly after clone Benedikt Andreas Koeppel
2010-03-09 21:59 6% ` Tarmigan
2021-01-03 21:18 [PATCH v2 0/5] Hashed mailmap brian m. carlson
2021-01-03 21:18 35% ` [PATCH v2 4/5] mailmap: use case-sensitive comparisons for local-parts and names brian m. carlson
2021-01-04 16:10 11% ` Ævar Arnfjörð Bjarmason
2021-01-06 0:46 8% ` Junio C Hamano
2021-01-12 14:08 8% ` Ævar Arnfjörð Bjarmason
2021-01-03 21:18 19% ` [PATCH v2 3/5] t4203: add failing test for case-sensitive " brian m. carlson
2014-06-11 22:30 [PATCH v4 0/1] receive-pack: optionally deny case clone refs David Turner
2014-06-12 19:47 ` Junio C Hamano
2014-06-13 18:20 ` Ronnie Sahlberg
2014-06-13 21:25 ` Junio C Hamano
2014-06-18 11:33 6% ` Michael Haggerty
2020-06-29 22:07 Commit graph chains with no corresponding files? Jonathan Tan
2020-06-30 1:51 6% ` Derrick Stolee
2008-02-26 12:22 [PATCH 0/4] Improve gitweb search, and other things Jakub Narebski
2008-02-26 12:22 11% ` [PATCH 4/4] gitweb: Clearly distinguish regexp / exact match searches Jakub Narebski
2010-10-03 4:32 [PATCH v2 0/6] Extensions of core.ignorecase=true support Joshua Jensen
2010-10-03 11:48 ` Robert Buck
2010-10-03 18:12 ` Johannes Sixt
2010-10-06 22:04 ` Robert Buck
2010-10-06 22:46 6% ` Joshua Jensen
2021-05-03 17:25 Bug: Changing folder case with `git mv` crashes on case-insensitive file system Mark Amery
2021-05-04 15:19 ` Torsten Bögershausen
2021-05-05 0:23 ` Junio C Hamano
2021-05-06 4:34 ` Torsten Bögershausen
2021-05-06 9:12 6% ` Mark Amery
2008-05-04 21:07 OSX, ZFS, UTF8, git - somebody hates me in this list Randal L. Schwartz
2008-05-04 21:52 ` Shawn O. Pearce
2008-05-04 21:56 ` Randal L. Schwartz
2008-05-04 22:00 ` Randal L. Schwartz
2008-05-05 6:52 6% ` David Brown
2019-12-09 19:42 [PATCH 0/1] sparse-checkout: respect core.ignoreCase in cone mode Derrick Stolee via GitGitGadget
2019-12-09 19:43 ` [PATCH 1/1] " Derrick Stolee via GitGitGadget
2019-12-11 18:44 ` Junio C Hamano
2019-12-11 19:11 6% ` Derrick Stolee
2011-08-26 12:26 Files that cannot be added to the index seanh
2011-08-26 14:10 ` Michael J Gruber
2011-08-26 20:59 ` seanh
2011-08-26 21:12 ` Shaun Ruffell
2011-08-27 15:35 6% ` seanh
2014-02-01 9:14 [PATCH 1/2] init-db.c: honor case on case preserving fs Reuben Hawkins
2014-02-01 9:14 7% ` [PATCH 2/2] init-db.c: factor out probe_case_sensitivity func Reuben Hawkins
2013-01-13 20:38 [PATCH] t0050: mark TC merge (case change) as success Torsten Bögershausen
2013-01-13 23:24 ` Junio C Hamano
2013-01-14 17:53 6% ` Torsten Bögershausen
2008-05-11 16:16 [PATCH 1/4] git-init: autodetect core.ignorecase Steffen Prohaska
2008-05-11 16:16 ` [PATCH 2/4] t0050: Test " Steffen Prohaska
2008-05-11 16:16 ` [PATCH 3/4] t0050: Set core.ignorecase case to activate case insensitivity Steffen Prohaska
2008-05-11 17:10 6% ` Linus Torvalds
2015-02-18 21:44 [PATCH] log --decorate: do not leak "commit" color into the next item Junio C Hamano
2015-03-04 21:33 ` [PATCH v2 0/7] Fix leak of color/attributes in "git log --decorate" Junio C Hamano
2015-03-04 21:33 20% ` [PATCH v2 1/7] Documentation/config.txt: avoid unnecessary negation Junio C Hamano
2014-02-02 13:13 [PATCH] fast-import.c: always honor the filename case Reuben Hawkins
2014-02-02 20:08 ` Torsten Bögershausen
[not found] ` <CAD_8n+RZACW0380co75gWSwVmCJdcH4COsySTF3BFCyKEumXNA@mail.gmail.com>
2014-02-03 20:21 ` Torsten Bögershausen
2014-02-04 0:14 6% ` Junio C Hamano
2018-08-10 15:36 [PATCH v3 0/1] clone: warn on colidding entries on checkout Nguyễn Thái Ngọc Duy
2018-08-12 9:07 9% ` [PATCH v4] clone: report duplicate entries on case-insensitive filesystems Nguyễn Thái Ngọc Duy
2018-08-17 16:16 9% ` [PATCH v5] " Nguyễn Thái Ngọc Duy
2018-08-17 17:20 ` Junio C Hamano
2018-08-17 18:00 9% ` Duy Nguyen
2017-03-18 22:34 [PATCH] rev-parse: match @{u}, @{push} and ^{<type>} case-insensitively Ævar Arnfjörð Bjarmason
2017-03-19 9:19 ` Duy Nguyen
2017-03-19 10:04 6% ` Ævar Arnfjörð Bjarmason
2010-03-30 8:32 git cvsimport and case-insensitive config Giuseppe Bilotta
2010-03-30 17:29 10% ` Junio C Hamano
2017-03-23 13:46 [PATCH v2 0/7] thread lazy_init_name_hash git
2017-03-23 13:47 7% ` [PATCH v2 4/7] hashmap: document memihash_cont, hashmap_disallow_rehash api git
2011-02-23 17:11 RFD: Handling case-colliding filenames on case-insensitive filesystems Johan Herland
2011-02-23 19:07 ` Jay Soffian
2011-02-23 22:52 6% ` Marc Branchaud
2018-01-30 21:21 [PATCH v5 00/10] increase wildmatch test coverage Ævar Arnfjörð Bjarmason
2018-01-04 19:26 ` [PATCH v4 0/7] " Ævar Arnfjörð Bjarmason
2018-01-30 21:21 6% ` [PATCH v5 08/10] wildmatch test: create & test files on disk in addition to in-memory Ævar Arnfjörð Bjarmason
2018-01-30 21:21 6% ` [PATCH v5 07/10] wildmatch test: perform all tests under all wildmatch() modes Ævar Arnfjörð Bjarmason
2018-01-04 11:50 ` [PATCH v2 7/7] wildmatch test: create & test files on disk in addition to in-memory Adam Dinwoodie
2018-01-04 19:26 8% ` [PATCH v4 " Ævar Arnfjörð Bjarmason
2014-04-29 19:02 Bug: Case-insensitive filesystems can cause merge and checkout problems David Turner
2014-05-02 0:21 7% ` [PATCH] merge-recursive.c: Fix case-changing merge bug David Turner
2023-04-13 10:35 Git branch capitalisation bug? Ilya Kamenshchikov
2023-04-13 19:03 ` Torsten Bögershausen
2023-04-13 20:31 ` Junio C Hamano
2023-04-20 7:04 ` Ilya Kamenshchikov
2023-04-20 7:28 7% ` Chris Torek
2011-10-14 8:14 [PATCH 1/4] git-gui: handle config booleans without value Bert Wesarg
2011-10-14 8:14 ` [PATCH 2/4] git-gui: add smart case search mode in searchbar Bert Wesarg
2011-10-14 8:14 8% ` [PATCH 3/4] git-gui: add regexp search mode to the searchbar Bert Wesarg
2011-08-13 7:57 can we have @{U} as an alias for @{u} Sitaram Chamarty
2011-08-14 1:57 ` [PATCH] rev-parse: Allow @{U} as a synonym " Conrad Irwin
2011-08-17 22:53 ` Junio C Hamano
2011-08-18 1:53 ` Nguyen Thai Ngoc Duy
2011-08-18 7:15 ` Michael J Gruber
2011-08-18 8:54 ` Nguyen Thai Ngoc Duy
2011-08-18 9:31 ` Michael J Gruber
2011-08-19 18:54 6% ` Conrad Irwin
2007-01-20 0:19 [RFC] Git config file reader in Perl (WIP) Junio C Hamano
2007-01-20 14:03 7% ` [PATCH] Documentation/config.txt: Document config file syntax better Jakub Narebski
2007-01-22 15:25 7% ` Jakub Narebski
2007-01-24 14:14 7% ` [PATCH 2/1] Documentation/config.txt: Correct info about subsection name Jakub Narebski
2015-06-29 20:20 rebase -i: drop, missing commits and static checks Galan Rémi
2015-06-30 9:19 ` [PATCH 0/3] " Matthieu Moy
2015-06-30 9:19 15% ` [PATCH 2/3] fixup! git rebase -i: warn about removed commits Matthieu Moy
2014-04-06 17:01 [PATCH v10 00/12] Add interpret-trailers builtin Christian Couder
2014-04-06 17:02 ` [PATCH v10 11/12] Documentation: add documentation for 'git interpret-trailers' Christian Couder
2014-04-08 7:30 6% ` Michael Haggerty
2009-09-25 9:40 git log --pretty=format:%h prints (unrequired) abbreviated sha Marco Costalba
2009-09-25 9:46 ` Marco Costalba
2009-09-25 10:33 ` Johannes Sixt
2009-09-25 10:44 ` Marco Costalba
2009-09-25 11:30 ` Marco Costalba
2009-09-25 14:04 6% ` Marco Costalba
2011-07-27 20:53 [PATCHv2] gitweb: Git config keys are case insensitive, make config search too Jakub Narebski
2011-07-28 20:14 ` Junio C Hamano
2011-07-28 21:38 7% ` [PATCHv3] " Jakub Narebski
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).