Re: [ANNOUNCE] Git for Windows 2.9.3

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 18, 2016, 08:37 UTC
Message-ID: <alpine.DEB.2.20.1608181022250.4924@virtualbox>
In-Reply-To: <xmqqeg5nbehc.fsf@gitster.mtv.corp.google.com>

Hi Junio,

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

Show 15 quoted lines

> 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