* [ANNOUNCE] Git for Windows 2.9.3 @ 2016-08-13 10:14 Johannes Schindelin 2016-08-13 15:50 ` Junio C Hamano 0 siblings, 1 reply; 24+ messages in thread From: Johannes Schindelin @ 2016-08-13 10:14 UTC (permalink / raw) To: git-for-windows, git [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=X-UNKNOWN, Size: 1724 bytes --] Dear Git users, It is my pleasure to announce that Git for Windows 2.9.3 is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.9.2 (July 16th 2016) New Features • Comes with Git 2.9.3. • Updated Git Credential Manager to version 1.6.0. • Includes support for git status --porcelain=v2. • Avoids evaluating unnecessary patch IDs when determining which commits do not need to be rebased because they are already upstream. • Sports a new --smudge option for git cat-file that lets it pass blob contents through smudge filters configured for the specified path. Bug Fixes • When offering to Launch Git Bash after the installation, it now launches in the home directory, consistent with the Git Bash Start Menu entry. • When ~/.gitconfig sets core.hideDotFiles=false, git init respects that again. Filename | SHA-256 -------- | ------- Git-2.9.3-64-bit.exe | 1a642cf2914e18fa868b1ed2c6d1df4a46ba8ef30355fd1965850895a658e024 Git-2.9.3-32-bit.exe | d6b4a19536ad408018688f1242ab0d1f5dc5544109662bfddf915f685eba58a9 PortableGit-2.9.3-64-bit.7z.exe | 3423ea5c7e025a67903e05d1493680d6d5d6666429a9c400cc9e33beea5adb1b PortableGit-2.9.3-32-bit.7z.exe | cd142cbb124d7c3e3c3bf144785e57573afd2fc9c043447b7f5111ec044e6ced MinGit-2.9.3-64-bit.zip | 17e40cb149ce6a348c8e8bbe7f1c1fff00f82882f0e57f32d60ea5c26feeef98 MinGit-2.9.3-32-bit.zip | 3c6515c09ccb7d1aa6620db51245c87f9836fbde5ee9af6c849b4cbd506f60e8 Git-2.9.3-64-bit.tar.bz2 | 7b165d400c2bcc427881d502dd46cd442e512053d92cba8b3e46173c5028e427 Git-2.9.3-32-bit.tar.bz2 | 00f265ddbbfedd25a8a0c38a33a6cb12761101a019f0c7f6189f07e771a522b7 Ciao, Johannes ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [ANNOUNCE] Git for Windows 2.9.3 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 0 siblings, 1 reply; 24+ messages in thread From: Junio C Hamano @ 2016-08-13 15:50 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git-for-windows, git Johannes Schindelin <johannes.schindelin@gmx.de> writes: > New Features > > • Comes with Git 2.9.3. For future reference, what time (in UTC) of the day is convenient for you to see an upstream tarball? > • Sports a new --smudge option for git cat-file that lets it pass > blob contents through smudge filters configured for the specified > path. Perhaps we want to upstream this, together with a new "--clean" option for git hash-object? And after writing all of the above, I noticed that hash-object by default uses the clean machinery and that can be turned off by giving the "--no-filters" option. The reason why the option is not called "--no-clean" is because it is not just about the clean filter but is about using the entirety of convert_to_git() filter chain. We probably should teach "hash-objects" to take "--filters" for consistency. 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. Thanks. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [ANNOUNCE] Git for Windows 2.9.3 2016-08-13 15:50 ` Junio C Hamano @ 2016-08-17 13:54 ` Johannes Schindelin 2016-08-17 15:29 ` Junio C Hamano 0 siblings, 1 reply; 24+ messages in thread From: Johannes Schindelin @ 2016-08-17 13:54 UTC (permalink / raw) To: Junio C Hamano; +Cc: git-for-windows, git [-- Attachment #1: Type: text/plain, Size: 2545 bytes --] Hi Junio, On Sat, 13 Aug 2016, Junio C Hamano wrote: > Johannes Schindelin <johannes.schindelin@gmx.de> writes: > > > New Features > > > > • Comes with Git 2.9.3. > > For future reference, what time (in UTC) of the day is convenient > for you to see an upstream tarball? Heh... I don't do tarballs anymore, I now use this newfangled tool to manage source code... "gyt" or something like that, it is called. :-) Given that between you and me there is currently a time zone difference of 9h (except for four weeks, two in spring, when it is only 8h, and two in fall, when it is 10h), I believe we cannot find a time that is convenient for both of us. But I also think it is fine, when I discover a new upstream Git version in the morning, I can spend all day on fixing any problems and on packaging the result ;-) > > • Sports a new --smudge option for git cat-file that lets it pass > > blob contents through smudge filters configured for the specified > > path. > > Perhaps we want to upstream this, together with a new "--clean" option > for git hash-object? No question about that. I just needed this in a hurry and short-circuited it into Git for Windows before submitting it upstream. > And after writing all of the above, I noticed that hash-object by > default uses the clean machinery and that can be turned off by giving > the "--no-filters" option. The reason why the option is not called > "--no-clean" is because it is not just about the clean filter but is > about using the entirety of convert_to_git() filter chain. Right, as is the --smudge option (it is about the entirety of convert_to_worktree()). > We probably should teach "hash-objects" to take "--filters" for > consistency. I actually thought about that, too. Which was one of the reasons I did not submit the patch to the Git mailing list first, as I expect several iterations to be necessary to get everything into `master`. > 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). Ciao, Dscho ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [ANNOUNCE] Git for Windows 2.9.3 2016-08-17 13:54 ` Johannes Schindelin @ 2016-08-17 15:29 ` Junio C Hamano 2016-08-18 8:37 ` Johannes Schindelin 0 siblings, 1 reply; 24+ messages in thread From: Junio C Hamano @ 2016-08-17 15:29 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git-for-windows, git Johannes Schindelin <Johannes.Schindelin@gmx.de> 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. That's the price of your using open source and taking a short-cut. Adding a "--smudge" synonym is spreading the same hurt to outside your fork. Let's see if we can avoid doing that. Perhaps mark that "--smudge" as experimental-and-subject-to-change and re-announce? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [ANNOUNCE] Git for Windows 2.9.3 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 0 siblings, 1 reply; 24+ messages in thread From: Johannes Schindelin @ 2016-08-18 8:37 UTC (permalink / raw) To: Junio C Hamano; +Cc: git-for-windows, git Hi Junio, On Wed, 17 Aug 2016, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> 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. > That's the price of your using open source and taking a short-cut. > Adding a "--smudge" synonym is spreading the same hurt to outside > your fork. Let's see if we can avoid doing that. Perhaps mark that > "--smudge" as experimental-and-subject-to-change and re-announce? I do not think so. I have plenty of experience to deal with the problem caused by Git for Windows requiring plenty of patches on top of your Git versions. I can easily deal with this here problem, too. FYI there have been two very strong reasons why I did not go through the review on the Git mailing list for the --smudge option: 1) I really needed this quick, and last time I needed something quick, it did not exactly work out, now, did it, and 2) as far as I am concerned, the most important part of developing patches is the practical testing, and this belief was reinforced by the core.hideDotFiles feature that was well-tested and well-exercised through years, only to be broken by changes necessitated by the review on the Git mailing list: despite the best efforts of both you and me, we managed to worsimprove the patches to a point where they may look more elegant than before, but unfortunately are also less correct at the same time. So I learned my lesson: I will try better to get patches robust and stable by exercising them and developing them as needed (the --smudge feature, for example, turned out to be only half of what I need, I developed more patches on that front), and I will be careful to avoid major modifications of my patches just to get things upstream. It is better to carry correct patches in Git for Windows than to upstream incorrect revisions of them. Ideally, all of the patches I carry in Git for Windows would make it into git.git eventually, of course. I fully support that. But not at the price of breakages. Ciao, Dscho ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 2016-08-18 8:37 ` Johannes Schindelin @ 2016-08-22 14:04 ` Duy Nguyen 2016-08-23 13:54 ` Johannes Schindelin 0 siblings, 1 reply; 24+ messages in thread From: Duy Nguyen @ 2016-08-22 14:04 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, git-for-windows, Git Mailing List On Thu, Aug 18, 2016 at 3:37 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > Hi Junio, > > On Wed, 17 Aug 2016, Junio C Hamano wrote: > >> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 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 0 siblings, 1 reply; 24+ messages in thread From: Johannes Schindelin @ 2016-08-23 13:54 UTC (permalink / raw) To: Duy Nguyen; +Cc: Junio C Hamano, git-for-windows, Git Mailing List Hi Duy, On Mon, 22 Aug 2016, Duy Nguyen wrote: > On Thu, Aug 18, 2016 at 3:37 PM, Johannes Schindelin > <Johannes.Schindelin@gmx.de> wrote: > > Hi Junio, > > > > On Wed, 17 Aug 2016, Junio C Hamano wrote: > > > >> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 2016-08-23 13:54 ` Johannes Schindelin @ 2016-08-23 14:41 ` Michael J Gruber 2016-08-23 15:37 ` Johannes Schindelin 0 siblings, 1 reply; 24+ messages in thread From: Michael J Gruber @ 2016-08-23 14:41 UTC (permalink / raw) To: Johannes Schindelin, Duy Nguyen Cc: Junio C Hamano, git-for-windows, Git Mailing List 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 >> <Johannes.Schindelin@gmx.de> wrote: >>> Hi Junio, >>> >>> On Wed, 17 Aug 2016, Junio C Hamano wrote: >>> >>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 2016-08-23 14:41 ` Michael J Gruber @ 2016-08-23 15:37 ` Johannes Schindelin 2016-08-23 16:05 ` Johannes Schindelin 0 siblings, 1 reply; 24+ messages in thread From: Johannes Schindelin @ 2016-08-23 15:37 UTC (permalink / raw) To: Michael J Gruber Cc: Duy Nguyen, Junio C Hamano, git-for-windows, Git Mailing List 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 2016-08-23 15:37 ` Johannes Schindelin @ 2016-08-23 16:05 ` Johannes Schindelin 2016-08-23 19:25 ` Junio C Hamano 2016-08-24 5:09 ` Junio C Hamano 0 siblings, 2 replies; 24+ messages in thread From: Johannes Schindelin @ 2016-08-23 16:05 UTC (permalink / raw) To: Michael J Gruber Cc: Duy Nguyen, Junio C Hamano, git-for-windows, Git Mailing List 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 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 15:39 ` Johannes Schindelin 2016-08-24 5:09 ` Junio C Hamano 1 sibling, 2 replies; 24+ messages in thread From: Junio C Hamano @ 2016-08-23 19:25 UTC (permalink / raw) To: Johannes Schindelin Cc: Michael J Gruber, Duy Nguyen, git-for-windows, Git Mailing List 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. 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"). ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 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:39 ` Johannes Schindelin 1 sibling, 1 reply; 24+ messages in thread From: Junio C Hamano @ 2016-08-23 21:42 UTC (permalink / raw) To: Johannes Schindelin Cc: Michael J Gruber, Duy Nguyen, git-for-windows, Git Mailing List Junio C Hamano <gitster@pobox.com> 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 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 0 siblings, 1 reply; 24+ messages in thread From: Dakota Hawkins @ 2016-08-24 1:04 UTC (permalink / raw) To: Junio C Hamano Cc: Johannes Schindelin, Michael J Gruber, Duy Nguyen, git-for-windows, Git Mailing List On Tue, Aug 23, 2016 at 5:42 PM, Junio C Hamano <gitster@pobox.com> wrote: > > Junio C Hamano <gitster@pobox.com> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Git for Windows documentation, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 2016-08-24 1:04 ` Dakota Hawkins @ 2016-08-24 15:41 ` Johannes Schindelin 2016-08-24 16:06 ` Dakota Hawkins 0 siblings, 1 reply; 24+ messages in thread From: Johannes Schindelin @ 2016-08-24 15:41 UTC (permalink / raw) To: Dakota Hawkins Cc: Junio C Hamano, Michael J Gruber, Duy Nguyen, git-for-windows, Git Mailing List 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Git for Windows documentation, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 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 0 siblings, 2 replies; 24+ messages in thread From: Dakota Hawkins @ 2016-08-24 16:06 UTC (permalink / raw) To: Johannes Schindelin Cc: Junio C Hamano, Michael J Gruber, Duy Nguyen, git-for-windows, Git Mailing List On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Git for Windows documentation, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 2016-08-24 16:06 ` Dakota Hawkins @ 2016-08-24 23:28 ` Philip Oakley 2016-08-25 11:42 ` Johannes Schindelin 1 sibling, 0 replies; 24+ messages in thread From: Philip Oakley @ 2016-08-24 23:28 UTC (permalink / raw) To: Dakota Hawkins, Johannes Schindelin Cc: Junio C Hamano, Michael J Gruber, Duy Nguyen, git-for-windows, Git Mailing List From: "Dakota Hawkins" <dakotahawkins@gmail.com> > On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin > <Johannes.Schindelin@gmx.de> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Git for Windows documentation, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 2016-08-24 16:06 ` Dakota Hawkins 2016-08-24 23:28 ` Philip Oakley @ 2016-08-25 11:42 ` Johannes Schindelin 1 sibling, 0 replies; 24+ messages in thread From: Johannes Schindelin @ 2016-08-25 11:42 UTC (permalink / raw) To: Dakota Hawkins Cc: Junio C Hamano, Michael J Gruber, Duy Nguyen, git-for-windows, Git Mailing List Hi Dakota, On Wed, 24 Aug 2016, Dakota Hawkins wrote: > On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin > <Johannes.Schindelin@gmx.de> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 2016-08-23 19:25 ` Junio C Hamano 2016-08-23 21:42 ` Junio C Hamano @ 2016-08-24 15:39 ` Johannes Schindelin 1 sibling, 0 replies; 24+ messages in thread From: Johannes Schindelin @ 2016-08-24 15:39 UTC (permalink / raw) To: Junio C Hamano Cc: Michael J Gruber, Duy Nguyen, git-for-windows, Git Mailing List 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 2016-08-23 16:05 ` Johannes Schindelin 2016-08-23 19:25 ` Junio C Hamano @ 2016-08-24 5:09 ` Junio C Hamano 2016-08-24 15:48 ` core.autocrlf, was " Johannes Schindelin 1 sibling, 1 reply; 24+ messages in thread From: Junio C Hamano @ 2016-08-24 5:09 UTC (permalink / raw) To: Johannes Schindelin Cc: Michael J Gruber, Duy Nguyen, git-for-windows, Git Mailing List Johannes Schindelin <Johannes.Schindelin@gmx.de> 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? ^ permalink raw reply [flat|nested] 24+ messages in thread
* core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 2016-08-24 5:09 ` Junio C Hamano @ 2016-08-24 15:48 ` Johannes Schindelin 2016-08-24 16:45 ` Junio C Hamano 0 siblings, 1 reply; 24+ messages in thread From: Johannes Schindelin @ 2016-08-24 15:48 UTC (permalink / raw) To: Junio C Hamano Cc: Michael J Gruber, Duy Nguyen, git-for-windows, Git Mailing List Hi Junio, On Tue, 23 Aug 2016, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 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 0 siblings, 1 reply; 24+ messages in thread From: Junio C Hamano @ 2016-08-24 16:45 UTC (permalink / raw) To: Johannes Schindelin Cc: Michael J Gruber, Duy Nguyen, git-for-windows, Git Mailing List Johannes Schindelin <Johannes.Schindelin@gmx.de> 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 2016-08-24 16:45 ` Junio C Hamano @ 2016-08-25 11:54 ` Johannes Schindelin 2016-08-25 12:43 ` Torsten Bögershausen 0 siblings, 1 reply; 24+ messages in thread From: Johannes Schindelin @ 2016-08-25 11:54 UTC (permalink / raw) To: Junio C Hamano Cc: Michael J Gruber, Duy Nguyen, git-for-windows, Git Mailing List Hi Junio, On Wed, 24 Aug 2016, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> 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 <revision> -- <path>" (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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 2016-08-25 11:54 ` Johannes Schindelin @ 2016-08-25 12:43 ` Torsten Bögershausen 2016-08-25 13:50 ` Johannes Schindelin 0 siblings, 1 reply; 24+ messages in thread From: Torsten Bögershausen @ 2016-08-25 12:43 UTC (permalink / raw) To: Johannes Schindelin, Junio C Hamano Cc: Michael J Gruber, Duy Nguyen, git-for-windows, Git Mailing List > 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 ? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3 2016-08-25 12:43 ` Torsten Bögershausen @ 2016-08-25 13:50 ` Johannes Schindelin 0 siblings, 0 replies; 24+ messages in thread From: Johannes Schindelin @ 2016-08-25 13:50 UTC (permalink / raw) To: Torsten Bögershausen Cc: Junio C Hamano, Michael J Gruber, Duy Nguyen, git-for-windows, Git Mailing List [-- Attachment #1: Type: text/plain, Size: 919 bytes --] 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2016-08-25 13:58 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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).