Re: [ANNOUNCE] Git for Windows 2.9.3

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

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