[PATCH v2] log -G: Ignore binary files

[Thomas Braun]

The -G option of log looks for the differences whose patch text
contains added/removed lines that match regex.

As the concept of patch text only makes sense for text files, we need to
ignore binary files when searching with -G  as well.

The -S option of log looks for differences that changes
the number of occurrences of the specified block of text (i.e.
addition/deletion) in a file. As we want to keep the current behaviour,
add a test to ensure it.

Signed-off-by: Thomas Braun 
---

Changes since v1:
- Merged both patches into one
- Adapted commit messages
- Added missing support for -a flag with tests
- Placed new code into correct location to be able to reuse an existing
  optimization
- Uses help-suggested -Ga writing without spaces
- Uses orphan branches instead of cannonball cleanup with rm -rf
- Changed search text to make it clear that it is not about the \0 boundary

 Documentation/gitdiffcore.txt |  2 +-
 diffcore-pickaxe.c|  6 ++
 t/t4209-log-pickaxe.sh| 40 +++
 3 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt
index c0a60f3158..059ddd3431 100644
--- a/Documentation/gitdiffcore.txt
+++ b/Documentation/gitdiffcore.txt
@@ -242,7 +242,7 @@ textual diff has an added or a deleted line that matches 
the given
 regular expression.  This means that it will detect in-file (or what
 rename-detection considers the same file) moves, which is noise.  The
 implementation runs diff twice and greps, and this can be quite
-expensive.
+expensive.  Binary files without textconv filter are ignored.
 
 When `-S` or `-G` are used without `--pickaxe-all`, only filepairs
 that match their respective criterion are kept in the output.  When
diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
index 69fc55ea1e..4cea086f80 100644
--- a/diffcore-pickaxe.c
+++ b/diffcore-pickaxe.c
@@ -154,6 +154,12 @@ static int pickaxe_match(struct diff_filepair *p, struct 
diff_options *o,
if (textconv_one == textconv_two && diff_unmodified_pair(p))
return 0;
 
+   if ((o->pickaxe_opts & DIFF_PICKAXE_KIND_G) &&
+   !o->flags.text &&
+   ((!textconv_one && diff_filespec_is_binary(o->repo, p->one)) ||
+(!textconv_two && diff_filespec_is_binary(o->repo, p->two
+   return 0;
+
mf1.size = fill_textconv(o->repo, textconv_one, p->one, );
mf2.size = fill_textconv(o->repo, textconv_two, p->two, );
 
diff --git a/t/t4209-log-pickaxe.sh b/t/t4209-log-pickaxe.sh
index 844df760f7..5c3e2a16b2 100755
--- a/t/t4209-log-pickaxe.sh
+++ b/t/t4209-log-pickaxe.sh
@@ -106,4 +106,44 @@ test_expect_success 'log -S --no-textconv (missing 
textconv tool)' '
rm .gitattributes
 '
 
+test_expect_success 'log -G ignores binary files' '
+   git checkout --orphan orphan1 &&
+   printf "a\0a" >data.bin &&
+   git add data.bin &&
+   git commit -m "message" &&
+   git log -Ga >result &&
+   test_must_be_empty result
+'
+
+test_expect_success 'log -G looks into binary files with -a' '
+   git checkout --orphan orphan2 &&
+   printf "a\0a" >data.bin &&
+   git add data.bin &&
+   git commit -m "message" &&
+   git log -a -Ga >actual &&
+   git log >expected &&
+   test_cmp actual expected
+'
+
+test_expect_success 'log -G looks into binary files with textconv filter' '
+   git checkout --orphan orphan3 &&
+   echo "* diff=bin" > .gitattributes &&
+   printf "a\0a" >data.bin &&
+   git add data.bin &&
+   git commit -m "message" &&
+   git -c diff.bin.textconv=cat log -Ga >actual &&
+   git log >expected &&
+   test_cmp actual expected
+'
+
+test_expect_success 'log -S looks into binary files' '
+   git checkout --orphan orphan4 &&
+   printf "a\0a" >data.bin &&
+   git add data.bin &&
+   git commit -m "message" &&
+   git log -Sa >actual &&
+   git log >expected &&
+   test_cmp actual expected
+'
+
 test_done
-- 
2.19.0.271.gfe8321ec05.dirty

Re: [PATCH v1 1/2] log -G: Ignore binary files

[Thomas Braun]

> Ævar Arnfjörð Bjarmason  hat am 22. November 2018 um 11:16 
> geschrieben:

[...]

> >
> > +test_expect_success 'log -G ignores binary files' '
> > +   rm -rf .git &&
> > +   git init &&
> > +   printf "a\0b" >data.bin &&
> > +   git add data.bin &&
> > +   git commit -m "message" &&
> > +   git log -G a >result &&
> 
> Would be less confusing as "-Ga" since that's the invocation we
> document, even though I see (but wasn't aware that...) "-G a" works too.

Done.

> > +   test_must_be_empty result
> > +'
> > +
> > +test_expect_success 'log -G looks into binary files with textconv filter' '
> > +   rm -rf .git &&
> > +   git init &&
> > +   echo "* diff=bin" > .gitattributes &&
> > +   printf "a\0b" >data.bin &&
> > +   git add data.bin &&
> > +   git commit -m "message" &&
> > +   git -c diff.bin.textconv=cat log -G a >actual &&
> > +   git log >expected &&
> > +   test_cmp actual expected
> > +'
> > +
> >  test_done
> 
> This patch seems like the wrong direction to me. In particular the
> assertion that "the concept of differences only makes sense for text
> files". That's just not true. This patch breaks this:
> 
> (
> rm -rf /tmp/g-test &&
> git init /tmp/g-test &&
> cd /tmp/g-test &&
> for i in {1..10}; do
> echo "Always matching thensome 5" >file &&
> printf "a thensome %d binary \0" $i >>file &&
> git add file &&
> git commit -m"Bump $i"
> done &&
> git log -Gthensome.*5
> )
> 
> Right now this will emit 3/10 patches, and the right ones! I.e. "Bump
> [156]". The 1st one because it introduces the "Always matching thensome
> 5". Then 5/6 because the add/remove the string "a thensome 5 binary",
> respectively. Which matches /thensome.*5/.

log -p does not show you the patch text in your example because it is treated
as binary. And currently "log -G" has a different opinion into what it looks
and what it ignores. My patch tries to bring both more in line.
 
> I.e. in the first one we do a regex match against the content here
> because we don't have both sides:
> https://github.com/git/git/blob/v2.19.2/diffcore-pickaxe.c#L48-L53
> 
> And then for the later ones where we have both sides we end up in
> diffgrep_consume():
> https://github.com/git/git/blob/v2.19.2/diffcore-pickaxe.c#L27-L36
> 
> I think there may be a real issue here to address, which might be some
> combination of:
> 
>  a) Even though the diffcore can do a binary diff internally, this is
> not what it exposes with "-p", we just say "Binary files differ".
> 
> I don't know how to emit the raw version we'll end up passing to
> diffgrep_consume() in this case. Is it just --binary without the
> encoding? I don't know...
> 
>  b) Your test case shows that you're matching a string at a \0
> boundary. Is this perhaps something you ran into? I.e. that we don't
> have some -F version of -G so we can't supply regexes that match
> past a \0? I had some related work on grep for this that hasn't been
> carried over to the diffcore:
> 
> git log --grep='grep:.*\\0' --author=Ævar
> 
>  c) Is this binary diff we end up matching against just bad in some
> cases? I haven't dug but that wouldn't surprise me, i.e. that it's
> trying to be line-based so we'll overmatch in many cases.
> 
> So maybe this is something that should be passed down as a flag? See a
> recent discussion at
> https://public-inbox.org/git/87lg77cmr1@evledraar.gmail.com/ for how
> that could be done.

It is not about the \0 boundary. v2 of the patches will clarify that. My main
motiviation is to speed up "log -G" as that takes a considerable amount of time 
when it wades through MBs of binary files which change often. And in multiple 
places
I can already treat binary files differently (e.g. turn off delta compression, 
skip
trying to diff them, no EOL normalization). And for me making log -G ignore 
what git 
thinks are binary files is making the line clearer between what should be 
treated
as binary and what as text.

> Also if we don't have some tests already that were failing with this
> patch we really should have those as "let's test the current behavior
> first". Unfortunately tests in this area are really lacking, see
> e.g. my:
> 
> git log --author=Junio --min-parents=2 --grep=ab/.*grep
> 
> For some series of patches to grep where to get one patch in I needed to
> often lead with 5-10 test patches to convince reviewers that I knew what
> I was changing, and also to be comfortable that I'd covered all the edge
> cases we currently supported, but weren't testing for.

I'm happy to add more test cases to convince everyone involved :)

Re: [PATCH v1 2/2] log -S: Add test which searches in binary files

[Thomas Braun]

> Junio C Hamano  hat am 22. November 2018 um 02:34 
> geschrieben:
> 
> 
> Thomas Braun  writes:
> 
> > The -S  option of log looks for differences that changes the
> > number of occurrences of the specified string (i.e. addition/deletion)
> > in a file.
> 
> s/-S /-S/ and
> s/the specified string/the specified block of text/ would make it
> more in line with how Documentation/gitdiffcore.txt explains it.
> The original discussion from early 2017 also explains with a pointer
> why the primary mode of -S is not  but is .

Thanks for the pointer. I've updated the commit message.
 
> > diff --git a/t/t4209-log-pickaxe.sh b/t/t4209-log-pickaxe.sh
> > index 42cc8afd8b..d430f6f2f9 100755
> > --- a/t/t4209-log-pickaxe.sh
> > +++ b/t/t4209-log-pickaxe.sh
> > @@ -128,4 +128,15 @@ test_expect_success 'log -G looks into binary files 
> > with textconv filter' '
> > test_cmp actual expected
> >  '
> >  
> > +test_expect_success 'log -S looks into binary files' '
> > +   rm -rf .git &&
> > +   git init &&
> 
> Same comment as the one for 1/2 applies here.

Fixed as well.

> > +   printf "a\0b" >data.bin &&
> > +   git add data.bin &&
> > +   git commit -m "message" &&
> > +   git log -S a >actual &&
> > +   git log >expected &&
> > +   test_cmp actual expected
> > +'
> > +
> >  test_done
> 
> Other than these, I think both patches look sensible.  Thanks for
> resurrecting the old topic and reigniting it.
>

Re: [PATCH v1 1/2] log -G: Ignore binary files

[Thomas Braun]

> Junio C Hamano  hat am 27. November 2018 um 01:51 
> geschrieben:
> 
> 
> Stefan Beller  writes:
> 
> > On Wed, Nov 21, 2018 at 1:08 PM Thomas Braun
> >  wrote:
> >>
> >> The -G  option of log looks for the differences whose patch text
> >> contains added/removed lines that match regex.
> >>
> >> The concept of differences only makes sense for text files, therefore
> >> we need to ignore binary files when searching with -G  as well.
> >
> > What about partial text/partial binary files?
> 
> Good point. You'd use "-a" (or "--text") to tell the diff machinery
> to treat the contents as text, and the new logic must pay attention
> to that command line option.

Yes exactly. Either use -a for the occasional use or a textconv filter
for permanent use.

Coming from the opposite side: I usually mark svg files as binary as the
textual diff is well, let's say uninspiring.

Re: [PATCH v1 2/2] log -S: Add test which searches in binary files

[Thomas Braun]

> Ævar Arnfjörð Bjarmason  hat am 22. November 2018 um 10:14 
> geschrieben:
> 
> 
> 
> On Wed, Nov 21 2018, Thomas Braun wrote:
> 
> > The -S  option of log looks for differences that changes the
> > number of occurrences of the specified string (i.e. addition/deletion)
> > in a file.
> >
> > Add a test to ensure that we keep looking into binary files with -S
> > as changing that would break backwards compatibility in unexpected ways.
> >
> > Signed-off-by: Thomas Braun 
> > ---
> >  t/t4209-log-pickaxe.sh | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/t/t4209-log-pickaxe.sh b/t/t4209-log-pickaxe.sh
> > index 42cc8afd8b..d430f6f2f9 100755
> > --- a/t/t4209-log-pickaxe.sh
> > +++ b/t/t4209-log-pickaxe.sh
> > @@ -128,4 +128,15 @@ test_expect_success 'log -G looks into binary files 
> > with textconv filter' '
> > test_cmp actual expected
> >  '
> >
> > +test_expect_success 'log -S looks into binary files' '
> > +   rm -rf .git &&
> > +   git init &&
> > +   printf "a\0b" >data.bin &&
> > +   git add data.bin &&
> > +   git commit -m "message" &&
> > +   git log -S a >actual &&
> > +   git log >expected &&
> > +   test_cmp actual expected
> > +'
> > +
> >  test_done
> 
> This should just be part of 1/2 since the behavior is changed there &
> the commit message should describe both cases.

My reasoning was that this is a separate test which does not fit in with the 
other part.
But I'm happy in folding both into one patch. Done.

Re: [PATCH v1 1/2] log -G: Ignore binary files

[Thomas Braun]

> Ævar Arnfjörð Bjarmason  hat am 22. November 2018 um 11:16 
> geschrieben:

[...]

> >
> > +test_expect_success 'log -G ignores binary files' '
> > +   rm -rf .git &&
> > +   git init &&
> > +   printf "a\0b" >data.bin &&
> > +   git add data.bin &&
> > +   git commit -m "message" &&
> > +   git log -G a >result &&
> 
> Would be less confusing as "-Ga" since that's the invocation we
> document, even though I see (but wasn't aware that...) "-G a" works too.

Done.

> > +   test_must_be_empty result
> > +'
> > +
> > +test_expect_success 'log -G looks into binary files with textconv filter' '
> > +   rm -rf .git &&
> > +   git init &&
> > +   echo "* diff=bin" > .gitattributes &&
> > +   printf "a\0b" >data.bin &&
> > +   git add data.bin &&
> > +   git commit -m "message" &&
> > +   git -c diff.bin.textconv=cat log -G a >actual &&
> > +   git log >expected &&
> > +   test_cmp actual expected
> > +'
> > +
> >  test_done
> 
> This patch seems like the wrong direction to me. In particular the
> assertion that "the concept of differences only makes sense for text
> files". That's just not true. This patch breaks this:
> 
> (
> rm -rf /tmp/g-test &&
> git init /tmp/g-test &&
> cd /tmp/g-test &&
> for i in {1..10}; do
> echo "Always matching thensome 5" >file &&
> printf "a thensome %d binary \0" $i >>file &&
> git add file &&
> git commit -m"Bump $i"
> done &&
> git log -Gthensome.*5
> )
> 
> Right now this will emit 3/10 patches, and the right ones! I.e. "Bump
> [156]". The 1st one because it introduces the "Always matching thensome
> 5". Then 5/6 because the add/remove the string "a thensome 5 binary",
> respectively. Which matches /thensome.*5/.

log -p does not show you the patch text in your example because it is treated
as binary. And currently "log -G" has a different opinion into what it looks
and what it ignores. My patch tries to bring both more in line.
 
> I.e. in the first one we do a regex match against the content here
> because we don't have both sides:
> https://github.com/git/git/blob/v2.19.2/diffcore-pickaxe.c#L48-L53
> 
> And then for the later ones where we have both sides we end up in
> diffgrep_consume():
> https://github.com/git/git/blob/v2.19.2/diffcore-pickaxe.c#L27-L36
> 
> I think there may be a real issue here to address, which might be some
> combination of:
> 
>  a) Even though the diffcore can do a binary diff internally, this is
> not what it exposes with "-p", we just say "Binary files differ".
> 
> I don't know how to emit the raw version we'll end up passing to
> diffgrep_consume() in this case. Is it just --binary without the
> encoding? I don't know...
> 
>  b) Your test case shows that you're matching a string at a \0
> boundary. Is this perhaps something you ran into? I.e. that we don't
> have some -F version of -G so we can't supply regexes that match
> past a \0? I had some related work on grep for this that hasn't been
> carried over to the diffcore:
> 
> git log --grep='grep:.*\\0' --author=Ævar
> 
>  c) Is this binary diff we end up matching against just bad in some
> cases? I haven't dug but that wouldn't surprise me, i.e. that it's
> trying to be line-based so we'll overmatch in many cases.
> 
> So maybe this is something that should be passed down as a flag? See a
> recent discussion at
> https://public-inbox.org/git/87lg77cmr1@evledraar.gmail.com/ for how
> that could be done.

It is not about the \0 boundary. v2 of the patches will clarify that. My main
motiviation is to speed up "log -G" as that takes a considerable amount of time 
when it wades through MBs of binary files which change often. And in multiple 
places
I can already treat binary files differently (e.g. turn off delta compression, 
skip
trying to diff them, no EOL normalization). And for me making log -G ignore 
what git 
thinks are binary files is making the line clearer between what should be 
treated as binary
and what as text.

> Also if we don't have some tests already that were failing with this
> patch we really should have those as "let's test the current behavior
> first". Unfortunately tests in this area are really lacking, see
> e.g. my:
> 
> git log --author=Junio --min-parents=2 --grep=ab/.*grep
> 
> For some series of patches to grep where to get one patch in I needed to
> often lead with 5-10 test patches to convince reviewers that I knew what
> I was changing, and also to be comfortable that I'd covered all the edge
> cases we currently supported, but weren't testing for.

I'm happy to add more test cases to convince everyone involved :)

Re: [PATCH v1 1/2] log -G: Ignore binary files

[Thomas Braun]

> Jeff King  hat am 22. November 2018 um 17:20 geschrieben:
> 
> 
> On Wed, Nov 21, 2018 at 09:52:27PM +0100, Thomas Braun wrote:
> 
> > diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
> > index 69fc55ea1e..8c2558b07d 100644
> > --- a/diffcore-pickaxe.c
> > +++ b/diffcore-pickaxe.c
> > @@ -144,6 +144,11 @@ static int pickaxe_match(struct diff_filepair *p, 
> > struct diff_options *o,
> > textconv_two = get_textconv(o->repo->index, p->two);
> > }
> >  
> > +   if ((o->pickaxe_opts & DIFF_PICKAXE_KIND_G) &&
> > +   ((!textconv_one && diff_filespec_is_binary(o->repo, p->one)) ||
> > +(!textconv_two && diff_filespec_is_binary(o->repo, p->two
> > +   return 0;
> 
> If the user passes "-a" to treat binary files as text, we should
> probably skip the binary check. I think we'd need to check
> "o->flags.text" here.

Good point. I missed that flag. Added.

> > diff --git a/t/t4209-log-pickaxe.sh b/t/t4209-log-pickaxe.sh
> > index 844df760f7..42cc8afd8b 100755
> > --- a/t/t4209-log-pickaxe.sh
> > +++ b/t/t4209-log-pickaxe.sh
> > @@ -106,4 +106,26 @@ test_expect_success 'log -S --no-textconv (missing 
> > textconv tool)' '
> > [...]
> > +test_expect_success 'log -G ignores binary files' '
> > [...]
> > +test_expect_success 'log -G looks into binary files with textconv filter' '
> 
> And likewise add a test here similar to the textconv one.

Added as well.

Re: [PATCH v1 1/2] log -G: Ignore binary files

[Thomas Braun]

> Junio C Hamano  hat am 22. November 2018 um 02:29 
> geschrieben:
> 
> 
> Thomas Braun  writes:
> 
> > The -G  option of log looks for the differences whose patch text
> > contains added/removed lines that match regex.
> >
> > The concept of differences only makes sense for text files, therefore
> > we need to ignore binary files when searching with -G  as well.
> >
> > Signed-off-by: Thomas Braun 
> > ---
> >  Documentation/gitdiffcore.txt |  2 +-
> >  diffcore-pickaxe.c|  5 +
> >  t/t4209-log-pickaxe.sh| 22 ++
> >  3 files changed, 28 insertions(+), 1 deletion(-)
> 
> OK.
> 
> > diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt
> > index c0a60f3158..059ddd3431 100644
> > --- a/Documentation/gitdiffcore.txt
> > +++ b/Documentation/gitdiffcore.txt
> > @@ -242,7 +242,7 @@ textual diff has an added or a deleted line that 
> > matches the given
> >  regular expression.  This means that it will detect in-file (or what
> >  rename-detection considers the same file) moves, which is noise.  The
> >  implementation runs diff twice and greps, and this can be quite
> > -expensive.
> > +expensive.  Binary files without textconv filter are ignored.
> 
> OK.
> 
> > diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
> > index 69fc55ea1e..8c2558b07d 100644
> > --- a/diffcore-pickaxe.c
> > +++ b/diffcore-pickaxe.c
> > @@ -144,6 +144,11 @@ static int pickaxe_match(struct diff_filepair *p, 
> > struct diff_options *o,
> > textconv_two = get_textconv(o->repo->index, p->two);
> > }
> >  
> > +   if ((o->pickaxe_opts & DIFF_PICKAXE_KIND_G) &&
> > +   ((!textconv_one && diff_filespec_is_binary(o->repo, p->one)) ||
> > +(!textconv_two && diff_filespec_is_binary(o->repo, p->two
> > +   return 0;
> > +
> > /*
> >  * If we have an unmodified pair, we know that the count will be the
> >  * same and don't even have to load the blobs. Unless textconv is in
> 
> Shouldn't this new test come after the existing optimization, which
> allows us to leave without loading the blob contents (which is
> needed once you call diff_filespec_is_binary())?

Yes, good point.

> > diff --git a/t/t4209-log-pickaxe.sh b/t/t4209-log-pickaxe.sh
> > index 844df760f7..42cc8afd8b 100755
> > --- a/t/t4209-log-pickaxe.sh
> > +++ b/t/t4209-log-pickaxe.sh
> > @@ -106,4 +106,26 @@ test_expect_success 'log -S --no-textconv (missing 
> > textconv tool)' '
> > rm .gitattributes
> >  '
> >  
> > +test_expect_success 'log -G ignores binary files' '
> > +   rm -rf .git &&
> > +   git init &&
> 
> Please never never ever do the above two unless you are writing a
> test that checks low-level repository details.
> 
> If you want a clean history that has specific lineage of commits
> without getting affected by commits that have been made by the
> previous test pieces, it is OK to "checkout --orphan" to create an
> empty history to work with.

Thanks for the hint. I thought I had seen a less intrusive way for getting an 
empty history. 
Changed.

> > +   printf "a\0b" >data.bin &&
> > +   git add data.bin &&
> > +   git commit -m "message" &&
> > +   git log -G a >result &&
> > +   test_must_be_empty result
> > +'
> > +
> > +test_expect_success 'log -G looks into binary files with textconv filter' '
> > +   rm -rf .git &&
> > +   git init &&
> > +   echo "* diff=bin" > .gitattributes &&
> > +   printf "a\0b" >data.bin &&
> > +   git add data.bin &&
> > +   git commit -m "message" &&
> > +   git -c diff.bin.textconv=cat log -G a >actual &&
> > +   git log >expected &&
> > +   test_cmp actual expected
> > +'
> > +
> >  test_done
>

[PATCH v1 2/2] log -S: Add test which searches in binary files

[Thomas Braun]

The -S  option of log looks for differences that changes the
number of occurrences of the specified string (i.e. addition/deletion)
in a file.

Add a test to ensure that we keep looking into binary files with -S
as changing that would break backwards compatibility in unexpected ways.

Signed-off-by: Thomas Braun 
---
 t/t4209-log-pickaxe.sh | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/t/t4209-log-pickaxe.sh b/t/t4209-log-pickaxe.sh
index 42cc8afd8b..d430f6f2f9 100755
--- a/t/t4209-log-pickaxe.sh
+++ b/t/t4209-log-pickaxe.sh
@@ -128,4 +128,15 @@ test_expect_success 'log -G looks into binary files with 
textconv filter' '
test_cmp actual expected
 '
 
+test_expect_success 'log -S looks into binary files' '
+   rm -rf .git &&
+   git init &&
+   printf "a\0b" >data.bin &&
+   git add data.bin &&
+   git commit -m "message" &&
+   git log -S a >actual &&
+   git log >expected &&
+   test_cmp actual expected
+'
+
 test_done
-- 
2.19.0.271.gfe8321ec05.dirty

[PATCH 0/2] Teach log -G to ignore binary files

[Thomas Braun]

Based on the previous discussion in [1] I've prepared patches which teach 
log -G to ignore binary files. log -S keeps its behaviour but got a test to 
ensure that.

Feedback welcome!

[1]: 
https://public-inbox.org/git/7a0992eb-adb9-a7a1-cfaa-3384bc4d3...@virtuell-zuhause.de/

Thomas Braun (2):
  log -G: Ignore binary files
  log -S: Add test which searches in binary files

 Documentation/gitdiffcore.txt |  2 +-
 diffcore-pickaxe.c|  5 +
 t/t4209-log-pickaxe.sh| 21 +
 3 files changed, 27 insertions(+), 1 deletion(-)

-- 
2.19.0.271.gfe8321ec05.dirty

[PATCH v1 1/2] log -G: Ignore binary files

[Thomas Braun]

The -G  option of log looks for the differences whose patch text
contains added/removed lines that match regex.

The concept of differences only makes sense for text files, therefore
we need to ignore binary files when searching with -G  as well.

Signed-off-by: Thomas Braun 
---
 Documentation/gitdiffcore.txt |  2 +-
 diffcore-pickaxe.c|  5 +
 t/t4209-log-pickaxe.sh| 22 ++
 3 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt
index c0a60f3158..059ddd3431 100644
--- a/Documentation/gitdiffcore.txt
+++ b/Documentation/gitdiffcore.txt
@@ -242,7 +242,7 @@ textual diff has an added or a deleted line that matches 
the given
 regular expression.  This means that it will detect in-file (or what
 rename-detection considers the same file) moves, which is noise.  The
 implementation runs diff twice and greps, and this can be quite
-expensive.
+expensive.  Binary files without textconv filter are ignored.
 
 When `-S` or `-G` are used without `--pickaxe-all`, only filepairs
 that match their respective criterion are kept in the output.  When
diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
index 69fc55ea1e..8c2558b07d 100644
--- a/diffcore-pickaxe.c
+++ b/diffcore-pickaxe.c
@@ -144,6 +144,11 @@ static int pickaxe_match(struct diff_filepair *p, struct 
diff_options *o,
textconv_two = get_textconv(o->repo->index, p->two);
}
 
+   if ((o->pickaxe_opts & DIFF_PICKAXE_KIND_G) &&
+   ((!textconv_one && diff_filespec_is_binary(o->repo, p->one)) ||
+(!textconv_two && diff_filespec_is_binary(o->repo, p->two
+   return 0;
+
/*
 * If we have an unmodified pair, we know that the count will be the
 * same and don't even have to load the blobs. Unless textconv is in
diff --git a/t/t4209-log-pickaxe.sh b/t/t4209-log-pickaxe.sh
index 844df760f7..42cc8afd8b 100755
--- a/t/t4209-log-pickaxe.sh
+++ b/t/t4209-log-pickaxe.sh
@@ -106,4 +106,26 @@ test_expect_success 'log -S --no-textconv (missing 
textconv tool)' '
rm .gitattributes
 '
 
+test_expect_success 'log -G ignores binary files' '
+   rm -rf .git &&
+   git init &&
+   printf "a\0b" >data.bin &&
+   git add data.bin &&
+   git commit -m "message" &&
+   git log -G a >result &&
+   test_must_be_empty result
+'
+
+test_expect_success 'log -G looks into binary files with textconv filter' '
+   rm -rf .git &&
+   git init &&
+   echo "* diff=bin" > .gitattributes &&
+   printf "a\0b" >data.bin &&
+   git add data.bin &&
+   git commit -m "message" &&
+   git -c diff.bin.textconv=cat log -G a >actual &&
+   git log >expected &&
+   test_cmp actual expected
+'
+
 test_done
-- 
2.19.0.271.gfe8321ec05.dirty

[PATCH 0/2] Teach log -G to ignore binary files

[Thomas Braun]

Based on the previous discussion in [1] I've prepared patches which teach
log -G to ignore binary files. log -S keeps its behaviour but got a test to 
ensure that.

Feedback welcome!

[1]: 
https://public-inbox.org/git/7a0992eb-adb9-a7a1-cfaa-3384bc4d3...@virtuell-zuhause.de/

PS: This is the (possibly missing) cover letter.

Re: Git for games working group

[Thomas Braun]

Am 17.09.2018 um 17:58 schrieb Jonathan Nieder:

[...]

> Ah, thanks.  See git-config(1):
> 
>   core.bigFileThreshold
>   Files larger than this size are stored deflated,
>   without attempting delta compression.
> 
>   Default is 512 MiB on all platforms.
> 

In addition to config.bigFileThreshold you can also unset the delta
attribute for file extensions you don't want to get delta compressed.
See "git help attributes". And while you are at it, mark the files as
binary so that git diff/log don't have to guess.

2.19.0.rc2.windows.1: stash fails with dirty submodule

[Thomas Braun]

Hi,

(reported at [1] already but reposting here as suggested)

I'm using git with stash and rebase builtins.

$ git --version --build-options

git version 2.19.0.rc2.windows.1
cpu: x86_64
built from commit: 425f414f8e04123eacb5597776d6a8de445a8d8b
sizeof-long: 4
sizeof-size_t: 8

With the following recipe

mkdir test
cd test
git init
echo 1 > file
git add file
git commit file -m "message"
git submodule add ./ mysubmod
git commit -m "Add submodule"
echo 2 > mysubmod/file
git checkout -b mybranch
git rebase -i --autosquash master

I get

Initialized empty Git repository in E:/projekte/test/.git/
[master (root-commit) 97c0108] message
 1 file changed, 1 insertion(+)
 create mode 100644 file
Cloning into 'E:/projekte/test/mysubmod'...
done.
[master 282a50f] Add submodule
 2 files changed, 4 insertions(+)
 create mode 100644 .gitmodules
 create mode 16 mysubmod
Switched to a new branch 'mybranch'
M   mysubmod
fatal: Unexpected stash response: ''

and that used to work with older git versions.

Thanks for reading,
Thomas

[1]:
https://github.com/git-for-windows/git/issues/1820#issuecomment-419411808

Re: [RFC PATCH v1] telemetry design overview (part 1)

[Thomas Braun]

Am 08.06.2018 um 11:07 schrieb Jeff King:
> On Thu, Jun 07, 2018 at 11:10:52PM +0200, Johannes Sixt wrote:
> 
>> Am 07.06.2018 um 16:53 schrieb g...@jeffhostetler.com:
>>> From: Jeff Hostetler 
>>>
>>> I've been working to add code to Git to optionally collect telemetry data.
>>> The goal is to be able to collect performance data from Git commands and
>>> allow it to be aggregated over a user community to find "slow commands".
>>
>> Seriously? "add code to collect telemetry data" said by somebody whose email
>> address ends with @microsoft.com is very irritating. I really don't want to
>> have yet another switch that I must check after every update that it is
>> still off.
> 
> If you look at the design document, it's off by default and would write
> to a file on the filesystem. That doesn't seem all that different from
> GIT_TRACE.

The patch also includes the following part

+telemetry.plugin
+
+
+If the config setting "telemetry.plugin" contains the pathname to a shared
+library, the library will be dynamically loaded during start up and events
+will be sent to it using the plugin API.
+
+This plugin model allows an organization to define a custom or private
+telemetry solution while using a stock version of Git.
+
+For example, on Windows, it allows telemetry events to go directly to the
+kernel via the plugin using the high performance Event Tracing for Windows
+(ETW) facility.
+
+The contrib/telemetry-plugin-examples directory contains two example
+plugins:
+ * A trivial log to stderr
+ * A trivial ETW writer

which is not a file but, if enabled, some windows internal thingie where the 
data is gone/duplicated/sent out/whatever.

I for my part would much rather prefer that to be a compile time option so that 
I don't need to check on every git update on windows if this is now enabled or 
not.

BUG: No way to set fsck. when cloning

[Thomas Braun]

Am 24.05.2018 um 17:25 schrieb Ævar Arnfjörð Bjarmason:
> When I do:
> 
> git -c fetch.fsckObjects=true clone 
> g...@github.com:robbyrussell/oh-my-zsh.git
> 
> I get:
> 
> error: object 2b7227859263b6aabcc28355b0b994995b7148b6: 
> zeroPaddedFilemode: contains zero-padded file modes
> fatal: Error in object
> fatal: index-pack failed
>
> [...]

Doing

git clone --config transfer.fsckobjects=false --config
receive.fsckobjects=false --config fetch.fsckobjects=false
g...@github.com:robbyrussell/oh-my-zsh.git

does the trick here (stolen from [1]).

$ git --version
git version 2.17.0.windows.1

I don't know why though.

[1]:
https://github.com/michaeljones/breathe/issues/340#issuecomment-390775142

Re: [PATCH] travis-ci: run gcc-7 on linux-gcc jobs

[Thomas Braun]

Am 13.05.2018 um 11:17 schrieb Nguyễn Thái Ngọc Duy:
> Switch from gcc-4.8 to gcc-7. Newer compilers come with more warning
> checks (usually in -Wextra).  Since -Wextra is enabled in developer
> mode (which is also enabled in travis), this lets travis report more
> warnings before other people do it.
> 
> Signed-off-by: Nguyễn Thái Ngọc Duy 
> ---
>  .travis.yml| 3 +++
>  ci/lib-travisci.sh | 3 +++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 5f5ee4f3bd..a77f5f5bd5 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -16,10 +16,13 @@ compiler:
>  
>  addons:
>apt:
> +sources:
> +- ubuntu-toolchain-r-test
>  packages:
>  - language-pack-is
>  - git-svn
>  - apache2
> +- gcc-7

You could also use gcc-8 here as that is already present according to [1].

[1]:
https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test/+packages

>  matrix:
>include:
> diff --git a/ci/lib-travisci.sh b/ci/lib-travisci.sh
> index 109ef280da..ef2848fd45 100755
> --- a/ci/lib-travisci.sh
> +++ b/ci/lib-travisci.sh
> @@ -99,6 +99,9 @@ export DEFAULT_TEST_TARGET=prove
>  export GIT_PROVE_OPTS="--timer --jobs 3 --state=failed,slow,save"
>  export GIT_TEST_OPTS="--verbose-log -x"
>  export GIT_TEST_CLONE_2GB=YesPlease
> +if [ "$jobname" = linux-gcc ]; then
> + export CC=gcc-7
> +fi
>  
>  case "$jobname" in
>  linux-clang|linux-gcc)
> 

Re: [RFC] 'unsigned long' to 'size_t' conversion

[Thomas Braun]

Am 06.12.2017 um 16:08 schrieb Derrick Stolee:

Hi Derrick,

> If there are small, isolated chunks that can be done safely, then this
> may be a good target for a first patch.

Here are some pointers to past discussions:
-
https://public-inbox.org/git/trinity-9f703269-6f73-4f6d-b90b-45e09e1c094c-1489582854278@3capp-gmx-bs66/
-
https://public-inbox.org/git/1502527643-21944-1-git-send-email-martin@mail.zuhause/

I'm posting this mainly so that we can avoid, if possible, duplicated work.

Hope that helps,
Thomas

Re: Unify annotated and non-annotated tags

[Thomas Braun]

Am 23.11.2017 um 16:08 schrieb Randall S. Becker:

[...]

>> So my proposal is to get rid of non-annotated tags, so to get all
>> tags with commits that they point to, one would use:
>> git for-each-ref --format='%(*objectname) %(refname)' refs/tags>
>> For so-called non-annotated tags just leave the message empty.
>> I don't see why anyone would need non-annotated tags though.

I'm using exclusively non-annotated tags. Why? Because that is the
default of "git tag" and I also, until now, never needed more than
giving a commit a "name".

Many annotated tag messages just repeat the tag name itself, so the
message seems quite redundant to me.

Just my 2 cents,
Thomas

[PATCH v2 1/1] completion: add remaining flags to checkout

[Thomas Braun]

In the commits 1fc458d9 (builtin/checkout: add --recurse-submodules
switch, 2017-03-14), 08d595dc (checkout: add --ignore-skip-worktree-bits
in sparse checkout mode, 2013-04-13) and 32669671 (checkout: introduce
--detach synonym for "git checkout foo^{commit}", 2011-02-08) checkout
gained new flags but the completion was not updated, although these flags
are useful completions. Add them.

The flags --force and --ignore-other-worktrees are not added as they are
potentially dangerous.

The flags --progress and --no-progress are only useful for scripting and are
therefore also not included.

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index d934417475..eb6ade6974 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1250,7 +1250,8 @@ _git_checkout ()
--*)
__gitcomp "
--quiet --ours --theirs --track --no-track --merge
-   --conflict= --orphan --patch
+   --conflict= --orphan --patch --detach 
--ignore-skip-worktree-bits
+   --recurse-submodules --no-recurse-submodules
"
;;
*)
-- 
2.15.0.rc0.245.g6d586db062

Re: [PATCH v1 1/1] completion: add remaining flags to checkout

[Thomas Braun]

> Johannes Sixt <j...@kdbg.org> hat am 12. Oktober 2017 um 18:50 geschrieben:
> 
> 
> Am 12.10.2017 um 14:20 schrieb Thomas Braun:
> > In the commits 1d0fa898 (checkout: add --ignore-other-wortrees,
> > 2015-01-03), 1fc458d9 (builtin/checkout: add --recurse-submodules switch,
> > 2017-03-14), 870ebdb9 (checkout: add --progress option, 2015-11-01),
> > 08d595dc (checkout: add --ignore-skip-worktree-bits in sparse checkout
> > mode, 2013-04-13), 1d0fa898 (checkout: add --ignore-other-wortrees,
> > 2015-01-03), 32669671 (checkout: introduce --detach synonym for "git
> > checkout foo^{commit}", 2011-02-08) and db941099 (checkout -f: allow
> > ignoring unmerged paths when checking out of the index, 2008-08-30)
> > checkout gained new flags but the completion was not updated, although
> > these flags are useful completions. Add them.
> > 
> > Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
> > ---
> >   contrib/completion/git-completion.bash | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/contrib/completion/git-completion.bash 
> > b/contrib/completion/git-completion.bash
> > index d934417475..393d4ae230 100644
> > --- a/contrib/completion/git-completion.bash
> > +++ b/contrib/completion/git-completion.bash
> > @@ -1250,7 +1250,9 @@ _git_checkout ()
> > --*)
> > __gitcomp "
> > --quiet --ours --theirs --track --no-track --merge
> > -   --conflict= --orphan --patch
> > +   --conflict= --orphan --patch --detach --progress 
> > --no-progress
> > +   --force --ignore-skip-worktree-bits 
> > --ignore-other-worktrees
> 
> Destructive and dangerous options are typically not offered by command 
> completion. You should omit all three in the line above, IMO.
> 
> Furthermore, --progress and --no-progress are not useful in daily work 
> on the command line, I think. By offering them, --p would not 
> complete to --patch anymore, you would need --pa. You should omit 
> them, too.

Thanks for the review.

I've fixed that for the next reroll.

[PATCH v1 1/1] completion: add remaining flags to checkout

[Thomas Braun]

In the commits 1d0fa898 (checkout: add --ignore-other-wortrees,
2015-01-03), 1fc458d9 (builtin/checkout: add --recurse-submodules switch,
2017-03-14), 870ebdb9 (checkout: add --progress option, 2015-11-01),
08d595dc (checkout: add --ignore-skip-worktree-bits in sparse checkout
mode, 2013-04-13), 1d0fa898 (checkout: add --ignore-other-wortrees,
2015-01-03), 32669671 (checkout: introduce --detach synonym for "git
checkout foo^{commit}", 2011-02-08) and db941099 (checkout -f: allow
ignoring unmerged paths when checking out of the index, 2008-08-30)
checkout gained new flags but the completion was not updated, although
these flags are useful completions. Add them.

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index d934417475..393d4ae230 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1250,7 +1250,9 @@ _git_checkout ()
--*)
__gitcomp "
--quiet --ours --theirs --track --no-track --merge
-   --conflict= --orphan --patch
+   --conflict= --orphan --patch --detach --progress 
--no-progress
+   --force --ignore-skip-worktree-bits 
--ignore-other-worktrees
+   --recurse-submodules --no-recurse-submodules
"
;;
*)
-- 
2.15.0.rc0.245.g6d586db062

Re: Branch switching with submodules where the submodule replaces a folder aborts unexpectedly

[Thomas Braun]

> Stefan Beller <sbel...@google.com> hat am 9. Oktober 2017 um 23:59 
> geschrieben:
> 
> 
> On Mon, Oct 9, 2017 at 2:29 PM, Thomas Braun
> <thomas.br...@virtuell-zuhause.de> wrote:
> > Hi,
> >
> > I'm currently in the progress of pulling some subprojects in a git 
> > repository of mine into their
> > own repositories and adding these subprojects back as submodules.
> >
> > While doing this I enountered a potential bug as checkout complains on 
> > branch switching that a 
> > file already exists.
> 
> (And I presume you know about --recurse-submodules as a flag for git-checkout)

No I did not know about it. I tend to not know options which don't complete in 
my shell (patch follows for that).

> This is consistent with our tests, unfortunately.
> 
> git/t$ ./t2013-checkout-submodule.sh
> ...
> not ok 15 - git checkout --recurse-submodules: replace submodule with
> a directory # TODO known breakage
> ...
> 
> > If I'm misusing git here I'm glad for any advice.
> 
> You are not.

Glad to know that.

> Apart from this bug report, would you think that such filtering of
> trees into submodules (and back again) might be an interesting feature
> of Git or are these cases rare and special?

For me not particularly. In my case it is a one time thing going from an 
embedded project folder to a submodule.

Branch switching with submodules where the submodule replaces a folder aborts unexpectedly

[Thomas Braun]

Hi,

I'm currently in the progress of pulling some subprojects in a git repository 
of mine into their own repositories and adding these subprojects back as 
submodules.

While doing this I enountered a potential bug as checkout complains on branch 
switching that a file already exists.

I've reproduced it on debian stretch with the following git versions:

master:
git version 2.15.0.rc0.39.g2f0e14e649
pu:
git version 2.15.0.rc0.245.g6d586db062

A script to trigger it is

mkdir -p test/subproject
cd test
git init
touch subproject/1
git add subproject
git commit -m "blah"
cd ..
mkdir subproject
cd subproject
git init
touch 1
git add 1
git commit -m "blubb"
cd ../test
git branch old
git rm -rf subproject
git commit -m "remove blah"
git submodule add ../subproject
git add -A
git commit -m "added subproject"
git branch new
git checkout old

and this fails with 

$LANG=C ./run.sh 
Initialized empty Git repository in /home/XXX/devel/test/.git/
[master (root-commit) 33e6607] blah
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 subproject/1
Initialized empty Git repository in /home/XXX/devel/subproject/.git/
[master (root-commit) e817644] blubb
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 1
rm 'subproject/1'
[master 9cbfd57] remove blah
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 subproject/1
Cloning into '/home/XXX/devel/test/subproject'...
done.
[master 1c67e23] added subproject
 2 files changed, 4 insertions(+)
 create mode 100644 .gitmodules
 create mode 16 subproject
error: The following untracked working tree files would be overwritten by 
checkout:
subproject/1
Please move or remove them before you switch branches.
Aborting

If I'm misusing git here I'm glad for any advice.

Thanks,
Thomas

[PATCH v2 1/1] completion: add --broken and --dirty to describe

[Thomas Braun]

When the flags for broken and dirty were implemented in
b0176ce6b5 (builtin/describe: introduce --broken flag, 2017-03-21)
and 9f67d2e827 (Teach "git describe" --dirty option, 2009-10-21)
the completion was not updated, although these flags are useful
completions. Add them.

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
Helped-by: Stefan Beller <sbel...@google.com>
---
 contrib/completion/git-completion.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index d934417475..0e16f017a4 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1385,7 +1385,7 @@ _git_describe ()
__gitcomp "
--all --tags --contains --abbrev= --candidates=
--exact-match --debug --long --match --always 
--first-parent
-   --exclude
+   --exclude --dirty --broken
"
return
esac
-- 
2.14.2.746.g8fb8a945bc.dirty

Re: [PATCH 1/1] completion: Add forgotten describe options

[Thomas Braun]

> Stefan Beller <sbel...@google.com> hat am 6. Oktober 2017 um 00:17 
> geschrieben:
> On Thu, Oct 5, 2017 at 2:23 PM, Thomas Braun
> <thomas.br...@virtuell-zuhause.de> wrote:

Hi Stefan,

> > completion: Add forgotten describe options
> 
> When/Why was it forgotten? git-blame thinks it was me in b0176ce6b5
> (builtin/describe: introduce --broken flag, 2017-03-21)
> Which do you add? (dirty and broken)
> 
> I had these questions when reading the subject (which is the
> equivalent of reading the output of `git log --oneline` in the future)
> I think a better wording might be
> 
> completion: add --broken and --dirty to describe
> 
> When the flags for broken and dirty were implemented in
> b0176ce6b5 (builtin/describe: introduce --broken flag, 2017-03-21)
> and 9f67d2e827 (Teach "git describe" --dirty option, 2009-10-21)
> the completion was not updated, although these flags are useful
> completions. Add them.

Thanks for the review. Your commit message is (obviously) much better than 
mine. Reroll follows.

> > ---
> 
> The patch looks correct.
> 

Thanks,
Thomas

[PATCH 1/1] completion: Add forgotten describe options

[Thomas Braun]

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index d934417475..0e16f017a4 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1385,7 +1385,7 @@ _git_describe ()
__gitcomp "
--all --tags --contains --abbrev= --candidates=
--exact-match --debug --long --match --always 
--first-parent
-   --exclude
+   --exclude --dirty --broken
"
return
esac
-- 
2.14.2.746.g8fb8a945bc.dirty

[PATCH 1/1] completion: Add forgotten describe options

[Thomas Braun]

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index d934417475..0e16f017a4 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1385,7 +1385,7 @@ _git_describe ()
__gitcomp "
--all --tags --contains --abbrev= --candidates=
--exact-match --debug --long --match --always 
--first-parent
-   --exclude
+   --exclude --dirty --broken
"
return
esac
-- 
2.14.2.746.g8fb8a945bc.dirty

Re: Commiting files larger than 4 GB on Windows

[Thomas Braun]

> Torsten Bögershausen  hat am 17. März 2017 um 06:29
> geschrieben:
> 
> 
> On 15/03/17 22:29, Junio C Hamano wrote:
> > Torsten Bögershausen  writes:
> >
> >> The real "show stopper" is at the end.
> >> ...
> >>
> >> ==
> >> And it seams as if zlib is the limitation here.
> >> Unless we include the zlib source code into Git and redefine uLong,
> >> is there a nice way around this:
> >> ===
> >>
> >>
> >> /usr/include/zconf.h:#  define uLong z_uLong
> >> /usr/include/zconf.h:#  define uLongfz_uLongf
> >> /usr/include/zconf.h:typedef unsigned long  uLong; /* 32 bits or more */
> >> /usr/include/zconf.h:typedef uLong FAR uLongf;
> > Hmph.  Would ef49a7a0 ("zlib: zlib can only process 4GB at a time",
> > 2011-06-10) and e01503b5 ("zlib: allow feeding more than 4GB in one
> > go", 2011-06-10) help us here, though?
> >
> That is good news.
> I tried to replace all "unsigned long" with size_t and got that compiling
> without warnings under Windows 64 bit.
> 
> Compiling this on a 32 bit Linux gave lots of warnings..
> 
> Converting all unsigned long into is probably an overkill.
> Some may stay, some may be converted into off_t, and some size_t.
> 
> Does anybody wants to pick this up?

I'd be interested, altough I can't promise to get it done in the near future.

Re: Commiting files larger than 4 GB on Windows

[Thomas Braun]

Am 15.03.2017 um 17:13 schrieb Jeff King:
> On Wed, Mar 15, 2017 at 11:59:52AM -0400, Jeff King wrote:
> 
>> I agree that detecting the situation in the meantime is a good idea.
>> The patch above probably handles the bulk-checkin code path, I'd guess.
>> It might be nice to have similar checks in other places, too:
>>
>>   - when reading from an existing packfile
>>
>> Looks like we may already have such a check in
>> unpack_object_header_buffer().
>>
>>   - when taking in new objects via index-pack or unpack-objects (to
>> catch a fetch of a too-big object)
>>
>> I think index-pack.c:unpack_raw_entry() would want a similar check
>> to what is in unpack_object_header_buffer().
> 
> Here are the results of a few quick experiments using two versions of
> git, one built for 32-bit and one for 64-bit:
> 
>   $ git init
>   $ dd if=/dev/zero of=foo.zero bs=1M count=4097
>   $ git32 add foo.zero
>   fatal: Cannot handle files this big
> 
> That comes from the xsize_t() wrapper. I guess it wouldn't trigger on
> Windows, though, because it is measuring size_t, not "unsigned long" (on
> my 32-bit build they are the same, of course).
> 
>   $ git64 add foo.zero
>   $ git32 cat-file blob :foo.zero
>   error: bad object header
>   fatal: packed object df6f032f301d1ce40477eefa505f2fac1de5e243 (stored in 
> .git/objects/pack/pack-57d422f19904e9651bec43d10b7a9cd882de48ac.pack) is 
> corrupt
> 
> So we notice, which is good. This is the message from
> unpack_object_header_buffer(). It might be worth improving the error
> message to mention the integer overflow.
> 
> And here's what index-pack looks like:
> 
>   $ git32 index-pack --stdin <.git/objects/pack/*.pack
>   fatal: pack has bad object at offset 12: inflate returned -5
> 
> It's good that we notice, but the error message isn't great. What
> happens is that we overflow the size integer, allocate a too-small
> buffer, and then zlib complains when we run out of buffer but there's
> still content to inflate. We probably ought to notice the integer
> overflow in the first place and complain there.

Thanks for the pointers Peff. I'll try to come up with a patch in the
next weeks. If somebody else steps in the meantime I'm not mad at all.

Thomas

Re: Commiting files larger than 4 GB on Windows

[Thomas Braun]

Am 15.03.2017 um 14:00 schrieb Florian Adamus:
> Hello,
> 
> I am managing my large files with the git-lfs-extension. Some of them
> were more than 4GB in size. After deleting one of those files from my
> working tree and do a normal git checkout I ended up with a somehow
> crippled file with a size of only 46 MB left. For testing reasons I
> tried to commit a 4,3 GB file to my git repository without the LFS
> extension. After checking out a different branch and switching back
> to the branch with the large file, I ended up with the same small
> file as mentioned before. I already wrote a bug issues to Git for
> Windows and I was told that it is a problem with the git source code,
> which uses unsinged long, where it should use size_t. For more
> information on the issue you can check the issue tracker of Git for
> Windows on github. Issue #1063 Is there a way to fix this problem?

Hi,

I can not comment on the git-lfs issues. The issue that you can not properly 
use files larger than 4GB on windows (no matter if 32bit or 64bit) is known, 
see my findings from May last year [1]. Unfortunately nobody, including me, did 
find time to fix the underlying issue properly.

My band-aid patch from [1]

diff --git a/pack-write.c b/pack-write.c
index 33293ce..ebb8b0a 100644
--- a/pack-write.c
+++ b/pack-write.c
@@ -313,6 +313,9 @@ int encode_in_pack_object_header(enum object_type type, 
uintmax_t size, unsigned
if (type < OBJ_COMMIT || type > OBJ_REF_DELTA)
die("bad type %d", type);

+   if (bitsizeof(unsigned long) != bitsizeof(uintmax_t) && size > 
(unsigned long) size)
+   die("Cannot handle files this big");
+
c = (type << 4) | (size & 15);
size >>= 4;
while (size) {

would at least tell the user much earlier about the problem. I can submit the 
above diff as proper patch if it is deemed a worthy change.

Thomas

[1]: http://public-inbox.org/git/56ef1402.4050...@virtuell-zuhause.de/  

Re: Delta compression not so effective

[Thomas Braun]

> Marius Storm-Olsen  hat am 4. März 2017 um 09:27
> geschrieben:

[...]

> I really don't want the files on the mailinglist, so I'll send you a 
> link directly. However, small snippets for public discussions about 
> potential issues would be fine, obviously.

git fast-export can anonymize a repository [1]. Maybe an anonymized repository
still shows the issue you are seeing.

[1]: https://www.git-scm.com/docs/git-fast-export#_anonymizing

Re: log -S/-G (aka pickaxe) searches binary files by default

[Thomas Braun]

Am 03.03.2017 um 17:07 schrieb Junio C Hamano:
> Jeff King  writes:
> 
>> On Thu, Mar 02, 2017 at 05:36:17PM -0800, Junio C Hamano wrote:
>> ...
 Is that on purpose?
>>>
>>> No, it's a mere oversight (as I do not think I never even thought
>>> about special casing binary
>>> files from day one, it is unlikely that you would find _any_ old
>>> version of Git that behaves
>>> differently).
>>
>> The email focuses on "-G", and I think it is wrong to look in binary
>> files there, as "grep in diff" does not make sense for a binary file
>> that we would refuse to diff.
> 
> Yeah, I agree.
> 
>> But the subject also mentions "-S". I always assumed it was intentional
>> to look in binary files there, as it is searching for a pure byte
>> sequence. I would not mind an option to disable that, but I think the
>> default should remain on.
> 
> As the feature was built to be one of the core ingredients necessary
> towards the 'ideal SCM' envisioned in
> 
>   
> 
> 
> "-S" is about finding "a block of text". It was merely an oversight
> that we didn't add explicit code to ignore binary when we introduced
> the concept of "is this text?  is it worth finding things in and
> diffing binary files?".
> 
> I do agree that it may be too late and/or disruptive to change its
> behaviour now, as people may grew expectations different from the
> original motivation and design, though.

Thanks both for the encouraging answers.

I'll try to come up with patches in the next couple of weeks for the
following changes:
"log -G": disable looking in binaries
"log -S": add option to switch looking into binaries, defaults to true

Thomas

log -S/-G (aka pickaxe) searches binary files by default

[Thomas Braun]

Hi,

I happen to have quite large binary files in my repos.

Today I realized that a line like
git log -G a
searches also files found to be binary (or explicitly marked as binary).

Is that on purpose?
The documentation of "-G" states

"Look for differences whose patch text contains added/removed lines that
match ."

which contradicts the current behaviour. At least for me text != binary.

To reproduce:
$ git init
$ echo -e "a\0b" > data.bin
$ git add data.bin
$ git commit -m "Add new data"
$ git log -p
[...]
diff --git a/data.bin b/data.bin
new file mode 100644
index 000..1a23e4b
Binary files /dev/null and b/data.bin differ
$ git log -G a
[...]

Add new data

I've verified the behaviour with git version 2.12.0.windows.1 and git
version 2.12.0.189.g3bc5322 on debian.

If it is on purpose is there a config option to disable that?

Thanks for reading,
Thomas

Re: SHA1 collisions found

[Thomas Braun]

Am 25.02.2017 um 00:06 schrieb Jeff King:
> So we don't actually know how Git would behave in the face of a SHA-1
> collision. It would be pretty easy to simulate it with something like:
>
> ---
> diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
> index 22b125cf8..1be5b5ba3 100644
> --- a/block-sha1/sha1.c
> +++ b/block-sha1/sha1.c
> @@ -231,6 +231,16 @@ void blk_SHA1_Update(blk_SHA_CTX *ctx, const void *data, 
> unsigned long len)
>   memcpy(ctx->W, data, len);
>  }
>  
> +/* sha1 of blobs containing "foo\n" and "bar\n" */
> +static const unsigned char foo_sha1[] = {
> + 0x25, 0x7c, 0xc5, 0x64, 0x2c, 0xb1, 0xa0, 0x54, 0xf0, 0x8c,
> + 0xc8, 0x3f, 0x2d, 0x94, 0x3e, 0x56, 0xfd, 0x3e, 0xbe, 0x99
> +};
> +static const unsigned char bar_sha1[] = {
> + 0x57, 0x16, 0xca, 0x59, 0x87, 0xcb, 0xf9, 0x7d, 0x6b, 0xb5,
> + 0x49, 0x20, 0xbe, 0xa6, 0xad, 0xde, 0x24, 0x2d, 0x87, 0xe6
> +};
> +
>  void blk_SHA1_Final(unsigned char hashout[20], blk_SHA_CTX *ctx)
>  {
>   static const unsigned char pad[64] = { 0x80 };
> @@ -248,4 +258,8 @@ void blk_SHA1_Final(unsigned char hashout[20], 
> blk_SHA_CTX *ctx)
>   /* Output hash */
>   for (i = 0; i < 5; i++)
>   put_be32(hashout + i * 4, ctx->H[i]);
> +
> + /* pretend "foo" and "bar" collide */
> + if (!memcmp(hashout, bar_sha1, 20))
> + memcpy(hashout, foo_sha1, 20);
>  }

While reading about the subject I came across [1]. The author reduced
the hash size to 4bits and then played around with git.

Diff taken from the posting (not my code)
--- git-2.7.0~rc0+next.20151210.orig/block-sha1/sha1.c
+++ git-2.7.0~rc0+next.20151210/block-sha1/sha1.c
@@ -246,6 +246,8 @@ void blk_SHA1_Final(unsigned char hashou
blk_SHA1_Update(ctx, padlen, 8);

/* Output hash */
-   for (i = 0; i < 5; i++)
-   put_be32(hashout + i * 4, ctx->H[i]);
+   for (i = 0; i < 1; i++)
+   put_be32(hashout + i * 4, (ctx->H[i] & 0xf00));
+   for (i = 1; i < 5; i++)
+   put_be32(hashout + i * 4, 0);
 }

>From a noob git-dev perspective this sounds more flexibel.

[1]: http://stackoverflow.com/a/34599081

Re: What's cooking in git.git (Jan 2017, #03; Thu, 19)

[Thomas Braun]

> Junio C Hamano  hat am 20. Januar 2017 um 00:37
> geschrieben:

[snip]
  
> * rh/mergetool-regression-fix (2017-01-10) 14 commits
>   (merged to 'next' on 2017-01-10 at e8e00c798b)
>  + mergetool: fix running in subdir when rerere enabled
>  + mergetool: take the "-O" out of $orderfile
>  + t7610: add test case for rerere+mergetool+subdir bug
>  + t7610: spell 'git reset --hard' consistently
>  + t7610: don't assume the checked-out commit
>  + t7610: always work on a test-specific branch
>  + t7610: delete some now-unnecessary 'git reset --hard' lines
>  + t7610: run 'git reset --hard' after each test to clean up
>  + t7610: don't rely on state from previous test
>  + t7610: use test_when_finished for cleanup tasks
>  + t7610: move setup code to the 'setup' test case
>  + t7610: update branch names to match test number
>  + rev-parse doc: pass "--" to rev-parse in the --prefix example
>  + .mailmap: record canonical email for Richard Hansen
> 
>  "git mergetool" without any pathspec on the command line that is
>  run from a subdirectory became no-op in Git v2.11 by mistake, which
>  has been fixed.

Hi Junio, 

Sorry for asking a maybe obvious question.
Will that be merged into maint as well?
It is a regression in 2.11 so I would have expected to see that in maint.

Thanks,
Thomas

Re: Idea: Add a filter option to 'git rebase'

[Thomas Braun]

Am 20.01.2017 um 23:28 schrieb Philip Oakley:
> A recent question on stackoverflow
> http://stackoverflow.com/questions/41753252/drop-commits-by-commit-message-in-git-rebase
> sought to remove automatically commits that could be identified by
> relevant words in the commit message.
> 
> I had thought that the ubiquitous `git filter-branch` should be able to
> do this sort of thing. I was wrong. (It was pointed out to me that...)
> The man page notes that removing a commit via filter-branch does not
> remove the changes from following commits and directs readers to using
> `git rebase(1)`.
> 
> However the rebase command does not have any filter option to allow the
> automatic population of its TODO list with the appropriate
> pick/edit/drop/etc. values.

Well you can use an arbitrary shell command as editor, so something like

$ GIT_SEQUENCE_EDITOR="sed -i -re 's/^pick /edit /'" git rebase -i master

will change pick to edit of all commits.

Maybe that can be mentioned in the man page of rebase?

Re: [PATCH v4 2/3] completion: add __git_get_option_value helper

[Thomas Braun]

> SZEDER Gábor <sze...@ira.uka.de> hat am 10. Juni 2016 um 15:10 geschrieben:
> 
> Hallo Thomas,
> 
> I saw v5 hit my mailbox while writing this.  I glanced it over and it
> seems my comments here apply to that version as well.

Hi Gábor,

thanks for your comments.
I plan to send a reroll in the near future adressing your remarks.

Bye,
Thomas

> Quoting Thomas Braun <thomas.br...@virtuell-zuhause.de>:
> 
> > This function allows to search the commmand line and config
> > files for an option, long and short, with mandatory value.
> >
> > The function would return e.g. for the command line
> > "git status -uno --untracked-files=all" the result
> > "all" regardless of the config option.
> 
> Wow, regarding my earlier remark about bonus points: I didn't realize
> that there were so many bonus point to give away :)
> 
> > Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
> > ---
> > contrib/completion/git-completion.bash | 44  
> > ++
> > 1 file changed, 44 insertions(+)
> >
> > diff --git a/contrib/completion/git-completion.bash  
> > b/contrib/completion/git-completion.bash
> > index addea89..4bd17aa 100644
> > --- a/contrib/completion/git-completion.bash
> > +++ b/contrib/completion/git-completion.bash
> > @@ -803,6 +803,50 @@ __git_find_on_cmdline ()
> > done
> > }
> >
> > +# Echo the value of an option set on the command line or config
> > +#
> > +# $1: short option name
> > +# $2: long option name including =
> 
> I'm not sure about requiring the '=', the function could just append
> it as necessary.  More on this below.
> 
> > +# $3: list of possible values
> > +# $4: config string (optional)
> 
> I don't understand why the list of possible values is necessary.
> 
> This function will be called when the caller wants to take different
> actions based on different values, so the caller will process the
> function's output with a case statement or an if-else chain, both of
> which would be perfectly capable to ignore whatever invalid value the
> user might have specified.  Therefore, I think this function doesn't
> need the list of possible values, it should just return whatever value
> it found after the option.
> 
> > +# example:
> > +# result="$(__git_get_option_value "-d" "--do-something="\
> > +# "yes no" "core.doSomething")"
> > +#
> > +# result is then either empty (no option set) or "yes" or "no"
> > +#
> > +# __git_get_option_value requires 3 arguments
> > +__git_get_option_value ()
> > +{
> > +   local c short_opt long_opt val
> > +   local result= values config_key word
> > +
> > +   short_opt="$1"
> > +   long_opt="$2"
> > +   values="$3"
> > +   config_key="$4"
> 
> These can be assigned when the variables are declared, saving a couple
> of lines.
> 
> > +   ((c = $cword - 1))
> > +   while [ $c -ge 0 ]; do
> 
> Searching from the end of the command line, so even if someone were to
> do a 'git status -uall -unormal -uno ', this would still do the
> right thing.  Good!
> 
> However ;)
> Just for fun imagine following:
> 
>$ >-uno
>$ git status -- -uno 
> 
> 'git status' treats that '-uno' after the doubledash as a filename,
> but this function interprets it as an option, and on the subsequent
> TAB the completion script won't list untracked files.
> 
> I'm tempted to say that this is such a pathological corner case that
> it doesn't worth worrying about.
> 
> > +   word="${words[c]}"
> > +   for val in $values; do
> 
> Without the possible values argument this inner loop could go away.
> 
> > +   if [ "$short_opt$val" = "$word" ]
> > +   || [ "$long_opt$val"  = "$word" ]; then
> > +   result="$val"
> > +   break 2
> 
> You could just 'echo "$val"' or rather ${word#$short_opt} and return
> here ...
> 
> > +   fi
> > +   done
> > +   ((c--))
> > +   done
> > +
> > +   if [ -n "$config_key" ] && [ -z "$result" ]; then
> 
> ... and that would make the second condition unnecessary here ...
> 
> > +   result="$(git --git-dir="$(__gitdir)" config "$config_key")"
> 
> ... and this could just be a sim

Re: [PATCH] hooks--pre-commit.sample: check for chars, that are not allowed for a windows file name

[Thomas Braun]

Am 15.06.2016 um 10:02 schrieb dexteritas:
> After the ASCII-check, test the windows compatibility of file names.
> Can be disabled by:
> git config hooks.allownonwindowschars true
> ---
>  templates/hooks--pre-commit.sample | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/templates/hooks--pre-commit.sample 
> b/templates/hooks--pre-commit.sample
> index 68d62d5..120daf1 100755
> --- a/templates/hooks--pre-commit.sample
> +++ b/templates/hooks--pre-commit.sample
> @@ -17,6 +17,7 @@ fi
>  
>  # If you want to allow non-ASCII filenames set this variable to true.
>  allownonascii=$(git config --bool hooks.allownonascii)
> +allownonwindowschars=$(git config --bool hooks.allownonwindowschars)
>  
>  # Redirect output to stderr.
>  exec 1>&2
> @@ -43,6 +44,27 @@ If you know what you are doing you can disable this check 
> using:
>git config hooks.allownonascii true
>  EOF
>   exit 1
> +elif [ "$allownonwindowschars" != "true" ] &&
> + # If you work with linux and windows, there is a problem, if you use
> + # chars like \ / : * ? " < > |
> + # Check if there are used only windows compatible chars
> + test $(git diff --cached --name-only --diff-filter=A -z $against |
> +   LC_ALL=C tr -d '[0-9A-Za-z\[\]\{\}_ -)+-.]\0' | wc -c) != 0
> +then
> + cat <<\EOF
> +Error: Attempt to add a chars that are not allowed for a windows file name.
> +
> +This can cause problems if you want to work with people on other platforms.
> +
> +To be portable it is advisable to rename the file.
> +
> +Check your filenames for: \ / : * ? " < > |
> +
> +If you know what you are doing you can disable this check using:
> +
> +  git config hooks.allownonwindowschars true
> +EOF
> + exit 2
>  fi
>  
>  # If there are whitespace errors, print the offending file names and fail.

There are some cases of illegal file names missing. E.g. reserved names,
trailing period and space. My trial with a precommit hook for avoiding
illegal filenames on windows can be found at [1]. Feel free to loot my
version for a reroll.

[1]:
https://github.com/t-b/git-pre-commit-hook-windows-filenames/blob/master/pre-commit

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/3] completion: factor out untracked file modes into a variable

[Thomas Braun]

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 3402475..addea89 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1098,6 +1098,8 @@ _git_clone ()
esac
 }
 
+__git_untracked_file_modes="all no normal"
+
 _git_commit ()
 {
case "$prev" in
@@ -1119,7 +1121,7 @@ _git_commit ()
return
;;
--untracked-files=*)
-   __gitcomp "all no normal" "" "${cur##--untracked-files=}"
+   __gitcomp "$__git_untracked_file_modes" "" 
"${cur##--untracked-files=}"
return
;;
--*)
-- 
2.8.4.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 3/3] completion: add git status

[Thomas Braun]

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 50 ++
 1 file changed, 50 insertions(+)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 0bf67c9..ddda5e5 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1826,6 +1826,56 @@ _git_stage ()
_git_add
 }
 
+_git_status ()
+{
+   local complete_opt
+   local untracked_state
+
+   case "$cur" in
+   --ignore-submodules=*)
+   __gitcomp "none untracked dirty all" "" 
"${cur##--ignore-submodules=}"
+   return
+   ;;
+   --untracked-files=*)
+   __gitcomp "$__git_untracked_file_modes" "" 
"${cur##--untracked-files=}"
+   return
+   ;;
+   --column=*)
+   __gitcomp "
+   always never auto column row plain dense nodense
+   " "" "${cur##--column=}"
+   return
+   ;;
+   --*)
+   __gitcomp "
+   --short --branch --porcelain --long --verbose
+   --untracked-files= --ignore-submodules= --ignored
+   --column= --no-column
+   "
+   return
+   ;;
+   esac
+
+   untracked_state="$(__git_get_option_value "-u" "--untracked-files=" \
+   "$__git_untracked_file_modes" "status.showUntrackedFiles")"
+
+   case "$untracked_state" in
+   no)
+   # --ignored option does not matter
+   complete_opt=
+   ;;
+   all|normal|*)
+   complete_opt="--cached --directory --no-empty-directory 
--others"
+
+   if [ -n "$(__git_find_on_cmdline "--ignored")" ]; then
+   complete_opt="$complete_opt --ignored --exclude=*"
+   fi
+   ;;
+   esac
+
+   __git_complete_index_file "$complete_opt"
+}
+
 __git_config_get_set_variables ()
 {
local prevword word config_file= c=$cword
-- 
2.8.4.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Jun 2016, #03; Thu, 9)

[Thomas Braun]

Am 09.06.2016 um 19:21 schrieb Junio C Hamano:
> * tb/complete-status (2016-06-06) 3 commits
>  - completion: add git status
>  - completion: add __git_get_option_value helper
>  - completion: factor out untracked file modes into a variable
> 
>  The completion script (in contrib/) learned to complete "git
>  status" options.
> 
>  Breaks t9902.

Fixed in v5.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/3] completion: factor out untracked file modes into a variable

[Thomas Braun]

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 3402475..addea89 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1098,6 +1098,8 @@ _git_clone ()
esac
 }
 
+__git_untracked_file_modes="all no normal"
+
 _git_commit ()
 {
case "$prev" in
@@ -1119,7 +1121,7 @@ _git_commit ()
return
;;
--untracked-files=*)
-   __gitcomp "all no normal" "" "${cur##--untracked-files=}"
+   __gitcomp "$__git_untracked_file_modes" "" 
"${cur##--untracked-files=}"
return
;;
--*)
-- 
2.8.4.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 3/3] completion: add git status

[Thomas Braun]

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 50 ++
 1 file changed, 50 insertions(+)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 0bf67c9..ddda5e5 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1826,6 +1826,56 @@ _git_stage ()
_git_add
 }
 
+_git_status ()
+{
+   local complete_opt
+   local untracked_state
+
+   case "$cur" in
+   --ignore-submodules=*)
+   __gitcomp "none untracked dirty all" "" 
"${cur##--ignore-submodules=}"
+   return
+   ;;
+   --untracked-files=*)
+   __gitcomp "$__git_untracked_file_modes" "" 
"${cur##--untracked-files=}"
+   return
+   ;;
+   --column=*)
+   __gitcomp "
+   always never auto column row plain dense nodense
+   " "" "${cur##--column=}"
+   return
+   ;;
+   --*)
+   __gitcomp "
+   --short --branch --porcelain --long --verbose
+   --untracked-files= --ignore-submodules= --ignored
+   --column= --no-column
+   "
+   return
+   ;;
+   esac
+
+   untracked_state="$(__git_get_option_value "-u" "--untracked-files=" \
+   "$__git_untracked_file_modes" "status.showUntrackedFiles")"
+
+   case "$untracked_state" in
+   no)
+   # --ignored option does not matter
+   complete_opt=
+   ;;
+   all|normal|*)
+   complete_opt="--cached --directory --no-empty-directory 
--others"
+
+   if [ -n "$(__git_find_on_cmdline "--ignored")" ]; then
+   complete_opt="$complete_opt --ignored --exclude=*"
+   fi
+   ;;
+   esac
+
+   __git_complete_index_file "$complete_opt"
+}
+
 __git_config_get_set_variables ()
 {
local prevword word config_file= c=$cword
-- 
2.8.4.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 0/3] completion: add git status

[Thomas Braun]

Changes since v4:
- Add SP before backslash at EOL
- Fix line continuation issue in __git_get_option_value,
  now t9902 passes again

Thomas Braun (3):
  completion: factor out untracked file modes into a variable
  completion: add __git_get_option_value helper
  completion: add git status

 contrib/completion/git-completion.bash | 98 +-
 1 file changed, 97 insertions(+), 1 deletion(-)

-- 
2.8.4.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 2/3] completion: add __git_get_option_value helper

[Thomas Braun]

This function allows to search the commmand line and config
files for an option, long and short, with mandatory value.

The function would return e.g. for the command line
"git status -uno --untracked-files=all" the result
"all" regardless of the config option.

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 44 ++
 1 file changed, 44 insertions(+)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index addea89..0bf67c9 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -803,6 +803,50 @@ __git_find_on_cmdline ()
done
 }
 
+# Echo the value of an option set on the command line or config
+#
+# $1: short option name
+# $2: long option name including =
+# $3: list of possible values
+# $4: config string (optional)
+#
+# example:
+# result="$(__git_get_option_value "-d" "--do-something=" \
+# "yes no" "core.doSomething")"
+#
+# result is then either empty (no option set) or "yes" or "no"
+#
+# __git_get_option_value requires 3 arguments
+__git_get_option_value ()
+{
+   local c short_opt long_opt val
+   local result= values config_key word
+
+   short_opt="$1"
+   long_opt="$2"
+   values="$3"
+   config_key="$4"
+
+   ((c = $cword - 1))
+   while [ $c -ge 0 ]; do
+   word="${words[c]}"
+   for val in $values; do
+   if [ "$short_opt$val" = "$word" ] ||
+  [ "$long_opt$val"  = "$word" ]; then
+   result="$val"
+   break 2
+   fi
+   done
+   ((c--))
+   done
+
+   if [ -n "$config_key" ] && [ -z "$result" ]; then
+   result="$(git --git-dir="$(__gitdir)" config "$config_key")"
+   fi
+
+   echo "$result"
+}
+
 __git_has_doubledash ()
 {
local c=1
-- 
2.8.4.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/3] completion: add git status

[Thomas Braun]

Am 06.06.2016 um 19:57 schrieb Junio C Hamano:
> Thomas Braun <thomas.br...@virtuell-zuhause.de> writes:
> 
>> +case "$cur" in
>> +--ignore-submodules=*)
>> +__gitcomp "none untracked dirty all" "" 
>> "${cur##--ignore-submodules=}"
>> +return
>> +;;
>> +--untracked-files=*)
>> +__gitcomp "$__git_untracked_file_modes" "" 
>> "${cur##--untracked-files=}"
>> +return
>> +;;
>> +--column=*)
>> +__gitcomp "
>> +always never auto column row plain dense nodense
>> +" "" "${cur##--column=}"
>> +return
>> +;;
>> +--*)
>> +__gitcomp "
>> +--short --branch --porcelain --long --verbose
>> +--untracked-files= --ignore-submodules= --ignored
>> +--column= --no-column
>> +"
>> +return
>> +;;
>> +esac
>> +
>> +untracked_state="$(__git_get_option_value "-u" "--untracked-files="\
> 
> If you have a SP before that backslash, you can avoid getting
> misunderstood that you are attempting to extend that string
> "--untracked-files=".  The backslash is telling the shell that there
> are more arguments to come, and it is misleading to rely on the fast
> that the next line happens to begin with a whitespace.

Thanks, will be fixed in the reroll.

>> +"$__git_untracked_file_modes" "status.showUntrackedFiles")"
> 
> 
>> +case "$untracked_state" in
>> +no)
>> +# --ignored option does not matter
>> +complete_opt=
>> +;;
>> +all|normal|*)
>> +complete_opt="--cached --directory --no-empty-directory 
>> --others"
>> +
>> +if [ -n "$(__git_find_on_cmdline "--ignored")" ]; then
>> +complete_opt="$complete_opt --ignored --exclude=*"
>> +fi
>> +;;
>> +esac
>> +
>> +__git_complete_index_file "$complete_opt"
>> +}
>> +
>>  __git_config_get_set_variables ()
>>  {
>>  local prevword word config_file= c=$cword
> 

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Creating empty commits with --intent-to-add

[Thomas Braun]

Am 05.06.2016 um 05:15 schrieb Duy Nguyen:
> On Sun, Jun 5, 2016 at 12:54 AM, Thomas Braun
> <thomas.br...@virtuell-zuhause.de> wrote:
>> Hi,
>>
>> the following procedure
>>
>> mkdir test
>> cd test
>> git init
>> echo 1 >file
>> git add --intent-to-add file
>> git commit -m "blurb"
>>
>> results in a commit. I would have expected that git commit complains,
>> as I have not pased the --allow-empty option.
>>
>> Is that intended behaviour?
> 
> It's a bug. I'll get to it very soon.

Thanks for looking into that!

Encouraged by your statement I've done some bisecting via

#!/bin/sh

git=../git/git
( make -j10 git >/dev/null || exit 125 ) &&
cd .. &&
rm -rf test &&
mkdir test &&
cd test &&
$git init &&
echo 1>file &&
$git add --intent-to-add file  &&
$git commit -m "blurb"  &&
exit 1

exit 0

and found 3f6d56de (commit: ignore intent-to-add entries instead of refusing, 
2012-02-07)
as first "bad" commit.

This commit states

#
commit: ignore intent-to-add entries instead of refusing

Originally, "git add -N" was introduced to help users from forgetting to
add new files to the index before they ran "git commit -a".  As an attempt
to help them further so that they do not forget to say "-a", "git commit"
to commit the index as-is was taught to error out, reminding the user that
they may have forgotten to add the final contents of the paths before
running the command.

This turned out to be a false "safety" that is useless.  If the user made
changes to already tracked paths and paths added with "git add -N", and
then ran "git add" to register the final contents of the paths added with
"git add -N", "git commit" will happily create a commit out of the index,
without including the local changes made to the already tracked paths. It
was not a useful "safety" measure to prevent "forgetful" mistakes from
happening.

It turns out that this behaviour is not just a useless false "safety", but
actively hurts use cases of "git add -N" that were discovered later and
have become popular, namely, to tell Git to be aware of these paths added
by "git add -N", so that commands like "git status" and "git diff" would
include them in their output, even though the user is not interested in
including them in the next commit they are going to make.

Fix this ancient UI mistake, and instead make a commit from the index
ignoring the paths added by "git add -N" without adding real contents.
#
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Creating empty commits with --intent-to-add

[Thomas Braun]

Hi,

the following procedure

mkdir test
cd test
git init
echo 1 >file
git add --intent-to-add file
git commit -m "blurb"

results in a commit. I would have expected that git commit complains,
as I have not pased the --allow-empty option.

Is that intended behaviour?

Tested with 2.8.3.windows.1 and 2.1.4 on linux.

Thomas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/3] completion: factor out untracked file modes into a variable

[Thomas Braun]

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 3402475..addea89 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1098,6 +1098,8 @@ _git_clone ()
esac
 }
 
+__git_untracked_file_modes="all no normal"
+
 _git_commit ()
 {
case "$prev" in
@@ -1119,7 +1121,7 @@ _git_commit ()
return
;;
--untracked-files=*)
-   __gitcomp "all no normal" "" "${cur##--untracked-files=}"
+   __gitcomp "$__git_untracked_file_modes" "" 
"${cur##--untracked-files=}"
return
;;
--*)
-- 
2.8.3.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 0/3] support completion for git status

[Thomas Braun]

changes since v3:
* support short version -u of --untracked-files option
* introduce __git_get_option_value for general usage
* fix style issues
* support order dependent statements like
  git status -uno --untracked-files=all
  properly

Thomas Braun (3):
  completion: factor out untracked file modes into a variable
  completion: add __git_get_option_value helper
  completion: add git status

 contrib/completion/git-completion.bash | 98 +-
 1 file changed, 97 insertions(+), 1 deletion(-)

-- 
2.8.3.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 3/3] completion: add git status

[Thomas Braun]

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 50 ++
 1 file changed, 50 insertions(+)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 4bd17aa..9eff33c 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1826,6 +1826,56 @@ _git_stage ()
_git_add
 }
 
+_git_status ()
+{
+   local complete_opt
+   local untracked_state
+
+   case "$cur" in
+   --ignore-submodules=*)
+   __gitcomp "none untracked dirty all" "" 
"${cur##--ignore-submodules=}"
+   return
+   ;;
+   --untracked-files=*)
+   __gitcomp "$__git_untracked_file_modes" "" 
"${cur##--untracked-files=}"
+   return
+   ;;
+   --column=*)
+   __gitcomp "
+   always never auto column row plain dense nodense
+   " "" "${cur##--column=}"
+   return
+   ;;
+   --*)
+   __gitcomp "
+   --short --branch --porcelain --long --verbose
+   --untracked-files= --ignore-submodules= --ignored
+   --column= --no-column
+   "
+   return
+   ;;
+   esac
+
+   untracked_state="$(__git_get_option_value "-u" "--untracked-files="\
+   "$__git_untracked_file_modes" "status.showUntrackedFiles")"
+
+   case "$untracked_state" in
+   no)
+   # --ignored option does not matter
+   complete_opt=
+   ;;
+   all|normal|*)
+   complete_opt="--cached --directory --no-empty-directory 
--others"
+
+   if [ -n "$(__git_find_on_cmdline "--ignored")" ]; then
+   complete_opt="$complete_opt --ignored --exclude=*"
+   fi
+   ;;
+   esac
+
+   __git_complete_index_file "$complete_opt"
+}
+
 __git_config_get_set_variables ()
 {
local prevword word config_file= c=$cword
-- 
2.8.3.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/3] completion: add __git_get_option_value helper

[Thomas Braun]

This function allows to search the commmand line and config
files for an option, long and short, with mandatory value.

The function would return e.g. for the command line
"git status -uno --untracked-files=all" the result
"all" regardless of the config option.

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 44 ++
 1 file changed, 44 insertions(+)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index addea89..4bd17aa 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -803,6 +803,50 @@ __git_find_on_cmdline ()
done
 }
 
+# Echo the value of an option set on the command line or config
+#
+# $1: short option name
+# $2: long option name including =
+# $3: list of possible values
+# $4: config string (optional)
+#
+# example:
+# result="$(__git_get_option_value "-d" "--do-something="\
+# "yes no" "core.doSomething")"
+#
+# result is then either empty (no option set) or "yes" or "no"
+#
+# __git_get_option_value requires 3 arguments
+__git_get_option_value ()
+{
+   local c short_opt long_opt val
+   local result= values config_key word
+
+   short_opt="$1"
+   long_opt="$2"
+   values="$3"
+   config_key="$4"
+
+   ((c = $cword - 1))
+   while [ $c -ge 0 ]; do
+   word="${words[c]}"
+   for val in $values; do
+   if [ "$short_opt$val" = "$word" ]
+   || [ "$long_opt$val"  = "$word" ]; then
+   result="$val"
+   break 2
+   fi
+   done
+   ((c--))
+   done
+
+   if [ -n "$config_key" ] && [ -z "$result" ]; then
+   result="$(git --git-dir="$(__gitdir)" config "$config_key")"
+   fi
+
+   echo "$result"
+}
+
 __git_has_doubledash ()
 {
local c=1
-- 
2.8.3.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] completion: add git status

[Thomas Braun]

Am 03.06.2016 um 19:54 schrieb Junio C Hamano:
> Jeff King  writes:
> 
>> I know not everybody will the "natural thing" I claim, and if it were
>> easy to support everywhere, I don't mind doing it. But I suspect
>> (without thinking very hard on it) that it would make those case
>> statements a bit harder to read and maintain.
> 
> Oh, I agree with that 100%.  I didn't mean to suggest (let alone to
> demand) to support the possible truncations.
> 
> I simply was hoping that Thomas would respond with your "For a user
> who uses tab completion, it is natural to use --unt so by the
> time we use find-on-command-line, we can expect the fully-spelled
> form" when I asked about "--unt=no"; that would give us a warm and
> fuzzy confirmation that the patch author has thought things through
> when designing the new feature.

I understood from Junio's comment [1]

> $ git status -uno 

that the question was about the short option version not about how
possible truncations are handled.

On the other side I must confess I did not think about the possibility
that the user truncates a long option as in --unt=all. Looking through
the completion file I have not found a place where the truncated
versions are supported.

[1]: http://article.gmane.org/gmane.comp.version-control.git/296220
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] completion: add git status

[Thomas Braun]

Am 02.06.2016 um 20:14 schrieb Junio C Hamano:
> Thomas Braun <thomas.br...@virtuell-zuhause.de> writes:
> 
>> +untracked_state="$(__git_find_on_cmdline "--untracked-files=no\
>> +--untracked-files=normal --untracked-files=all")"
> 
> Just wondering but does this help my use of the command like
> 
>   $ git status -uno 
> 
> or do I now have to spell it out like
> 
>   $ git status --untracked-files=no 
> 
> to take advantage of it?

I was unsure if I should support the short option (-u) as well. On
thinking about it again there is little use of only doing it for the
long option.
Will be handled in a reroll.

>> +untracked_state=${untracked_state##--untracked-files=}
>> +
>> +if [ -z "$untracked_state" ]; then
>> +untracked_state="$(git --git-dir="$(__gitdir)" config 
>> "status.showUntrackedFiles")"
>> +fi
>> +
>> +case "$untracked_state" in
>> +no)
>> +# --ignored option does not matter
> 
> Style.  I see existing case/esac statements that use this style, but
> our preference is not to indent case arms like this; rather:
> 
>   case "$untracked_state" in
> no)
>   # --ignored ...
> 
> which saves the indentation one level overall.

thanks, will be fixed.

>> +complete_opt=
>> +;;
>> +all|normal|*)
>> +complete_opt="--cached --directory --no-empty-directory 
>> --others"
>> +
>> +if [ -n "$(__git_find_on_cmdline "--ignored")" ]; then
> 
> Same question as the "--untracked-files=no vs -uno" applies here.

Is there a short version of --ignored? I could not find one in the help,
and from a look into cmd_status in commit.c I would say there is none.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/2] completion: factor out untracked file modes into a variable

[Thomas Braun]

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 3402475..addea89 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1098,6 +1098,8 @@ _git_clone ()
esac
 }
 
+__git_untracked_file_modes="all no normal"
+
 _git_commit ()
 {
case "$prev" in
@@ -1119,7 +1121,7 @@ _git_commit ()
return
;;
--untracked-files=*)
-   __gitcomp "all no normal" "" "${cur##--untracked-files=}"
+   __gitcomp "$__git_untracked_file_modes" "" 
"${cur##--untracked-files=}"
return
;;
--*)


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/2] completion: add git status

[Thomas Braun]

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 55 ++
 1 file changed, 55 insertions(+)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index addea89..fa7a03a 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1782,6 +1782,61 @@ _git_stage ()
_git_add
 }
 
+_git_status ()
+{
+   local complete_opt
+   local untracked_state
+
+   case "$cur" in
+   --ignore-submodules=*)
+   __gitcomp "none untracked dirty all" "" 
"${cur##--ignore-submodules=}"
+   return
+   ;;
+   --untracked-files=*)
+   __gitcomp "$__git_untracked_file_modes" "" 
"${cur##--untracked-files=}"
+   return
+   ;;
+   --column=*)
+   __gitcomp "
+   always never auto column row plain dense nodense
+   " "" "${cur##--column=}"
+   return
+   ;;
+   --*)
+   __gitcomp "
+   --short --branch --porcelain --long --verbose
+   --untracked-files= --ignore-submodules= --ignored
+   --column= --no-column
+   "
+   return
+   ;;
+   esac
+
+   untracked_state="$(__git_find_on_cmdline "--untracked-files=no\
+   --untracked-files=normal --untracked-files=all")"
+   untracked_state=${untracked_state##--untracked-files=}
+
+   if [ -z "$untracked_state" ]; then
+   untracked_state="$(git --git-dir="$(__gitdir)" config 
"status.showUntrackedFiles")"
+   fi
+
+   case "$untracked_state" in
+   no)
+   # --ignored option does not matter
+   complete_opt=
+   ;;
+   all|normal|*)
+   complete_opt="--cached --directory --no-empty-directory 
--others"
+
+   if [ -n "$(__git_find_on_cmdline "--ignored")" ]; then
+   complete_opt="$complete_opt --ignored 
--exclude=*"
+   fi
+   ;;
+   esac
+
+   __git_complete_index_file "$complete_opt"
+}
+
 __git_config_get_set_variables ()
 {
local prevword word config_file= c=$cword
-- 
2.8.3.windows.1



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] completion: add git status

[Thomas Braun]

Am 01.06.2016 um 14:15 schrieb SZEDER Gábor:
> 
> Quoting Thomas Braun <thomas.br...@virtuell-zuhause.de>:
> 
>> Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
>> ---
>>  contrib/completion/git-completion.bash | 29
>> +
>>  1 file changed, 29 insertions(+)
>>
>> diff --git a/contrib/completion/git-completion.bash
>> b/contrib/completion/git-completion.bash
>> index addea89..77343da 100644
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -1782,6 +1782,35 @@ _git_stage ()
>>  _git_add
>>  }
>>
>> +_git_status ()
>> +{
>> +case "$cur" in
>> +--ignore-submodules=*)
>> +__gitcomp "none untracked dirty all" ""
>> "${cur##--ignore-submodules=}"
>> +return
>> +;;
>> +--untracked-files=*)
>> +__gitcomp "$__git_untracked_file_modes" ""
>> "${cur##--untracked-files=}"
>> +return
>> +;;
>> +--column=*)
>> +__gitcomp "
>> +always never auto column row plain dense nodense
>> +" "" "${cur##--column=}"
>> +return
>> +;;
>> +--*)
>> +__gitcomp "
>> +--short --branch --porcelain --long --verbose
>> +--untracked-files= --ignore-submodules= --ignored
>> +--column= --no-column
>> +"
>> +return
>> +;;
>> +esac
>> +__git_complete_file
> 
> __git_complete_file()'s job is to complete the ':' notation,
> e.g. 'master:Mak',  which is not what we want here, because this
> notation doesn't make sense for 'git status' and because 'git status
> ' would then offer refs instead of files.

Correct. I might have been mislead by the name ;)

> I think there are two choices what to do instead:
> 
>   - Don't do anything :)  Bash will then fall back to filename
> completion, which is quite close to what we want here (and in this
> case the return statements from the other case arms can go away as
> well).  The drawback is that all ignored files in the current
> working directory will show up after 'git status '.
> 
>   - use __git_complete_index_file() with appropriate options, perhaps
> '--cached --others', but I didn't think this through.  For bonus
> points pass additional options when certain 'git status' options are
> already present on the command line, e.g. pass '--ignored', too, if
> it is present.

I went for the bonus points way. If that is too involved I can also go
back to "Don't do anything".


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] completion: create variable for untracked file modes

[Thomas Braun]

Am 01.06.2016 um 13:59 schrieb SZEDER Gábor:
> 
> This subject would perhaps read better:
> 
>   completion: factor out untracked file modes into a variable

Yes, definitly. Will be included in reroll.

> Quoting Thomas Braun <thomas.br...@virtuell-zuhause.de>:
> 
>> Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
>> ---
>>  contrib/completion/git-completion.bash | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/contrib/completion/git-completion.bash
>> b/contrib/completion/git-completion.bash
>> index 3402475..addea89 100644
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -1098,6 +1098,8 @@ _git_clone ()
>>  esac
>>  }
>>
>> +__git_untracked_file_modes="all no normal"
>> +
>>  _git_commit ()
>>  {
>>  case "$prev" in
>> @@ -1119,7 +1121,7 @@ _git_commit ()
>>  return
>>  ;;
>>  --untracked-files=*)
>> -__gitcomp "all no normal" "" "${cur##--untracked-files=}"
>> +__gitcomp "$__git_untracked_file_modes" ""
>> "${cur##--untracked-files=}"
>>  return
>>  ;;
>>  --*)
> 
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] completion: add git status

[Thomas Braun]

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 29 +
 1 file changed, 29 insertions(+)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index addea89..77343da 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1782,6 +1782,35 @@ _git_stage ()
_git_add
 }
 
+_git_status ()
+{
+   case "$cur" in
+   --ignore-submodules=*)
+   __gitcomp "none untracked dirty all" "" 
"${cur##--ignore-submodules=}"
+   return
+   ;;
+   --untracked-files=*)
+   __gitcomp "$__git_untracked_file_modes" "" 
"${cur##--untracked-files=}"
+   return
+   ;;
+   --column=*)
+   __gitcomp "
+   always never auto column row plain dense nodense
+   " "" "${cur##--column=}"
+   return
+   ;;
+   --*)
+   __gitcomp "
+   --short --branch --porcelain --long --verbose
+   --untracked-files= --ignore-submodules= --ignored
+   --column= --no-column
+   "
+   return
+   ;;
+   esac
+   __git_complete_file
+}
+
 __git_config_get_set_variables ()
 {
local prevword word config_file= c=$cword


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] completion: create variable for untracked file modes

[Thomas Braun]

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 3402475..addea89 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1098,6 +1098,8 @@ _git_clone ()
esac
 }
 
+__git_untracked_file_modes="all no normal"
+
 _git_commit ()
 {
case "$prev" in
@@ -1119,7 +1121,7 @@ _git_commit ()
return
;;
--untracked-files=*)
-   __gitcomp "all no normal" "" "${cur##--untracked-files=}"
+   __gitcomp "$__git_untracked_file_modes" "" 
"${cur##--untracked-files=}"
return
;;
--*)


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] completion: add git status

[Thomas Braun]

> Jeff King <p...@peff.net> hat am 1. Juni 2016 um 06:07 geschrieben:
> 
> 
> On Wed, Jun 01, 2016 at 01:42:18AM +0200, Thomas Braun wrote:
> 
> > Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
> > ---
> >  contrib/completion/git-completion.bash | 29 +
> >  1 file changed, 29 insertions(+)
> > 
> > diff --git a/contrib/completion/git-completion.bash
> > b/contrib/completion/git-completion.bash
> > index 57a0acc..96b7d86 100644
> > --- a/contrib/completion/git-completion.bash
> > +++ b/contrib/completion/git-completion.bash
> > @@ -1782,6 +1782,35 @@ _git_stage ()
> > _git_add
> >  }
> >  +_git_status ()
> 
> This patch has the same funniness as the other. Weird.

Should be fixed now.

> > +{
> > +   case "$cur" in
> > +   --ignore-submodules=*)
> > +   __gitcomp "none untracked dirty all" "" 
> > "${cur##--ignore-submodules=}"
> > +   return
> > +   ;;
> > +   --untracked-files=*)
> > +   __gitcomp "$(__git_untracked_file_modes)" "" 
> > "${cur##--untracked-files=}"
> 
> Same comment on $() here.

Fixed.

> > +   return
> > +   ;;
> > +   --column=*)
> > +   __gitcomp "
> > +   always never auto column row plain dense nodense
> > +   " "" "${cur##--column=}"
> > +   return
> > +   ;;
> > +   --*)
> > +   __gitcomp "
> > +   --short --branch --porcelain --long --verbose
> > +   --untracked-files= --ignore-submodules= --ignored
> > +   --column= --no-column
> > +   "
> > +   return
> > +   ;;
> > +   esac
> > +   __git_complete_file
> > +}
> 
> The rest of it (both the overall goal, and the patch itself) look OK to
> me.

Thanks,
Thomas

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] completion: create variable for untracked file modes

[Thomas Braun]

> Junio C Hamano  hat am 1. Juni 2016 um 09:02 geschrieben:
> 
> 
> Jeff King  writes:
> 
> >> diff --git a/contrib/completion/git-completion.bash
> >> b/contrib/completion/git-completion.bash
> >> index 3402475..57a0acc 100644
> >> --- a/contrib/completion/git-completion.bash
> >> +++ b/contrib/completion/git-completion.bash
> >> @@ -1098,6 +1098,8 @@ _git_clone ()
> >>esac
> >>  }
> >>  +__git_untracked_file_modes="all no normal"
> >> +
> >>  _git_commit ()
> >>  {
> >>case "$prev" in
> >
> > There's something funny about the formatting of your patch. The first
> > "+" line is indented, which it shouldn't be. As it is, it looks like
> > context (but it's not actually part of the preimage). But if it's not
> > context, then you are missing a context line.
> 
> Not just that.  Count the context lines and notice that this appears
> to have only 2 lines of precontext.
> 
> I think the MUA is somehow eating a blank line context (i.e. a
> single SP on a line by itself) immediately after the closing brace
> of the function before _git_commit and the next new line that began
> with '+' in the original and made them into a single line.  I've
> seen this exact breakage before, I think.

Thanks both for noticing and sorry for the mess.

I'm using Thunderbird 45.1.1 on Windows and the "Toggle Word Wrap" addon
for well trying to avoid messing up whitespace. The emails are created
with `git format-patch ... | git imap-send` and sent to my drafts
folder. There they look good *until* I choose "Edit as new" which seems
to be required to actually send the email.  So I'll
stick to other solutions for now.

Reroll follows.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] completion: create variable for untracked file modes

[Thomas Braun]

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 3402475..57a0acc 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1098,6 +1098,8 @@ _git_clone ()
esac
 }
 +__git_untracked_file_modes="all no normal"
+
 _git_commit ()
 {
case "$prev" in
@@ -1119,7 +1121,7 @@ _git_commit ()
return
;;
--untracked-files=*)
-   __gitcomp "all no normal" "" "${cur##--untracked-files=}"
+   __gitcomp "$(__git_untracked_file_modes)" "" 
"${cur##--untracked-files=}"
return
;;
--*)
-- 
2.8.3.windows.1


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] completion: add git status

[Thomas Braun]

Hi,

I was suprised to learn that git status does not get completed for bash.

So I thought this has to change, see the following patches.

Thomas Braun (2):
  completion: create variable for untracked file modes
  completion: add git status

 contrib/completion/git-completion.bash | 33
-
 1 file changed, 32 insertions(+), 1 deletion(-)

-- 
2.8.3.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] completion: add git status

[Thomas Braun]

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 29 +
 1 file changed, 29 insertions(+)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 57a0acc..96b7d86 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1782,6 +1782,35 @@ _git_stage ()
_git_add
 }
 +_git_status ()
+{
+   case "$cur" in
+   --ignore-submodules=*)
+   __gitcomp "none untracked dirty all" "" 
"${cur##--ignore-submodules=}"
+   return
+   ;;
+   --untracked-files=*)
+   __gitcomp "$(__git_untracked_file_modes)" "" 
"${cur##--untracked-files=}"
+   return
+   ;;
+   --column=*)
+   __gitcomp "
+   always never auto column row plain dense nodense
+   " "" "${cur##--column=}"
+   return
+   ;;
+   --*)
+   __gitcomp "
+   --short --branch --porcelain --long --verbose
+   --untracked-files= --ignore-submodules= --ignored
+   --column= --no-column
+   "
+   return
+   ;;
+   esac
+   __git_complete_file
+}
+
 __git_config_get_set_variables ()
 {
local prevword word config_file= c=$cword
-- 
2.8.3.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Creates unreadable pack files on platforms with sizeof(unsigned long) != sizeof(uintmax_t)

[Thomas Braun]

Hi,

while playing around with some git settings I encountered some problems on 
Windows x64
using the 64bit build of git.
And it is not restricted to that platform.

Recipe to break:
mkdir test &&
cd test &&
truncate -s 5g largefile.bin &&
git init &&
git add . &&
git commit -m "changes" &&
git fsck

Result:
Initialized empty Git repository in E:/ttest/.git/
[master (root-commit) d19adaf] changes
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 largefile.bin
Checking object directories: 100% (256/256), done.
error: bad object header
error: unknown object type -1 at offset 12 in
.git/objects/pack/pack-25250ce5c176078ba51a42fee177c2f03f8845ca.pack
error: cannot unpack 0be2be10a4c8764f32c4bf372a98edc731a4b204 from
.git/objects/pack/pack-25250ce5c176078ba51a42fee177c2f03f8845ca.pack at offset
12
Checking objects: 100% (1/1), done.

So I've created a repository which I can now not use.

The die() call is from unpack_object_header_buffer() in sha1_file.c. On windows 
x64
bitsizeof(long) returns 32 and equals shift at some point.
unpack_object_header_buffer() returns the size in an unsigned long (32bit). [1, 
2, 3]

The questions why this has not been detected on creating the pack leads to
encode_in_pack_object_header()
which uses uintmax_t (64 bit wide) for storing the size.

unsigned long is used in more places for file sizes e.g. in struct object_entry
in pack-objects.h.

The proper solution now would be, I guess, to convert file sizes from unsigned 
long to something
which is wider on windows x64 and in the best case the same size on linux. My 
git code base foo is rather
low and it looks much more involved than a simple s//.

A first intermediate solution could be to die on pack creation e.g. in 

diff --git a/pack-write.c b/pack-write.c
index 33293ce..ebb8b0a 100644
--- a/pack-write.c
+++ b/pack-write.c
@@ -313,6 +313,9 @@ int encode_in_pack_object_header(enum object_type type, 
uintmax_t size, unsigned
if (type < OBJ_COMMIT || type > OBJ_REF_DELTA)
die("bad type %d", type);

+   if (bitsizeof(unsigned long) != bitsizeof(uintmax_t) && size > 
(unsigned long) size)
+   die("Cannot handle files this big");
+
c = (type << 4) | (size & 15);
size >>= 4;
while (size) {

With that patch I get

$ ../git add .
fatal: Cannot handle files this big

I know that usually people don't add big binary files to git. But I do, so I 
care ;)
If this direction sounds reasonable I can provide a proper patch.

Thanks,
Thomas

[1]: https://msdn.microsoft.com/en-us/library/323b6b3k.aspx
[2]: https://msdn.microsoft.com/en-us/library/s3f49ktz.aspx
[3]: http://stackoverflow.com/questions/7607502/sizeoflong-in-64-bit-c
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] completion: Add --word-diff-regex= to diff

[Thomas Braun]

Am 21.01.2016 um 01:18 schrieb Junio C Hamano:
> Thomas Braun <thomas.br...@virtuell-zuhause.de> writes:
> 
>> Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
>> ---
>>  contrib/completion/git-completion.bash | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/contrib/completion/git-completion.bash
>> b/contrib/completion/git-completion.bash
>> index ab4da7f..d2a08dd 100644
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -1169,7 +1169,7 @@ __git_diff_common_options="--stat --numstat
>> --shortstat --summary
>>  --no-prefix --src-prefix= --dst-prefix=
>>  --inter-hunk-context=
>>  --patience --histogram --minimal
>> ---raw --word-diff
>> +--raw --word-diff --word-diff-regex=
>>  --dirstat --dirstat= --dirstat-by-file
>>  --dirstat-by-file= --cumulative
>>  --diff-algorithm=
> 
> Thanks; the patch was word-wrapped, but I fixed it up and managed to
> apply.

Thanks for applying Junio, and sorry that you had to clean up my sloppyness.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] completion: Add --word-diff-regex= to diff

[Thomas Braun]

Signed-off-by: Thomas Braun <thomas.br...@virtuell-zuhause.de>
---
 contrib/completion/git-completion.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index ab4da7f..d2a08dd 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1169,7 +1169,7 @@ __git_diff_common_options="--stat --numstat
--shortstat --summary
--no-prefix --src-prefix= --dst-prefix=
--inter-hunk-context=
--patience --histogram --minimal
-   --raw --word-diff
+   --raw --word-diff --word-diff-regex=
--dirstat --dirstat= --dirstat-by-file
--dirstat-by-file= --cumulative
--diff-algorithm=
-- 
2.7.0.windows.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/1] completion: offer '--edit-todo' during interactive rebase

[Thomas Braun]

Signed-off-by: Thomas Braun thomas.br...@virtuell-zuhause.de
Helped-by: John Keeping j...@keeping.me.uk
Helped-by: SZEDER Gábor sze...@ira.uka.de
---
Tested by:
- ensuring I'm in a bash shell
- source git-completion.bash
- git rebase -i HEAD~1, choose edit instead of pick in the editor
- on entering git rebase you should be offered --edit-todo

 contrib/completion/git-completion.bash | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index c97c648..087771b 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1667,7 +1667,10 @@ _git_push ()
 _git_rebase ()
 {
local dir=$(__gitdir)
-   if [ -d $dir/rebase-apply ] || [ -d $dir/rebase-merge ]; then
+   if [ -f $dir/rebase-merge/interactive ]; then
+   __gitcomp --continue --skip --abort --edit-todo
+   return
+   elif [ -d $dir/rebase-apply ] || [ -d $dir/rebase-merge ]; then
__gitcomp --continue --skip --abort
return
fi
-- 
2.4.3.413.ga5fe668
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] completion: Add '--edit-todo' to rebase

[Thomas Braun]

Signed-off-by: Thomas Braun thomas.br...@virtuell-zuhause.de
---
 John Keeping j...@keeping.me.uk hat am 13. Juli 2015 um 15:11 geschrieben:
 git-rebase.sh contains:
 
   if test $action = edit-todo  test $type != interactive
   then
   die $(gettext The --edit-todo action can only be used during 
 interactive
 rebase.)
   fi
 
 I wonder if it's worth doing a similar check here, which presumably
 means testing if $dir/interactive exists.

Good point. Thanks for the hint.

 contrib/completion/git-completion.bash | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index c97c648..b03050e 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1668,7 +1668,11 @@ _git_rebase ()
 {
local dir=$(__gitdir)
if [ -d $dir/rebase-apply ] || [ -d $dir/rebase-merge ]; then
-   __gitcomp --continue --skip --abort
+   if [ -d $dir/interactive ]; then
+   __gitcomp --continue --skip --abort --edit-todo
+   else
+   __gitcomp --continue --skip --abort
+   fi
return
fi
__git_complete_strategy  return
-- 
2.4.5.windows.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] completion: Add '--edit-todo' to rebase

[Thomas Braun]

Signed-off-by: Thomas Braun thomas.br...@virtuell-zuhause.de
---
 contrib/completion/git-completion.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index c97c648..2567a61 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1668,7 +1668,7 @@ _git_rebase ()
 {
local dir=$(__gitdir)
if [ -d $dir/rebase-apply ] || [ -d $dir/rebase-merge ]; then
-   __gitcomp --continue --skip --abort
+   __gitcomp --continue --skip --abort --edit-todo
return
fi
__git_complete_strategy  return


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] 4th release candidate of Git for Windows 2.x, was Re: 3rd release candidate of Git for Windows 2.x

[Thomas Braun]

Am 30.06.2015 um 19:15 schrieb Konstantin Khomoutov:
 On Mon, 29 Jun 2015 18:19:09 +0200
 Johannes Schindelin johannes.schinde...@gmx.de wrote:
 
 I've finally took time to switch from my old msys1 release to this
 RC4, and immediately got hit by the fact Git is now speaking to me
 in Russian, which is not what I want (previously this behaviour was
 only exhibited by `git gui` and `gitk`).

 Should I make Git see LC_MESSAGES=en (or other thing like LANG) in
 the environment or is there some Git-local method to affect this
 behaviour? I tried to grep the release notes using relevant
 keywords but was left empty-handed.

 Personally, I would use LC_ALL=C. Maybe that's good for you, too?
 
 After reading [1], I've ended up installing LANG=C into my user's
 environment variables -- so far so good, thanks for the tip!

Just for the record.
I created the file lang.sh with contents
export LC_ALL=C
in
/etc/profile.d
which also fixes the problem. And also survives new versions of git.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] completion: suggest sequencer commands for revert

[Thomas Braun]

Signed-off-by: Thomas Braun thomas.br...@virtuell-zuhause.de
---
 contrib/completion/git-completion.bash | 8 
 1 file changed, 8 insertions(+)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index f6e5bf6..486c61b 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -868,6 +868,12 @@ __git_complete_sequencer ()
return 0
fi
;;
+   revert)
+   if [ -f $dir/REVERT_HEAD ]; then
+   __gitcomp --continue --quit --abort
+   return 0
+   fi
+   ;;
rebase)
if [ -d $dir/rebase-apply ] || [ -d $dir/rebase-merge ]; 
then
__gitcomp --continue --skip --abort
@@ -2300,6 +2306,8 @@ _git_reset ()
 
 _git_revert ()
 {
+   __git_complete_sequencer revert  return
+
case $cur in
--*)
__gitcomp --edit --mainline --no-edit --no-commit --signoff


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/2] completion: sequencer commands

[Thomas Braun]

Ramkumar Ramachandra wrote:
 Junio C Hamano wrote:
 
contrib/completion/git-completion.bash | 5 +
1 file changed, 5 insertions(+)
  
   diff --git a/contrib/completion/git-completion.bash
 b/contrib/completion/git-completion.bash
   index bfc74e9..3c00acd 100644
   --- a/contrib/completion/git-completion.bash
   +++ b/contrib/completion/git-completion.bash
   @@ -2282,6 +2282,11 @@ _git_reset ()
  
_git_revert ()
{
   + local dir=$(__gitdir)
   + if [ -f $dir/REVERT_HEAD ]; then
   + __gitcomp --continue --quit --abort
   + return
   + fi
 case $cur in
 --*)
 __gitcomp --edit --mainline --no-edit --no-commit
 --signoff

 This corresponds exactly to what we do for git-cherry-pick:

 local dir=$(__gitdir)
 if [ -f $dir/CHERRY_PICK_HEAD ]; then
 __gitcomp --continue --quit --abort
 return
 fi

 Perhaps _git_revert() and _git_cherry_pick() should call into the same
 function with different arguments.

Good idea.
I created a new function __git_complete_sequencer which is now used to complete
all commands with active sequencer.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] completion: Add sequencer function

[Thomas Braun]

Signed-off-by: Thomas Braun thomas.br...@virtuell-zuhause.de
---
 contrib/completion/git-completion.bash | 48 +++---
 1 file changed, 33 insertions(+), 15 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index bfc74e9..f6e5bf6 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -851,15 +851,40 @@ __git_count_arguments ()
printf %d $c
 }
 
+__git_complete_sequencer ()
+{
+   local dir=$(__gitdir)
+
+   case $1 in
+   am)
+   if [ -d $dir/rebase-apply ]; then
+   __gitcomp --skip --continue --resolved --abort
+   return 0
+   fi
+   ;;
+   cherry-pick)
+   if [ -f $dir/CHERRY_PICK_HEAD ]; then
+   __gitcomp --continue --quit --abort
+   return 0
+   fi
+   ;;
+   rebase)
+   if [ -d $dir/rebase-apply ] || [ -d $dir/rebase-merge ]; 
then
+   __gitcomp --continue --skip --abort
+   return 0
+   fi
+   ;;
+   esac
+
+   return 1
+}
+
 __git_whitespacelist=nowarn warn error error-all fix
 
 _git_am ()
 {
-   local dir=$(__gitdir)
-   if [ -d $dir/rebase-apply ]; then
-   __gitcomp --skip --continue --resolved --abort
-   return
-   fi
+   __git_complete_sequencer am  return
+
case $cur in
--whitespace=*)
__gitcomp $__git_whitespacelist  ${cur##--whitespace=}
@@ -1044,11 +1069,8 @@ _git_cherry ()
 
 _git_cherry_pick ()
 {
-   local dir=$(__gitdir)
-   if [ -f $dir/CHERRY_PICK_HEAD ]; then
-   __gitcomp --continue --quit --abort
-   return
-   fi
+   __git_complete_sequencer cherry-pick  return
+
case $cur in
--*)
__gitcomp --edit --no-commit --signoff --strategy= --mainline
@@ -1666,11 +1688,7 @@ _git_push ()
 
 _git_rebase ()
 {
-   local dir=$(__gitdir)
-   if [ -d $dir/rebase-apply ] || [ -d $dir/rebase-merge ]; then
-   __gitcomp --continue --skip --abort
-   return
-   fi
+   __git_complete_sequencer rebase  return
__git_complete_strategy  return
case $cur in
--whitespace=*)


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] completion: Add sequencer function

[Thomas Braun]

Signed-off-by: Thomas Braun thomas.br...@virtuell-zuhause.de
---
 contrib/completion/git-completion.bash | 48 +++---
 1 file changed, 33 insertions(+), 15 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index bfc74e9..f6e5bf6 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -851,15 +851,40 @@ __git_count_arguments ()
printf %d $c
 }
 
+__git_complete_sequencer ()
+{
+   local dir=$(__gitdir)
+
+   case $1 in
+   am)
+   if [ -d $dir/rebase-apply ]; then
+   __gitcomp --skip --continue --resolved --abort
+   return 0
+   fi
+   ;;
+   cherry-pick)
+   if [ -f $dir/CHERRY_PICK_HEAD ]; then
+   __gitcomp --continue --quit --abort
+   return 0
+   fi
+   ;;
+   rebase)
+   if [ -d $dir/rebase-apply ] || [ -d $dir/rebase-merge ]; 
then
+   __gitcomp --continue --skip --abort
+   return 0
+   fi
+   ;;
+   esac
+
+   return 1
+}
+
 __git_whitespacelist=nowarn warn error error-all fix
 
 _git_am ()
 {
-   local dir=$(__gitdir)
-   if [ -d $dir/rebase-apply ]; then
-   __gitcomp --skip --continue --resolved --abort
-   return
-   fi
+   __git_complete_sequencer am  return
+
case $cur in
--whitespace=*)
__gitcomp $__git_whitespacelist  ${cur##--whitespace=}
@@ -1044,11 +1069,8 @@ _git_cherry ()
 
 _git_cherry_pick ()
 {
-   local dir=$(__gitdir)
-   if [ -f $dir/CHERRY_PICK_HEAD ]; then
-   __gitcomp --continue --quit --abort
-   return
-   fi
+   __git_complete_sequencer cherry-pick  return
+
case $cur in
--*)
__gitcomp --edit --no-commit --signoff --strategy= --mainline
@@ -1666,11 +1688,7 @@ _git_push ()
 
 _git_rebase ()
 {
-   local dir=$(__gitdir)
-   if [ -d $dir/rebase-apply ] || [ -d $dir/rebase-merge ]; then
-   __gitcomp --continue --skip --abort
-   return
-   fi
+   __git_complete_sequencer rebase  return
__git_complete_strategy  return
case $cur in
--whitespace=*)


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] completion: suggest sequencer commands for revert

[Thomas Braun]

Signed-off-by: Thomas Braun thomas.br...@virtuell-zuhause.de
---

Hi,

I added the sequencer commands for git revert. These are handy in case a git
revert needs manual intervention.

Thanks,
Thomas

 contrib/completion/git-completion.bash | 5 +
 1 file changed, 5 insertions(+)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index bfc74e9..3c00acd 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2282,6 +2282,11 @@ _git_reset ()
 
 _git_revert ()
 {
+   local dir=$(__gitdir)
+   if [ -f $dir/REVERT_HEAD ]; then
+   __gitcomp --continue --quit --abort
+   return
+   fi
case $cur in
--*)
__gitcomp --edit --mainline --no-edit --no-commit --signoff


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Issue: repack semi-frequently fails on Windows (msysgit) - suspecting file descriptor issues

[Thomas Braun]

Am 16.04.2015 um 12:03 schrieb Andreas Mohr:
 Hi all,
 
 over the years I've had the same phenomenon with various versions of msysgit
 (now at 1.9.5.msysgit.0, on Windows 7 64bit), so I'm now sufficiently
 confident of it being a long-standing, longer-term issue and thus I'm
 reporting it now.

(CC'ing msysgit)

Hi Andreas,

 Since I'm doing development in a sufficiently rebase-heavy manner,
 I seem to aggregate a lot of objects.
 Thus, when fetching content I'm sufficiently frequently greeted with
 a git gc run.
 This, however, does not work fully reliably:
 
 Auto packing the repository for optimum performance. You may also
 run git gc manually. See git help gc for more information.
 Counting objects: 206527, done.
 Delta compression using up to 4 threads.
 Compressing objects: 100% (27430/27430), done.
 Writing objects: 100% (206527/206527), done.
 Total 206527 (delta 178632), reused 206527 (delta 178632)
 Unlink of file 
 '.git/objects/pack/pack-ab1712db0a94b5c55538d3b4cb3660cedc264c3c.pack' 
 failed. Should I try again? (y/n) n
 Unlink of file 
 '.git/objects/pack/pack-ab1712db0a94b5c55538d3b4cb3660cedc264c3c.idx' failed. 
 Should I try again? (y/n) n
 Checking connectivity: 206527, done.
 
 A workable workaround for this recurring issue
 (such a fetch will fail repeatedly,
 thereby hampering my ability to update properly)
 is to manually do a git gc --auto
 prior to the fetch (which will then succeed).

I've never had this issue. The error message from unlinking the file
means that someone is still accessing the file and thus it can not be
deleted (due to the implicit file locking on windows).

Can you reproduce the error reliably?

Thomas


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re:

[Thomas Braun]

Am 08.04.2015 um 22:44 schrieb Mamta Upadhyay:
 Hi git team,

(CC'ing msysgit as this is the git for windows list)

Hi Mamta,

 I tried to research everywhere on a issue I am facing and emailing you
 as the last resource. This is critical for me and I needed your help.
 
 I am trying to run the latest git 1.9.5 installer on windows. When I
 run strings on libneon-25.dll it shows this:
 
 ./libneon-25.dll:OpenSSL 1.0.1h 5 Jun 2014
 
 But when I load this dll in dependency walker, it picks up
 msys-openssl 1.0.1m and has no trace of openssl-1.0.1h. My questions
 to you:
 
 1. Is libneon-25.dll statically linked with openssl-1.0.1h?
 2. If not, where is the reference to 1.0.1h coming from?

I would be suprised if we link openssl statically into libneon. I guess
libneon just reports against which openssl version it was *built*.

 I am asked to rebuild git with libneon-25.dll linked against
 openssl-1.0.1m. But I am having a feeling that this is not needed,
 since libneon is already picking the latest openssl version. Can you
 please confirm?

You can download the development enviroment for git for windows here
[1]. After installation, checkout the msys branch and then you can try
to recomplile libneon using /src/subversion/release.sh.

[1]:
https://github.com/msysgit/msysgit/releases/download/Git-1.9.5-preview20150319/msysGit-netinstall-1.9.5-preview20150319.exe

Hope that helps
Thomas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] Git for Windows 1.9.5.msysgit.1

[Thomas Braun]

On Freitag, 20. März 2015 02:15:31 CEST, Mike Hommey wrote:

On Fri, Mar 20, 2015 at 12:03:43AM +0100, Thomas Braun wrote:


Hi,


the Git for Windows team just released the first maintenance release of
the Windows-specific installers for git 1.9.5.


is it expected that there is no corresponding release on
https://github.com/git-for-windows/git/releases ?


https://github.com/msysgit/git/releases/tag/v1.9.5.msysgit.1 is the 
corresponding source code release. Binaries are available from 
https://github.com/msysgit/msysgit/releases/tag/Git-1.9.5-preview20150319.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Git for Windows 1.9.5.msysgit.1

[Thomas Braun]

Hi,

the Git for Windows team just released the first maintenance release of
the Windows-specific installers for git 1.9.5.

It can be downloaded from the usual place [1] and I also attached some
(although non-gpg-signed) SHA sums [2].

New Features
- Comes with Git 1.9.5 plus Windows-specific patches.
- Make vimdiff usable with git mergetool.

Security Updates
- Mingw-openssl to 0.9.8zf and msys-openssl to 1.0.1m
- Bash to 3.1.23(6)
- Curl to 7.41.0

Bugfixes
- ssh-agent: only ask for password if not already loaded
- Reenable perl debugging (perl -de 1 possible again)
- Set icon background color for Windows 8 tiles
- poll: honor the timeout on Win32
- For git.exe alone, use the same HOME directory fallback mechanism as
/etc/profile

Have phun,
Thomas

[1]:
https://github.com/msysgit/msysgit/releases/download/Git-1.9.5-preview20150319/Git-1.9.5-preview20150319.exe
[2]:
SHA1(Git-1.9.5-preview20150319.exe)=
a8658bae0de8c8d3e40aa97a236a4fcf81de50df
SHA1(PortableGit-1.9.5-preview20150319.7z)=
44e7f249797af9a3833b88e17575bcbf22c282df
SHA1(msysGit-netinstall-1.9.5-preview20150319.exe)=
60b73db7959fb841b7d29286608e2333f429ca85
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] Re: Windows Bluescreen

[Thomas Braun]

Am 12.02.2015 um 14:21 schrieb Erik Friesen:
 Sorry, I don't know what this TOP posting problem is, and hitting
 reply only replies to the last sender.   If you prefer, and you have
 some regular bugtracker, I could use that instead of email posting.
 
 To repro-
 Set up git user on local linux repo, in my case 192.168.0.100
 
 On a windows 7 64bit machine-
 $ cd myproject
 $ git init
 $ git add .
 $ git commit -m 'initial commit'
 $ git remote add origin git@192.168.0.100:/opt/git/project.git
 $ git push origin master
 (Shamelessly copied from git page)
 
 Problem happens after entering password, it may or may not get started.
 
 The nature of a bluescreen doesn't make debugging and reproduction
 real easy.  If it helps, I can get the dumps from those crashes.  To
 move on, I moved back to local http pushes.

I'm doing pushes over ssh on a daily basis against my linux server.
And I'm using a Win7 64bit machine as well.

Can you try if it makes any difference if you use ssh login with public
keys instead of passwords?

You can also try to add LogLevel Debug to ~/.ssh/config in order to
get more verbose ssh output.


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] Win32: implement nanosecond-precision file times

[Thomas Braun]

Am 12.02.2015 um 00:53 schrieb Karsten Blees:
 We no longer use any of MSVCRT's stat-functions, so there's no need to
 stick to a CRT-compatible 'struct stat' either.
 
 Define and use our own POSIX-2013-compatible 'struct stat' with nanosecond-
 precision file times.
 
 Signed-off-by: Karsten Blees bl...@dcon.de
 ---
  compat/mingw.c   | 12 ++--
  compat/mingw.h   | 43 +++
  config.mak.uname |  4 ++--
  3 files changed, 39 insertions(+), 20 deletions(-)
 
 diff --git a/compat/mingw.c b/compat/mingw.c
 index 6d73a3d..e4d5e3f 100644
 --- a/compat/mingw.c
 +++ b/compat/mingw.c
 @@ -442,9 +442,9 @@ static int do_lstat(int follow, const char *file_name, 
 struct stat *buf)
   buf-st_size = fdata.nFileSizeLow |
   (((off_t)fdata.nFileSizeHigh)32);
   buf-st_dev = buf-st_rdev = 0; /* not used by Git */
 - buf-st_atime = filetime_to_time_t((fdata.ftLastAccessTime));
 - buf-st_mtime = filetime_to_time_t((fdata.ftLastWriteTime));
 - buf-st_ctime = filetime_to_time_t((fdata.ftCreationTime));
 + filetime_to_timespec((fdata.ftLastAccessTime), 
 (buf-st_atim));
 + filetime_to_timespec((fdata.ftLastWriteTime), (buf-st_mtim));
 + filetime_to_timespec((fdata.ftCreationTime), (buf-st_ctim));
   if (fdata.dwFileAttributes  FILE_ATTRIBUTE_REPARSE_POINT) {
   WIN32_FIND_DATAW findbuf;
   HANDLE handle = FindFirstFileW(wfilename, findbuf);
 @@ -550,9 +550,9 @@ int mingw_fstat(int fd, struct stat *buf)
   buf-st_mode = file_attr_to_st_mode(fdata.dwFileAttributes);
   buf-st_size = fdata.nFileSizeLow |
   (((off_t)fdata.nFileSizeHigh)32);
 - buf-st_atime = filetime_to_time_t((fdata.ftLastAccessTime));
 - buf-st_mtime = filetime_to_time_t((fdata.ftLastWriteTime));
 - buf-st_ctime = filetime_to_time_t((fdata.ftCreationTime));
 + filetime_to_timespec((fdata.ftLastAccessTime), 
 (buf-st_atim));
 + filetime_to_timespec((fdata.ftLastWriteTime), (buf-st_mtim));
 + filetime_to_timespec((fdata.ftCreationTime), (buf-st_ctim));
   return 0;
  
   case FILE_TYPE_CHAR:
 diff --git a/compat/mingw.h b/compat/mingw.h
 index f2a78b4..8dee9c9 100644
 --- a/compat/mingw.h
 +++ b/compat/mingw.h
 @@ -293,22 +293,48 @@ static inline long long filetime_to_hnsec(const 
 FILETIME *ft)
   return winTime - 1164447360LL;
  }
  
 -static inline time_t filetime_to_time_t(const FILETIME *ft)
 +struct timespec {
 + time_t tv_sec;
 + long tv_nsec;
 +};
 +
 +static inline void filetime_to_timespec(const FILETIME *ft, struct timespec 
 *ts)
  {
 - return (time_t)(filetime_to_hnsec(ft) / 1000);
 + long long hnsec = filetime_to_hnsec(ft);
 + ts-tv_sec = (time_t)(hnsec / 1000);
 + ts-tv_nsec = (hnsec % 1000) * 100;
  }
  
  /*
 - * Use mingw specific stat()/lstat()/fstat() implementations on Windows.
 + * Use mingw specific stat()/lstat()/fstat() implementations on Windows,
 + * including our own struct stat with 64 bit st_size and nanosecond-precision
 + * file times.
   */
  #define off_t off64_t
  #define lseek _lseeki64
  
 -/* use struct stat with 64 bit st_size */
 +struct mingw_stat {
 +_dev_t st_dev;
 +_ino_t st_ino;
 +_mode_t st_mode;
 +short st_nlink;
 +short st_uid;
 +short st_gid;
 +_dev_t st_rdev;
 +off64_t st_size;
 +struct timespec st_atim;
 +struct timespec st_mtim;
 +struct timespec st_ctim;
 +};
 +
 +#define st_atime st_atim.tv_sec
 +#define st_mtime st_mtim.tv_sec
 +#define st_ctime st_ctim.tv_sec
 +
  #ifdef stat
  #undef stat
  #endif
 -#define stat _stati64
 +#define stat mingw_stat
  int mingw_lstat(const char *file_name, struct stat *buf);
  int mingw_stat(const char *file_name, struct stat *buf);
  int mingw_fstat(int fd, struct stat *buf);
 @@ -321,13 +347,6 @@ int mingw_fstat(int fd, struct stat *buf);
  #endif
  #define lstat mingw_lstat
  
 -#ifndef _stati64
 -# define _stati64(x,y) mingw_stat(x,y)
 -#elif defined (_USE_32BIT_TIME_T)
 -# define _stat32i64(x,y) mingw_stat(x,y)
 -#else
 -# define _stat64(x,y) mingw_stat(x,y)
 -#endif
  
  int mingw_utime(const char *file_name, const struct utimbuf *times);
  #define utime mingw_utime
 diff --git a/config.mak.uname b/config.mak.uname
 index b64b63c..a18a4cc 100644
 --- a/config.mak.uname
 +++ b/config.mak.uname
 @@ -346,7 +346,7 @@ ifeq ($(uname_S),Windows)
   NO_SVN_TESTS = YesPlease
   RUNTIME_PREFIX = YesPlease
   NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
 - NO_NSEC = YesPlease
 + USE_NSEC = YesPlease
   USE_WIN32_MMAP = YesPlease
   # USE_NED_ALLOCATOR = YesPlease
   UNRELIABLE_FSTAT = UnfortunatelyYes
 @@ -498,7 +498,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
   NO_PERL_MAKEMAKER = YesPlease
   RUNTIME_PREFIX = 

Re: [msysGit] Re: Windows Bluescreen

[Thomas Braun]

Am Donnerstag, den 12.02.2015, 07:21 -0500 schrieb Erik Friesen:
 I'd say this is related.  http://sourceforge.net/p/mingw/bugs/2240/
 
 There isn't much hope, that was filed months ago with no action.  I
 suggest moving to another ssh library perhaps?  Anyways, this is a
 windows git bug report, so it really needs to stay with mysgit in my
 opinion.
 
 I'd say it should reproduce without much effort.  Do a git push using
 win7 64 pro or similar, I'd say it will have issues.
 
 At minimum, this should be on the list for others to view.  I have run
 across problems from others, but I don't think they realized it could
 be an ssh problem.

(Please don't TOP post)

The cited bug report does not correlate to msysgit as we compile and
ship our own openssh.

Git for Windows Version 1.8.x might still have the old and slow openssh.
With the newest version I get speeds of up to 30MB/s over Gigabit LAN.

Can you create a minimal test case to reprocude the problem?

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git describe oddity with GIT_DIR

[Thomas Braun]

Hi,

I've encountered an oddity with git describe.
Consider the following snippet:
-
mkdir test
cd test
git init
echo 1  file
git add file
git commit -m changes
$ git describe --always --dirty
8ad486e
$ cd ..
$ git --git-dir=test/.git describe --always --dirty
8ad486e-dirty
$ GIT_DIR=test/.git git describe --always --dirty
8ad486e-dirty
-

The -dirty suffix appears if invoking git not from the worktree
itself, but should actually never appear.

According to my research this behaviour is there since 9f67d2e8 (Teach
git describe --dirty option, 2009-10-27).

Is that to expected?

Thanks
Thomas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git describe oddity with GIT_DIR

[Thomas Braun]

Am 16.10.2014 um 18:57 schrieb Junio C Hamano:
 Thomas Braun thomas.br...@virtuell-zuhause.de writes:
 
 I've encountered an oddity with git describe.
 Consider the following snippet:
 -
 mkdir test
 cd test
 git init
 echo 1  file
 git add file
 git commit -m changes
 $ git describe --always --dirty
 8ad486e
 $ cd ..
 $ git --git-dir=test/.git describe --always --dirty
 8ad486e-dirty
 $ GIT_DIR=test/.git git describe --always --dirty
 8ad486e-dirty
 -

 The -dirty suffix appears if invoking git not from the worktree
 itself, but should actually never appear.
 
 This is not oddity with describe.  You are using --git-dir incorrectly.
 
 When you tell Git where its repository resides with the $GIT_DIR
 environment variable or the --git-dir command-line option, unless
 you tell it where the top-level of your working tree is, you are
 telling that your current working directory is the top-level of your
 working tree.
 
 You are asking git describe to describe the state of the HEAD
 including the dirtyness of the working tree in various ways.  With
 the first invocation, you do not tell Git where things are and let
 it correctly figure it out, i.e. you are in 'test' directory and
 relative to where you are, .git is the repository and . is the
 top of the working tree.  The commit recorded in the .git/HEAD,
 i.e. 8ad486e, is used, and its compared with the working tree to
 determine dirtiness.  Specifically, the blob object 8ad486e:file is
 the same as ./file (that is test/file relative to where you
 started with mkdir test above).
 
 With the latter two, you are asking the same question but you go one
 level up and then tell Git that the repository is test/.git
 (correct) and the top of the working tree is . (a lie).  Again,
 test/.git/HEAD records the same commit, but when trying to compare
 the contents of its tree, e.g. file at the top-level in the
 commit, you do not have file in the working tree.  Git is led to
 believe that you removed file, hence your working tree state is
 dirty.
 
 Make it a habit to always specify GIT_WORK_TREE when you use
 GIT_DIR, unless you know you will always start from the top of the
 working tree.

Thanks a lot Junio for the in-depth explanation.
I'll promise to do more research next time :)

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] core.filemode may need manual action

[Thomas Braun]

Am 16.10.2014 um 21:29 schrieb Torsten Bögershausen:
 core.filemode is set automatically when a repo is created.
 But when a repo is exported via CIFS or cygwin is mixed with Git for Windows
 core.filemode may better be set manually to false.
 Update and improve the documentation.
 
 Helped-by: Junio C Hamano gits...@pobox.com
 Signed-off-by: Torsten Bögershausen tbo...@web.de
 ---
 
 Does this reflect the discussion via email ?
 Or is more tweaking needed ?
 
 
  Documentation/config.txt | 19 +--
  1 file changed, 17 insertions(+), 2 deletions(-)
 
 diff --git a/Documentation/config.txt b/Documentation/config.txt
 index 4333636..b4fea43 100644
 --- a/Documentation/config.txt
 +++ b/Documentation/config.txt
 @@ -204,8 +204,23 @@ advice.*::
  --
  
  core.fileMode::
 - If false, the executable bit differences between the index and
 - the working tree are ignored; useful on broken filesystems like FAT.
 + Tells Git if the executable bit of files in the working tree
 + is to be honored.
 +
 + Some filesystems lose the executable bit when a file that is
 + marked as executable is checked out, or checks out an
 + non-executable file with executable bit on.  git init and
 + git clone probe the filesystem to see if it records
 + executable bit correctly when they create a new repository
 + and this variable is automatically set as necessary.
 +
 + A repository, however, may be on a filesystem that records
 + the filemode correctly, and this variable is set to 'true'
 + when created, but later may be made accessible from another
 + environment that loses the filemode (e.g. exporting ext4 via
 + CIFS mount, visiting a Cygwin managed repository with
 + MsysGit).  In such a case, it may be necessary to set this
 + variable to 'false'.
   See linkgit:git-update-index[1].
  +
  The default is true, except linkgit:git-clone[1] or linkgit:git-init[1]
 

[CC'ing msysgit aka git-for-windows/sdk for input]

I'm not really happy with the term MsysGit here.
Would it be too bold to say
[... ] visiting a Cygwin managed repository with Git for Windows.
?

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] Allow building Git with Asciidoctor

[Thomas Braun]

Am 14.10.2014 um 11:51 schrieb Jeff King:
 What's the status on AsciiDoc versus AsciiDoctor? The latter seems more
 actively developed these days, but perhaps that is just my perception.
 The incompatibilities seem fairly minimal (if those first two patches
 are the extent of it, I have no problem at all trying to remain
 compatible with both). Would it ever make sense to switch to AsciiDoctor
 as our official command-line build program? I know it is supposed to be
 much faster (though a lot of the slowness in our build chain is due to
 docbook, not asciidoc itself).

Just recently we added the AsciiDoc toolchain to our git-for-windows/sdk
(formerly known as msysgit). So I'm not really fond of switching now to
something different again.

Remaining compatible with both would therefore be my choice.

Thomas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Custom hunk-header with ignore case setting

[Thomas Braun]

Hi,

I'm working with a proprietary programming language which ignores case.
I now started to write a custom version of
diff.*.xfuncname and it is kind of ugly to always spell out all cases like
[Ff][Uu][Nn][cC][Tt][Ii][oO][Nn].

I've seen that the builtin diff patterns in userdiff.c can be specified 
ignoring case using the IPATTERN macro.

One of the possible solutions would be to patch userdiff.c
(patch courtesy of Johannes Schindelin):

-- snip --
diff --git a/userdiff.c b/userdiff.c
index fad52d6..f089e50 100644
--- a/userdiff.c
+++ b/userdiff.c
@@ -228,6 +228,9 @@ int userdiff_config(const char *k, const char *v)
return parse_funcname(drv-funcname, k, v, 0);
if (!strcmp(type, xfuncname))
return parse_funcname(drv-funcname, k, v, REG_EXTENDED);
+   if (!strcmp(type, ixfuncname))
+   return parse_funcname(drv-funcname, k, v,
+   REG_EXTENDED | REG_ICASE);
if (!strcmp(type, binary))
return parse_tristate(drv-binary, k, v);
if (!strcmp(type, command))
-- snap -

With a patch like that I would, of course, supply documentation and tests.

Is that something worth a try from my side?

An alternative solution would be to add something like pxfuncname which
understands PCREs which we we already support in git grep.

And yet another alternative would be that I send a patch enhancing userdiff.c
with a reasonable pattern for the programming language. But its community,
and especially intersected with git users, is not that large.

Thanks,
Thomas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: msysgit works on wine

[Thomas Braun]

Am 10.10.2014 um 13:58 schrieb Duy Nguyen:
 Just wanted to share that with at least wine 1.7.23 I can install
 msysgit using the netboot method, clone and build git ok. I had to do
 this to make gcc works actually, but it's probably no big deal
 
 $ mkdir -p ~/.wine/drive_c/usr/libexec/gcc/mingw32 -p
 $ cp ~/.wine/drive_c/msysgit/mingw/bin/as.exe
 ~/.wine/drive_c/usr/libexec/gcc/mingw32/
 $ cp ~/.wine/drive_c/msysgit/mingw/bin/ld.exe
 ~/.wine/drive_c/usr/libexec/gcc/mingw32/
 
 This may open a door for many people like me, who are interested in
 Windows support, but don't own a Windows license (and probably don't
 want to dual boot anyway). Of course tricky stuff would require real
 Windows, but this would help with most standard windows stuff.

Are you compiling git.git or msysgit.git?
And how about the test suite?

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] MinGW(-W64) compilation

[Thomas Braun]

Am 08.10.2014 um 06:53 schrieb Marat Radchenko:
 On Wed, Oct 08, 2014 at 01:09:20AM +0200, Thomas Braun wrote:
 Am 30.09.2014 um 09:02 schrieb Marat Radchenko:
 This patch series fixes building on modern MinGW and MinGW-W64 (including 
 x86_64!).

 *Compilation* tested on:
  - MSVC
  - msysGit environment (twice)

 Hi Marat,

 I wanted to verify that on msysgit but some patches fail to apply
 cleanly. Did you also had to tweak the patches?
 If yes, are these tweaked patches still available somewhere?
 
 msysgit != git-for-windows, as msysgit folks say. msysgit is a development
 environment for git-for-windows.

I surely know that!

 I tested my patches by applying them to git.git/master and building
 inside msysgit.

Fine, but then please explicitly state that. Compiling git.git/master
in msysgit and msysgit.git/master in msysgit are two different things.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] MinGW(-W64) compilation

[Thomas Braun]

Am 30.09.2014 um 09:02 schrieb Marat Radchenko:
 This patch series fixes building on modern MinGW and MinGW-W64 (including 
 x86_64!).
 
 *Compilation* tested on:
  - MSVC
  - msysGit environment (twice)

Hi Marat,

I wanted to verify that on msysgit but some patches fail to apply
cleanly. Did you also had to tweak the patches?
If yes, are these tweaked patches still available somewhere?

Thomas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Failing tests in t0027-autocrlf.sh under msysgit/git-win-sdk

[Thomas Braun]

Hi,

I've enabled EXPENSIVE and ran the git test suite under msysgit/git-win-sdk with
git version 2.1.0.9753.g360f311.dirty.

Now I have some failing tests in t0027-autocrlf.sh in the MINGW only section 
which puzzle me.

The offending test sets are

diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
index 72dd3e8..90c4cd1 100755
--- a/t/t0027-auto-crlf.sh
+++ b/t/t0027-auto-crlf.sh
@@ -245,18 +245,18 @@ if test_have_prereq MINGW
 then
 check_files_in_ws   false LFCRLF  CRLF_mix_LF  LF_mix_CR   
 CRLF_nul
 check_files_in_ws   true  CRLF  CRLF  CRLF_mix_LF  LF_mix_CR   
 CRLF_nul
-check_files_in_ws   false autoLFCRLF  CRLF_mix_LF  LF_mix_CR   
 CRLF_nul
+# check_files_in_ws   false autoLFCRLF  CRLF_mix_LF  LF_mix_CR 
   CRLF_nul # first broken
 check_files_in_ws   true  autoCRLF  CRLF  CRLF LF_mix_CR   
 CRLF_nul
-check_files_in_ws   false textLFCRLF  CRLF_mix_LF  LF_mix_CR   
 CRLF_nul
+# check_files_in_ws   false textLFCRLF  CRLF_mix_LF  LF_mix_CR 
   CRLF_nul # broken
 check_files_in_ws   true  textCRLF  CRLF  CRLF CRLF_mix_CR 
 CRLF_nul
 check_files_in_ws   false -text   LFCRLF  CRLF_mix_LF  LF_mix_CR   
 CRLF_nul
 check_files_in_ws   true  -text   LFCRLF  CRLF_mix_LF  LF_mix_CR   
 CRLF_nul
 
 check_files_in_ws native  false LFCRLF  CRLF_mix_LF  LF_mix_CR   
 CRLF_nul
 check_files_in_ws native  true  CRLF  CRLF  CRLF_mix_LF  LF_mix_CR   
 CRLF_nul
-check_files_in_ws native  false autoLFCRLF  CRLF_mix_LF  LF_mix_CR   
 CRLF_nul
+# check_files_in_ws native  false autoLFCRLF  CRLF_mix_LF  LF_mix_CR 
   CRLF_nul # broken
 check_files_in_ws native  true  autoCRLF  CRLF  CRLF LF_mix_CR   
 CRLF_nul
-check_files_in_ws native  false textLFCRLF  CRLF_mix_LF  LF_mix_CR   
 CRLF_nul
+# check_files_in_ws native  false textLFCRLF  CRLF_mix_LF  LF_mix_CR 
   CRLF_nul # broken
 check_files_in_ws native  true  textCRLF  CRLF  CRLF CRLF_mix_CR 
 CRLF_nul
 check_files_in_ws native  false -text   LFCRLF  CRLF_mix_LF  LF_mix_CR   
 CRLF_nul
 check_files_in_ws native  true  -text   LFCRLF  CRLF_mix_LF  LF_mix_CR   
 CRLF_nul

I tried with NATIVE_CRLF = YesPlease but 117 failed too.

First question, under what MINGW system do these tests pass?
Second question any hints how to tackle this?

The first failing test is
not ok 117 - checkout core.eol= core.autocrlf=false gitattributes=auto file=LF
#
#   compare_ws_file eol__crlf_false_attr_auto_ LF
crlf_false_attr__LF.txt
#


where I have in the trash directory

$ diff -Nur *expect* *actual*
--- LF.expect   2014-10-02 12:15:17 +
+++ eol__crlf_false_attr_auto_.actual.crlf_false_attr__LF.txt   2014-10-02 12:15
:17 +
@@ -1,3 +1,3 @@
-000   l   i   n   e   1  \n   l   i   n   e   2  \n   l   i   n   e
-020   3
-021
+000   l   i   n   e   1  \r  \n   l   i   n   e   2  \r  \n   l   i
+020   n   e   3
+023

Reading convert.h tells me that for undefined NATIVE_CRLF the native EOL is LF.
Which looks like the test is correct.

Thomas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Failing tests in t0027-autocrlf.sh under msysgit/git-win-sdk

[Thomas Braun]

Am 02.10.2014 um 15:42 schrieb Torsten Bögershausen:
 On 2014-10-02 14.39, Thomas Braun wrote:
 Hi,

 I've enabled EXPENSIVE and ran the git test suite under msysgit/git-win-sdk 
 with
 git version 2.1.0.9753.g360f311.dirty.

 Now I have some failing tests in t0027-autocrlf.sh in the MINGW only section 
 which puzzle me.

 The offending test sets are

 diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
 index 72dd3e8..90c4cd1 100755
 --- a/t/t0027-auto-crlf.sh
 +++ b/t/t0027-auto-crlf.sh
 @@ -245,18 +245,18 @@ if test_have_prereq MINGW
  then
  check_files_in_ws   false LFCRLF  CRLF_mix_LF  
 LF_mix_CRCRLF_nul
  check_files_in_ws   true  CRLF  CRLF  CRLF_mix_LF  
 LF_mix_CRCRLF_nul
 -check_files_in_ws   false autoLFCRLF  CRLF_mix_LF  
 LF_mix_CRCRLF_nul
 +# check_files_in_ws   false autoLFCRLF  CRLF_mix_LF  
 LF_mix_CRCRLF_nul # first broken
 
  check_files_in_ws   true  autoCRLF  CRLF  CRLF 
 LF_mix_CRCRLF_nul
 -check_files_in_ws   false textLFCRLF  CRLF_mix_LF  
 LF_mix_CRCRLF_nul
 +# check_files_in_ws   false textLFCRLF  CRLF_mix_LF  
 LF_mix_CRCRLF_nul # broken
  check_files_in_ws   true  textCRLF  CRLF  CRLF 
 CRLF_mix_CR  CRLF_nul
  check_files_in_ws   false -text   LFCRLF  CRLF_mix_LF  
 LF_mix_CRCRLF_nul
  check_files_in_ws   true  -text   LFCRLF  CRLF_mix_LF  
 LF_mix_CRCRLF_nul
  
  check_files_in_ws native  false LFCRLF  CRLF_mix_LF  
 LF_mix_CRCRLF_nul
  check_files_in_ws native  true  CRLF  CRLF  CRLF_mix_LF  
 LF_mix_CRCRLF_nul
 -check_files_in_ws native  false autoLFCRLF  CRLF_mix_LF  
 LF_mix_CRCRLF_nul
 +# check_files_in_ws native  false autoLFCRLF  CRLF_mix_LF  
 LF_mix_CRCRLF_nul # broken
  check_files_in_ws native  true  autoCRLF  CRLF  CRLF 
 LF_mix_CRCRLF_nul
 -check_files_in_ws native  false textLFCRLF  CRLF_mix_LF  
 LF_mix_CRCRLF_nul
 +# check_files_in_ws native  false textLFCRLF  CRLF_mix_LF  
 LF_mix_CRCRLF_nul # broken
  check_files_in_ws native  true  textCRLF  CRLF  CRLF 
 CRLF_mix_CR  CRLF_nul
  check_files_in_ws native  false -text   LFCRLF  CRLF_mix_LF  
 LF_mix_CRCRLF_nul
  check_files_in_ws native  true  -text   LFCRLF  CRLF_mix_LF  
 LF_mix_CRCRLF_nul

 I tried with NATIVE_CRLF = YesPlease but 117 failed too.

 First question, under what MINGW system do these tests pass?
 Second question any hints how to tackle this?
 

 The first failing test is
 not ok 117 - checkout core.eol= core.autocrlf=false gitattributes=auto 
 file=LF
 #
 #   compare_ws_file eol__crlf_false_attr_auto_ LF
 crlf_false_attr__LF.txt
 #


 where I have in the trash directory

 $ diff -Nur *expect* *actual*
 --- LF.expect   2014-10-02 12:15:17 +
 +++ eol__crlf_false_attr_auto_.actual.crlf_false_attr__LF.txt   2014-10-02 
 12:15
 
 First things first:
 We have a file with LF in the repo, and check it out.
 
 Read it like this:
 eol__crlf_false_attr_auto_.actual
  ^ *.txt auto in .gitconfig   
   ^
   core.autocrlf is false 
   ^
   core.eol is unset

Thanks for the explanation.

 The file is expected to have LF in the working tree, but has CRLF
 
 :17 +
 @@ -1,3 +1,3 @@
 -000   l   i   n   e   1  \n   l   i   n   e   2  \n   l   i   n   e
 -020   3
 -021
 +000   l   i   n   e   1  \r  \n   l   i   n   e   2  \r  \n   l   i
 +020   n   e   3
 +023

 Reading convert.h tells me that for undefined NATIVE_CRLF the native EOL is 
 LF.
 Which looks like the test is correct.

 Thomas

 Which version of t0027 do you have:
 The latest version in git.git is this one,
 and should pass (but I may have missed something)
 
 commit f6975a6b119128de1c5a89e6cd64f75ed1de2177
 Author: Torsten Bögershausen tbo...@web.de
 Date:   Sat Aug 16 22:16:58 2014 +0200
 
 t0027: Tests for core.eol=native, eol=lf, eol=crlf
 
 Add test cases for core.eol native and  (unset).
 (MINGW uses CRLF, all other systems LF as native line endings)
 
 Add test cases for the attributes eol=lf and eol=crlf
 
 Other minor changes:
 - Use the more portable 'tr' instead of 'od -c' to convert '\n' into 'Q'
   and '\0' into 'N'
 - Style fixes for shell functions according to the coding guide lines
 - Replace txtbin with attr
 
 Signed-off-by: Torsten Bögershausen tbo...@web.de
 Signed-off-by: Junio C Hamano gits...@pobox.com

Correct guess! I've been testing the original version 343151dc (t0027:
combinations of core.autocrlf, core.eol and text, 2014-07-08).
f6975a6 of t0027-autocrlf.sh passes now completely.

Thanks for the quick reply.

Thomas

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Git for Windows 1.9.4.msysgit.2

[Thomas Braun]

Hi,

the Git for Windows team just released the third maintenance release of
the Windows-specific installers for git 1.9.4.

It can be downloaded from the usual place [1] and I also attached some
unsigned SHA sums [2].

New Features
- Comes with Git 1.9.4 plus Windows-specific patches.

Bugfixes
- Update bash to patchlevel 3.1.20(4) (msysgit PR#254, msysgit issue #253).
  Fixes CVE-2014-6271, CVE-2014-7169, CVE-2014-7186 and CVE-2014-7187.
- gitk.cmd now works when paths contain the ampersand () symbol (msysgit PR 
#252)
- Default to automatically close and restart applications in silent mode 
installation type
- Git svn is now usable again (regression in previous update, msysgit PR#245)

Have phun,
Thomas

[1]: 
https://github.com/msysgit/msysgit/releases/download/Git-1.9.4-preview20140929/Git-1.9.4-preview20140929.exe
[2]: SHA1(Git-1.9.4-preview20140929.exe)= 
a7a50a18992a56de193e048b0205bf21b6721554
 SHA1(PortableGit-1.9.4-preview20140929.7z)= 
4b0698f2bf96b0dd64ecec477b3db9e3b3d46085
 SHA1(msysGit-netinstall-1.9.4-preview20140929.exe)= 
73ad668013941863e80e74bcf853d53eeed69714
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Passing tar(1) options via git-archive(1)

[Thomas Braun]

Am 23.09.2014 um 20:57 schrieb Daniel Brockman:
 Some background from the git-archive(1) man page:
 
 git-archive behaves differently when given a tree ID versus when
 given a commit ID or tag ID.  In the first case the current time is
 used as the modification time of each file in the archive.  In the
 latter case the commit time as recorded in the referenced commit
 object is used instead.
 
 Would it make sense to add an --mtime option to git-archive(1) to enable
 explicitly setting the mtime for all files in the archive?  It could
 just pass through to the tar(1) --mtime option.
 
 My use case is `git archive HEAD | docker build -`, in which the Docker
 cache is prevented from working because the mtime keeps getting bumped
 on all files.  I would like to have the mtime always be the same.
 
 See, e.g., https://github.com/deis/deis/issues/1334.
 
 Otherwise, how about a generic way to pass options to tar(1)?

Actually I wanted to just hint to TAR_OPTIONS
as in
TAR_OPTIONS=--mtime 2014-09-23\ 00:00 git archive -o ausg.tar HEAD
but that does not work here (on windows).

The questions is should it be supported?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] t9300: use cmp instead of test_cmp to compare binary files

[Thomas Braun]

Am 12.09.2014 um 19:58 schrieb Junio C Hamano:
 Johannes Sixt j...@kdbg.org writes:
 
 test_cmp is intended to produce diff output for human consumption. The
 input in one instance in t9300-fast-import.sh are binary files, however.
 Use cmp to compare the files.
 
 Thanks.
 

 This was noticed because on Windows we have a special implementation of
 test_cmp in pure bash code (to ignore differences due to intermittent CR
 in actual output), and bash runs into an infinite loop due to the binary
 nature of the input.

 Signed-off-by: Johannes Sixt j...@kdbg.org
 ---
  t/t9300-fast-import.sh | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
 index 99f5161..4b13170 100755
 --- a/t/t9300-fast-import.sh
 +++ b/t/t9300-fast-import.sh
 @@ -2687,7 +2687,7 @@ test_expect_success 'R: verify created pack' '
  test_expect_success \
  'R: verify written objects' \
  'git --git-dir=R/.git cat-file blob big-file:big1 actual 
 - test_cmp expect actual 
 + cmp expect actual 
   a=$(git --git-dir=R/.git rev-parse big-file:big1) 
   b=$(git --git-dir=R/.git rev-parse big-file:big2) 
   test $a = $b'

May I suggest to use test_cmp_bin instead of plain cmp?
test_cmp_bin was introduced in
b93e6e36 (t5000, t5003: do not use test_cmp to compare binary files,
2014-06-04) and by default is plain cmp.


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BUG I can't start git on Windows 7

[Thomas Braun]

Am 08.09.2014 um 11:15 schrieb Petr Bena:
 I installed git on my system using official package from git-scm.com
 but I can't launch it, I am always getting this error:
 
 C:\Users\petr.benaC:\Program Files (x86)\Git\bin\sh.exe --login -i
   0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
 AllocationBase 0x0, BaseAddress 0x6857, RegionSize 0x4, State 0x1
 C:\Program Files (x86)\Git\bin\sh.exe: *** Couldn't reserve space for
 cygwin's heap, Win32 error 0
 
 
 At some point this could be an issue with cygwin, but I am not sure.
 Did anyone had similar issue?

[CC'ing msysgit]

Do you have cygwin installed, or why do you mention cygwin?
What windows are you running?


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BUG I can't start git on Windows 7

[Thomas Braun]

Am 08.09.2014 um 17:34 schrieb Konstantin Khomoutov:
 I wonder, why the error message mentions Cygwin though.

This is a leftover. Msys was forked from cygwin some time ago.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html