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
On Wed, Jun 6, 2018 at 10:22 AM, Eric Sunshine wrote:
> On Wed, Jun 6, 2018 at 1:18 PM, Anthony Sottile wrote:
>> On Wed, Jun 6, 2018 at 10:17 AM, Eric Sunshine
>> wrote:
>>> On Wed, Jun 6, 2018 at 1:15 PM, Eric Sunshine
>>> wrote:
>>>> On Mon, J
On Wed, Jun 6, 2018 at 10:17 AM, Eric Sunshine wrote:
> On Wed, Jun 6, 2018 at 1:15 PM, Eric Sunshine wrote:
>> On Mon, Jun 4, 2018 at 4:17 PM, Anthony Sottile wrote:
>>> + for w in I am all CRLF; do echo $w; done | append_cr >allcrlf &&
>>
>
A regression introduced in 8462ff43e42ab67cecd16fdfb59451a53cc8a945 caused
autocrlf rewrites to produce a warning message despite setting safecrlf=false.
Signed-off-by: Anthony Sottile
---
config.c| 2 +-
t/t0020-crlf.sh | 10 ++
2 files changed, 11 insertions(+), 1 deletion
On Mon, Jun 4, 2018 at 12:55 AM, Torsten Bögershausen wrote:
>
> Does the following patch fix your problem ?
>
> diff --git a/config.c b/config.c
> index 6f8f1d8c11..c625aec96a 100644
> --- a/config.c
> +++ b/config.c
> @@ -1233,7 +1233,7 @@ static int git_default_core_config(const char *var,
>
I'm a bit unclear if I was depending on undocumented behaviour or not
here but it seems the messaging has recently changed with respect to
`core.safecrlf`
My reading of the documentation
https://git-scm.com/docs/git-config#git-config-coresafecrlf (I might
be wrong here)
- core.safecrlf = true ->
Functionality was removed in c48f6816f0 but the cli option was not removed.
Signed-off-by: Anthony Sottile <asott...@umich.edu>
---
builtin/diff-files.c | 2 --
builtin/diff.c | 2 --
diff.h | 4 +---
3 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/builti
::git-log[]
That is, it exits with 1 if there were differences and
0 means no differences.
+-q::
--quiet::
Disable all output of the program. Implies `--exit-code`.
endif::git-log[]
0
$
After:
$ ./git diff -q -- Documentation/; echo $?
1
$
Signed-off-by: Anthony Sottile
::git-log[]
That is, it exits with 1 if there were differences and
0 means no differences.
+-q::
--quiet::
Disable all output of the program. Implies `--exit-code`.
endif::git-log[]
0
$
After:
$ ./git diff -q -- Documentation/; echo $?
1
$
Signed-off-by: Anthony Sottile
The handling of `status_only` no longer interferes with the handling of
`unmatch_name_only`. `--quiet` no longer affects the exit code when using
`-L`/`--files-without-match`.
Signed-off-by: Anthony Sottile <asott...@umich.edu>
---
grep.c | 2 +-
t/t7810-grep.sh | 5 +
2
<gits...@pobox.com> wrote:
> Anthony Sottile <asott...@umich.edu> writes:
>
>> Ah yes, I didn't intend to include the first hunk (forgot to amend it
>> out when formatting the patch).
>>
>> I think git's exit codes for -L actually make more sense than the GN
(producing
*something* on stdout) and `1` when the search fails.
Shall I create a new mail with the adjusted patch as suggested above?
(I'm not familiar with the expected workflow).
Anthony
On Tue, Aug 15, 2017 at 2:33 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Anthony Sottile <asott.
The handling of `status_only` no longer interferes with the handling of
`unmatch_name_only`. `--quiet` no longer affects the exit code when using
`-L`/`--files-without-match`.
Signed-off-by: Anthony Sottile <asott...@umich.edu>
---
grep.c | 9 +
t/t7810-grep.sh | 5 ++
Using the latest revision of git:
$ ./git --version
git version 2.14.GIT
$ ./git-grep --files-without-match nope -- blob.c; echo $?
blob.c
0
$ ./git-grep --files-without-match --quiet nope -- blob.c; echo $?
1
I expect both to exit 0
Note that blob.c does not contain "nope", here is the
+1,2 @@\n-1\n-2\n+3\n+4\n'
+ git checkout -- .
+ git -c core.autocrlf=false apply patch
error: patch failed: foo:1
```
My current workaround is:
- try `git apply patch`
- try `git -c core.autocrlf=false apply patch`
which seems to work pretty well.
Anthony
On Tue, Aug 1, 2017 at 1:47 PM,
Here's my minimal reproduction -- it's slightly far-fetched in that it
involves *committing crlf* and
then using `autocrlf=true` (commit lf, check out crlf).
```
#!/bin/bash
set -ex
rm -rf foo
git init foo
cd foo
# Commit crlf into repository
git config --local core.autocrlf false
python3 -c
Thanks!
I'll keep this in mind next time I send a patch.
Anthony
On Mon, Jul 31, 2017 at 9:59 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Anthony Sottile <asott...@umich.edu> writes:
>
>> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
&
I'm not sure if this is a bug or the intended behaviour.
Here's my minimal reproduction (using python3 to write files so I can
control line endings)
```
#!/bin/bash
set -ex
rm -rf repo
git init repo
cd repo
git config --local core.autocrlf input
python3 -c 'open("foo",
To be honest, I'm a bit overwhelmed by the documentation for submitting a patch!
I tried to follow as best I could, here's my attempt (please advise).
>From e88ad689a7587c11f270a10f191a3b6bc52a90d4 Mon Sep 17 00:00:00 2001
From: Anthony Sottile <asott...@umich.edu>
Date: Mon, 31 Jul 2
I actually only expected the --grep to be inverted -- I think I'm on
the same page with what's documented.
I'd be happy to dig into the code and investigate this some more but I
am not familiar with the git codebase, any code hints on where to get
bootstrapped?
Anthony
On Thu, Jun 1, 2017 at
commit --allow-empty -m "foo"
[master (root-commit) c9df62b] foo
asottile@asottile-VirtualBox:/tmp/test$ git commit -m "blah" --allow-empty
[master 9e3ee9b] blah
asottile@asottile-VirtualBox:/tmp/test$ git log
commit 9e3ee9bc1adab2ae8eb1884a8f6237da18dfd27b
Author: Anthony Sottile
Noticed as part of my automated tests here:
https://travis-ci.org/pre-commit/pre-commit/jobs/173957051
Minimal reproduction:
rm -rf /tmp/git /tmp/foo /tmp/bar
git clone git://github.com/git/git --depth 1 /tmp/git
pushd /tmp/git
make -j 8
popd
export PATH="/tmp/git:$PATH"
git init /tmp/foo
git
* Short description of the problem *
It seems GIT_WORK_DIR is now exported invariantly when calling git
hooks such as pre-commit. If these hooks involve cloning repositories
they will not fail due to this exported environment variable. This
was not the case in prior versions (such as v2.5.0).
23 matches
Mail list logo
