Thread (7 messages) flat view 7 messages, 4 authors, 2016-08-23

Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

From: Duy Nguyen <hidden>
Date: 2016-08-22 14:05:45

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help