Re: Incorrect unified diff when run with "--find-copies-harder"
Hi Andrei, Thanks for the prompt reply. I'm sorry for the false alarm, I should've investigated this more thoroughly before submitting a bug. Now I see I get that context hint in many diffs, I was confused by many simple file diffs I was working with recently which didn't have it. Thank you for your time and help. Kind regards, Daniil Penkin вс, 24 июн. 2018 г. в 23:33, Andrei Rybak : > > On 2018-06-24 12:36, Daniel Penkin wrote: > > Hello, > > > > Hi, > > > I believe I found a bug in how Git represents a diff when invoked with > > "--find-copies-harder" parameter. > > Specifically, the unified diff header of a hunk contains an extra > > piece of text which appears to be a line from the context (i.e. > > unchanged line), something like this: > > > > > git diff --find-copies-harder d00ca3f 20fb313 > > diff --git a/test.txt b/copy.txt > > similarity index 81% > > copy from test.txt > > copy to copy.txt > > index 734156d..43a3f9d 100644 > > --- a/test.txt > > +++ b/copy.txt > > @@ -2,6 +2,7 @@ line 1 > > line 2 > > line 3 > > line 4 > > +added line > > line 5 > > line 6 > > line 7 > > > > Note "line 1" after the standard unified diff header. > > > > This text after @@ is usually a function name in a programming language or > some other relevant part of hunk context, to help user navigate the diff more > easily. What you are getting is the default version of it, as it is just > comparing txt files. You can read more about it in the documentation of > gitattributes: > > https://git-scm.com/docs/gitattributes#_defining_a_custom_hunk_header > > > I prepared a sample repository with a minimal file I can reproduce > > this problem with: > > https://bitbucket.org/dpenkin/find-copies-harder-bug > > > > I'm running Git 2.18.0 on a macOS, but I also tried with Git 2.15.0 > > and 2.8.6 running on Alpine Linux and was able to reproduce the same > > problem. > > > > Please advise whether this is expected output or is indeed a bug. > > > > This is expected output. > > > Thank you. > > > > Kind regards, > > Daniil Penkin > > > > -- > Best regards, Andrei R.
Re: [PATCH v2] Documentation: declare "core.ignorecase" as internal variable
On Sun, Jun 24, 2018 at 12:44:26PM +0200, Marc Strapetz wrote: > 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. This is a nice explanation, thanaks for that, Some users of Mac OS or SAMBA will see core.ignoreCase=true, and are not supposed to change it. The same explanation (Git for Windows) is alse valid for HFS+ and APFS under Mac OS and VFAT under all OS. (or even an ext4 file system under Linux exported to Mac OS using SAMBA) May be something like this? Git on a case insensitve file system (Windows, Mac OS, VFAT, SAMBA) 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 . > > [1] https://marc.info/?l=git=152972992729761=2 > > Signed-off-by: Marc Strapetz > --- > 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
Re: Incorrect unified diff when run with "--find-copies-harder"
On 2018-06-24 12:36, Daniel Penkin wrote: > Hello, > Hi, > I believe I found a bug in how Git represents a diff when invoked with > "--find-copies-harder" parameter. > Specifically, the unified diff header of a hunk contains an extra > piece of text which appears to be a line from the context (i.e. > unchanged line), something like this: > > > git diff --find-copies-harder d00ca3f 20fb313 > diff --git a/test.txt b/copy.txt > similarity index 81% > copy from test.txt > copy to copy.txt > index 734156d..43a3f9d 100644 > --- a/test.txt > +++ b/copy.txt > @@ -2,6 +2,7 @@ line 1 > line 2 > line 3 > line 4 > +added line > line 5 > line 6 > line 7 > > Note "line 1" after the standard unified diff header. > This text after @@ is usually a function name in a programming language or some other relevant part of hunk context, to help user navigate the diff more easily. What you are getting is the default version of it, as it is just comparing txt files. You can read more about it in the documentation of gitattributes: https://git-scm.com/docs/gitattributes#_defining_a_custom_hunk_header > I prepared a sample repository with a minimal file I can reproduce > this problem with: > https://bitbucket.org/dpenkin/find-copies-harder-bug > > I'm running Git 2.18.0 on a macOS, but I also tried with Git 2.15.0 > and 2.8.6 running on Alpine Linux and was able to reproduce the same > problem. > > Please advise whether this is expected output or is indeed a bug. > This is expected output. > Thank you. > > Kind regards, > Daniil Penkin > -- Best regards, Andrei R.
Re: [PATCH v2] Documentation: declare "core.ignorecase" as internal variable
Hello Bryan, hello Marc, Marc Strapetz writes: > 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]: Does this apply to Mac OS X as well? I helped someone recently who had trouble with renamed files (case change only) in a repository residing on a case-insensitive HFS+ file system. Setting core.ignoreCase explicitly (apparently it didn't get set automatically during clone for some reason) helped; the files are recognised correctly now and the case-only rename could be pulled. Is the post-clone change insufficient on Mac OS X? Do we need to replace the existing repository and clone again using '--config core.ignoreCase=true' to avoid future issues? PS: Including the message-id of the mail being referenced would be useful; the id in the URL you gave is specific to the service being used (public-inbox.org) and cannot be used to reference the mail in any other archive (local or public). If you use the mid: syntax (RFC 1630) some MUAs can even recognise the link and open the mail directly. Sascha -- Softwareentwicklung Sascha Silbe, Niederhofenstraße 5/1, 71229 Leonberg https://se-silbe.de/ USt-IdNr.: DE281696641
[PATCH v2] Documentation: declare "core.ignorecase" as internal variable
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=152972992729761=2 Signed-off-by: Marc Strapetz --- 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
Incorrect unified diff when run with "--find-copies-harder"
Hello, I believe I found a bug in how Git represents a diff when invoked with "--find-copies-harder" parameter. Specifically, the unified diff header of a hunk contains an extra piece of text which appears to be a line from the context (i.e. unchanged line), something like this: > git diff --find-copies-harder d00ca3f 20fb313 diff --git a/test.txt b/copy.txt similarity index 81% copy from test.txt copy to copy.txt index 734156d..43a3f9d 100644 --- a/test.txt +++ b/copy.txt @@ -2,6 +2,7 @@ line 1 line 2 line 3 line 4 +added line line 5 line 6 line 7 Note "line 1" after the standard unified diff header. I prepared a sample repository with a minimal file I can reproduce this problem with: https://bitbucket.org/dpenkin/find-copies-harder-bug I'm running Git 2.18.0 on a macOS, but I also tried with Git 2.15.0 and 2.8.6 running on Alpine Linux and was able to reproduce the same problem. Please advise whether this is expected output or is indeed a bug. Thank you. Kind regards, Daniil Penkin
Re: [PATCH] Documentation: declare "core.ignorecase" as internal variable
On Sun, Jun 24, 2018 at 6:05 AM Marc Strapetz wrote: > 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=152972992729761=2 Thanks for following up the discussion with a patch. The commit message, unfortunately, doesn't explain the "why" of this change in enough detail for someone to understand the issue without chasing down that link (which could go stale, or the reader might be offline). Incorporating Bryan's explanation[1] directly into the commit message would likely be a good idea if you happen to re-roll. 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://public-inbox.org/git/cagyf7-gvcn8ehmgtazcdjnyndflwvh8hvbdmzqju40nze0n...@mail.gmail.com/ > Signed-off-by: Marc Strapetz
Re: Unexpected ignorecase=false behavior on Windows
On 22.06.2018 22:58, Bryan Turner wrote: On Fri, Jun 22, 2018 at 1:45 PM Marc Strapetz wrote: On 22.06.2018 19:36, Johannes Sixt wrote: Am 22.06.2018 um 14:04 schrieb Marc Strapetz: On Windows, when creating following repository: $ git init $ echo "1" > file.txt $ git add . $ git commit -m "initial import" $ ren file.txt File.txt $ git config core.ignorecase false This is a user error. core.ignorecase is *not* an instruction as in "hey, Git, do not ignore the case of file names". It is better regarded as an internal value, with which Git remembers how it should treat the names of files that it receives when it traverses the directories on the disk. Git could probe the file system capabilities each time it runs. But that would be wasteful. Hence, this probe happens only once when the repository is initialized, and the result is recorded in this configuration value. You should not change it. Sorry, it looks like my example was misleading. I'm actually questioning current behavior in case of Windows repositories with core.ignorecase initialized to false, like in following setup: $ git init $ git config core.ignorecase false The repository is now set up to be case-sensitive on Windows. From this point on, core.ignorecase won't change anymore and the repository will be filled: I don't think Hannes's point was _when_ you changed it; it was that you changed it _at all_. 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. NTFS is case-preserving-but-case-insensitive by default[1]. So long as that's the case, the only mode for running Git on Windows is core.ignoreCase=true. Hopefully this clarifies things! Thanks, it does. In this case, I'd suggest to make this clear in the documentation, too. I've just sent a patch. -Marc
[PATCH] Documentation: declare "core.ignorecase" as internal variable
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=152972992729761=2 Signed-off-by: Marc Strapetz --- 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
Re: ^D to credentials prompt results in "fatal: ... Success"
On Fri, Jun 22, 2018 at 07:42:38PM -0700, Anthony Sottile wrote:
> A bit of an amusing edge case.
>
> I'm not exactly sure the correct approach to fix this but here's my
> reproduction, triage, and a few potential options I see.
>
> Note that after the username prompt, I pressed ^D
>
> $./prefix/bin/git --version
> git version 2.18.0
> $ PATH=$PWD/prefix/bin:$PATH git clone
> https://github.com/asottile/this-does-not-exist-i-promise
> Cloning into 'this-does-not-exist-i-promise'...
> Username for 'https://github.com': fatal: could not read Username for
> 'https://github.com': Success
Yeah, agreed that is not ideal.
> I see a couple of options here:
>
> 1. special case EOF in `git_terminal_prompt` / `git_prompt` and
> produce an error message such as:
>
> fatal: could not read Username for 'https://github.com': EOF
> [...]
>
> 2. treat EOF less specially
>
> The function this is replacing, `getpass` simply returns an empty
> string on `EOF`. This patch would implement that:
Either of those would be fine with me. We do not have to adhere to
getpass() behavior exactly (the whole point of having our custom wrapper
is that getpass() behaves badly in a few situations). But I doubt
anybody really cares that much either way, so we might as well have
consistent behavior.
> diff --git a/compat/terminal.c b/compat/terminal.c
> index fa13ee672..8bd08108e 100644
> --- a/compat/terminal.c
> +++ b/compat/terminal.c
> @@ -122,7 +122,7 @@ char *git_terminal_prompt(const char *prompt, int echo)
> fputs(prompt, output_fh);
> fflush(output_fh);
>
> - r = strbuf_getline_lf(, input_fh);
> + strbuf_getline_lf(, input_fh);
> if (!echo) {
> putc('\n', output_fh);
> fflush(output_fh);
> @@ -132,8 +132,6 @@ char *git_terminal_prompt(const char *prompt, int echo)
> fclose(input_fh);
> fclose(output_fh);
>
> - if (r == EOF)
> - return NULL;
> return buf.buf;
> }
I think this goes too far, though. We get EOF from strbuf_getline on
actual EOF _or_ on a real error. And we'd want to keep reporting a real
error, since it may tell the user something useful.
I suspect you probably need to check ferror(input_fh) before closing,
and rewrite "r" to 0 in that case.
-Peff
[BUG] url schemes should be case-insensitive
We seem to match url schemes case-sensitively: $ git clone SSH://example.com/repo.git Cloning into 'repo'... fatal: Unable to find remote helper for 'SSH' whereas rfc3986 is clear that the scheme portion is case-insensitive. We probably ought to match at least our internal ones with strcasecmp. Possibly we should also normalize external helpers (so "FOO://bar" would always call git-remote-foo, never git-remote-FOO). We could probably also give an advise() message in the above output, suggesting that the problem is likely one of: 1. They misspelled the scheme. 2. They need to install the appropriate helper. This may be a good topic for somebody looking for low-hanging fruit to get involved in development (I'd maybe call it a #leftoverbits, but since I didn't start on it, I'm not sure if it counts as "left over" ;)). -Peff
