git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Michael J Gruber <git@drmicha.warpmail.net>,
	Duy Nguyen <pclouds@gmail.com>,
	git-for-windows <git-for-windows@googlegroups.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3
Date: Wed, 24 Aug 2016 17:39:43 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1608241735520.4924@virtualbox> (raw)
In-Reply-To: <xmqqzio3uw31.fsf@gitster.mtv.corp.google.com>

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

  parent reply	other threads:[~2016-08-24 15:40 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-13 10:14 [ANNOUNCE] Git for Windows 2.9.3 Johannes Schindelin
2016-08-13 15:50 ` Junio C Hamano
2016-08-17 13:54   ` Johannes Schindelin
2016-08-17 15:29     ` Junio C Hamano
2016-08-18  8:37       ` Johannes Schindelin
2016-08-22 14:04         ` [git-for-windows] " Duy Nguyen
2016-08-23 13:54           ` Johannes Schindelin
2016-08-23 14:41             ` Michael J Gruber
2016-08-23 15:37               ` Johannes Schindelin
2016-08-23 16:05                 ` Johannes Schindelin
2016-08-23 19:25                   ` Junio C Hamano
2016-08-23 21:42                     ` Junio C Hamano
2016-08-24  1:04                       ` Dakota Hawkins
2016-08-24 15:41                         ` Git for Windows documentation, was " Johannes Schindelin
2016-08-24 16:06                           ` Dakota Hawkins
2016-08-24 23:28                             ` Philip Oakley
2016-08-25 11:42                             ` Johannes Schindelin
2016-08-24 15:39                     ` Johannes Schindelin [this message]
2016-08-24  5:09                   ` Junio C Hamano
2016-08-24 15:48                     ` core.autocrlf, was " Johannes Schindelin
2016-08-24 16:45                       ` Junio C Hamano
2016-08-25 11:54                         ` Johannes Schindelin
2016-08-25 12:43                           ` Torsten Bögershausen
2016-08-25 13:50                             ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1608241735520.4924@virtualbox \
    --to=johannes.schindelin@gmx.de \
    --cc=git-for-windows@googlegroups.com \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).