git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [git-for-windows] Git for Windows v2.15.0-rc prerelease, was Re: [ANNOUNCE] Git v2.15.0-rc2

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Oct 28, 2017, 16:40 UTC
Message-ID
<alpine.DEB.2.21.1.1710281838230.6482@virtualbox>
In-Reply-To
<DC84FB2E-A26E-4957-B5FA-BE6DDEC3411B@gmail.com>
Hi Lars,
On Fri, 27 Oct 2017, Lars Schneider wrote:
Show 43 quoted lines
> > On 27 Oct 2017, at 14:11, Lars Schneider <larsxschneider@gmail.com> wrote:
> > 
> >> On 21 Oct 2017, at 00:22, Johannes Schindelin <johannes.schindelin@gmx.de> wrote:
> >> 
> >> [cutting linux-kernel]
> >> 
> >> On Fri, 20 Oct 2017, Junio C Hamano wrote:
> >> 
> >>> A release candidate Git v2.15.0-rc2 is now available for testing
> >>> at the usual places.
> >> 
> >> The Git for Windows equivalent is now available from
> >> 
> >>   https://github.com/git-for-windows/git/releases/tag/v2.15.0-rc2.windows.1
> > 
> > I just tested RC2 on Windows and I don't see my "Filtering content:"
> > output if I clone a Git repository with Git LFS files (and Git LFS
> > 2.3.3+ installed).
> > 
> > The feature was introduced in the following commit which is be part of
> > your RC2 build commit (b7f8941):
> > https://github.com/git/git/commit/52f1d62eb44faf569edca360ec9af9ddd4045fe0
> > 
> > On macOS everything works as expcted with RC2:
> >    ...
> >    remote: Total 15012 (delta 0), reused 0 (delta 0), pack-reused 15012
> >    Receiving objects: 100% (15012/15012), 2.02 MiB | 753.00 KiB/s, done.
> >    Filtering content:  43% (6468/15000), 33.30 KiB | 0 bytes/s
> >    ...
> > 
> > Do you, or other Windows experts, spot something in the commit linked
> > above that could cause trouble on Windows?
> 
> Well, it turns out the output works for my real life repos but not for
> my Git LFS testing repo.
> 
>     git clone https://github.com/larsxschneider/lfstest-manyfiles
> 
> ... prints the filtering content output on macOS but not on Windows.
> The progress function has some delay feature that suppresses the output
> if it is only shown for a second or something. However, in this test case
> the output should be visible for several seconds at least...
> I am still puzzled.
Nothing really strikes me as obvious.

Do you do this in Git Bash? If so, maybe you can also test in Git CMD? I do remember having issues with stderr only showing up in time if it was fflush()ed explicitly, but only in Git Bash (i.e. a MinTTY problem).

Ciao, Dscho

Previous: Lars SchneiderNext: Lars Schneider
Message 8 of 9 in “[ANNOUNCE] Git v2.15.0-rc2”
  1. Junio C HamanoOct 20, 2017
  2. Git for Windows v2.15.0-rc prerelease, was Re: [ANNOUNCE] Git v2.15.0-rc2Johannes Schindelin, Oct 20, 2017
  3. Bryan TurnerOct 20, 2017
  4. Junio C HamanoOct 21, 2017
  5. Johannes SchindelinOct 23, 2017
  6. Lars SchneiderOct 27, 2017
  7. Lars SchneiderOct 27, 2017
  8. Johannes SchindelinOct 28, 2017
  9. Lars SchneiderOct 28, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.