Re: [ANNOUNCE] Git for Windows 2.9.3

Johannes Schindelin [off-list ref] writes:

quoted

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?

Hi Junio,

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

Johannes Schindelin [off-list ref] writes:

quoted

quoted

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

On Thu, Aug 18, 2016 at 3:37 PM, Johannes Schindelin
[off-list ref] wrote:

Hi Junio,

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

quoted

Johannes Schindelin [off-list ref] writes:

quoted

quoted

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

Hi Duy,

On Mon, 22 Aug 2016, Duy Nguyen wrote:

On Thu, Aug 18, 2016 at 3:37 PM, Johannes Schindelin
[off-list ref] wrote:

quoted

Hi Junio,

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

quoted

Johannes Schindelin [off-list ref] writes:

quoted

quoted

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

Johannes Schindelin venit, vidit, dixit 23.08.2016 15:54:

Hi Duy,

On Mon, 22 Aug 2016, Duy Nguyen wrote:

quoted

On Thu, Aug 18, 2016 at 3:37 PM, Johannes Schindelin
[off-list ref] wrote:

quoted

Hi Junio,

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

quoted

Johannes Schindelin [off-list ref] writes:

quoted

quoted

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

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

Hi Michael,

On Tue, 23 Aug 2016, Johannes Schindelin wrote:

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

quoted

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