Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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