On Thu, Aug 18, 2016 at 3:37 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi Junio, > > On Wed, 17 Aug 2016, Junio C Hamano wrote: > >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html