[ANNOUNCE] Git for Windows 2.9.3

[ANNOUNCE] Git for Windows 2.9.3

[Johannes Schindelin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=X-UNKNOWN, Size: 1724 bytes --]

Dear Git users,

It is my pleasure to announce that Git for Windows 2.9.3 is available from:

	https://git-for-windows.github.io/

Changes since Git for Windows v2.9.2 (July 16th 2016)

New Features

  • Comes with Git 2.9.3.
  • Updated Git Credential Manager to version 1.6.0.
  • Includes support for git status --porcelain=v2.
  • Avoids evaluating unnecessary patch IDs when determining which
    commits do not need to be rebased because they are already
    upstream.
  • Sports a new --smudge option for git cat-file that lets it pass
    blob contents through smudge filters configured for the specified
    path.

Bug Fixes

  • When offering to Launch Git Bash after the installation, it now
    launches in the home directory, consistent with the Git Bash Start
    Menu entry.
  • When ~/.gitconfig sets core.hideDotFiles=false, git init respects
    that again.

Filename | SHA-256
-------- | -------
Git-2.9.3-64-bit.exe | 1a642cf2914e18fa868b1ed2c6d1df4a46ba8ef30355fd1965850895a658e024
Git-2.9.3-32-bit.exe | d6b4a19536ad408018688f1242ab0d1f5dc5544109662bfddf915f685eba58a9
PortableGit-2.9.3-64-bit.7z.exe | 3423ea5c7e025a67903e05d1493680d6d5d6666429a9c400cc9e33beea5adb1b
PortableGit-2.9.3-32-bit.7z.exe | cd142cbb124d7c3e3c3bf144785e57573afd2fc9c043447b7f5111ec044e6ced
MinGit-2.9.3-64-bit.zip | 17e40cb149ce6a348c8e8bbe7f1c1fff00f82882f0e57f32d60ea5c26feeef98
MinGit-2.9.3-32-bit.zip | 3c6515c09ccb7d1aa6620db51245c87f9836fbde5ee9af6c849b4cbd506f60e8
Git-2.9.3-64-bit.tar.bz2 | 7b165d400c2bcc427881d502dd46cd442e512053d92cba8b3e46173c5028e427
Git-2.9.3-32-bit.tar.bz2 | 00f265ddbbfedd25a8a0c38a33a6cb12761101a019f0c7f6189f07e771a522b7

Ciao,
Johannes

Re: [ANNOUNCE] Git for Windows 2.9.3

[Junio C Hamano]

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

> New Features
>
>   • Comes with Git 2.9.3.

For future reference, what time (in UTC) of the day is convenient
for you to see an upstream tarball?

>   • Sports a new --smudge option for git cat-file that lets it pass
>     blob contents through smudge filters configured for the specified
>     path.

Perhaps we want to upstream this, together with a new "--clean"
option for git hash-object?

And after writing all of the above, I noticed that hash-object by
default uses the clean machinery and that can be turned off by
giving the "--no-filters" option.  The reason why the option is not
called "--no-clean" is because it is not just about the clean filter
but is about using the entirety of convert_to_git() filter chain.

We probably should teach "hash-objects" to take "--filters" for
consistency.

And then your "git cat-file" patch can be upstreamed with the option
renamed to (or with an additional synonym) "--filters", which would
make things consistent.

Thanks.

Re: [ANNOUNCE] Git for Windows 2.9.3

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 2545 bytes --]

Hi Junio,

On Sat, 13 Aug 2016, Junio C Hamano wrote:

> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> 
> > New Features
> >
> >   • Comes with Git 2.9.3.
> 
> For future reference, what time (in UTC) of the day is convenient
> for you to see an upstream tarball?

Heh... I don't do tarballs anymore, I now use this newfangled tool to
manage source code... "gyt" or something like that, it is called.

:-)

Given that between you and me there is currently a time zone difference of
9h (except for four weeks, two in spring, when it is only 8h, and two in
fall, when it is 10h), I believe we cannot find a time that is convenient
for both of us.

But I also think it is fine, when I discover a new upstream Git version in
the morning, I can spend all day on fixing any problems and on packaging
the result ;-)

> >   • Sports a new --smudge option for git cat-file that lets it pass
> >   blob contents through smudge filters configured for the specified
> >   path.
> 
> Perhaps we want to upstream this, together with a new "--clean" option
> for git hash-object?

No question about that. I just needed this in a hurry and short-circuited
it into Git for Windows before submitting it upstream.

> And after writing all of the above, I noticed that hash-object by
> default uses the clean machinery and that can be turned off by giving
> the "--no-filters" option.  The reason why the option is not called
> "--no-clean" is because it is not just about the clean filter but is
> about using the entirety of convert_to_git() filter chain.

Right, as is the --smudge option (it is about the entirety of
convert_to_worktree()).

> We probably should teach "hash-objects" to take "--filters" for
> consistency.

I actually thought about that, too. Which was one of the reasons I did not
submit the patch to the Git mailing list first, as I expect several
iterations to be necessary to get everything into `master`.

> And then your "git cat-file" patch can be upstreamed with the option
> renamed to (or with an additional synonym) "--filters", which would make
> things consistent.

Right. I would like to ask for a `--smudge` synonym nevertheless, just
because I already use this. On the other hand, it is early enough to tell
everybody who knows about this feature to change their invocation (anybody
who would know about `--smudge` would be in that 1% of users that have
read the release notes, so most likely would read the next release notes,
too).

Ciao,
Dscho

Re: [ANNOUNCE] Git for Windows 2.9.3

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> And then your "git cat-file" patch can be upstreamed with the option
>> renamed to (or with an additional synonym) "--filters", which would make
>> things consistent.
>
> Right. I would like to ask for a `--smudge` synonym nevertheless, just
> because I already use this. On the other hand, it is early enough to tell
> everybody who knows about this feature to change their invocation (anybody
> who would know about `--smudge` would be in that 1% of users that have
> read the release notes, so most likely would read the next release notes,
> too).

It is OK if it were your private edition, but you end up hurting
your users if you need to redo the feature differently.

That's the price of your using open source and taking a short-cut.
Adding a "--smudge" synonym is spreading the same hurt to outside
your fork.  Let's see if we can avoid doing that.  Perhaps mark that
"--smudge" as experimental-and-subject-to-change and re-announce?

Re: [ANNOUNCE] Git for Windows 2.9.3

[Johannes Schindelin]

Hi Junio,

On Wed, 17 Aug 2016, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> And then your "git cat-file" patch can be upstreamed with the option
> >> renamed to (or with an additional synonym) "--filters", which would make
> >> things consistent.
> >
> > Right. I would like to ask for a `--smudge` synonym nevertheless, just
> > because I already use this. On the other hand, it is early enough to tell
> > everybody who knows about this feature to change their invocation (anybody
> > who would know about `--smudge` would be in that 1% of users that have
> > read the release notes, so most likely would read the next release notes,
> > too).
> 
> It is OK if it were your private edition, but you end up hurting
> your users if you need to redo the feature differently.

Unfortunately, this is the situation of Git for Windows from its
beginning: there has not been a single time that Git for Windows could
live with unpatched upstream Git's source code.

Business as usual, though.

> That's the price of your using open source and taking a short-cut.
> Adding a "--smudge" synonym is spreading the same hurt to outside
> your fork.  Let's see if we can avoid doing that.  Perhaps mark that
> "--smudge" as experimental-and-subject-to-change and re-announce?

I do not think so.

I have plenty of experience to deal with the problem caused by Git for
Windows requiring plenty of patches on top of your Git versions. I can
easily deal with this here problem, too.

FYI there have been two very strong reasons why I did not go through the
review on the Git mailing list for the --smudge option: 1) I really needed
this quick, and last time I needed something quick, it did not exactly
work out, now, did it, and 2) as far as I am concerned, the most important
part of developing patches is the practical testing, and this belief was
reinforced by the core.hideDotFiles feature that was well-tested and
well-exercised through years, only to be broken by changes necessitated by
the review on the Git mailing list: despite the best efforts of both you
and me, we managed to worsimprove the patches to a point where they may
look more elegant than before, but unfortunately are also less correct at
the same time.

So I learned my lesson: I will try better to get patches robust and stable
by exercising them and developing them as needed (the --smudge feature,
for example, turned out to be only half of what I need, I developed more
patches on that front), and I will be careful to avoid major modifications
of my patches just to get things upstream. It is better to carry correct
patches in Git for Windows than to upstream incorrect revisions of them.

Ideally, all of the patches I carry in Git for Windows would make it into
git.git eventually, of course. I fully support that. But not at the price
of breakages.

Ciao,
Dscho

Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Duy Nguyen]

On Thu, Aug 18, 2016 at 3:37 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi Junio,
>
> On Wed, 17 Aug 2016, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> >> And then your "git cat-file" patch can be upstreamed with the option
>> >> renamed to (or with an additional synonym) "--filters", which would make
>> >> things consistent.
>> >
>> > Right. I would like to ask for a `--smudge` synonym nevertheless, just
>> > because I already use this. On the other hand, it is early enough to tell
>> > everybody who knows about this feature to change their invocation (anybody
>> > who would know about `--smudge` would be in that 1% of users that have
>> > read the release notes, so most likely would read the next release notes,
>> > too).
>>
>> It is OK if it were your private edition, but you end up hurting
>> your users if you need to redo the feature differently.
>
> Unfortunately, this is the situation of Git for Windows from its
> beginning: there has not been a single time that Git for Windows could
> live with unpatched upstream Git's source code.
>
> Business as usual, though.

Bug fixes is one thing, features is completely different. Should we
just acknowledge git-for-windows as a long-living fork and rename it
to something else? Because if somebody comes here with a "git" problem
on Windows, I would look at git.git source code, not gfw. I'd rather
recognize it a special fork (by name) right away and ignore. You could
have the same policy distros have: all bugs go to distros (i.e. gfw),
some bugs may be forwarded upstream (git.git).
-- 
Duy

Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Johannes Schindelin]

Hi Duy,

On Mon, 22 Aug 2016, Duy Nguyen wrote:

> On Thu, Aug 18, 2016 at 3:37 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Hi Junio,
> >
> > On Wed, 17 Aug 2016, Junio C Hamano wrote:
> >
> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >>
> >> >> And then your "git cat-file" patch can be upstreamed with the option
> >> >> renamed to (or with an additional synonym) "--filters", which would make
> >> >> things consistent.
> >> >
> >> > Right. I would like to ask for a `--smudge` synonym nevertheless, just
> >> > because I already use this. On the other hand, it is early enough to tell
> >> > everybody who knows about this feature to change their invocation (anybody
> >> > who would know about `--smudge` would be in that 1% of users that have
> >> > read the release notes, so most likely would read the next release notes,
> >> > too).
> >>
> >> It is OK if it were your private edition, but you end up hurting
> >> your users if you need to redo the feature differently.
> >
> > Unfortunately, this is the situation of Git for Windows from its
> > beginning: there has not been a single time that Git for Windows could
> > live with unpatched upstream Git's source code.
> >
> > Business as usual, though.
> 
> Bug fixes is one thing, features is completely different.

Oh? Completely?

So the core.hideDotFiles feature should have forced me to rename Git for
Windows to, say, DschoGit on Windows?

Let's just stop here. This is getting too silly.

Ciao,
Dscho

Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Michael J Gruber]

Johannes Schindelin venit, vidit, dixit 23.08.2016 15:54:
> Hi Duy,
> 
> On Mon, 22 Aug 2016, Duy Nguyen wrote:
> 
>> On Thu, Aug 18, 2016 at 3:37 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>> Hi Junio,
>>>
>>> On Wed, 17 Aug 2016, Junio C Hamano wrote:
>>>
>>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>>
>>>>>> And then your "git cat-file" patch can be upstreamed with the option
>>>>>> renamed to (or with an additional synonym) "--filters", which would make
>>>>>> things consistent.
>>>>>
>>>>> Right. I would like to ask for a `--smudge` synonym nevertheless, just
>>>>> because I already use this. On the other hand, it is early enough to tell
>>>>> everybody who knows about this feature to change their invocation (anybody
>>>>> who would know about `--smudge` would be in that 1% of users that have
>>>>> read the release notes, so most likely would read the next release notes,
>>>>> too).
>>>>
>>>> It is OK if it were your private edition, but you end up hurting
>>>> your users if you need to redo the feature differently.
>>>
>>> Unfortunately, this is the situation of Git for Windows from its
>>> beginning: there has not been a single time that Git for Windows could
>>> live with unpatched upstream Git's source code.
>>>
>>> Business as usual, though.
>>
>> Bug fixes is one thing, features is completely different.
> 
> Oh? Completely?
> 
> So the core.hideDotFiles feature should have forced me to rename Git for
> Windows to, say, DschoGit on Windows?
> 
> Let's just stop here. This is getting too silly.

I see more truth than silliness in Duy's suggestion. Maybe you want to
re-read what you wrote to trigger his response, and consider adjusting
your attitude ("I want this now so I'll release it in Git4Win") rather
than the downstream name.

Michael

Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Johannes Schindelin]

Hi Michael,

On Tue, 23 Aug 2016, Michael J Gruber wrote:

> Maybe you want to re-read what you wrote to trigger his response, and
> consider adjusting your attitude ("I want this now so I'll release it in
> Git4Win") rather than the downstream name.

I am working *very* hard on improving the user experience of Git for
Windows. And yes, sometimes I have to include something in Git for Windows
versions that upstream Git does not include in the corresponding version
number.

I am really at a loss why you see fit to attack me about that.

Ciao,
Dscho

Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Johannes Schindelin]

Hi Michael,

On Tue, 23 Aug 2016, Johannes Schindelin wrote:

> On Tue, 23 Aug 2016, Michael J Gruber wrote:
> 
> > Maybe you want to re-read what you wrote to trigger his response, and
> > consider adjusting your attitude ("I want this now so I'll release it in
> > Git4Win") rather than the downstream name.
> 
> I am working *very* hard on improving the user experience of Git for
> Windows. And yes, sometimes I have to include something in Git for Windows
> versions that upstream Git does not include in the corresponding version
> number.
> 
> I am really at a loss why you see fit to attack me about that.

In case it is not crystal-clear, let me clarify one very important point.
It seems that some people mistake the work I do for something I do on a
whim. This is not so.

The patch series that triggered this entire unfortunate discussion
introduced the --smudge option, which I have subsequently renamed to
--filters and submitted as a patch series to the Git project.

So it is an altogether unfair misrepresentation to state that I introduce
features that deviate so much from upstream Git as to require a new name.

The feature in question is also highly unlikely to be used as much by
non-Windows users as by Windows users due to the unfortunate choice of the
default setting for core.autocrlf. Basically, Windows users have to use
those --filters all the time, and in many cases, git cat-file --batch
without --filters is simply useless. This is nothing, say, Linux users
would care about, of course, but Windows folks like me care a great deal
about it.

It is this need that literally guarantees that I will get more useful
feedback from Windows users about this feature (and in this context I mean
application developers) than from Linux or MacOSX users. And as a matter
of fact, I got exactly that: great feedback. This feedback resulted in the
addition of the --path option, and of the work I did on making --filters
compatible with the --batch mode.

So I take great exception at this criticism. I think these comments were
not really thought through, and I also would consider this discussion in
and of itself ("is Git for Windows really Git? Should it not be renamed,
despite Dscho's best efforts to get them in sync?") to be much more
harmful than any feature I introduced into Git for Windows before trying
to get it integrated into upstream Git.

Thank you very much for your attention,
Dscho

Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> In case it is not crystal-clear, let me clarify one very important point.
> It seems that some people mistake the work I do for something I do on a
> whim. This is not so.
>
> The patch series that triggered this entire unfortunate discussion
> introduced the --smudge option, which I have subsequently renamed to
> --filters and submitted as a patch series to the Git project.

As the "--filters" is meant as a new feature, it will not land on
the maintenance track.  It is very likely that it won't be in 2.10,
so it won't appear in 2.10.x maintenance track, either.

I do not agree with Duy that the "port to Windows" needs a separate
distinct name, though.  Having said that, aside from the issue of
handling of bugreports has been already meantioned, which mostly
costs for Git developers, whatever new feature you unleash ahead of
upstream to your Windows port has cost to your end-users.  Its
implementation or its external interface may have to change when you
upstream the new feature that has already been in the field, and
your end-users would have to adjust their scripts and/or muscle
memory.

One way to avoid that risk may be to release the new feature as
"experimental-and-subject-to-change", so that interested users on
Windows can actually try it out to see if the feature itself
(whatever its interface to them is) makes sense, and you can gauge
the value of upstreaming it, while cautioning these early adopters
that it has not fully been through the usual review process and may
have to change while becoming part of the official release.  This is
no different from various "experimental features" we unleash to the
wild, either via 'master' or keeping it in 'next' (we tend to do
more of the latter, marking "see if anybody screams").

Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> One way to avoid that risk may be to release the new feature as
> "experimental-and-subject-to-change", so that interested users on
> Windows can actually try it out to see if the feature itself
> (whatever its interface to them is) makes sense, and you can gauge
> the value of upstreaming it, while cautioning these early adopters
> that it has not fully been through the usual review process and may
> have to change while becoming part of the official release.  This is
> no different from various "experimental features" we unleash to the
> wild, either via 'master' or keeping it in 'next' (we tend to do
> more of the latter, marking "see if anybody screams").

In case it was not clear, I am _not_ saying that the port to Windows
must not ship with any feature that is not yet in the upstream (the
same goes for a port to Macs, where it may want to do more about
dealing with Unicode "normalization" gotchas).  The differences in
platforms make it more likely that needs for certain things are felt
earlier and more strongly on a particular platform, and shipping a
new thing as an experimental feature to end-users may be the most
effective way to come up with the best approach to help the users.

Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Dakota Hawkins]

On Tue, Aug 23, 2016 at 5:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > One way to avoid that risk may be to release the new feature as
> > "experimental-and-subject-to-change", so that interested users on
> > Windows can actually try it out to see if the feature itself
> > (whatever its interface to them is) makes sense, and you can gauge
> > the value of upstreaming it, while cautioning these early adopters
> > that it has not fully been through the usual review process and may
> > have to change while becoming part of the official release.  This is
> > no different from various "experimental features" we unleash to the
> > wild, either via 'master' or keeping it in 'next' (we tend to do
> > more of the latter, marking "see if anybody screams").
>
> In case it was not clear, I am _not_ saying that the port to Windows
> must not ship with any feature that is not yet in the upstream (the
> same goes for a port to Macs, where it may want to do more about
> dealing with Unicode "normalization" gotchas).  The differences in
> platforms make it more likely that needs for certain things are felt
> earlier and more strongly on a particular platform, and shipping a
> new thing as an experimental feature to end-users may be the most
> effective way to come up with the best approach to help the users.

What is the practical difference between what happened and releasing a
feature as "experimental-and-subject-to-change"?

I use GFW almost exclusively, but I pretty much always consult the
upstream documentation anyway (because I find it easier).

It doesn't seem likely that many users who weren't in dire need of
this feature will even realize/remember it exists, so it's hard for me
to conclude that anybody will really be harmed by this particular
(temporary?) discontinuity.

At any rate it doesn't seem like you guys are going to persuade one
another and from the outside looking in it seems like this argument is
more ideological than technical, which makes it seem like it should
probably embarrass all involved because of its length and publicity.
But maybe I'm wrong, in which case I'm here to embarrass myself.

-Dakota

Git for Windows documentation, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Johannes Schindelin]

Hi Dakota,

On Tue, 23 Aug 2016, Dakota Hawkins wrote:

> I use GFW almost exclusively, but I pretty much always consult the
> upstream documentation anyway (because I find it easier).

Oh... I thought that typing "git help git-commit" opening a nice HTML page
in your favorite browser was good enough.

Do you have any suggestion how to improve the user experience?

Thanks,
Johannes

Re: Git for Windows documentation, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Dakota Hawkins]

On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi Dakota,
>
> On Tue, 23 Aug 2016, Dakota Hawkins wrote:
>
>> I use GFW almost exclusively, but I pretty much always consult the
>> upstream documentation anyway (because I find it easier).
>
> Oh... I thought that typing "git help git-commit" opening a nice HTML page
> in your favorite browser was good enough.
>
> Do you have any suggestion how to improve the user experience?

Just a small one, and that's that I'd prefer the option to have help
display in my terminal (that option might exist and I don't know how
to turn it on). That would be very convenient for me.

Opening a nice HTML page is probably nice for a lot of users. What
frustrates me about it is that I don't know which browser window on
which monitor (of 3) it's going to open in, so it's a context-switch
to a different window somewhere that I don't have much control over.

The thing I find easier about using the upstream documentation is just
that I can pick the browser window I want it to come up in, and it's
usually faster enough for me to just google "git-whatever" or
re-purpose an open doc tab. I don't prefer the _content_ of the
upstream documentation, it's just less frustrating for me to use, if
that makes sense.

-Dakota

Re: Git for Windows documentation, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Philip Oakley]

From: "Dakota Hawkins" <dakotahawkins@gmail.com>
> On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> Hi Dakota,
>>
>> On Tue, 23 Aug 2016, Dakota Hawkins wrote:
>>
>>> I use GFW almost exclusively, but I pretty much always consult the
>>> upstream documentation anyway (because I find it easier).
>>
>> Oh... I thought that typing "git help git-commit" opening a nice HTML 
>> page
>> in your favorite browser was good enough.
>>
>> Do you have any suggestion how to improve the user experience?
>
> Just a small one, and that's that I'd prefer the option to have help
> display in my terminal (that option might exist and I don't know how
> to turn it on). That would be very convenient for me.
>
> Opening a nice HTML page is probably nice for a lot of users. What
> frustrates me about it is that I don't know which browser window on
> which monitor (of 3) it's going to open in, so it's a context-switch
> to a different window somewhere that I don't have much control over.
>
> The thing I find easier about using the upstream documentation is just
> that I can pick the browser window I want it to come up in, and it's
> usually faster enough for me to just google "git-whatever" or
> re-purpose an open doc tab. I don't prefer the _content_ of the
> upstream documentation, it's just less frustrating for me to use, if
> that makes sense.
>
If you would like to use the man pages, then one option is to install the 
SDK, which then allows you to install the man package, (setting the manpath 
as required) to allow your choice of viewer. You may need to set the minnty 
config BoldAsFont=yes if you want the bold for the headings in the man 
pages.

With the SDK you can also create a personal release version of GfW that 
includes the man viewer if you like.
--
Philip

Re: Git for Windows documentation, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Johannes Schindelin]

Hi Dakota,

On Wed, 24 Aug 2016, Dakota Hawkins wrote:

> On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Tue, 23 Aug 2016, Dakota Hawkins wrote:
> >
> >> I use GFW almost exclusively, but I pretty much always consult the
> >> upstream documentation anyway (because I find it easier).
> >
> > Oh... I thought that typing "git help git-commit" opening a nice HTML
> > page in your favorite browser was good enough.
> >
> > Do you have any suggestion how to improve the user experience?
> 
> Just a small one, and that's that I'd prefer the option to have help
> display in my terminal (that option might exist and I don't know how to
> turn it on). That would be very convenient for me.

Ah, okay... The reason why this is not that easy is: we ship with HTML
documentation (and skip `man` altogether, also to conserve space in the
already large installer: it is ~30MB, which might seem acceptable to you
until you are stuck in a country where the download is at 30-70 kB/s).

So I am afraid that the only solution in that case would be to install the
Git for Windows SDK (https://git-for-windows.github.io/#download-sdk, as
pointed out by Philip).

Ciao,
Johannes

Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Johannes Schindelin]

Hi Junio,

On Tue, 23 Aug 2016, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > In case it is not crystal-clear, let me clarify one very important point.
> > It seems that some people mistake the work I do for something I do on a
> > whim. This is not so.
> >
> > The patch series that triggered this entire unfortunate discussion
> > introduced the --smudge option, which I have subsequently renamed to
> > --filters and submitted as a patch series to the Git project.
> 
> As the "--filters" is meant as a new feature, it will not land on
> the maintenance track.  It is very likely that it won't be in 2.10,
> so it won't appear in 2.10.x maintenance track, either.

Right. Which is even more a reason for me to decouple this feature from
non-Windows Git.

> [...] whatever new feature you unleash ahead of upstream to your Windows
> port has cost to your end-users.  Its implementation or its external
> interface may have to change when you upstream the new feature that has
> already been in the field, and your end-users would have to adjust their
> scripts and/or muscle memory.

This is nothing new. As I said earlier, I have plenty of experience with
this. Including the experience of worsimproving a feature that has been
battle-tested for years, only to be broken in the process to appease
reviewers on the Git mailing list.

I talk about the core.hideDotFiles feature, of course, which in the
process of being integrated into core Git lost its ability to respect the
setting to be "false".

Git for Windows has a work-around already, of course, it's just ugly, so I
am hesitating to "upstream it" yet.

As I said. All of this is old hat. Git for Windows has been, and probably
will be for a long time to come, diverging from upstream Git. This is not
something I wanted, or worked toward. It's just reality that happened and
I have to deal with it and there is nothing to see here, please move on.

Ciao,
Dscho

Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> The feature in question is also highly unlikely to be used as much by
> non-Windows users as by Windows users due to the unfortunate choice of the
> default setting for core.autocrlf.

My vague recollection from some years ago was that even among those
who were active in msysGit development there were people who
advocated for straight-thru and others who wanted core.autocrlf as
the default, but I do not know the current state of the affairs.

In any case, in the ideal future, I would imagine that we would want
to have "cat-file blob" to enable "--filters" by default; that would
make cat-file and hash-objects a pair of symmetric operations.

That certainly will not happen within 2.x timeframe, and the new
"cat-file --filter" feature can appear in 2.11 at the earliest, but
I think by that time (or with a few more cycles) we may have a
handful other improvements that are backward incompatible lined up
to urge us to think about bumping the version number to 3.0.  I
recall writing "Will keep in next to see if anybody screams" a few
times already, and they are all good excuses to invite a version
bump.

To prepare for that future, we would probably want to start updating
in-tree scripts (including the tests) so that they call "cat-file
--no-filter blob" whereever they currently say "cat-file blob" in or
soon after 2.11.  Of course, if some of them currently pipe
"cat-file blob" output to munge it to produce what --filters would
have done (I didn't check), we would want to rewrite them to use the
new feature "cat-file --filter blob" when we do so.  In short, there
won't be any "cat-file blob" call that does not have either --filters
or --no-filters, except the ones we write specifically to check the
updated default behaviour when that happens.

Would that sound like a good longer-term plan?

core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Johannes Schindelin]

Hi Junio,

On Tue, 23 Aug 2016, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > The feature in question is also highly unlikely to be used as much by
> > non-Windows users as by Windows users due to the unfortunate choice of the
> > default setting for core.autocrlf.
> 
> My vague recollection from some years ago was that even among those
> who were active in msysGit development there were people who
> advocated for straight-thru and others who wanted core.autocrlf as
> the default, but I do not know the current state of the affairs.

I remember this very non-vaguely, for I was one of the people advocating
straight-through. I basically was shot down by people using Windows more
regularly than I did.

In any case, now is not the time to lament about this.

> In any case, in the ideal future, I would imagine that we would want
> to have "cat-file blob" to enable "--filters" by default; that would
> make cat-file and hash-objects a pair of symmetric operations.

I would advocate against that. It is not like the terms "hash-object" and
"cat-file" even *look* like they are opposites.

The main problem you face with making --filters the default is that it is
a possibly costly switch. Too costly in my opinion, just think of git-lfs.

> That certainly will not happen within 2.x timeframe, and the new
> "cat-file --filter" feature can appear in 2.11 at the earliest, but

s/--filter/--filters/

> I think by that time (or with a few more cycles) we may have a
> handful other improvements that are backward incompatible lined up
> to urge us to think about bumping the version number to 3.0.  I
> recall writing "Will keep in next to see if anybody screams" a few
> times already, and they are all good excuses to invite a version
> bump.
> 
> To prepare for that future, we would probably want to start updating
> in-tree scripts (including the tests) so that they call "cat-file
> --no-filter blob" whereever they currently say "cat-file blob" in or

s/--no-filter/--no-filters/

> soon after 2.11.  Of course, if some of them currently pipe
> "cat-file blob" output to munge it to produce what --filters would
> have done (I didn't check), we would want to rewrite them to use the
> new feature "cat-file --filter blob" when we do so.  In short, there

s/--filter/--filters/

> won't be any "cat-file blob" call that does not have either --filters
> or --no-filters, except the ones we write specifically to check the
> updated default behaviour when that happens.
> 
> Would that sound like a good longer-term plan?

Apart from my objecting against changing the default of cat-file, it sure
sounds like a good long-term plan ;-)

Ciao,
Dscho

Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> In any case, in the ideal future, I would imagine that we would want
>> to have "cat-file blob" to enable "--filters" by default; that would
>> make cat-file and hash-objects a pair of symmetric operations.
>
> I would advocate against that. It is not like the terms "hash-object" and
> "cat-file" even *look* like they are opposites.

I do not quite understand your objection.

hash-object is "I have data somewhere on the filesystem, and I want
to store it in the object store even though I am not ready to add it
to the index yet (or I may not even add it to the index ever), just
to make it available to Git tools".  cat-file is "I have data in the
object store, I want to make it available to my other tools that
understand data stored on the filesystem."

When we taught "--no-filters" to "hash-object" back in 2008, we
should have realized that "cat-file :path >path" would want to be a
way to do "checkout path" (with "--no-filters" option to allow us to
inspect the "canonical version"), but we didn't.

Yes, correcting ancient mistakes is costly.  Such is life.

Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Johannes Schindelin]

Hi Junio,

On Wed, 24 Aug 2016, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> In any case, in the ideal future, I would imagine that we would want
> >> to have "cat-file blob" to enable "--filters" by default; that would
> >> make cat-file and hash-objects a pair of symmetric operations.
> >
> > I would advocate against that. It is not like the terms "hash-object" and
> > "cat-file" even *look* like they are opposites.
> 
> I do not quite understand your objection.
> 
> hash-object is "I have data somewhere on the filesystem, and I want
> to store it in the object store even though I am not ready to add it
> to the index yet (or I may not even add it to the index ever), just
> to make it available to Git tools".

That is not how I read it. I read "hash-object" as: "hash this object".
There was not a thought in my mind that it would apply filters. Since that
was so clear in my mind, I failed to understand that you do not consider
it a design mistake to turn on --filters by default in hash-object.

I read "cat-file" just the same: concatenate files and print on the
standard output. Now, it is confusing enough that it does not concatenate
files in unless in batch mode, and it would be even more confusing if it
started to behave as if the user had called "git checkout --dry-run
<revision> -- <path>" (which does not exist, but for which I would
understand the --filters default).

> Yes, correcting ancient mistakes is costly.  Such is life.

I was not talking about the cost of correcting mistakes. Running --filters
is potentially very costly. Just so you understand what I am talking
about: I have a report that says that checking out a sizeable worktree
with core.autocrlf=true is 58% slower than with core.autocrlf=false. That
is horrible. And it is a cost that is entirely born by Windows users.

In short: I think letting hash-object default to --filters was a mistake,
and doing the same for cat-file would be a mistake, too.

Ciao,
Dscho

Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Torsten Bögershausen]

> I was not talking about the cost of correcting mistakes. Running --filters
> is potentially very costly. Just so you understand what I am talking
> about: I have a report that says that checking out a sizeable worktree
> with core.autocrlf=true is 58% slower than with core.autocrlf=false. That
> is horrible. []

Is this a public repo ?

Or is there a benchmark repo somewhere ?

Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

Hi Torsten,

On Thu, 25 Aug 2016, Torsten Bögershausen wrote:

> > I was not talking about the cost of correcting mistakes. Running --filters
> > is potentially very costly. Just so you understand what I am talking
> > about: I have a report that says that checking out a sizeable worktree
> > with core.autocrlf=true is 58% slower than with core.autocrlf=false. That
> > is horrible. []
> 
> Is this a public repo ?

No.

> Or is there a benchmark repo somewhere ?

Unfortunately not. The only information I have is that it contains
gazillions of files and that most of that time was spent in figuring out
whether the files contain CR/LF, LF, or both.

I hope to get back to some performance benchmarking soon. I have some
experimental code to generate Git repositories of a specific size, and I
hope to be able to replicate the issues with that infrastructure.

Should be fun.

Ciao,
Dscho