Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Johannes Schindelin]

Hi Torsten,

On Thu, 25 Aug 2016, Torsten Bögershausen wrote:

> > I was not talking about the cost of correcting mistakes. Running --filters
> > is potentially very costly. Just so you understand what I am talking
> > about: I have a report that says that checking out a sizeable worktree
> > with core.autocrlf=true is 58% slower than with core.autocrlf=false. That
> > is horrible. []
> 
> Is this a public repo ?

No.

> Or is there a benchmark repo somewhere ?

Unfortunately not. The only information I have is that it contains
gazillions of files and that most of that time was spent in figuring out
whether the files contain CR/LF, LF, or both.

I hope to get back to some performance benchmarking soon. I have some
experimental code to generate Git repositories of a specific size, and I
hope to be able to replicate the issues with that infrastructure.

Should be fun.

Ciao,
Dscho

Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Torsten Bögershausen]

I was not talking about the cost of correcting mistakes. Running --filters
is potentially very costly. Just so you understand what I am talking
about: I have a report that says that checking out a sizeable worktree
with core.autocrlf=true is 58% slower than with core.autocrlf=false. That
is horrible. []


Is this a public repo ?

Or is there a benchmark repo somewhere ?

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Johannes Schindelin]

Hi Junio,

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

> Johannes Schindelin  writes:
> 
> >> In any case, in the ideal future, I would imagine that we would want
> >> to have "cat-file blob" to enable "--filters" by default; that would
> >> make cat-file and hash-objects a pair of symmetric operations.
> >
> > I would advocate against that. It is not like the terms "hash-object" and
> > "cat-file" even *look* like they are opposites.
> 
> I do not quite understand your objection.
> 
> hash-object is "I have data somewhere on the filesystem, and I want
> to store it in the object store even though I am not ready to add it
> to the index yet (or I may not even add it to the index ever), just
> to make it available to Git tools".

That is not how I read it. I read "hash-object" as: "hash this object".
There was not a thought in my mind that it would apply filters. Since that
was so clear in my mind, I failed to understand that you do not consider
it a design mistake to turn on --filters by default in hash-object.

I read "cat-file" just the same: concatenate files and print on the
standard output. Now, it is confusing enough that it does not concatenate
files in unless in batch mode, and it would be even more confusing if it
started to behave as if the user had called "git checkout --dry-run
 -- " (which does not exist, but for which I would
understand the --filters default).

> Yes, correcting ancient mistakes is costly.  Such is life.

I was not talking about the cost of correcting mistakes. Running --filters
is potentially very costly. Just so you understand what I am talking
about: I have a report that says that checking out a sizeable worktree
with core.autocrlf=true is 58% slower than with core.autocrlf=false. That
is horrible. And it is a cost that is entirely born by Windows users.

In short: I think letting hash-object default to --filters was a mistake,
and doing the same for cat-file would be a mistake, too.

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Johannes Schindelin]

Hi Dakota,

On Wed, 24 Aug 2016, Dakota Hawkins wrote:

> On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin
>  wrote:
> >
> > On Tue, 23 Aug 2016, Dakota Hawkins wrote:
> >
> >> I use GFW almost exclusively, but I pretty much always consult the
> >> upstream documentation anyway (because I find it easier).
> >
> > Oh... I thought that typing "git help git-commit" opening a nice HTML
> > page in your favorite browser was good enough.
> >
> > Do you have any suggestion how to improve the user experience?
> 
> Just a small one, and that's that I'd prefer the option to have help
> display in my terminal (that option might exist and I don't know how to
> turn it on). That would be very convenient for me.

Ah, okay... The reason why this is not that easy is: we ship with HTML
documentation (and skip `man` altogether, also to conserve space in the
already large installer: it is ~30MB, which might seem acceptable to you
until you are stuck in a country where the download is at 30-70 kB/s).

So I am afraid that the only solution in that case would be to install the
Git for Windows SDK (https://git-for-windows.github.io/#download-sdk, as
pointed out by Philip).

Ciao,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Philip Oakley]

From: "Dakota Hawkins" 

On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin
 wrote:

Hi Dakota,

On Tue, 23 Aug 2016, Dakota Hawkins wrote:


I use GFW almost exclusively, but I pretty much always consult the
upstream documentation anyway (because I find it easier).


Oh... I thought that typing "git help git-commit" opening a nice HTML 
page

in your favorite browser was good enough.

Do you have any suggestion how to improve the user experience?


Just a small one, and that's that I'd prefer the option to have help
display in my terminal (that option might exist and I don't know how
to turn it on). That would be very convenient for me.

Opening a nice HTML page is probably nice for a lot of users. What
frustrates me about it is that I don't know which browser window on
which monitor (of 3) it's going to open in, so it's a context-switch
to a different window somewhere that I don't have much control over.

The thing I find easier about using the upstream documentation is just
that I can pick the browser window I want it to come up in, and it's
usually faster enough for me to just google "git-whatever" or
re-purpose an open doc tab. I don't prefer the _content_ of the
upstream documentation, it's just less frustrating for me to use, if
that makes sense.

If you would like to use the man pages, then one option is to install the 
SDK, which then allows you to install the man package, (setting the manpath 
as required) to allow your choice of viewer. You may need to set the minnty 
config BoldAsFont=yes if you want the bold for the headings in the man 
pages.


With the SDK you can also create a personal release version of GfW that 
includes the man viewer if you like.

--
Philip

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Junio C Hamano]

Johannes Schindelin  writes:

>> In any case, in the ideal future, I would imagine that we would want
>> to have "cat-file blob" to enable "--filters" by default; that would
>> make cat-file and hash-objects a pair of symmetric operations.
>
> I would advocate against that. It is not like the terms "hash-object" and
> "cat-file" even *look* like they are opposites.

I do not quite understand your objection.

hash-object is "I have data somewhere on the filesystem, and I want
to store it in the object store even though I am not ready to add it
to the index yet (or I may not even add it to the index ever), just
to make it available to Git tools".  cat-file is "I have data in the
object store, I want to make it available to my other tools that
understand data stored on the filesystem."

When we taught "--no-filters" to "hash-object" back in 2008, we
should have realized that "cat-file :path >path" would want to be a
way to do "checkout path" (with "--no-filters" option to allow us to
inspect the "canonical version"), but we didn't.

Yes, correcting ancient mistakes is costly.  Such is life.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Dakota Hawkins]

On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin
 wrote:
> Hi Dakota,
>
> On Tue, 23 Aug 2016, Dakota Hawkins wrote:
>
>> I use GFW almost exclusively, but I pretty much always consult the
>> upstream documentation anyway (because I find it easier).
>
> Oh... I thought that typing "git help git-commit" opening a nice HTML page
> in your favorite browser was good enough.
>
> Do you have any suggestion how to improve the user experience?

Just a small one, and that's that I'd prefer the option to have help
display in my terminal (that option might exist and I don't know how
to turn it on). That would be very convenient for me.

Opening a nice HTML page is probably nice for a lot of users. What
frustrates me about it is that I don't know which browser window on
which monitor (of 3) it's going to open in, so it's a context-switch
to a different window somewhere that I don't have much control over.

The thing I find easier about using the upstream documentation is just
that I can pick the browser window I want it to come up in, and it's
usually faster enough for me to just google "git-whatever" or
re-purpose an open doc tab. I don't prefer the _content_ of the
upstream documentation, it's just less frustrating for me to use, if
that makes sense.

-Dakota
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

[Johannes Schindelin]

Hi Junio,

On Tue, 23 Aug 2016, Junio C Hamano wrote:

> Johannes Schindelin  writes:
> 
> > The feature in question is also highly unlikely to be used as much by
> > non-Windows users as by Windows users due to the unfortunate choice of the
> > default setting for core.autocrlf.
> 
> My vague recollection from some years ago was that even among those
> who were active in msysGit development there were people who
> advocated for straight-thru and others who wanted core.autocrlf as
> the default, but I do not know the current state of the affairs.

I remember this very non-vaguely, for I was one of the people advocating
straight-through. I basically was shot down by people using Windows more
regularly than I did.

In any case, now is not the time to lament about this.

> In any case, in the ideal future, I would imagine that we would want
> to have "cat-file blob" to enable "--filters" by default; that would
> make cat-file and hash-objects a pair of symmetric operations.

I would advocate against that. It is not like the terms "hash-object" and
"cat-file" even *look* like they are opposites.

The main problem you face with making --filters the default is that it is
a possibly costly switch. Too costly in my opinion, just think of git-lfs.

> That certainly will not happen within 2.x timeframe, and the new
> "cat-file --filter" feature can appear in 2.11 at the earliest, but

s/--filter/--filters/

> I think by that time (or with a few more cycles) we may have a
> handful other improvements that are backward incompatible lined up
> to urge us to think about bumping the version number to 3.0.  I
> recall writing "Will keep in next to see if anybody screams" a few
> times already, and they are all good excuses to invite a version
> bump.
> 
> To prepare for that future, we would probably want to start updating
> in-tree scripts (including the tests) so that they call "cat-file
> --no-filter blob" whereever they currently say "cat-file blob" in or

s/--no-filter/--no-filters/

> soon after 2.11.  Of course, if some of them currently pipe
> "cat-file blob" output to munge it to produce what --filters would
> have done (I didn't check), we would want to rewrite them to use the
> new feature "cat-file --filter blob" when we do so.  In short, there

s/--filter/--filters/

> won't be any "cat-file blob" call that does not have either --filters
> or --no-filters, except the ones we write specifically to check the
> updated default behaviour when that happens.
> 
> Would that sound like a good longer-term plan?

Apart from my objecting against changing the default of cat-file, it sure
sounds like a good long-term plan ;-)

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Johannes Schindelin]

Hi Dakota,

On Tue, 23 Aug 2016, Dakota Hawkins wrote:

> I use GFW almost exclusively, but I pretty much always consult the
> upstream documentation anyway (because I find it easier).

Oh... I thought that typing "git help git-commit" opening a nice HTML page
in your favorite browser was good enough.

Do you have any suggestion how to improve the user experience?

Thanks,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Johannes Schindelin]

Hi Junio,

On Tue, 23 Aug 2016, Junio C Hamano wrote:

> Johannes Schindelin  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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Junio C Hamano]

Johannes Schindelin  writes:

> The feature in question is also highly unlikely to be used as much by
> non-Windows users as by Windows users due to the unfortunate choice of the
> default setting for core.autocrlf.

My vague recollection from some years ago was that even among those
who were active in msysGit development there were people who
advocated for straight-thru and others who wanted core.autocrlf as
the default, but I do not know the current state of the affairs.

In any case, in the ideal future, I would imagine that we would want
to have "cat-file blob" to enable "--filters" by default; that would
make cat-file and hash-objects a pair of symmetric operations.

That certainly will not happen within 2.x timeframe, and the new
"cat-file --filter" feature can appear in 2.11 at the earliest, but
I think by that time (or with a few more cycles) we may have a
handful other improvements that are backward incompatible lined up
to urge us to think about bumping the version number to 3.0.  I
recall writing "Will keep in next to see if anybody screams" a few
times already, and they are all good excuses to invite a version
bump.

To prepare for that future, we would probably want to start updating
in-tree scripts (including the tests) so that they call "cat-file
--no-filter blob" whereever they currently say "cat-file blob" in or
soon after 2.11.  Of course, if some of them currently pipe
"cat-file blob" output to munge it to produce what --filters would
have done (I didn't check), we would want to rewrite them to use the
new feature "cat-file --filter blob" when we do so.  In short, there
won't be any "cat-file blob" call that does not have either --filters
or --no-filters, except the ones we write specifically to check the
updated default behaviour when that happens.

Would that sound like a good longer-term plan?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Dakota Hawkins]

On Tue, Aug 23, 2016 at 5:42 PM, Junio C Hamano  wrote:
>
> Junio C Hamano  writes:
>
> > One way to avoid that risk may be to release the new feature as
> > "experimental-and-subject-to-change", so that interested users on
> > Windows can actually try it out to see if the feature itself
> > (whatever its interface to them is) makes sense, and you can gauge
> > the value of upstreaming it, while cautioning these early adopters
> > that it has not fully been through the usual review process and may
> > have to change while becoming part of the official release.  This is
> > no different from various "experimental features" we unleash to the
> > wild, either via 'master' or keeping it in 'next' (we tend to do
> > more of the latter, marking "see if anybody screams").
>
> In case it was not clear, I am _not_ saying that the port to Windows
> must not ship with any feature that is not yet in the upstream (the
> same goes for a port to Macs, where it may want to do more about
> dealing with Unicode "normalization" gotchas).  The differences in
> platforms make it more likely that needs for certain things are felt
> earlier and more strongly on a particular platform, and shipping a
> new thing as an experimental feature to end-users may be the most
> effective way to come up with the best approach to help the users.

What is the practical difference between what happened and releasing a
feature as "experimental-and-subject-to-change"?

I use GFW almost exclusively, but I pretty much always consult the
upstream documentation anyway (because I find it easier).

It doesn't seem likely that many users who weren't in dire need of
this feature will even realize/remember it exists, so it's hard for me
to conclude that anybody will really be harmed by this particular
(temporary?) discontinuity.

At any rate it doesn't seem like you guys are going to persuade one
another and from the outside looking in it seems like this argument is
more ideological than technical, which makes it seem like it should
probably embarrass all involved because of its length and publicity.
But maybe I'm wrong, in which case I'm here to embarrass myself.

-Dakota
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Junio C Hamano]

Junio C Hamano  writes:

> One way to avoid that risk may be to release the new feature as
> "experimental-and-subject-to-change", so that interested users on
> Windows can actually try it out to see if the feature itself
> (whatever its interface to them is) makes sense, and you can gauge
> the value of upstreaming it, while cautioning these early adopters
> that it has not fully been through the usual review process and may
> have to change while becoming part of the official release.  This is
> no different from various "experimental features" we unleash to the
> wild, either via 'master' or keeping it in 'next' (we tend to do
> more of the latter, marking "see if anybody screams").

In case it was not clear, I am _not_ saying that the port to Windows
must not ship with any feature that is not yet in the upstream (the
same goes for a port to Macs, where it may want to do more about
dealing with Unicode "normalization" gotchas).  The differences in
platforms make it more likely that needs for certain things are felt
earlier and more strongly on a particular platform, and shipping a
new thing as an experimental feature to end-users may be the most
effective way to come up with the best approach to help the users.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Junio C Hamano]

Johannes Schindelin  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.

I do not agree with Duy that the "port to Windows" needs a separate
distinct name, though.  Having said that, aside from the issue of
handling of bugreports has been already meantioned, which mostly
costs for Git developers, 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.

One way to avoid that risk may be to release the new feature as
"experimental-and-subject-to-change", so that interested users on
Windows can actually try it out to see if the feature itself
(whatever its interface to them is) makes sense, and you can gauge
the value of upstreaming it, while cautioning these early adopters
that it has not fully been through the usual review process and may
have to change while becoming part of the official release.  This is
no different from various "experimental features" we unleash to the
wild, either via 'master' or keeping it in 'next' (we tend to do
more of the latter, marking "see if anybody screams").



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Johannes Schindelin]

Hi Michael,

On Tue, 23 Aug 2016, Johannes Schindelin wrote:

> On Tue, 23 Aug 2016, Michael J Gruber wrote:
> 
> > Maybe you want to re-read what you wrote to trigger his response, and
> > consider adjusting your attitude ("I want this now so I'll release it in
> > Git4Win") rather than the downstream name.
> 
> I am working *very* hard on improving the user experience of Git for
> Windows. And yes, sometimes I have to include something in Git for Windows
> versions that upstream Git does not include in the corresponding version
> number.
> 
> I am really at a loss why you see fit to attack me about that.

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.

So it is an altogether unfair misrepresentation to state that I introduce
features that deviate so much from upstream Git as to require a new name.

The feature in question is also highly unlikely to be used as much by
non-Windows users as by Windows users due to the unfortunate choice of the
default setting for core.autocrlf. Basically, Windows users have to use
those --filters all the time, and in many cases, git cat-file --batch
without --filters is simply useless. This is nothing, say, Linux users
would care about, of course, but Windows folks like me care a great deal
about it.

It is this need that literally guarantees that I will get more useful
feedback from Windows users about this feature (and in this context I mean
application developers) than from Linux or MacOSX users. And as a matter
of fact, I got exactly that: great feedback. This feedback resulted in the
addition of the --path option, and of the work I did on making --filters
compatible with the --batch mode.

So I take great exception at this criticism. I think these comments were
not really thought through, and I also would consider this discussion in
and of itself ("is Git for Windows really Git? Should it not be renamed,
despite Dscho's best efforts to get them in sync?") to be much more
harmful than any feature I introduced into Git for Windows before trying
to get it integrated into upstream Git.

Thank you very much for your attention,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Johannes Schindelin]

Hi Michael,

On Tue, 23 Aug 2016, Michael J Gruber wrote:

> Maybe you want to re-read what you wrote to trigger his response, and
> consider adjusting your attitude ("I want this now so I'll release it in
> Git4Win") rather than the downstream name.

I am working *very* hard on improving the user experience of Git for
Windows. And yes, sometimes I have to include something in Git for Windows
versions that upstream Git does not include in the corresponding version
number.

I am really at a loss why you see fit to attack me about that.

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Michael J Gruber]

Johannes Schindelin venit, vidit, dixit 23.08.2016 15:54:
> Hi Duy,
> 
> On Mon, 22 Aug 2016, Duy Nguyen wrote:
> 
>> On Thu, Aug 18, 2016 at 3:37 PM, Johannes Schindelin
>>  wrote:
>>> Hi Junio,
>>>
>>> On Wed, 17 Aug 2016, Junio C Hamano wrote:
>>>
 Johannes Schindelin  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.
> 
> Oh? Completely?
> 
> So the core.hideDotFiles feature should have forced me to rename Git for
> Windows to, say, DschoGit on Windows?
> 
> Let's just stop here. This is getting too silly.

I see more truth than silliness in Duy's suggestion. Maybe you want to
re-read what you wrote to trigger his response, and consider adjusting
your attitude ("I want this now so I'll release it in Git4Win") rather
than the downstream name.

Michael

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Johannes Schindelin]

Hi Duy,

On Mon, 22 Aug 2016, Duy Nguyen wrote:

> On Thu, Aug 18, 2016 at 3:37 PM, Johannes Schindelin
>  wrote:
> > Hi Junio,
> >
> > On Wed, 17 Aug 2016, Junio C Hamano wrote:
> >
> >> Johannes Schindelin  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.

Oh? Completely?

So the core.hideDotFiles feature should have forced me to rename Git for
Windows to, say, DschoGit on Windows?

Let's just stop here. This is getting too silly.

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Duy Nguyen]

On Thu, Aug 18, 2016 at 3:37 PM, Johannes Schindelin
 wrote:
> Hi Junio,
>
> On Wed, 17 Aug 2016, Junio C Hamano wrote:
>
>> Johannes Schindelin  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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html