* [RFD] On deprecating "git-foo" for builtins @ 2008-08-24 3:33 Junio C Hamano 2008-08-24 4:23 ` [kernel.org users] " Linus Torvalds ` (2 more replies) 0 siblings, 3 replies; 193+ messages in thread From: Junio C Hamano @ 2008-08-24 3:33 UTC (permalink / raw) To: git, users People seems to have quite strong negative feelings on the removal of dashed form "git-foo" commands from their $PATH. We have deprecated the dashed form in early 2006, and announced that 1.6.0 will remove them from $PATH in the 1.5.4 release notes, with instructions on how to update their scripts before 1.6.0 happens. Many people knew about this transition, but they didn't do anything about it. Since 2005, git has matured enough that majority of people are using it without building one themselves, without a chance to even read Release Notes. The pain was exacerbated partly because we tried to be too nice during the "deprecation" period, not to annoy people and not to break people's scripts. But that niceness backfired. Many people seem to argue now that we should have annoyed people by throwing loud deprecation notices to stderr when they typed "git-foo", and we should have risked breaking their scripts iff they relied on not seeing anything extra on the stderr. I am 50% sympathetic to them, while the remainder of me think that they can say that in retrospect only because they didn't actually got annoyed with such extra messages and they did not have to fix their scripts before the actual switch-over happened. If we did go the "annoy them early" route, I am sure they would have complained as loudly. That's all history now anyway. We should try to do better the next time, which is much more important, and that is the topic of this message. Now, we haven't set the timeframe yet, but the original plan, advocated by Linus and others, was to eventually stop installing "git-foo" form on the filesystem for builtin commands. If we were to do this, we should plan how the deprecation period for this change should look like. I think the sequence of events would look like this: (1) Declare that the dashed form are deprecated even in scripts that use "git --exec-path" the way 1.5.4 release notes suggested (it does not make sense to say "deprecated only for builtins", as the distinction between builtins and others are implementation details) and will be removed in 1.7.0; (2) Update git.c (the "git" wrapper) so that when the command is invoked in "git-foo" form for a builtin, issue messages to the standard error stream about the deprecation. Also, when the wrapper invokes an external "git-foo" command, it exports an environment variable (say, "GIT_WRAPPER_IS_RUNNING_YOU"); Update non-builtin commands and scripts to first check the environment variable, and otherwise issue the same deprecation message, and then unset the environment variable before continuing. (3) At 1.7.0, stop installing the hardlinks to builtin commands. There is one alternative, and one augmentation: (A) We do not do anything. (B) In addition to the main transition plan, outside git, prepare an optional "git-old-style" package that installs many "git-foo" wrappers in $PATH (i.e. /usr/bin). Each of them exec "git foo". People who like the dashed form can keep typing "git-foo", even though that will cost them two exec()s. I personally do not mind seeing dozens of git-foo commands in /usr/bin, did not have strong opinion on the transition we just did either way, but: * Alternative (A) does not logically make much sense. Now with 1.6.0, people are strongly encouraged to use "git foo" form already. * Variant (B) feels quite backwards and I think it will have a negative effect on our userbase in the longer term. People who train their fingers to say "git-foo" on machines with the "git-old-style" package will have hard time adjusting to working on machines without it. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-24 3:33 [RFD] On deprecating "git-foo" for builtins Junio C Hamano @ 2008-08-24 4:23 ` Linus Torvalds 2008-08-24 4:54 ` Imran M Yousuf 2008-08-24 8:40 ` Stefan Richter 2008-08-25 11:49 ` David Woodhouse 2 siblings, 1 reply; 193+ messages in thread From: Linus Torvalds @ 2008-08-24 4:23 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, users On Sat, 23 Aug 2008, Junio C Hamano wrote: > > There is one alternative, and one augmentation: > > (A) We do not do anything. > > (B) In addition to the main transition plan, outside git, prepare an > optional "git-old-style" package that installs many "git-foo" > wrappers in $PATH (i.e. /usr/bin). Each of them exec "git foo". > People who like the dashed form can keep typing "git-foo", even > though that will cost them two exec()s. I actually suspect that (A) is fine. I suggested removing the "git-xyzzy" hardlinks entirely, but that was just because I didn't think anybody wanted them. But given that with the 1.6.0 model you can always just do PATH="PATH:$(git --exec-path)" in your .bashrc or similar to get the git-xyzzy form, and given that clearly some people like using them, there's really no downside to keeping them. I _would_ suggest against putting them in /usr/bin, even as a "compatibility plan". Just expose them to people who want them, who can really quite easily do the above PATH setting. Linus ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-24 4:23 ` [kernel.org users] " Linus Torvalds @ 2008-08-24 4:54 ` Imran M Yousuf 0 siblings, 0 replies; 193+ messages in thread From: Imran M Yousuf @ 2008-08-24 4:54 UTC (permalink / raw) To: git, users; +Cc: Junio C Hamano, Linus Torvalds On Sun, Aug 24, 2008 at 10:23 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > On Sat, 23 Aug 2008, Junio C Hamano wrote: >> >> There is one alternative, and one augmentation: >> >> (A) We do not do anything. >> >> (B) In addition to the main transition plan, outside git, prepare an >> optional "git-old-style" package that installs many "git-foo" >> wrappers in $PATH (i.e. /usr/bin). Each of them exec "git foo". >> People who like the dashed form can keep typing "git-foo", even >> though that will cost them two exec()s. > > I actually suspect that (A) is fine. > > I suggested removing the "git-xyzzy" hardlinks entirely, but that was just > because I didn't think anybody wanted them. > > But given that with the 1.6.0 model you can always just do > > PATH="PATH:$(git --exec-path)" > If it is simple enough to get the git-abc commands by simply editing the PATH var then I would have to agree that (A) is the option I would prefer as well (not that I am as important as Linus though :)). I am also using the git-abc formats in some of my scripts but I would rather edit the PATH variable than to have then installed in /usr/bin (Not to mention that I will be update to 'git abc' as soon as I have time :)). > in your .bashrc or similar to get the git-xyzzy form, and given that > clearly some people like using them, there's really no downside to keeping > them. > > I _would_ suggest against putting them in /usr/bin, even as a > "compatibility plan". Just expose them to people who want them, who can > really quite easily do the above PATH setting. > > Linus > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Best regards -- Imran M Yousuf Email: imran@smartitengineering.com Blog: http://imyousuf-tech.blogs.smartitengineering.com/ Mobile: +880-1711402557 ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-24 3:33 [RFD] On deprecating "git-foo" for builtins Junio C Hamano 2008-08-24 4:23 ` [kernel.org users] " Linus Torvalds @ 2008-08-24 8:40 ` Stefan Richter 2008-08-25 11:49 ` David Woodhouse 2 siblings, 0 replies; 193+ messages in thread From: Stefan Richter @ 2008-08-24 8:40 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, users Junio C Hamano wrote: > People seems to have quite strong negative feelings on the removal of > dashed form "git-foo" commands from their $PATH. Some of them may appreciate git-completion.bash. On my box I found it named /usr/share/bash-completion/git. -- Stefan Richter -=====-==--- =--- ==--- http://arcgraph.de/sr/ ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-24 3:33 [RFD] On deprecating "git-foo" for builtins Junio C Hamano 2008-08-24 4:23 ` [kernel.org users] " Linus Torvalds 2008-08-24 8:40 ` Stefan Richter @ 2008-08-25 11:49 ` David Woodhouse 2008-08-25 12:17 ` Geert Uytterhoeven ` (4 more replies) 2 siblings, 5 replies; 193+ messages in thread From: David Woodhouse @ 2008-08-25 11:49 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, users On Sat, 2008-08-23 at 20:33 -0700, Junio C Hamano wrote: > > There is one alternative, and one augmentation: > > (A) We do not do anything. > > (B) In addition to the main transition plan, outside git, prepare an > optional "git-old-style" package that installs many "git-foo" > wrappers in $PATH (i.e. /usr/bin). Each of them exec "git foo". > People who like the dashed form can keep typing "git-foo", even > though that will cost them two exec()s. (C) Just don't do it. Leave the git-foo commands as they were. They weren't actually hurting anyone, and you don't actually _gain_ anything by removing them. For those occasional nutters who _really_ care about the size of /usr/bin, give them the _option_ of a 'make install' without installing the aliases. (Oh look, my /usr/bin has 3806 files in it. And except when I accidentally point the $%#@&! GNOME file dialog box at it, I don't _care_.) -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-25 11:49 ` David Woodhouse @ 2008-08-25 12:17 ` Geert Uytterhoeven 2008-08-25 12:43 ` Andi Kleen ` (3 subsequent siblings) 4 siblings, 0 replies; 193+ messages in thread From: Geert Uytterhoeven @ 2008-08-25 12:17 UTC (permalink / raw) To: David Woodhouse; +Cc: Junio C Hamano, git, users [-- Attachment #1: Type: TEXT/PLAIN, Size: 1541 bytes --] On Mon, 25 Aug 2008, David Woodhouse wrote: > On Sat, 2008-08-23 at 20:33 -0700, Junio C Hamano wrote: > > There is one alternative, and one augmentation: > > > > (A) We do not do anything. > > > > (B) In addition to the main transition plan, outside git, prepare an > > optional "git-old-style" package that installs many "git-foo" > > wrappers in $PATH (i.e. /usr/bin). Each of them exec "git foo". > > People who like the dashed form can keep typing "git-foo", even > > though that will cost them two exec()s. > > (C) Just don't do it. Leave the git-foo commands as they were. They > weren't actually hurting anyone, and you don't actually _gain_ > anything by removing them. For those occasional nutters who > _really_ care about the size of /usr/bin, give them the _option_ > of a 'make install' without installing the aliases. Acked-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> BTW, now we have man pages for deprecated commands that are not in the default PATH, which are showing examples for deprecated commands that are not in the default PATH? With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone: +32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: Geert.Uytterhoeven@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-25 11:49 ` David Woodhouse 2008-08-25 12:17 ` Geert Uytterhoeven @ 2008-08-25 12:43 ` Andi Kleen 2008-08-26 3:00 ` A Large Angry SCM 2008-08-25 13:22 ` Ben Collins ` (2 subsequent siblings) 4 siblings, 1 reply; 193+ messages in thread From: Andi Kleen @ 2008-08-25 12:43 UTC (permalink / raw) To: David Woodhouse; +Cc: Junio C Hamano, git, users > (C) Just don't do it. Leave the git-foo commands as they were. They > weren't actually hurting anyone, and you don't actually _gain_ > anything by removing them. For those occasional nutters who > _really_ care about the size of /usr/bin, give them the _option_ > of a 'make install' without installing the aliases. (Ca) Only leave the widely used commands in $PATH and remove the ones which are mostly used by internal scripts only. -Andi ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-25 12:43 ` Andi Kleen @ 2008-08-26 3:00 ` A Large Angry SCM 0 siblings, 0 replies; 193+ messages in thread From: A Large Angry SCM @ 2008-08-26 3:00 UTC (permalink / raw) To: Andi Kleen; +Cc: David Woodhouse, Junio C Hamano, git, users Andi Kleen wrote: >> (C) Just don't do it. Leave the git-foo commands as they were. They >> weren't actually hurting anyone, and you don't actually _gain_ >> anything by removing them. For those occasional nutters who >> _really_ care about the size of /usr/bin, give them the _option_ >> of a 'make install' without installing the aliases. > > (Ca) Only leave the widely used commands in $PATH and remove the ones > which are mostly used by internal scripts only. Please define what you mean by "widely used". I define it as "any git command I care use". ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-25 11:49 ` David Woodhouse 2008-08-25 12:17 ` Geert Uytterhoeven 2008-08-25 12:43 ` Andi Kleen @ 2008-08-25 13:22 ` Ben Collins 2008-08-25 14:38 ` Felipe Contreras 2008-08-25 18:19 ` Johannes Schindelin 2008-08-26 2:58 ` A Large Angry SCM 4 siblings, 1 reply; 193+ messages in thread From: Ben Collins @ 2008-08-25 13:22 UTC (permalink / raw) To: David Woodhouse; +Cc: Junio C Hamano, git, users David Woodhouse wrote: > On Sat, 2008-08-23 at 20:33 -0700, Junio C Hamano wrote: >> There is one alternative, and one augmentation: >> >> (A) We do not do anything. >> >> (B) In addition to the main transition plan, outside git, prepare an >> optional "git-old-style" package that installs many "git-foo" >> wrappers in $PATH (i.e. /usr/bin). Each of them exec "git foo". >> People who like the dashed form can keep typing "git-foo", even >> though that will cost them two exec()s. > > (C) Just don't do it. Leave the git-foo commands as they were. They > weren't actually hurting anyone, and you don't actually _gain_ > anything by removing them. For those occasional nutters who > _really_ care about the size of /usr/bin, give them the _option_ > of a 'make install' without installing the aliases. > > (Oh look, my /usr/bin has 3806 files in it. And except when I > accidentally point the $%#@&! GNOME file dialog box at it, I don't > _care_.) > I'll second that. I've not heard a good argument against the git-foo commands. If they were going to be deprecated, it should have actually happened a long time ago. -- BenC, late to the discussion as usual ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-25 13:22 ` Ben Collins @ 2008-08-25 14:38 ` Felipe Contreras 0 siblings, 0 replies; 193+ messages in thread From: Felipe Contreras @ 2008-08-25 14:38 UTC (permalink / raw) To: Ben Collins; +Cc: David Woodhouse, Junio C Hamano, git, users On Mon, Aug 25, 2008 at 4:22 PM, Ben Collins <ben.collins@canonical.com> wrote: > David Woodhouse wrote: >> >> On Sat, 2008-08-23 at 20:33 -0700, Junio C Hamano wrote: >>> >>> There is one alternative, and one augmentation: >>> >>> (A) We do not do anything. >>> >>> (B) In addition to the main transition plan, outside git, prepare an >>> optional "git-old-style" package that installs many "git-foo" >>> wrappers in $PATH (i.e. /usr/bin). Each of them exec "git foo". >>> People who like the dashed form can keep typing "git-foo", even >>> though that will cost them two exec()s. >> >> (C) Just don't do it. Leave the git-foo commands as they were. They >> weren't actually hurting anyone, and you don't actually _gain_ >> anything by removing them. For those occasional nutters who >> _really_ care about the size of /usr/bin, give them the _option_ >> of a 'make install' without installing the aliases. >> >> (Oh look, my /usr/bin has 3806 files in it. And except when I >> accidentally point the $%#@&! GNOME file dialog box at it, I don't >> _care_.) >> > > I'll second that. I've not heard a good argument against the git-foo > commands. If they were going to be deprecated, it should have actually > happened a long time ago. I personally like to use the git- format in written discussions regarding git stuff (git-status vs git status), and for man. I rarely do ls on /usr/bin, so I don't care if there are thousands of git-whatever files there (thought exec-path somehow feels right), but I can see how that could be an issue for people with minimal systems or in different platforms with no hardlinks (win32 on fat32). But in those cases aliases can be used: git-whatever -> "git whatever". So I agree, there's no valid reason to remove the git-whatever stuff, actually for documentation it does makes sense to me. Best regards. -- Felipe Contreras ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-25 11:49 ` David Woodhouse ` (2 preceding siblings ...) 2008-08-25 13:22 ` Ben Collins @ 2008-08-25 18:19 ` Johannes Schindelin 2008-08-25 23:41 ` Junio C Hamano 2008-08-26 2:58 ` A Large Angry SCM 4 siblings, 1 reply; 193+ messages in thread From: Johannes Schindelin @ 2008-08-25 18:19 UTC (permalink / raw) To: David Woodhouse; +Cc: Junio C Hamano, git, users Hi, On Mon, 25 Aug 2008, David Woodhouse wrote: > On Sat, 2008-08-23 at 20:33 -0700, Junio C Hamano wrote: > > > > There is one alternative, and one augmentation: > > > > (A) We do not do anything. > > > > (B) In addition to the main transition plan, outside git, prepare an > > optional "git-old-style" package that installs many "git-foo" > > wrappers in $PATH (i.e. /usr/bin). Each of them exec "git foo". > > People who like the dashed form can keep typing "git-foo", even > > though that will cost them two exec()s. > > (C) Just don't do it. Leave the git-foo commands as they were. They > weren't actually hurting anyone, and you don't actually _gain_ > anything by removing them. Umm. What exactly makes you feel you should ignore the discussions we had around the issues on the git and msysgit mailing list? Ciao, Dscho ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-25 18:19 ` Johannes Schindelin @ 2008-08-25 23:41 ` Junio C Hamano 2008-08-26 12:27 ` David Woodhouse 2008-08-26 14:57 ` Jeff King 0 siblings, 2 replies; 193+ messages in thread From: Junio C Hamano @ 2008-08-25 23:41 UTC (permalink / raw) To: Johannes Schindelin; +Cc: David Woodhouse, git, users Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > On Mon, 25 Aug 2008, David Woodhouse wrote: > >> On Sat, 2008-08-23 at 20:33 -0700, Junio C Hamano wrote: >> > >> > There is one alternative, and one augmentation: >> > >> > (A) We do not do anything. >> > >> > (B) In addition to the main transition plan, outside git, prepare an >> > optional "git-old-style" package that installs many "git-foo" >> > wrappers in $PATH (i.e. /usr/bin). Each of them exec "git foo". >> > People who like the dashed form can keep typing "git-foo", even >> > though that will cost them two exec()s. >> >> (C) Just don't do it. Leave the git-foo commands as they were. They >> weren't actually hurting anyone, and you don't actually _gain_ >> anything by removing them. > > Umm. What exactly makes you feel you should ignore the discussions we had > around the issues on the git and msysgit mailing list? Well, this was partly my fault, as I did not make it clear in this part that beating the horse that has been dead for two years is not a productive way to spend out time. I however did, in the part David did not quote, try to make it clear: That's all history now anyway. We should try to do better the next time, which is much more important, and that is the topic of this message. Now, we haven't set the timeframe yet, but the original plan, advocated by Linus and others, was to eventually stop installing "git-foo" form on the filesystem for builtin commands. If we were to do this, we should plan how the deprecation period for this change should look like. I think the sequence of events would look like this: that we are now talking about what we can do better from here going forward, but these paragraphs were separated from the quoted part that describes what kind of *variations* are possible in addition to the "the sequence of events would look like this:" list, and allowed David to make an out of context quoting that made a comment on an offtopic tangent look as if it were one of the valid alternatives. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-25 23:41 ` Junio C Hamano @ 2008-08-26 12:27 ` David Woodhouse 2008-08-26 14:57 ` Jeff King 1 sibling, 0 replies; 193+ messages in thread From: David Woodhouse @ 2008-08-26 12:27 UTC (permalink / raw) To: Junio C Hamano; +Cc: Johannes Schindelin, git, users On Mon, 2008-08-25 at 16:41 -0700, Junio C Hamano wrote: > Well, this was partly my fault, as I did not make it clear in this part > that beating the horse that has been dead for two years is not a > productive way to spend out time. I however did, in the part David did > not quote, try to make it clear: Do you have a reference to the previous discussion? In particular, any part of it where any _real_ benefits of breaking compatibility are given. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-25 23:41 ` Junio C Hamano 2008-08-26 12:27 ` David Woodhouse @ 2008-08-26 14:57 ` Jeff King 2008-08-26 15:34 ` Kristian Høgsberg 2008-08-26 20:39 ` Junio C Hamano 1 sibling, 2 replies; 193+ messages in thread From: Jeff King @ 2008-08-26 14:57 UTC (permalink / raw) To: Junio C Hamano; +Cc: Johannes Schindelin, David Woodhouse, git, users On Mon, Aug 25, 2008 at 04:41:57PM -0700, Junio C Hamano wrote: > > Umm. What exactly makes you feel you should ignore the discussions we had > > around the issues on the git and msysgit mailing list? > > Well, this was partly my fault, as I did not make it clear in this part > that beating the horse that has been dead for two years is not a > productive way to spend out time. I however did, in the part David did > not quote, try to make it clear: > > That's all history now anyway. We should try to do better the next time, > which is much more important, and that is the topic of this message. I don't want to stir up this discussion too much; I am sure you have many more important things to be working on. But I did want to make one observation. One side of the argument, I see a lot of "I would prefer it this way." And on the other side I see a lot of "this discussion is already history" and "but I do not care personally that much." It makes me wonder why nobody has said "no, really, I prefer it without the programs in /bin." Are they simply confident that the decision has been made, and don't feel the need to say something? I am just concerned that we are following a path that is not the best one because "it was decided" already, when perhaps: - the reasons for making that decision may have changed - the people interested in opposing that decision didn't speak up at the time, either because they weren't git users then, weren't as active in the mailing list, changed their minds, or were simply too lazy to read the release notes Again, I don't want to waste time (especially yours, Junio) with a discussion that is fruitless. But I also don't like to see "no, you are not allowed to bring fresh arguments to this decision". That precludes the possibility that the decision was wrong. Maybe the people who want to keep git-* can discuss amongst themselves (on the list, but the rest of us can ignore it) and present a concise argument why circumstances around this decision may have changed. -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 14:57 ` Jeff King @ 2008-08-26 15:34 ` Kristian Høgsberg 2008-08-26 15:59 ` David Woodhouse 2008-08-27 12:23 ` Krzysztof Halasa 2008-08-26 20:39 ` Junio C Hamano 1 sibling, 2 replies; 193+ messages in thread From: Kristian Høgsberg @ 2008-08-26 15:34 UTC (permalink / raw) To: Jeff King Cc: Junio C Hamano, Johannes Schindelin, David Woodhouse, git, users On Tue, 2008-08-26 at 10:57 -0400, Jeff King wrote: > On Mon, Aug 25, 2008 at 04:41:57PM -0700, Junio C Hamano wrote: > > > > Umm. What exactly makes you feel you should ignore the discussions we had > > > around the issues on the git and msysgit mailing list? > > > > Well, this was partly my fault, as I did not make it clear in this part > > that beating the horse that has been dead for two years is not a > > productive way to spend out time. I however did, in the part David did > > not quote, try to make it clear: > > > > That's all history now anyway. We should try to do better the next time, > > which is much more important, and that is the topic of this message. > > I don't want to stir up this discussion too much; I am sure you have > many more important things to be working on. But I did want to make one > observation. > > One side of the argument, I see a lot of "I would prefer it this way." > And on the other side I see a lot of "this discussion is already > history" and "but I do not care personally that much." > > It makes me wonder why nobody has said "no, really, I prefer it without > the programs in /bin." Are they simply confident that the decision has > been made, and don't feel the need to say something? It's pretty normal to see opponents of a decision like this complain loudly when it lands on their system, whereas the silent majority in favour will be happy to see the change finally implemented but reluctant to stir up the discussion again. I don't think new arguments are brought to the discussion, just new people, who are temporarily inconvened by a change towards sanity. Kristian ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 15:34 ` Kristian Høgsberg @ 2008-08-26 15:59 ` David Woodhouse 2008-08-26 16:04 ` Matthias Kestenholz ` (3 more replies) 2008-08-27 12:23 ` Krzysztof Halasa 1 sibling, 4 replies; 193+ messages in thread From: David Woodhouse @ 2008-08-26 15:59 UTC (permalink / raw) To: Kristian Høgsberg Cc: Jeff King, Junio C Hamano, Johannes Schindelin, git, users On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote: > It's pretty normal to see opponents of a decision like this complain > loudly when it lands on their system, whereas the silent majority in > favour will be happy to see the change finally implemented but reluctant > to stir up the discussion again. > > I don't think new arguments are brought to the discussion, just new > people, who are temporarily inconvened by a change towards sanity. Nice emotive response, especially the subtle but unsubstantiated 'silent majority in favour' bit -- but you forgot the part where you were supposed to actually point out a tangible benefit which is achieved by breaking compatibility like this. And no, reducing the size of /usr/bin by a tiny fraction isn't really a worthwhile benefit -- in reality, the 'silent majority' really couldn't give a monkey's left testicle about that, and breakage caused by the gratuitous change _far_ outweighs any minuscule improvement. It's particularly silly because we could have just made these aliases optional but present by default, so those few nutters who _really_ spend their days worrying about such stuff can do without them. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 15:59 ` David Woodhouse @ 2008-08-26 16:04 ` Matthias Kestenholz 2008-08-26 16:25 ` Petr Baudis 2008-08-26 16:17 ` Kristian Høgsberg ` (2 subsequent siblings) 3 siblings, 1 reply; 193+ messages in thread From: Matthias Kestenholz @ 2008-08-26 16:04 UTC (permalink / raw) To: David Woodhouse Cc: Kristian Høgsberg, Jeff King, Junio C Hamano, Johannes Schindelin, git, users On Tue, Aug 26, 2008 at 5:59 PM, David Woodhouse <dwmw2@infradead.org> wrote: > On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote: >> It's pretty normal to see opponents of a decision like this complain >> loudly when it lands on their system, whereas the silent majority in >> favour will be happy to see the change finally implemented but reluctant >> to stir up the discussion again. >> >> I don't think new arguments are brought to the discussion, just new >> people, who are temporarily inconvened by a change towards sanity. > > Nice emotive response, especially the subtle but unsubstantiated 'silent > majority in favour' bit -- but you forgot the part where you were > supposed to actually point out a tangible benefit which is achieved by > breaking compatibility like this. > > And no, reducing the size of /usr/bin by a tiny fraction isn't really a > worthwhile benefit -- in reality, the 'silent majority' really couldn't > give a monkey's left testicle about that, and breakage caused by the > gratuitous change _far_ outweighs any minuscule improvement. > Correct, but there is a benefit. Imagine a new user: git-<tab><tab> ... what? 140-something commands? I'll better start looking for alternatives _right now_! Having a cluttered namespace is never a good thing. It means that it's less obvious which commands you are supposed to use etc. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 16:04 ` Matthias Kestenholz @ 2008-08-26 16:25 ` Petr Baudis 2008-08-26 16:45 ` Andi Kleen 2008-08-26 17:07 ` Jeff King 0 siblings, 2 replies; 193+ messages in thread From: Petr Baudis @ 2008-08-26 16:25 UTC (permalink / raw) To: Matthias Kestenholz Cc: David Woodhouse, Kristian H??gsberg, Jeff King, Junio C Hamano, Johannes Schindelin, git, users On Tue, Aug 26, 2008 at 06:04:00PM +0200, Matthias Kestenholz wrote: > Correct, but there is a benefit. Imagine a new user: > > git-<tab><tab> ... what? 140-something commands? I'll better start looking > for alternatives _right now_! Actually, this is the only realistic argument I can remember at all. Are there any others? I couldn't come up with any - but I didn't do much history digging: others seem to be equally in dark, though. (And I'm not saying this one is not important; it's apparently a significant "P.R." issue. But is just this _the_ official rationale?) > Having a cluttered namespace is never a good thing. It means that it's > less obvious which commands you are supposed to use etc. This is not much of a valid argument; you could install the same set of commands to /usr/bin that you are offering in the bash autocompletion. (With the catch that this might break peoples scripts in a subtler way than just removing all of them.) -- Petr "Pasky" Baudis The next generation of interesting software will be done on the Macintosh, not the IBM PC. -- Bill Gates ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 16:25 ` Petr Baudis @ 2008-08-26 16:45 ` Andi Kleen 2008-08-26 17:04 ` Jeff King ` (3 more replies) 2008-08-26 17:07 ` Jeff King 1 sibling, 4 replies; 193+ messages in thread From: Andi Kleen @ 2008-08-26 16:45 UTC (permalink / raw) To: Petr Baudis Cc: Matthias Kestenholz, Kristian H??gsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git On Tue, Aug 26, 2008 at 06:25:13PM +0200, Petr Baudis wrote: > On Tue, Aug 26, 2008 at 06:04:00PM +0200, Matthias Kestenholz wrote: > > Correct, but there is a benefit. Imagine a new user: > > > > git-<tab><tab> ... what? 140-something commands? I'll better start looking > > for alternatives _right now_! > > Actually, this is the only realistic argument I can remember at all. It's not very convincing, because the bash completions script file for git is installed by default[1] which completes both forms, so the new user will experience instead: git<space><tab><tab>.... what? 140-something commands? etc.etc. Someone didn't think this through? I won't disagree that the 140 commands thing is a problem -- I remember thinking the same thoughts and I am still scared occasionally by the multitude of commands. But that doesn't seem to be the solution. -Andi [1] At least it's in my openSUSE build service git-core rpm by default. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 16:45 ` Andi Kleen @ 2008-08-26 17:04 ` Jeff King 2008-08-26 17:05 ` Linus Torvalds ` (2 subsequent siblings) 3 siblings, 0 replies; 193+ messages in thread From: Jeff King @ 2008-08-26 17:04 UTC (permalink / raw) To: Andi Kleen Cc: Petr Baudis, Matthias Kestenholz, Kristian H??gsberg, Johannes Schindelin, users, Junio C Hamano, David Woodhouse, git On Tue, Aug 26, 2008 at 06:45:26PM +0200, Andi Kleen wrote: > It's not very convincing, because the bash completions script file for git > is installed by default[1] which completes both forms, so the new user will > experience instead: > > git<space><tab><tab>.... what? 140-something commands? etc.etc. The bash completion has the luxury of not mentioning some commands if they are likely to be confusing (i.e., very low-level plumbing). That being said, it still produces 70-something commands. -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 16:45 ` Andi Kleen 2008-08-26 17:04 ` Jeff King @ 2008-08-26 17:05 ` Linus Torvalds 2008-08-26 17:27 ` Andi Kleen 2008-08-26 17:10 ` Petr Baudis 2008-08-27 6:00 ` Ulrich Windl 3 siblings, 1 reply; 193+ messages in thread From: Linus Torvalds @ 2008-08-26 17:05 UTC (permalink / raw) To: Andi Kleen Cc: Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git On Tue, 26 Aug 2008, Andi Kleen wrote: > > It's not very convincing, because the bash completions script file for git > is installed by default[1] which completes both forms, so the new user will > experience instead: > > git<space><tab><tab>.... what? 140-something commands? etc.etc. No. Your argument makes no sense. When you do ls<space><tab><tab> and it says Display all 122 possibilities? (y or n) (yeah, my home directory is a mess) do you really think "What? 120-something commands? etc etc". Hell no, you don't. There's a big difference between having the space and not having it, and anybody who argues otherwise is being dishonest. Linus ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 17:05 ` Linus Torvalds @ 2008-08-26 17:27 ` Andi Kleen 2008-08-27 6:04 ` Ulrich Windl 0 siblings, 1 reply; 193+ messages in thread From: Andi Kleen @ 2008-08-26 17:27 UTC (permalink / raw) To: Linus Torvalds Cc: Andi Kleen, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git > When you do > > ls<space><tab><tab> Actually do ls --<tab><tab> and you can well be scared too. Perhaps it's not quite git class yet, but it's working on it. I could imagine some Unix newbie be scared about that. ["Quick: mention the two characters not used as ls short options yet"] > > and it says > > Display all 122 possibilities? (y or n) > > (yeah, my home directory is a mess) It's quite tidy in fact :) % ls <tab><tab> Display all 584 possibilities? (y or n) > 120-something commands? etc etc". I was assuming someone thinking about using git. At some point they will do the git<space><tab><tab> thing and be scared away. Ok maybe it's not the first action, but it's likely in the first 10 minutes; more or less once they discover that git has sub commands. Anyways the real solution to that is either having less commands or hiding the internal ones better. I think both would be fine, but once that is done and there's a slimmed down non scary list, there's no reason to not put the remaining non internal ones back into $PATH isn't it? -Andi ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 17:27 ` Andi Kleen @ 2008-08-27 6:04 ` Ulrich Windl 0 siblings, 0 replies; 193+ messages in thread From: Ulrich Windl @ 2008-08-27 6:04 UTC (permalink / raw) To: Andi Kleen Cc: Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Jeff King, Andi Kleen, Petr Baudis, Junio C Hamano, David Woodhouse, git On 26 Aug 2008 at 19:27, Andi Kleen wrote: [...] > I was assuming someone thinking about using git. At some point > they will do the git<space><tab><tab> thing and be scared away. [...] Hi! Honestly I think, the user will type "git<ENTER>" first. Ulrich ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 16:45 ` Andi Kleen 2008-08-26 17:04 ` Jeff King 2008-08-26 17:05 ` Linus Torvalds @ 2008-08-26 17:10 ` Petr Baudis 2008-08-26 17:11 ` [PATCH] bash completion: Hide more plumbing commands Petr Baudis 2008-08-26 17:12 ` [kernel.org users] [RFD] On deprecating "git-foo" for builtins Shawn O. Pearce 2008-08-27 6:00 ` Ulrich Windl 3 siblings, 2 replies; 193+ messages in thread From: Petr Baudis @ 2008-08-26 17:10 UTC (permalink / raw) To: Andi Kleen Cc: Matthias Kestenholz, Kristian H??gsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git On Tue, Aug 26, 2008 at 06:45:26PM +0200, Andi Kleen wrote: > On Tue, Aug 26, 2008 at 06:25:13PM +0200, Petr Baudis wrote: > > On Tue, Aug 26, 2008 at 06:04:00PM +0200, Matthias Kestenholz wrote: > > > Correct, but there is a benefit. Imagine a new user: > > > > > > git-<tab><tab> ... what? 140-something commands? I'll better start looking > > > for alternatives _right now_! > > > > Actually, this is the only realistic argument I can remember at all. > > It's not very convincing, because the bash completions script file for git > is installed by default[1] which completes both forms, so the new user will > experience instead: > > git<space><tab><tab>.... what? 140-something commands? etc.etc. No, the point of course is that you should get much less. It offers 66 commands to me here, though it's still way too many - some of them are clearly plumbing: count-objects, ls-tree, checkout-index? Someone should submit a patch! ;-) (After eliminating these, this comes down to 56 commands - which is still a lot, but the numbers are getting somewhat sane already.) Petr "Pasky" Baudis ^ permalink raw reply [flat|nested] 193+ messages in thread
* [PATCH] bash completion: Hide more plumbing commands 2008-08-26 17:10 ` Petr Baudis @ 2008-08-26 17:11 ` Petr Baudis 2008-08-26 17:24 ` Shawn O. Pearce ` (2 more replies) 2008-08-26 17:12 ` [kernel.org users] [RFD] On deprecating "git-foo" for builtins Shawn O. Pearce 1 sibling, 3 replies; 193+ messages in thread From: Petr Baudis @ 2008-08-26 17:11 UTC (permalink / raw) To: git; +Cc: gitster, andi git <tab><tab> still shows way too many commands, some of them are clearly plumbing. This patch hides the plumbing commands liberally (that is, in special cases, users still might want to call one of the hidden commands, a *normal* workflow should never involve these, though - and if it does, we have a UI problem anyway). Signed-off-by: Petr Baudis <pasky@suse.cz> --- contrib/completion/git-completion.bash | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 89858c2..773d64b 100755 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -386,7 +386,9 @@ __git_porcelain_commands () cat-file) : plumbing;; check-attr) : plumbing;; check-ref-format) : plumbing;; + checkout-index) : plumbing;; commit-tree) : plumbing;; + count-objects) : plumbing;; cvsexportcommit) : export;; cvsimport) : import;; cvsserver) : daemon;; @@ -395,6 +397,7 @@ __git_porcelain_commands () diff-index) : plumbing;; diff-tree) : plumbing;; fast-import) : import;; + fast-export) : export;; fsck-objects) : plumbing;; fetch-pack) : plumbing;; fmt-merge-msg) : plumbing;; @@ -404,6 +407,10 @@ __git_porcelain_commands () index-pack) : plumbing;; init-db) : deprecated;; local-fetch) : plumbing;; + lost-found) : deprecated;; + ls-files) : plumbing;; + ls-remote) : plumbing;; + ls-tree) : plumbing;; mailinfo) : plumbing;; mailsplit) : plumbing;; merge-*) : plumbing;; @@ -428,6 +435,7 @@ __git_porcelain_commands () runstatus) : plumbing;; sh-setup) : internal;; shell) : daemon;; + show-ref) : plumbing;; send-pack) : plumbing;; show-index) : plumbing;; ssh-*) : transport;; @@ -442,6 +450,8 @@ __git_porcelain_commands () upload-archive) : plumbing;; upload-pack) : plumbing;; write-tree) : plumbing;; + var) : plumbing;; + verify-pack) : plumbing;; verify-tag) : plumbing;; *) echo $i;; esac ^ permalink raw reply related [flat|nested] 193+ messages in thread
* Re: [PATCH] bash completion: Hide more plumbing commands 2008-08-26 17:11 ` [PATCH] bash completion: Hide more plumbing commands Petr Baudis @ 2008-08-26 17:24 ` Shawn O. Pearce 2008-08-26 17:43 ` Jakub Narebski 2008-08-26 18:25 ` Junio C Hamano 2008-08-26 17:38 ` Jakub Narebski 2008-08-26 21:53 ` Matthieu Moy 2 siblings, 2 replies; 193+ messages in thread From: Shawn O. Pearce @ 2008-08-26 17:24 UTC (permalink / raw) To: Petr Baudis; +Cc: git, gitster, andi Petr Baudis <pasky@suse.cz> wrote: > git <tab><tab> still shows way too many commands, some of them > are clearly plumbing. This patch hides the plumbing commands > liberally (that is, in special cases, users still might want to > call one of the hidden commands, a *normal* workflow should never > involve these, though - and if it does, we have a UI problem anyway). > > Signed-off-by: Petr Baudis <pasky@suse.cz> Acked-by: Shawn O. Pearce <spearce@spearce.org> Though I use git ls-remote at least once every other day to see what branches are available on my egit/spearce.git fork. Its ok, I guess I can type a few extra characters... > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash > index 89858c2..773d64b 100755 > --- a/contrib/completion/git-completion.bash > +++ b/contrib/completion/git-completion.bash > @@ -386,7 +386,9 @@ __git_porcelain_commands () > cat-file) : plumbing;; > check-attr) : plumbing;; > check-ref-format) : plumbing;; > + checkout-index) : plumbing;; > commit-tree) : plumbing;; > + count-objects) : plumbing;; > cvsexportcommit) : export;; > cvsimport) : import;; > cvsserver) : daemon;; > @@ -395,6 +397,7 @@ __git_porcelain_commands () > diff-index) : plumbing;; > diff-tree) : plumbing;; > fast-import) : import;; > + fast-export) : export;; > fsck-objects) : plumbing;; > fetch-pack) : plumbing;; > fmt-merge-msg) : plumbing;; > @@ -404,6 +407,10 @@ __git_porcelain_commands () > index-pack) : plumbing;; > init-db) : deprecated;; > local-fetch) : plumbing;; > + lost-found) : deprecated;; > + ls-files) : plumbing;; > + ls-remote) : plumbing;; > + ls-tree) : plumbing;; > mailinfo) : plumbing;; > mailsplit) : plumbing;; > merge-*) : plumbing;; > @@ -428,6 +435,7 @@ __git_porcelain_commands () > runstatus) : plumbing;; > sh-setup) : internal;; > shell) : daemon;; > + show-ref) : plumbing;; > send-pack) : plumbing;; > show-index) : plumbing;; > ssh-*) : transport;; > @@ -442,6 +450,8 @@ __git_porcelain_commands () > upload-archive) : plumbing;; > upload-pack) : plumbing;; > write-tree) : plumbing;; > + var) : plumbing;; > + verify-pack) : plumbing;; > verify-tag) : plumbing;; > *) echo $i;; > esac -- Shawn. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [PATCH] bash completion: Hide more plumbing commands 2008-08-26 17:24 ` Shawn O. Pearce @ 2008-08-26 17:43 ` Jakub Narebski 2008-08-26 18:25 ` Junio C Hamano 1 sibling, 0 replies; 193+ messages in thread From: Jakub Narebski @ 2008-08-26 17:43 UTC (permalink / raw) To: Shawn O. Pearce; +Cc: Petr Baudis, git, gitster, andi "Shawn O. Pearce" <spearce@spearce.org> writes: > Petr Baudis <pasky@suse.cz> wrote: > > git <tab><tab> still shows way too many commands, some of them > > are clearly plumbing. This patch hides the plumbing commands > > liberally (that is, in special cases, users still might want to > > call one of the hidden commands, a *normal* workflow should never > > involve these, though - and if it does, we have a UI problem anyway). > > > > Signed-off-by: Petr Baudis <pasky@suse.cz> > > Acked-by: Shawn O. Pearce <spearce@spearce.org> > > Though I use git ls-remote at least once every other day to see > what branches are available on my egit/spearce.git fork. Its ok, > I guess I can type a few extra characters... One would think that one can use "git remote show <remote>" instead of "git ls-remote <remote>", but I'm not sure if it does show also _untracked_ remote branches. -- Jakub Narebski Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [PATCH] bash completion: Hide more plumbing commands 2008-08-26 17:24 ` Shawn O. Pearce 2008-08-26 17:43 ` Jakub Narebski @ 2008-08-26 18:25 ` Junio C Hamano 2008-08-26 18:27 ` Shawn O. Pearce ` (2 more replies) 1 sibling, 3 replies; 193+ messages in thread From: Junio C Hamano @ 2008-08-26 18:25 UTC (permalink / raw) To: Shawn O. Pearce; +Cc: Petr Baudis, git, gitster, andi "Shawn O. Pearce" <spearce@spearce.org> writes: > Petr Baudis <pasky@suse.cz> wrote: >> git <tab><tab> still shows way too many commands, some of them >> are clearly plumbing. This patch hides the plumbing commands >> liberally (that is, in special cases, users still might want to >> call one of the hidden commands, a *normal* workflow should never >> involve these, though - and if it does, we have a UI problem anyway). >> >> Signed-off-by: Petr Baudis <pasky@suse.cz> > > Acked-by: Shawn O. Pearce <spearce@spearce.org> > > Though I use git ls-remote at least once every other day to see > what branches are available on my egit/spearce.git fork. Its ok, > I guess I can type a few extra characters... Revision-requested-by: me Unless/until we have an easy way to obtain the information "git-ls-files -u" gives during conflict resolution, ls-files should stay on the list of commonly used commands. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [PATCH] bash completion: Hide more plumbing commands 2008-08-26 18:25 ` Junio C Hamano @ 2008-08-26 18:27 ` Shawn O. Pearce 2008-08-26 19:04 ` Daniel Barkalow 2008-09-03 22:23 ` Petr Baudis 2 siblings, 0 replies; 193+ messages in thread From: Shawn O. Pearce @ 2008-08-26 18:27 UTC (permalink / raw) To: Junio C Hamano; +Cc: Petr Baudis, git, andi Junio C Hamano <gitster@pobox.com> wrote: > "Shawn O. Pearce" <spearce@spearce.org> writes: > > > Petr Baudis <pasky@suse.cz> wrote: > >> git <tab><tab> still shows way too many commands, some of them > >> are clearly plumbing. This patch hides the plumbing commands > >> liberally (that is, in special cases, users still might want to > >> call one of the hidden commands, a *normal* workflow should never > >> involve these, though - and if it does, we have a UI problem anyway). > >> > >> Signed-off-by: Petr Baudis <pasky@suse.cz> > > > > Acked-by: Shawn O. Pearce <spearce@spearce.org> > > > > Though I use git ls-remote at least once every other day to see > > what branches are available on my egit/spearce.git fork. Its ok, > > I guess I can type a few extra characters... > > Revision-requested-by: me > > Unless/until we have an easy way to obtain the information "git-ls-files > -u" gives during conflict resolution, ls-files should stay on the list of > commonly used commands. Perhaps users should just do: git config --global alias.unmerged 'ls-files -u' ? Ok, well, maybe git.c should do that for you as a builtin. -- Shawn. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [PATCH] bash completion: Hide more plumbing commands 2008-08-26 18:25 ` Junio C Hamano 2008-08-26 18:27 ` Shawn O. Pearce @ 2008-08-26 19:04 ` Daniel Barkalow 2008-08-26 19:07 ` Shawn O. Pearce 2008-09-03 22:23 ` Petr Baudis 2 siblings, 1 reply; 193+ messages in thread From: Daniel Barkalow @ 2008-08-26 19:04 UTC (permalink / raw) To: Junio C Hamano; +Cc: Shawn O. Pearce, Petr Baudis, git, andi On Tue, 26 Aug 2008, Junio C Hamano wrote: > "Shawn O. Pearce" <spearce@spearce.org> writes: > > > Petr Baudis <pasky@suse.cz> wrote: > >> git <tab><tab> still shows way too many commands, some of them > >> are clearly plumbing. This patch hides the plumbing commands > >> liberally (that is, in special cases, users still might want to > >> call one of the hidden commands, a *normal* workflow should never > >> involve these, though - and if it does, we have a UI problem anyway). > >> > >> Signed-off-by: Petr Baudis <pasky@suse.cz> > > > > Acked-by: Shawn O. Pearce <spearce@spearce.org> > > > > Though I use git ls-remote at least once every other day to see > > what branches are available on my egit/spearce.git fork. Its ok, > > I guess I can type a few extra characters... > > Revision-requested-by: me > > Unless/until we have an easy way to obtain the information "git-ls-files > -u" gives during conflict resolution, ls-files should stay on the list of > commonly used commands. Doesn't "git status" tell you that? Or do you want the extra info from the implicit --stage? -Daniel *This .sig left intentionally blank* ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [PATCH] bash completion: Hide more plumbing commands 2008-08-26 19:04 ` Daniel Barkalow @ 2008-08-26 19:07 ` Shawn O. Pearce 2008-08-26 19:23 ` Daniel Barkalow 0 siblings, 1 reply; 193+ messages in thread From: Shawn O. Pearce @ 2008-08-26 19:07 UTC (permalink / raw) To: Daniel Barkalow; +Cc: Junio C Hamano, Petr Baudis, git, andi Daniel Barkalow <barkalow@iabervon.org> wrote: > On Tue, 26 Aug 2008, Junio C Hamano wrote: > > > > Unless/until we have an easy way to obtain the information "git-ls-files > > -u" gives during conflict resolution, ls-files should stay on the list of > > commonly used commands. > > Doesn't "git status" tell you that? Or do you want the extra info from the > implicit --stage? I think he doesn't want to see the other files that are already merged successfully. git status shows them, git ls-files -u does not. -- Shawn. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [PATCH] bash completion: Hide more plumbing commands 2008-08-26 19:07 ` Shawn O. Pearce @ 2008-08-26 19:23 ` Daniel Barkalow 0 siblings, 0 replies; 193+ messages in thread From: Daniel Barkalow @ 2008-08-26 19:23 UTC (permalink / raw) To: Shawn O. Pearce; +Cc: Junio C Hamano, Petr Baudis, git, andi On Tue, 26 Aug 2008, Shawn O. Pearce wrote: > Daniel Barkalow <barkalow@iabervon.org> wrote: > > On Tue, 26 Aug 2008, Junio C Hamano wrote: > > > > > > Unless/until we have an easy way to obtain the information "git-ls-files > > > -u" gives during conflict resolution, ls-files should stay on the list of > > > commonly used commands. > > > > Doesn't "git status" tell you that? Or do you want the extra info from the > > implicit --stage? > > I think he doesn't want to see the other files that are already > merged successfully. git status shows them, git ls-files -u > does not. I think it might make sense to support "git status --unmerged" or something like that, where it filters the output by the tags it would show. -Daniel *This .sig left intentionally blank* ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [PATCH] bash completion: Hide more plumbing commands 2008-08-26 18:25 ` Junio C Hamano 2008-08-26 18:27 ` Shawn O. Pearce 2008-08-26 19:04 ` Daniel Barkalow @ 2008-09-03 22:23 ` Petr Baudis 2008-09-03 22:31 ` Petr Baudis 2 siblings, 1 reply; 193+ messages in thread From: Petr Baudis @ 2008-09-03 22:23 UTC (permalink / raw) To: Junio C Hamano; +Cc: Shawn O. Pearce, git, andi On Tue, Aug 26, 2008 at 11:25:35AM -0700, Junio C Hamano wrote: > "Shawn O. Pearce" <spearce@spearce.org> writes: > > > Petr Baudis <pasky@suse.cz> wrote: > >> git <tab><tab> still shows way too many commands, some of them > >> are clearly plumbing. This patch hides the plumbing commands > >> liberally (that is, in special cases, users still might want to > >> call one of the hidden commands, a *normal* workflow should never > >> involve these, though - and if it does, we have a UI problem anyway). > >> > >> Signed-off-by: Petr Baudis <pasky@suse.cz> > > > > Acked-by: Shawn O. Pearce <spearce@spearce.org> > > > > Though I use git ls-remote at least once every other day to see > > what branches are available on my egit/spearce.git fork. Its ok, > > I guess I can type a few extra characters... > > Revision-requested-by: me > > Unless/until we have an easy way to obtain the information "git-ls-files > -u" gives during conflict resolution, ls-files should stay on the list of > commonly used commands. I started on a patch, but frankly, I hate it. Adding such a filtering to git-status is quite invasive, while I believe that it's simply not worth it - I have yet to encounter a situation with git when simply looking at either git diff or plain git status is impractical to check which files need to be merged yet, so I don't want to expend energy on a patch which is going to be ugly and useless by my belief. If you do insist that we need this functionality, can you please just drop the git ls-files bit from the patch, or should I resend it? Thanks, -- Petr "Pasky" Baudis The next generation of interesting software will be done on the Macintosh, not the IBM PC. -- Bill Gates ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [PATCH] bash completion: Hide more plumbing commands 2008-09-03 22:23 ` Petr Baudis @ 2008-09-03 22:31 ` Petr Baudis 0 siblings, 0 replies; 193+ messages in thread From: Petr Baudis @ 2008-09-03 22:31 UTC (permalink / raw) To: Junio C Hamano; +Cc: Shawn O. Pearce, git, andi On Thu, Sep 04, 2008 at 12:23:50AM +0200, Petr Baudis wrote: > I started on a patch, but frankly, I hate it. Adding such a filtering to > git-status is quite invasive, while I believe that it's simply not worth > it - I have yet to encounter a situation with git when simply looking at > either git diff or plain git status is impractical to check which files > need to be merged yet, so I don't want to expend energy on a patch which > is going to be ugly and useless by my belief. > > If you do insist that we need this functionality, can you please just > drop the git ls-files bit from the patch, or should I resend it? It just occured to me - what about git diff --diff-filter=U [--name-status] or is that too long? (The universal answer being, "you can alias it". ;-) Petr "Pasky" Baudis ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [PATCH] bash completion: Hide more plumbing commands 2008-08-26 17:11 ` [PATCH] bash completion: Hide more plumbing commands Petr Baudis 2008-08-26 17:24 ` Shawn O. Pearce @ 2008-08-26 17:38 ` Jakub Narebski 2008-09-03 17:56 ` Petr Baudis 2008-08-26 21:53 ` Matthieu Moy 2 siblings, 1 reply; 193+ messages in thread From: Jakub Narebski @ 2008-08-26 17:38 UTC (permalink / raw) To: Petr Baudis; +Cc: git, gitster, andi Petr Baudis <pasky@suse.cz> writes: > git <tab><tab> still shows way too many commands, some of them > are clearly plumbing. This patch hides the plumbing commands > liberally (that is, in special cases, users still might want to > call one of the hidden commands, a *normal* workflow should never > involve these, though - and if it does, we have a UI problem anyway). > > Signed-off-by: Petr Baudis <pasky@suse.cz> > --- > > contrib/completion/git-completion.bash | 10 ++++++++++ > 1 files changed, 10 insertions(+), 0 deletions(-) > > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash > index 89858c2..773d64b 100755 > --- a/contrib/completion/git-completion.bash > +++ b/contrib/completion/git-completion.bash > @@ -386,7 +386,9 @@ __git_porcelain_commands () > cat-file) : plumbing;; > check-attr) : plumbing;; > check-ref-format) : plumbing;; > + checkout-index) : plumbing;; Clearly plumbing. > commit-tree) : plumbing;; > + count-objects) : plumbing;; Plumbing (hyphenated name is a very good hint), but useful to decide when to repack. I'm partially to leaving it, as I use it from time to time from CLI. > cvsexportcommit) : export;; > cvsimport) : import;; > cvsserver) : daemon;; > @@ -395,6 +397,7 @@ __git_porcelain_commands () > diff-index) : plumbing;; > diff-tree) : plumbing;; > fast-import) : import;; > + fast-export) : export;; Good catch. BTW. both fast-import and fast-export are plumbing, in a sense that I don't see how they can be used from command line (well...) > fsck-objects) : plumbing;; > fetch-pack) : plumbing;; > fmt-merge-msg) : plumbing;; > @@ -404,6 +407,10 @@ __git_porcelain_commands () > index-pack) : plumbing;; > init-db) : deprecated;; > local-fetch) : plumbing;; > + lost-found) : deprecated;; True. > + ls-files) : plumbing;; IIRC it doesn't have porcelain equivalent. > + ls-remote) : plumbing;; "git remote show" is porcelain equivalent. > + ls-tree) : plumbing;; "git show" can be used instead. > mailinfo) : plumbing;; > mailsplit) : plumbing;; > merge-*) : plumbing;; > @@ -428,6 +435,7 @@ __git_porcelain_commands () > runstatus) : plumbing;; > sh-setup) : internal;; > shell) : daemon;; > + show-ref) : plumbing;; Clearly plumbing. > send-pack) : plumbing;; > show-index) : plumbing;; > ssh-*) : transport;; -- Jakub Narebski Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [PATCH] bash completion: Hide more plumbing commands 2008-08-26 17:38 ` Jakub Narebski @ 2008-09-03 17:56 ` Petr Baudis 2008-09-04 4:57 ` Junio C Hamano 0 siblings, 1 reply; 193+ messages in thread From: Petr Baudis @ 2008-09-03 17:56 UTC (permalink / raw) To: Jakub Narebski; +Cc: git, gitster, andi On Tue, Aug 26, 2008 at 10:38:45AM -0700, Jakub Narebski wrote: > Petr Baudis <pasky@suse.cz> writes: > > + count-objects) : plumbing;; > > Plumbing (hyphenated name is a very good hint), but useful to decide > when to repack. I'm partially to leaving it, as I use it from time to > time from CLI. Is this just residuum of customs developed before auto-gc was introduced? > > + ls-files) : plumbing;; > > IIRC it doesn't have porcelain equivalent. git status for the generally end-user-interesting functionality. Petr "Pasky" Baudis ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [PATCH] bash completion: Hide more plumbing commands 2008-09-03 17:56 ` Petr Baudis @ 2008-09-04 4:57 ` Junio C Hamano 0 siblings, 0 replies; 193+ messages in thread From: Junio C Hamano @ 2008-09-04 4:57 UTC (permalink / raw) To: Petr Baudis; +Cc: Jakub Narebski, git, gitster, andi Petr Baudis <pasky@suse.cz> writes: > On Tue, Aug 26, 2008 at 10:38:45AM -0700, Jakub Narebski wrote: >> Petr Baudis <pasky@suse.cz> writes: >> > + count-objects) : plumbing;; >> >> Plumbing (hyphenated name is a very good hint), but useful to decide >> when to repack. I'm partially to leaving it, as I use it from time to >> time from CLI. > > Is this just residuum of customs developed before auto-gc was > introduced? > >> > + ls-files) : plumbing;; >> >> IIRC it doesn't have porcelain equivalent. > > git status for the generally end-user-interesting functionality. I do not consider either of the above plumbing, but I tend to agree that they are much less frequently used. I think verify-pack falls into the same category. Applied to 'maint' but won't be pushing out for some time (my git day is over). ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [PATCH] bash completion: Hide more plumbing commands 2008-08-26 17:11 ` [PATCH] bash completion: Hide more plumbing commands Petr Baudis 2008-08-26 17:24 ` Shawn O. Pearce 2008-08-26 17:38 ` Jakub Narebski @ 2008-08-26 21:53 ` Matthieu Moy 2008-08-27 9:09 ` Karl Hasselström 2 siblings, 1 reply; 193+ messages in thread From: Matthieu Moy @ 2008-08-26 21:53 UTC (permalink / raw) To: Petr Baudis; +Cc: git, gitster, andi Petr Baudis <pasky@suse.cz> writes: > git <tab><tab> still shows way too many commands, some of them > are clearly plumbing. This patch hides the plumbing commands > liberally (that is, in special cases, users still might want to > call one of the hidden commands, a *normal* workflow should never > involve these, though - and if it does, we have a UI problem anyway). Is it possible to have the completion not show them by default, but fall back to them if no other completion is found? -- Matthieu ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [PATCH] bash completion: Hide more plumbing commands 2008-08-26 21:53 ` Matthieu Moy @ 2008-08-27 9:09 ` Karl Hasselström 0 siblings, 0 replies; 193+ messages in thread From: Karl Hasselström @ 2008-08-27 9:09 UTC (permalink / raw) To: Matthieu Moy; +Cc: Petr Baudis, git, gitster, andi On 2008-08-26 23:53:40 +0200, Matthieu Moy wrote: > Petr Baudis <pasky@suse.cz> writes: > > > git <tab><tab> still shows way too many commands, some of them are > > clearly plumbing. > > Is it possible to have the completion not show them by default, but > fall back to them if no other completion is found? I don't know if it's possible, but it sounds like a great idea. -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 17:10 ` Petr Baudis 2008-08-26 17:11 ` [PATCH] bash completion: Hide more plumbing commands Petr Baudis @ 2008-08-26 17:12 ` Shawn O. Pearce 2008-08-26 17:16 ` Jeff King 1 sibling, 1 reply; 193+ messages in thread From: Shawn O. Pearce @ 2008-08-26 17:12 UTC (permalink / raw) To: Petr Baudis Cc: Andi Kleen, Matthias Kestenholz, Kristian H??gsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git Petr Baudis <pasky@suse.cz> wrote: > On Tue, Aug 26, 2008 at 06:45:26PM +0200, Andi Kleen wrote: > > > > It's not very convincing, because the bash completions script file for git > > is installed by default[1] which completes both forms, so the new user will > > experience instead: > > > > git<space><tab><tab>.... what? 140-something commands? etc.etc. > > No, the point of course is that you should get much less. > > It offers 66 commands to me here, though it's still way too many - some > of them are clearly plumbing: count-objects, ls-tree, checkout-index? > Someone should submit a patch! ;-) (After eliminating these, this comes > down to 56 commands - which is still a lot, but the numbers are getting > somewhat sane already.) I'm the reason why count-objects, ls-tree and checkout-index are still offered by the bash completion. And sitting here reading your email I realized its been _months_ since I last called checkout-index by hand. I still run count-objects and ls-tree very so often, but the average user probably doesn't use ls-tree. So yea, these probably should be removed from the completion list. But I can make a weak argument for keeping count-objects. -- Shawn. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 17:12 ` [kernel.org users] [RFD] On deprecating "git-foo" for builtins Shawn O. Pearce @ 2008-08-26 17:16 ` Jeff King 2008-08-26 17:47 ` Nguyen Thai Ngoc Duy 2008-08-26 21:06 ` Willy Tarreau 0 siblings, 2 replies; 193+ messages in thread From: Jeff King @ 2008-08-26 17:16 UTC (permalink / raw) To: Shawn O. Pearce Cc: Petr Baudis, Andi Kleen, Matthias Kestenholz, Kristian H??gsberg, Johannes Schindelin, users, Junio C Hamano, David Woodhouse, git On Tue, Aug 26, 2008 at 10:12:55AM -0700, Shawn O. Pearce wrote: > I'm the reason why count-objects, ls-tree and checkout-index are > still offered by the bash completion. And sitting here reading your > email I realized its been _months_ since I last called checkout-index > by hand. I still run count-objects and ls-tree very so often, but the > average user probably doesn't use ls-tree. > > So yea, these probably should be removed from the completion list. > But I can make a weak argument for keeping count-objects. I think this message shows the conflict in setting up such a list. We want the command set to be as tiny as possible to help new users find their way. But we want the command set to be useful to git power users. I wonder if there should be multiple sets of commands for completion, with a minimal set enabled by default, and a "power user" set that exposes extra commands. I dunno. Maybe that is overengineering. I don't even use the bash completion at all. -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 17:16 ` Jeff King @ 2008-08-26 17:47 ` Nguyen Thai Ngoc Duy 2008-08-26 21:06 ` Willy Tarreau 1 sibling, 0 replies; 193+ messages in thread From: Nguyen Thai Ngoc Duy @ 2008-08-26 17:47 UTC (permalink / raw) To: Jeff King Cc: Shawn O. Pearce, Petr Baudis, Andi Kleen, Matthias Kestenholz, Kristian H??gsberg, Johannes Schindelin, users, Junio C Hamano, David Woodhouse, git On 8/27/08, Jeff King <peff@peff.net> wrote: > On Tue, Aug 26, 2008 at 10:12:55AM -0700, Shawn O. Pearce wrote: > > > I'm the reason why count-objects, ls-tree and checkout-index are > > still offered by the bash completion. And sitting here reading your > > email I realized its been _months_ since I last called checkout-index > > by hand. I still run count-objects and ls-tree very so often, but the > > average user probably doesn't use ls-tree. > > > > So yea, these probably should be removed from the completion list. > > But I can make a weak argument for keeping count-objects. > > > I think this message shows the conflict in setting up such a list. We > want the command set to be as tiny as possible to help new users find > their way. But we want the command set to be useful to git power users. > > I wonder if there should be multiple sets of commands for completion, > with a minimal set enabled by default, and a "power user" set that > exposes extra commands. I dunno. Maybe that is overengineering. I don't > even use the bash completion at all. How about providing a standard set of aliases? All other SCMs I know do it. You can type it short/quick without depending on bash. -- Duy ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 17:16 ` Jeff King 2008-08-26 17:47 ` Nguyen Thai Ngoc Duy @ 2008-08-26 21:06 ` Willy Tarreau 2008-08-27 20:24 ` Jeff Garzik 1 sibling, 1 reply; 193+ messages in thread From: Willy Tarreau @ 2008-08-26 21:06 UTC (permalink / raw) To: Jeff King Cc: Shawn O. Pearce, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Andi Kleen, Petr Baudis, Junio C Hamano, David Woodhouse, git On Tue, Aug 26, 2008 at 01:16:24PM -0400, Jeff King wrote: > On Tue, Aug 26, 2008 at 10:12:55AM -0700, Shawn O. Pearce wrote: > > > I'm the reason why count-objects, ls-tree and checkout-index are > > still offered by the bash completion. And sitting here reading your > > email I realized its been _months_ since I last called checkout-index > > by hand. I still run count-objects and ls-tree very so often, but the > > average user probably doesn't use ls-tree. > > > > So yea, these probably should be removed from the completion list. > > But I can make a weak argument for keeping count-objects. > > I think this message shows the conflict in setting up such a list. We > want the command set to be as tiny as possible to help new users find > their way. But we want the command set to be useful to git power users. > > I wonder if there should be multiple sets of commands for completion, > with a minimal set enabled by default, and a "power user" set that > exposes extra commands. I dunno. Maybe that is overengineering. I don't > even use the bash completion at all. The problem is not caused by the number of commands, but by their complexity. I need completion because it's hard to type their very long names without making mistakes (not counting the long options). "git am" is fine with me, but "git format-patch" is quite boring to type. It's also interesting to note that short names are currently in place for less commonly used commands : git-rm, git-mv, git-gc. Willy ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 21:06 ` Willy Tarreau @ 2008-08-27 20:24 ` Jeff Garzik 2008-08-27 20:27 ` Jeff King 2008-08-27 20:50 ` Linus Torvalds 0 siblings, 2 replies; 193+ messages in thread From: Jeff Garzik @ 2008-08-27 20:24 UTC (permalink / raw) To: Willy Tarreau Cc: Jeff King, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Andi Kleen, Petr Baudis, Junio C Hamano, David Woodhouse, git, Shawn O. Pearce Willy Tarreau wrote: > The problem is not caused by the number of commands, but by their > complexity. I need completion because it's hard to type their very > long names without making mistakes (not counting the long options). > "git am" is fine with me, but "git format-patch" is quite boring to > type. It's also interesting to note that short names are currently > in place for less commonly used commands : git-rm, git-mv, git-gc. Indeed. Also, I type "git-diff-tree" quite a lot. My fingers find that git SPACE diff DASH tree is slower and less consistent than git DASH diff DASH tree The same with git-format-patch... We are going from "all dashes" to "a mix of space and dashes" which is increasing inconsistency. Jeff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 20:24 ` Jeff Garzik @ 2008-08-27 20:27 ` Jeff King 2008-08-27 20:38 ` Jeff Garzik 2008-08-27 20:50 ` Linus Torvalds 1 sibling, 1 reply; 193+ messages in thread From: Jeff King @ 2008-08-27 20:27 UTC (permalink / raw) To: Jeff Garzik Cc: Willy Tarreau, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Andi Kleen, Petr Baudis, Junio C Hamano, David Woodhouse, git, Shawn O. Pearce On Wed, Aug 27, 2008 at 04:24:19PM -0400, Jeff Garzik wrote: > Indeed. > > Also, I type "git-diff-tree" quite a lot. > > My fingers find that > > git SPACE diff DASH tree > > is slower and less consistent than > > git DASH diff DASH tree > > The same with git-format-patch... We are going from "all dashes" to "a > mix of space and dashes" which is increasing inconsistency. I have also found the SPACE-DASH slightly harder to type. However, I'm curious: what are you doing frequently from the commandline with git-diff-tree that is not just as easily done with git-diff? -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 20:27 ` Jeff King @ 2008-08-27 20:38 ` Jeff Garzik 2008-08-27 20:53 ` Jeff King ` (3 more replies) 0 siblings, 4 replies; 193+ messages in thread From: Jeff Garzik @ 2008-08-27 20:38 UTC (permalink / raw) To: Jeff King Cc: Willy Tarreau, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Andi Kleen, Petr Baudis, Junio C Hamano, David Woodhouse, git, Shawn O. Pearce Jeff King wrote: > On Wed, Aug 27, 2008 at 04:24:19PM -0400, Jeff Garzik wrote: > >> Indeed. >> >> Also, I type "git-diff-tree" quite a lot. >> >> My fingers find that >> >> git SPACE diff DASH tree >> >> is slower and less consistent than >> >> git DASH diff DASH tree >> >> The same with git-format-patch... We are going from "all dashes" to "a >> mix of space and dashes" which is increasing inconsistency. > > I have also found the SPACE-DASH slightly harder to type. However, I'm > curious: what are you doing frequently from the commandline with > git-diff-tree that is not just as easily done with git-diff? I use it to spit out a patch for a specific commit: git-diff-tree -p $COMMIT Though probably someone will now come along and tell me I'm am old-timer, and there is a shorter command that accomplishes the same thing :) Regards, Jeff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 20:38 ` Jeff Garzik @ 2008-08-27 20:53 ` Jeff King 2008-08-27 21:05 ` Matthew Wilcox ` (2 subsequent siblings) 3 siblings, 0 replies; 193+ messages in thread From: Jeff King @ 2008-08-27 20:53 UTC (permalink / raw) To: Jeff Garzik Cc: Willy Tarreau, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Andi Kleen, Petr Baudis, Junio C Hamano, David Woodhouse, git, Shawn O. Pearce On Wed, Aug 27, 2008 at 04:38:13PM -0400, Jeff Garzik wrote: > I use it to spit out a patch for a specific commit: > > git-diff-tree -p $COMMIT > > Though probably someone will now come along and tell me I'm am old-timer, > and there is a shorter command that accomplishes the same thing :) Actually, that is something that diff-tree does better (a single tree-ish with git-diff is "compare against working tree"). To do it with git-diff you would have to use the obscure (and not very shell-friendly) syntax: git diff $COMMIT^! Although interactively, I tend to use "git show" for this purpose, though perhaps you intentionally don't want to see the commit message. Anyway, thank you for satisfying my curiosity. -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 20:38 ` Jeff Garzik 2008-08-27 20:53 ` Jeff King @ 2008-08-27 21:05 ` Matthew Wilcox 2008-08-27 21:13 ` Adrian Bunk 2008-08-27 21:23 ` Linus Torvalds 2008-08-28 5:43 ` Mike Hommey 3 siblings, 1 reply; 193+ messages in thread From: Matthew Wilcox @ 2008-08-27 21:05 UTC (permalink / raw) To: Jeff Garzik Cc: Jeff King, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Andi Kleen, Petr Baudis, Junio C Hamano, David Woodhouse, Willy Tarreau, git, Shawn O. Pearce On Wed, Aug 27, 2008 at 04:38:13PM -0400, Jeff Garzik wrote: > I use it to spit out a patch for a specific commit: > > git-diff-tree -p $COMMIT > > Though probably someone will now come along and tell me I'm am > old-timer, and there is a shorter command that accomplishes the same > thing :) git-show -p $COMMIT ? It also gives you the commit message, but that's not a hardship usually ... -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 21:05 ` Matthew Wilcox @ 2008-08-27 21:13 ` Adrian Bunk 2008-08-27 21:22 ` Jeff King 0 siblings, 1 reply; 193+ messages in thread From: Adrian Bunk @ 2008-08-27 21:13 UTC (permalink / raw) To: Matthew Wilcox Cc: Jeff Garzik, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Jeff King, Andi Kleen, Petr Baudis, Junio C Hamano, David Woodhouse, Willy Tarreau, git, Shawn O. Pearce On Wed, Aug 27, 2008 at 03:05:56PM -0600, Matthew Wilcox wrote: > On Wed, Aug 27, 2008 at 04:38:13PM -0400, Jeff Garzik wrote: > > I use it to spit out a patch for a specific commit: > > > > git-diff-tree -p $COMMIT > > > > Though probably someone will now come along and tell me I'm am > > old-timer, and there is a shorter command that accomplishes the same > > thing :) > > git-show -p $COMMIT ? > > It also gives you the commit message, but that's not a hardship usually > ... I'm usually using git-show --pretty=oneline $COMMIT cu Adrian BTW: I'd love to get a --pretty=noline -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 21:13 ` Adrian Bunk @ 2008-08-27 21:22 ` Jeff King 2008-08-27 22:29 ` Adrian Bunk 0 siblings, 1 reply; 193+ messages in thread From: Jeff King @ 2008-08-27 21:22 UTC (permalink / raw) To: Adrian Bunk Cc: Matthew Wilcox, Jeff Garzik, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Andi Kleen, Petr Baudis, Junio C Hamano, David Woodhouse, Willy Tarreau, git, Shawn O. Pearce On Thu, Aug 28, 2008 at 12:13:26AM +0300, Adrian Bunk wrote: > BTW: I'd love to get a --pretty=noline How about --pretty=format: ? -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 21:22 ` Jeff King @ 2008-08-27 22:29 ` Adrian Bunk 0 siblings, 0 replies; 193+ messages in thread From: Adrian Bunk @ 2008-08-27 22:29 UTC (permalink / raw) To: Jeff King Cc: Matthew Wilcox, Jeff Garzik, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Andi Kleen, Petr Baudis, Junio C Hamano, David Woodhouse, Willy Tarreau, git, Shawn O. Pearce On Wed, Aug 27, 2008 at 05:22:17PM -0400, Jeff King wrote: > On Thu, Aug 28, 2008 at 12:13:26AM +0300, Adrian Bunk wrote: > > > BTW: I'd love to get a --pretty=noline > > How about --pretty=format: ? Thanks, that does the trick. :-) > -Peff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 20:38 ` Jeff Garzik 2008-08-27 20:53 ` Jeff King 2008-08-27 21:05 ` Matthew Wilcox @ 2008-08-27 21:23 ` Linus Torvalds 2008-08-27 23:49 ` Jeff Garzik 2008-08-28 5:43 ` Mike Hommey 3 siblings, 1 reply; 193+ messages in thread From: Linus Torvalds @ 2008-08-27 21:23 UTC (permalink / raw) To: Jeff Garzik Cc: Jeff King, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Andi Kleen, Petr Baudis, Junio C Hamano, David Woodhouse, Willy Tarreau, git, Shawn O. Pearce On Wed, 27 Aug 2008, Jeff Garzik wrote: > > I use it to spit out a patch for a specific commit: > > git-diff-tree -p $COMMIT Use git show $COMMIT instead, which is shorter and gives you the log too, and uses a pager by default. And defaults to HEAD, so you don't even need to say $COMMIT if you want to see the top one. IOW, much nicer is so many ways. Yeah, the "much nicer" obviously does mean "different". If you _rely_ on the fact that you don't get a pager (you just want to scroll youself), or you really don't want to see what the commit message was all about, then 'git diff-tree' is obviously "better". But at least personally, I really don't know when I last wanted to have anything else than 'git show' for showing a commit. Linus ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 21:23 ` Linus Torvalds @ 2008-08-27 23:49 ` Jeff Garzik 2008-08-28 6:51 ` Ingo Molnar 0 siblings, 1 reply; 193+ messages in thread From: Jeff Garzik @ 2008-08-27 23:49 UTC (permalink / raw) To: Linus Torvalds Cc: Jeff King, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Andi Kleen, Petr Baudis, Junio C Hamano, David Woodhouse, Willy Tarreau, git, Shawn O. Pearce Linus Torvalds wrote: > > On Wed, 27 Aug 2008, Jeff Garzik wrote: >> I use it to spit out a patch for a specific commit: >> >> git-diff-tree -p $COMMIT > > Use > > git show $COMMIT > > instead, which is shorter and gives you the log too, and uses a pager by > default. And defaults to HEAD, so you don't even need to say $COMMIT if > you want to see the top one. IOW, much nicer is so many ways. > > Yeah, the "much nicer" obviously does mean "different". If you _rely_ on > the fact that you don't get a pager (you just want to scroll youself), or > you really don't want to see what the commit message was all about, then > 'git diff-tree' is obviously "better". 'git show' is quite sufficient, as long as I can pipe its output into patch(1) or write it to a foo.patch file, which appears to be the case. git-diff-tree -p was from the old days; I readily admit being a git old-timer :) Anything that reduces my typing is great, and 'git show' is certainly an improvement in that regard. Jeff, typing with a sprained finger (puppies can be a handful) ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 23:49 ` Jeff Garzik @ 2008-08-28 6:51 ` Ingo Molnar 2008-08-28 7:46 ` git-show vs git-log (or: git show vs git log) Dominik Brodowski 2008-08-28 14:44 ` [kernel.org users] [RFD] On deprecating "git-foo" for builtins Alex Riesen 0 siblings, 2 replies; 193+ messages in thread From: Ingo Molnar @ 2008-08-28 6:51 UTC (permalink / raw) To: Jeff Garzik Cc: Linus Torvalds, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Jeff King, Andi Kleen, Petr Baudis, Junio C Hamano, David Woodhouse, Willy Tarreau, git, Shawn O. Pearce * Jeff Garzik <jgarzik@pobox.com> wrote: > > Yeah, the "much nicer" obviously does mean "different". If you > > _rely_ on the fact that you don't get a pager (you just want to > > scroll youself), or you really don't want to see what the commit > > message was all about, then 'git diff-tree' is obviously "better". > > 'git show' is quite sufficient, as long as I can pipe its output into > patch(1) or write it to a foo.patch file, which appears to be the > case. the only time git show is not sufficient for me in practice, the following one is: git log --pretty=email -p -1 that's when i want to do precise import/export of patches from/to email. (but it's rare) Ingo ^ permalink raw reply [flat|nested] 193+ messages in thread
* git-show vs git-log (or: git show vs git log) 2008-08-28 6:51 ` Ingo Molnar @ 2008-08-28 7:46 ` Dominik Brodowski 2008-08-28 14:44 ` [kernel.org users] [RFD] On deprecating "git-foo" for builtins Alex Riesen 1 sibling, 0 replies; 193+ messages in thread From: Dominik Brodowski @ 2008-08-28 7:46 UTC (permalink / raw) To: Ingo Molnar Cc: Jeff Garzik, Kristian H??gsberg, David Woodhouse, Matthias Kestenholz, Johannes Schindelin, users, Jeff King, Andi Kleen, Petr Baudis, Junio C Hamano, Linus Torvalds, Willy Tarreau, git, Shawn O. Pearce On Thu, Aug 28, 2008 at 08:51:24AM +0200, Ingo Molnar wrote: > > 'git show' is quite sufficient, as long as I can pipe its output into > > patch(1) or write it to a foo.patch file, which appears to be the > > case. > > the only time git show is not sufficient for me in practice, the > following one is: > > git log --pretty=email -p -1 > > that's when i want to do precise import/export of patches from/to email. > (but it's rare) git show --pretty=email Best, Dominik ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 6:51 ` Ingo Molnar 2008-08-28 7:46 ` git-show vs git-log (or: git show vs git log) Dominik Brodowski @ 2008-08-28 14:44 ` Alex Riesen 1 sibling, 0 replies; 193+ messages in thread From: Alex Riesen @ 2008-08-28 14:44 UTC (permalink / raw) To: Ingo Molnar Cc: Jeff Garzik, Linus Torvalds, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Jeff King, Andi Kleen, Petr Baudis, Junio C Hamano, David Woodhouse, Willy Tarreau, git, Shawn O. Pearce 2008/8/28 Ingo Molnar <mingo@elte.hu>: > * Jeff Garzik <jgarzik@pobox.com> wrote: >> >> 'git show' is quite sufficient, as long as I can pipe its output into >> patch(1) or write it to a foo.patch file, which appears to be the >> case. > > the only time git show is not sufficient for me in practice, the > following one is: > > git log --pretty=email -p -1 > "git show --pretty=email", indeed 8-) > that's when i want to do precise import/export of patches from/to email. > (but it's rare) But it does not export them "precisely". You get no patch for merges (even if there were changes). Try using "git format-patch --stdout" (or with "-o <directory>" instead of "--stdout", to split in patches). ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 20:38 ` Jeff Garzik ` (2 preceding siblings ...) 2008-08-27 21:23 ` Linus Torvalds @ 2008-08-28 5:43 ` Mike Hommey 3 siblings, 0 replies; 193+ messages in thread From: Mike Hommey @ 2008-08-28 5:43 UTC (permalink / raw) To: Jeff Garzik Cc: Jeff King, Willy Tarreau, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Andi Kleen, Petr Baudis, Junio C Hamano, David Woodhouse, git, Shawn O. Pearce On Wed, Aug 27, 2008 at 04:38:13PM -0400, Jeff Garzik wrote: > Jeff King wrote: >> On Wed, Aug 27, 2008 at 04:24:19PM -0400, Jeff Garzik wrote: >> >>> Indeed. >>> >>> Also, I type "git-diff-tree" quite a lot. >>> >>> My fingers find that >>> >>> git SPACE diff DASH tree >>> >>> is slower and less consistent than >>> >>> git DASH diff DASH tree >>> >>> The same with git-format-patch... We are going from "all dashes" to >>> "a mix of space and dashes" which is increasing inconsistency. >> >> I have also found the SPACE-DASH slightly harder to type. However, I'm >> curious: what are you doing frequently from the commandline with >> git-diff-tree that is not just as easily done with git-diff? > > I use it to spit out a patch for a specific commit: > > git-diff-tree -p $COMMIT > > Though probably someone will now come along and tell me I'm am > old-timer, and there is a shorter command that accomplishes the same > thing :) Other than why you use git diff-tree so much, why don't you set 2 letters aliases for your most commonly used commands ? [alias] st = status co = checkout fp = format-patch dt = diff-tree etc. Mike ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 20:24 ` Jeff Garzik 2008-08-27 20:27 ` Jeff King @ 2008-08-27 20:50 ` Linus Torvalds 1 sibling, 0 replies; 193+ messages in thread From: Linus Torvalds @ 2008-08-27 20:50 UTC (permalink / raw) To: Jeff Garzik Cc: Willy Tarreau, Jeff King, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Andi Kleen, Petr Baudis, Junio C Hamano, David Woodhouse, git, Shawn O. Pearce On Wed, 27 Aug 2008, Jeff Garzik wrote: > > Also, I type "git-diff-tree" quite a lot. Why? I'd suggest you just type "git diff" (if you diff two trees) or "git show" (if you want to see just one commit) instead. There is _no_ reason to use diff-tree, it's purely a historical command due to how the implementation was done (ie diffing two trees is a very different operation from diffing against the index when looked at from an implementation standpoint). Linus ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 16:45 ` Andi Kleen ` (2 preceding siblings ...) 2008-08-26 17:10 ` Petr Baudis @ 2008-08-27 6:00 ` Ulrich Windl 2008-08-27 7:59 ` H. Peter Anvin ` (2 more replies) 3 siblings, 3 replies; 193+ messages in thread From: Ulrich Windl @ 2008-08-27 6:00 UTC (permalink / raw) To: Andi Kleen Cc: Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git On 26 Aug 2008 at 18:45, Andi Kleen wrote: > git<space><tab><tab>.... what? 140-something commands? etc.etc. > Hi! Just let me throw in one thought: Whether files in /usr/bin, or command completions: Long linear lists are a thing humans don't like. For the directory issue, one could (assuming a two-level hierarchy) take the square root of the number of binaries and create that many directories to put the files in (in theory). Likewise for git<TAB><TAB> one could deduce the list by making two levels out of one (i.e. sub-sommands). In HP-UX many commands (or "subsystems") use /opt/<subsys>/{bin,sbin} to place their binaries. PATH usually does not contain all of them. That's against Linux philosophy I think, and I really don't like huge PATHs, but it may be one solution to reduce the size of linear lists. It won't help against the git<TAB><TAB> issue directly, however. Regards, Ulrich ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 6:00 ` Ulrich Windl @ 2008-08-27 7:59 ` H. Peter Anvin 2008-08-27 19:14 ` Matthew Wilcox 2008-08-27 19:43 ` Perry Wagle 2 siblings, 0 replies; 193+ messages in thread From: H. Peter Anvin @ 2008-08-27 7:59 UTC (permalink / raw) To: Ulrich Windl Cc: Andi Kleen, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git Ulrich Windl wrote: > > In HP-UX many commands (or "subsystems") use /opt/<subsys>/{bin,sbin} to place > their binaries. PATH usually does not contain all of them. That's against Linux > philosophy I think, and I really don't like huge PATHs, but it may be one solution > to reduce the size of linear lists. It won't help against the git<TAB><TAB> issue > directly, however. > /opt is part of the Filesystem Hierarchy Standard which defines layouts on Linux systems. It is generally not used for binaries included in distributions or otherwise managed via distribution package managers, however. -hpa ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 6:00 ` Ulrich Windl 2008-08-27 7:59 ` H. Peter Anvin @ 2008-08-27 19:14 ` Matthew Wilcox 2008-08-27 19:43 ` Perry Wagle 2 siblings, 0 replies; 193+ messages in thread From: Matthew Wilcox @ 2008-08-27 19:14 UTC (permalink / raw) To: Ulrich Windl Cc: Andi Kleen, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git On Wed, Aug 27, 2008 at 08:00:17AM +0200, Ulrich Windl wrote: > In HP-UX many commands (or "subsystems") use /opt/<subsys>/{bin,sbin} to place > their binaries. PATH usually does not contain all of them. That's against Linux > philosophy I think, and I really don't like huge PATHs, but it may be one solution > to reduce the size of linear lists. It won't help against the git<TAB><TAB> issue > directly, however. In HP-UX, the default shell has a line length limit that is smaller than the length of $PATH. Be in awe of enterprise scalability. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 6:00 ` Ulrich Windl 2008-08-27 7:59 ` H. Peter Anvin 2008-08-27 19:14 ` Matthew Wilcox @ 2008-08-27 19:43 ` Perry Wagle 2008-08-27 19:50 ` Jeff King 2 siblings, 1 reply; 193+ messages in thread From: Perry Wagle @ 2008-08-27 19:43 UTC (permalink / raw) To: Ulrich Windl Cc: Andi Kleen, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git On Aug 26, 2008, at 11:00 PM, Ulrich Windl wrote: > On 26 Aug 2008 at 18:45, Andi Kleen wrote: >> git<space><tab><tab>.... what? 140-something commands? etc.etc. > Whether files in /usr/bin, or command completions: Long linear lists > are a thing > humans don't like. Bash and other shells use hash tables to store the commands in the PATH. Doing git-<tab> was shocking to me at first, but it also showed me a list of commands for me to learn. Now I guess that when everything's fixed up, I'll have to put in a space instead of a dash to get exactly the same thing. What difference did changing the dash to a space make? -- Perry ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 19:43 ` Perry Wagle @ 2008-08-27 19:50 ` Jeff King 2008-08-27 19:54 ` Perry Wagle 0 siblings, 1 reply; 193+ messages in thread From: Jeff King @ 2008-08-27 19:50 UTC (permalink / raw) To: Perry Wagle Cc: Ulrich Windl, Andi Kleen, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Junio C Hamano, David Woodhouse, git On Wed, Aug 27, 2008 at 12:43:23PM -0700, Perry Wagle wrote: > Doing git-<tab> was shocking to me at first, but it also showed me a list > of commands for me to learn. > > Now I guess that when everything's fixed up, I'll have to put in a space > instead of a dash to get exactly the same thing. > > What difference did changing the dash to a space make? Did you miss the part of the thread about how it's not exactly the same thing, but rather substantially fewer commands (and there is even additional discussion about _which_ commands)? -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 19:50 ` Jeff King @ 2008-08-27 19:54 ` Perry Wagle 2008-08-27 20:43 ` H. Peter Anvin 0 siblings, 1 reply; 193+ messages in thread From: Perry Wagle @ 2008-08-27 19:54 UTC (permalink / raw) To: Jeff King Cc: Ulrich Windl, Andi Kleen, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Junio C Hamano, David Woodhouse, git On Aug 27, 2008, at 12:50 PM, Jeff King wrote: > On Wed, Aug 27, 2008 at 12:43:23PM -0700, Perry Wagle wrote: > >> Doing git-<tab> was shocking to me at first, but it also showed me >> a list >> of commands for me to learn. >> >> Now I guess that when everything's fixed up, I'll have to put in a >> space >> instead of a dash to get exactly the same thing. >> >> What difference did changing the dash to a space make? > > Did you miss the part of the thread about how it's not exactly the > same > thing, but rather substantially fewer commands (and there is even > additional discussion about _which_ commands)? I guess I did. Being an optimist, I wouldn't expect the tab completion to *lie* and leave things out. -- Perry ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 19:54 ` Perry Wagle @ 2008-08-27 20:43 ` H. Peter Anvin 2008-08-27 21:19 ` Steven Rostedt 0 siblings, 1 reply; 193+ messages in thread From: H. Peter Anvin @ 2008-08-27 20:43 UTC (permalink / raw) To: Perry Wagle Cc: Jeff King, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Ulrich Windl, Andi Kleen, Junio C Hamano, David Woodhouse, git Perry Wagle wrote: >> Did you miss the part of the thread about how it's not exactly the >> same thing, but rather substantially fewer commands (and there is even >> additional discussion about _which_ commands)? > > I guess I did. Being an optimist, I wouldn't expect the tab > completion to *lie* and leave things out. Yes, that sounds, ahem, rude. -hpa ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 20:43 ` H. Peter Anvin @ 2008-08-27 21:19 ` Steven Rostedt 2008-08-27 23:27 ` Junio C Hamano 0 siblings, 1 reply; 193+ messages in thread From: Steven Rostedt @ 2008-08-27 21:19 UTC (permalink / raw) To: H. Peter Anvin Cc: Perry Wagle, Kristian H??gsberg, Matthias Kestenholz, Johannes Schindelin, users, Jeff King, Ulrich Windl, Andi Kleen, Junio C Hamano, David Woodhouse, git On Wed, 27 Aug 2008, H. Peter Anvin wrote: > Perry Wagle wrote: > >> Did you miss the part of the thread about how it's not exactly the > >> same thing, but rather substantially fewer commands (and there is even > >> additional discussion about _which_ commands)? > > > > I guess I did. Being an optimist, I wouldn't expect the tab > > completion to *lie* and leave things out. > > Yes, that sounds, ahem, rude. Yes, they are all a bunch of Nazi git fanatics, that Hitler himself would have used the space version of git. He sent the Jews off to the concentration camps because they insisted on using the dashes. There, we have a Hitler reference. CAN WE PLEASE LET THIS THREAD DIE! -- Steve ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 21:19 ` Steven Rostedt @ 2008-08-27 23:27 ` Junio C Hamano 2008-08-27 23:53 ` Perry Wagle 0 siblings, 1 reply; 193+ messages in thread From: Junio C Hamano @ 2008-08-27 23:27 UTC (permalink / raw) To: Steven Rostedt Cc: H. Peter Anvin, Kristian H??gsberg, Matthias Kestenholz, Ulrich Windl, Johannes Schindelin, users, Jeff King, Perry Wagle, Andi Kleen, David Woodhouse, git Steven Rostedt <rostedt@goodmis.org> writes: > Yes, they are all a bunch of Nazi git fanatics, that Hitler himself would > have used the space version of git. He sent the Jews off to the > concentration camps because they insisted on using the dashes. > > There, we have a Hitler reference. > > CAN WE PLEASE LET THIS THREAD DIE! Yeah, I second this. The primary topic has already settled, and we will keep git-foo in libexec even for built-ins. This offtopic tangent that shouldn't even have started from the beginning must die now. It outlived its usefulness even as a place for people to vent. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 23:27 ` Junio C Hamano @ 2008-08-27 23:53 ` Perry Wagle 2008-08-28 0:05 ` Perry Wagle 0 siblings, 1 reply; 193+ messages in thread From: Perry Wagle @ 2008-08-27 23:53 UTC (permalink / raw) To: Junio C Hamano Cc: Steven Rostedt, H. Peter Anvin, Kristian H??gsberg, Matthias Kestenholz, Ulrich Windl, Johannes Schindelin, users, Jeff King, Andi Kleen, David Woodhouse, git On Aug 27, 2008, at 4:27 PM, Junio C Hamano wrote: > Steven Rostedt <rostedt@goodmis.org> writes: > >> Yes, they are all a bunch of Nazi git fanatics, that Hitler himself >> would >> have used the space version of git. He sent the Jews off to the >> concentration camps because they insisted on using the dashes. >> >> There, we have a Hitler reference. >> >> CAN WE PLEASE LET THIS THREAD DIE! > > Yeah, I second this. > > The primary topic has already settled, and we will keep git-foo in > libexec > even for built-ins. > > This offtopic tangent that shouldn't even have started from the > beginning > must die now. It outlived its usefulness even as a place for people > to > vent. I suggested that git<DASH><TAB> used to give the same 143 completions that git<SPACE><TAB> would now. This meant that making any arguments that the number was off-putting to newbies did not apply, since you had a same number (143) either way. Putting stuff in libexec does not change the above observation in any fashion. A response to my observation was that "not everything will show up in the latter completion". I balked at that as it distorted the truth. If this distortion would actually take place then I have a real complaint. Not a tangent. But as long as git<DASH><TAB> does the *same* thing as git<SPACE><TAB>, I really do not see why you had to go break my scripts on a *minor* revision for what amounts to no reason as all. Shells *hash* the PATH, so there is no "linear list" issue, and you have the *same* behavior for <TAB> completion both ways. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 23:53 ` Perry Wagle @ 2008-08-28 0:05 ` Perry Wagle 2008-08-28 9:04 ` Petr Baudis 0 siblings, 1 reply; 193+ messages in thread From: Perry Wagle @ 2008-08-28 0:05 UTC (permalink / raw) To: Perry Wagle Cc: Junio C Hamano, Steven Rostedt, H. Peter Anvin, Kristian H??gsberg, Matthias Kestenholz, Ulrich Windl, Johannes Schindelin, users, Jeff King, Andi Kleen, David Woodhouse, git Oh yeah, sorry. I neglected to mention that my problem was having the git- forms in scripts all over an internal network, and having no amazingly easy way of fixing them. I don't know who all copied them. On Aug 27, 2008, at 4:53 PM, Perry Wagle wrote: > > On Aug 27, 2008, at 4:27 PM, Junio C Hamano wrote: > >> Steven Rostedt <rostedt@goodmis.org> writes: >> >>> Yes, they are all a bunch of Nazi git fanatics, that Hitler >>> himself would >>> have used the space version of git. He sent the Jews off to the >>> concentration camps because they insisted on using the dashes. >>> >>> There, we have a Hitler reference. >>> >>> CAN WE PLEASE LET THIS THREAD DIE! >> >> Yeah, I second this. >> >> The primary topic has already settled, and we will keep git-foo in >> libexec >> even for built-ins. >> >> This offtopic tangent that shouldn't even have started from the >> beginning >> must die now. It outlived its usefulness even as a place for >> people to >> vent. > > I suggested that git<DASH><TAB> used to give the same 143 > completions that git<SPACE><TAB> would now. This meant that making > any arguments that the number was off-putting to newbies did not > apply, since you had a same number (143) either way. Putting stuff > in libexec does not change the above observation in any fashion. > > A response to my observation was that "not everything will show up > in the latter completion". I balked at that as it distorted the > truth. If this distortion would actually take place then I have a > real complaint. Not a tangent. > > But as long as git<DASH><TAB> does the *same* thing as > git<SPACE><TAB>, I really do not see why you had to go break my > scripts on a *minor* revision for what amounts to no reason as all. > > Shells *hash* the PATH, so there is no "linear list" issue, and you > have the *same* behavior for <TAB> completion both ways. > > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 0:05 ` Perry Wagle @ 2008-08-28 9:04 ` Petr Baudis 2008-08-28 10:33 ` Perry Wagle 0 siblings, 1 reply; 193+ messages in thread From: Petr Baudis @ 2008-08-28 9:04 UTC (permalink / raw) To: Perry Wagle Cc: Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, users, Jeff King, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git This thread is starting to seriously irritate even *me* by now, which is quite a feat... On Wed, Aug 27, 2008 at 05:05:33PM -0700, Perry Wagle wrote: > Oh yeah, sorry. I neglected to mention that my problem was having the > git- forms in scripts all over an internal network, and having no > amazingly easy way of fixing them. I don't know who all copied them. Should I count for you how many times the $PATH workaround has been mentioned already? Or the gitexecdir workaround? > On Aug 27, 2008, at 4:53 PM, Perry Wagle wrote: > > > > > On Aug 27, 2008, at 4:27 PM, Junio C Hamano wrote: > > > >> Steven Rostedt <rostedt@goodmis.org> writes: > >> > >>> Yes, they are all a bunch of Nazi git fanatics, that Hitler > >>> himself would > >>> have used the space version of git. He sent the Jews off to the > >>> concentration camps because they insisted on using the dashes. > >>> > >>> There, we have a Hitler reference. > >>> > >>> CAN WE PLEASE LET THIS THREAD DIE! Intentional invocations of Godwin's Law don't count - sadly. ;-) > > I suggested that git<DASH><TAB> used to give the same 143 > > completions that git<SPACE><TAB> would now. This meant that making > > any arguments that the number was off-putting to newbies did not > > apply, since you had a same number (143) either way. Putting stuff > > in libexec does not change the above observation in any fashion. > > > > A response to my observation was that "not everything will show up > > in the latter completion". I balked at that as it distorted the > > truth. If this distortion would actually take place then I have a > > real complaint. Not a tangent. > > > > But as long as git<DASH><TAB> does the *same* thing as > > git<SPACE><TAB>, I really do not see why you had to go break my > > scripts on a *minor* revision for what amounts to no reason as all. What the hell are you talking about? Did you *try*? git<SPACE><TAB> does not do the same thing as git<DASH><TAB>, and it has been clearly stated in this thread several times. It shows only the commands that are *interesting* for the user, just as $PATH does not include /usr/sbin and /sbin and /usr/lib/wine because the executables in these directories just aren't interesting for the users. If you care about all the Git internals, go read git(1) to see the list of all the plumbing stuff. -- Petr "Pasky" Baudis The next generation of interesting software will be done on the Macintosh, not the IBM PC. -- Bill Gates ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 9:04 ` Petr Baudis @ 2008-08-28 10:33 ` Perry Wagle 2008-08-28 10:42 ` David Woodhouse ` (2 more replies) 0 siblings, 3 replies; 193+ messages in thread From: Perry Wagle @ 2008-08-28 10:33 UTC (permalink / raw) To: Petr Baudis Cc: Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, users, Jeff King, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Aug 28, 2008, at 2:04 AM, Petr Baudis wrote: > This thread is starting to seriously irritate even *me* by now, which > is quite a feat... > > On Wed, Aug 27, 2008 at 05:05:33PM -0700, Perry Wagle wrote: >> Oh yeah, sorry. I neglected to mention that my problem was having >> the >> git- forms in scripts all over an internal network, and having no >> amazingly easy way of fixing them. I don't know who all copied them. > > Should I count for you how many times the $PATH workaround has been > mentioned already? Or the gitexecdir workaround? The PATH thing fixes the problem of typing in git-commands at the command line, but not for scripts containing git<DASH> commands. I've seen no-one rebut my rebuttal. Are you suggesting that I break into machines that I don't have access to add a export PATH= line to copies of scripts that were written 6 months ago, and worked just fine until someone decided that "upward compatibility" wasn't an important concept? What other upward compatibilities were broken in the past six months? What am I testing for tomorrow when I fix it before releasing an upgraded git? Next month? I really don't understand this "upward compatibility doesn't matter" thing. > What the hell are you talking about? Did you *try*? git<SPACE><TAB> > does not do the same thing as git<DASH><TAB>, and it has been clearly > stated in this thread several times. It shows only the commands that > are > *interesting* for the user, just as $PATH does not include /usr/sbin > and > /sbin and /usr/lib/wine because the executables in these directories > just aren't interesting for the users. If you care about all the Git > internals, go read git(1) to see the list of all the plumbing stuff. In this thread the new completion thing has been clearly stated both ways. I have one, apparently very authoritative, response in this thread assuring me that it will not be the case that the command completion space will be restricted in the fashion you support. I'm not sure who to believe. It might not matter: apparently, one person in the thread was forced to make the change we are all responding to here. When does that happen again? I find the notion that the command completion should give partial results an unpleasant concept. I've been stuck with systems with no documentation, but with command completion with that sort of thinking, and as a result, and it was very frustrating. -- Perry ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 10:33 ` Perry Wagle @ 2008-08-28 10:42 ` David Woodhouse 2008-08-28 19:56 ` Perry Wagle 2008-08-28 10:47 ` Petr Baudis 2008-08-28 16:35 ` Linus Torvalds 2 siblings, 1 reply; 193+ messages in thread From: David Woodhouse @ 2008-08-28 10:42 UTC (permalink / raw) To: Perry Wagle Cc: Petr Baudis, Kristian Høgsberg, Matthias Kestenholz, Steven Rostedt, users, Jeff King, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, git On Thu, 2008-08-28 at 03:33 -0700, Perry Wagle wrote: > Are you suggesting that I break into machines that I don't have access > to add a export PATH= line to copies of scripts that were written 6 > months ago, and worked just fine until someone decided that "upward > compatibility" wasn't an important concept? Not at all. But as long as you also refrain from breaking into those same machines and upgrading them to git 1.6.0, you should be fine. Or if you _do_ upgrade them to git 1.6.0, you should make sure you build with gitexecdir=/usr/bin to prevent the breakage. What distribution are you running on those machines? If they upgrade their version of git from an earlier version to 1.6.0 in a stable release without setting gitexecdir=/usr/bin to preserve compatibility, then the packager needs to be taken out back and shot. Perhaps you should file a bug in advance, to make sure they're aware of the issue and make sure that if/when they update to 1.6.0, they set gitexecdir properly. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 10:42 ` David Woodhouse @ 2008-08-28 19:56 ` Perry Wagle 0 siblings, 0 replies; 193+ messages in thread From: Perry Wagle @ 2008-08-28 19:56 UTC (permalink / raw) To: David Woodhouse Cc: Petr Baudis, Kristian Høgsberg, Matthias Kestenholz, Steven Rostedt, users, Jeff King, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, git On Aug 28, 2008, at 3:42 AM, David Woodhouse wrote: > On Thu, 2008-08-28 at 03:33 -0700, Perry Wagle wrote: >> Are you suggesting that I break into machines that I don't have >> access >> to add a export PATH= line to copies of scripts that were written 6 >> months ago, and worked just fine until someone decided that "upward >> compatibility" wasn't an important concept? > > Not at all. But as long as you also refrain from breaking into those > same machines and upgrading them to git 1.6.0, you should be fine. I was being over-dramatic in an attempt to get people to at least try to think it out. You did, thanks! But the actual problem is that I provide a central repository with "the current version of git" for us. I'm not sure who all pulls from that repository, but a number of them have finally learned git well enough to clamor for 1.6.0. So it's them upgrading from my repository, not me upgrading for them. > Or if you _do_ upgrade them to git 1.6.0, you should make sure you > build > with gitexecdir=/usr/bin to prevent the breakage. That's a hack, which will burn me in less than a year. > What distribution are you running on those machines? If they upgrade > their version of git from an earlier version to 1.6.0 in a stable > release without setting gitexecdir=/usr/bin to preserve compatibility, > then the packager needs to be taken out back and shot. I'm the packager. I didn't upgrade our customized version of git because I'm still trying to think it out. I don't get to break things. If I break them, I gotta fix them. I haven't been paid to do git stuff for months, and I have a deadline tomorrow. But I gotta act now if I want a chance to live a life without the git community breaking upward compatibility on minor version releases for completely frivolous reasons. It wasn't broke, but you "fixed" it anyway. What's next? I'm more worried about what's next and what's already slipped through than this one particular thing. -- Perry ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 10:33 ` Perry Wagle 2008-08-28 10:42 ` David Woodhouse @ 2008-08-28 10:47 ` Petr Baudis 2008-08-28 16:35 ` Linus Torvalds 2 siblings, 0 replies; 193+ messages in thread From: Petr Baudis @ 2008-08-28 10:47 UTC (permalink / raw) To: Perry Wagle Cc: Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Jeff King, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git I'm removing users@kernel.org from the Cc list since this is far beyond relevant there. On Thu, Aug 28, 2008 at 03:33:46AM -0700, Perry Wagle wrote: > The PATH thing fixes the problem of typing in git-commands at the command > line, but not for scripts containing git<DASH> commands. I've seen no-one > rebut my rebuttal. Huh? $PATH takes effect both on command-line and in scripts. Maybe you wanted to phrase this paragraph differently. > Are you suggesting that I break into machines that I don't have access to > add a export PATH= line to copies of scripts that were written 6 months > ago, and worked just fine until someone decided that "upward compatibility" > wasn't an important concept? No, they worked just fine until someone upgraded Git there. That $someone needs to take care of this. > What other upward compatibilities were broken in the past six months? What > am I testing for tomorrow when I fix it before releasing an upgraded git? > Next month? > > I really don't understand this "upward compatibility doesn't matter" thing. The deprecation has been announced several times. Yes, we might've done better job spreading the word and the documentation still needs updates; from that it's apparent we're lacking at resources here and help is welcome. Ask your money back or send patches. > In this thread the new completion thing has been clearly stated both ways. > > I have one, apparently very authoritative, response in this thread assuring > me that it will not be the case that the command completion space will be > restricted in the fashion you support. I'm not sure who to believe. It > might not matter: apparently, one person in the thread was forced to make > the change we are all responding to here. When does that happen again? What response is that? I can see only Andi Kleen's post, and it didn't actually even directly claim that this is the current behaviour. Then there's bunch of posts showing that it's not the case. Well, I can only shrug my shoulders. Since after all, you clearly just feel like flaming and don't actually _care_ about this issue at all since you would just _try_ it out if this actually mattered to you. > I find the notion that the command completion should give partial results > an unpleasant concept. I've been stuck with systems with no documentation, > but with command completion with that sort of thinking, and as a result, > and it was very frustrating. Git has documentation. -- Petr "Pasky" Baudis The next generation of interesting software will be done on the Macintosh, not the IBM PC. -- Bill Gates ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 10:33 ` Perry Wagle 2008-08-28 10:42 ` David Woodhouse 2008-08-28 10:47 ` Petr Baudis @ 2008-08-28 16:35 ` Linus Torvalds 2008-08-28 19:24 ` Perry Wagle 2 siblings, 1 reply; 193+ messages in thread From: Linus Torvalds @ 2008-08-28 16:35 UTC (permalink / raw) To: Perry Wagle Cc: Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, users, Jeff King, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Thu, 28 Aug 2008, Perry Wagle wrote: > > The PATH thing fixes the problem of typing in git-commands at the > command line, but not for scripts containing git<DASH> commands. I've > seen no-one rebut my rebuttal. What drugs are you people on? Just put it in your .bash_profile or something. It will now work for all your scripts. And for us people who do _not_ want it, we fix the scripts, or we don't run them. Linus ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 16:35 ` Linus Torvalds @ 2008-08-28 19:24 ` Perry Wagle 2008-08-28 19:52 ` Teemu Likonen 0 siblings, 1 reply; 193+ messages in thread From: Perry Wagle @ 2008-08-28 19:24 UTC (permalink / raw) To: Linus Torvalds Cc: Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Jeff King, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Aug 28, 2008, at 9:35 AM, Linus Torvalds wrote: > On Thu, 28 Aug 2008, Perry Wagle wrote: >> >> The PATH thing fixes the problem of typing in git-commands at the >> command line, but not for scripts containing git<DASH> commands. >> I've >> seen no-one rebut my rebuttal. > > What drugs are you people on? No drugs, just that I was expecting people to do more than demonstrate to me the excellence of their knee reflex. Especially you (Linus), who supports thinking things out and not depending on debugging tools. I prefer to think things out and not "coding from the hip". I can be proven wrong, but you are going to have to engage your brain to do so. Threatening me or whacking me with the neural loop from your spine to your knee isn't going to cut it. > Just put it in your .bash_profile or something. It will now work for > all > your scripts. In terms of continuing to provide me git<DASH><TAB> if I so desire, that's an excellent idea, and I've repeatedly said so. In terms of preserving scripts, thats a filthy hack that only fixes my own execution of those scripts, not for other people. And some people don't run bash, so /etc/bashrc *on every system* or whatever doesn't actually do it either. Did you think that out? > And for us people who do _not_ want it, we fix the scripts, or we > don't > run them. This is one upward compatibility broken for goofy reasons, at least those given in this thread, where there were numerous "ZOMG! I get 143 completions!" accompanied by false claims that it was a 143 element *list* when in fact a *hash table* is used. But the issue for me is what other upward compatibilities were broken? What am I testing for? Is is really only that I sed s/git-/git<SPACE>/g on the scripts? I'm doubting it, given the quality of reasoning and lack of respect for upward compatibility on this thread. Yes, I'm over-killing a molehill, but I see you all building a mountain in the distance that I don't feel like climbing. I haven't been paid to do git stuff for months. -- Perry ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 19:24 ` Perry Wagle @ 2008-08-28 19:52 ` Teemu Likonen 2008-08-28 20:23 ` Perry Wagle 0 siblings, 1 reply; 193+ messages in thread From: Teemu Likonen @ 2008-08-28 19:52 UTC (permalink / raw) To: Perry Wagle Cc: Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Jeff King, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git Perry Wagle wrote (2008-08-28 12:24 -0700): > Is is really only that I > > sed s/git-/git<SPACE>/g > > on the scripts? I'm doubting it, given the quality of reasoning and > lack of respect for upward compatibility on this thread. I have come to understand that "git " has quite long time been more robust and portable way of writing scripts. They work in both configurations so I'd definitely suggest doing "s/git-/git /g" for every script. Of course in an interactive shell everyone can use whatever they prefer and works at the moment. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 19:52 ` Teemu Likonen @ 2008-08-28 20:23 ` Perry Wagle 2008-08-28 20:44 ` Petr Baudis 2008-08-28 21:23 ` Jeff King 0 siblings, 2 replies; 193+ messages in thread From: Perry Wagle @ 2008-08-28 20:23 UTC (permalink / raw) To: Teemu Likonen Cc: Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Jeff King, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Aug 28, 2008, at 12:52 PM, Teemu Likonen wrote: > Perry Wagle wrote (2008-08-28 12:24 -0700): > >> Is is really only that I >> >> sed s/git-/git<SPACE>/g >> >> on the scripts? I'm doubting it, given the quality of reasoning and >> lack of respect for upward compatibility on this thread. > > I have come to understand that "git " has quite long time been more > robust and portable way of writing scripts. They work in both > configurations so I'd definitely suggest doing "s/git-/git /g" for > every > script. Of course in an interactive shell everyone can use whatever > they > prefer and works at the moment. Sure. Its an extra fork in git command intensive scripts (and git is racey still maybe), but *shrug*. When I started with git in Fall 2007, the sample scripts and gitweb both used git<DASH> and git<SPACE> willy-nilly. I liked git<DASH> better since it was what I used at the command line for the <TAB> completion for the commands and for the man pages, and I like being meticulously consistent so I can greatly reduce mistakes. Even as of March 2008 (our last sync with git before the git scripting was completed and we got on to other things), the sample scripts and gitweb still used the git<DASH> form. If this has been brewing for two years, there shouldn't have been a git<DASH> form in the scripts in the standard source *anywhere* for those two years. There was. Therefore, you don't get to claim that this was decided two years ago, finally done now, and what's Perry's problem anyway? But, my problem is not git<DASH> vs git<SPACE>, but the slap-dash way upward compatibility was broken and the "water over the dam" slippery slope rationalizations that refuse to consider reverting. "You" will do it again in the future since you are declaring success here. And "you" have likely done it in the past 6 months. -- Perry ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 20:23 ` Perry Wagle @ 2008-08-28 20:44 ` Petr Baudis 2008-08-28 20:57 ` Perry Wagle 2008-08-28 21:23 ` Jeff King 1 sibling, 1 reply; 193+ messages in thread From: Petr Baudis @ 2008-08-28 20:44 UTC (permalink / raw) To: Perry Wagle Cc: Teemu Likonen, Linus Torvalds, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Jeff King, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Thu, Aug 28, 2008 at 01:23:50PM -0700, Perry Wagle wrote: > > On Aug 28, 2008, at 12:52 PM, Teemu Likonen wrote: > >> I have come to understand that "git " has quite long time been more >> robust and portable way of writing scripts. They work in both >> configurations so I'd definitely suggest doing "s/git-/git /g" for every >> script. Of course in an interactive shell everyone can use whatever they >> prefer and works at the moment. > > Sure. Its an extra fork in git command intensive scripts (and git is racey > still maybe), but *shrug*. Do you have any details on the races in Git you know about? This does not mean an extra fork, only extra exec. In case of builtin commands (which is actually a large majority by now), not even that. > Even as of March 2008 (our last sync with git before the git scripting was > completed and we got on to other things), the sample scripts and gitweb > still used the git<DASH> form. If this has been brewing for two years, > there shouldn't have been a git<DASH> form in the scripts in the standard > source *anywhere* for those two years. I agree that this is a problem. Even now, the documentation is using git- at plenty of places. Patches are welcome, I'm sure. -- Petr "Pasky" Baudis The next generation of interesting software will be done on the Macintosh, not the IBM PC. -- Bill Gates ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 20:44 ` Petr Baudis @ 2008-08-28 20:57 ` Perry Wagle 0 siblings, 0 replies; 193+ messages in thread From: Perry Wagle @ 2008-08-28 20:57 UTC (permalink / raw) To: Petr Baudis Cc: Teemu Likonen, Linus Torvalds, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Jeff King, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Aug 28, 2008, at 1:44 PM, Petr Baudis wrote: > On Thu, Aug 28, 2008 at 01:23:50PM -0700, Perry Wagle wrote: >> >> On Aug 28, 2008, at 12:52 PM, Teemu Likonen wrote: >> >>> I have come to understand that "git " has quite long time been more >>> robust and portable way of writing scripts. They work in both >>> configurations so I'd definitely suggest doing "s/git-/git /g" for >>> every >>> script. Of course in an interactive shell everyone can use >>> whatever they >>> prefer and works at the moment. >> >> Sure. Its an extra fork in git command intensive scripts (and git >> is racey >> still maybe), but *shrug*. > > Do you have any details on the races in Git you know about? Sorry, I should have just left that line out. But I didn't, so: Fall of 2007, I'd get spurious reports that the working dir was inconsistent when iterating through 612 commits in a script (I was converting from quilt/cvs to git) when it wasn't. I got around most of this by sprinkling the script with git-status and git update-index --refresh. My understanding was that it really was the one-second granularity of the timestamps on my file system doing it, so nothing for me to do at the time. However, it was really bugging people, so I figured by this time someone had found a clever way to fix it, hence the "maybe". I haven't tried it for a while. > This does not mean an extra fork, only extra exec. In case of builtin > commands (which is actually a large majority by now), not even that. Yeah, I should have deleted that line. 8) >> Even as of March 2008 (our last sync with git before the git >> scripting was >> completed and we got on to other things), the sample scripts and >> gitweb >> still used the git<DASH> form. If this has been brewing for two >> years, >> there shouldn't have been a git<DASH> form in the scripts in the >> standard >> source *anywhere* for those two years. > > I agree that this is a problem. Even now, the documentation is using > git- at plenty of places. Patches are welcome, I'm sure. Heh. -- Perry ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 20:23 ` Perry Wagle 2008-08-28 20:44 ` Petr Baudis @ 2008-08-28 21:23 ` Jeff King 2008-08-28 21:41 ` Perry Wagle 2008-08-29 9:33 ` Wincent Colaiuta 1 sibling, 2 replies; 193+ messages in thread From: Jeff King @ 2008-08-28 21:23 UTC (permalink / raw) To: Perry Wagle Cc: Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Thu, Aug 28, 2008 at 01:23:50PM -0700, Perry Wagle wrote: > But, my problem is not git<DASH> vs git<SPACE>, but the slap-dash way > upward compatibility was broken and the "water over the dam" slippery > slope rationalizations that refuse to consider reverting. "You" will do > it again in the future since you are declaring success here. And "you" > have likely done it in the past 6 months. I don't think Junio is declaring success. In fact, I think he has sent several messages saying (paraphrasing of course): - this was obviously not done in the best manner possible, because of the number of people complaining - we will try to do better about notification next time such a change is made. Please make suggestions about how to do so. - since we have already released and already broken everybody, and these people are now complaining on the list, there is not much point in trying to notify people of _this_ change now Junio (and others) have tried to be very careful about breaking backwards compatibility, especially for scripting interfaces. We thought sufficient steps were taken this time, but clearly some disagree. So please stop making specious claims that there are crazy backwards-incompatibility bugs lurking throughout new versions of git. If there are, then please find and name them. If not, then I think the git community would welcome suggestions about how better to notify users about the rare changes like this one. -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 21:23 ` Jeff King @ 2008-08-28 21:41 ` Perry Wagle 2008-08-28 21:53 ` Petr Baudis 2008-08-28 21:59 ` Jeff King 2008-08-29 9:33 ` Wincent Colaiuta 1 sibling, 2 replies; 193+ messages in thread From: Perry Wagle @ 2008-08-28 21:41 UTC (permalink / raw) To: Jeff King Cc: Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Aug 28, 2008, at 2:23 PM, Jeff King wrote: > On Thu, Aug 28, 2008 at 01:23:50PM -0700, Perry Wagle wrote: > >> But, my problem is not git<DASH> vs git<SPACE>, but the slap-dash way >> upward compatibility was broken and the "water over the dam" slippery >> slope rationalizations that refuse to consider reverting. "You" >> will do >> it again in the future since you are declaring success here. And >> "you" >> have likely done it in the past 6 months. > > I don't think Junio is declaring success. In fact, I think he has sent > several messages saying (paraphrasing of course): I did not name anyone, and put "you" in quotes to try to not even imply I was pointing at one person. Several people have declared success, but Junio wasn't one of them. I think (?) that he was just the unwilling gunman. 8) > So please stop making specious claims that there are crazy > backwards-incompatibility bugs lurking throughout new versions of git. > If there are, then please find and name them. If not, then I think the > git community would welcome suggestions about how better to notify > users > about the rare changes like this one. I now have to TEST to find those crazy backwards-incompatibility bugs before I can upgrade us to 1.6.0. To test, I have to try to imagine what I and others were assuming about git. And this episode means that I can't make any assumptions about the sanity of any changes since March, which is the version I'm thinking of upgrading. But note that THIS upward compatibility bug has been declared to not be a bug. Will any others receive the same stamp? So please put on your engineer hat, and stop talking about "specious claims" and hurting feelings. Heck, I even got Linus himself to ask if us people were on drugs, and I didn't take it personally. At least I'm saying something that can be disputed, and not ad hominem like Linus. 8) How to better notify them is to do it on a major release, like Git 2.0. THEN, they expect upward compatibility to break. -- Perry ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 21:41 ` Perry Wagle @ 2008-08-28 21:53 ` Petr Baudis 2008-08-28 21:59 ` Jeff King 1 sibling, 0 replies; 193+ messages in thread From: Petr Baudis @ 2008-08-28 21:53 UTC (permalink / raw) To: Perry Wagle Cc: Jeff King, Teemu Likonen, Linus Torvalds, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git It's getting repetitive. :-( On Thu, Aug 28, 2008 at 02:41:52PM -0700, Perry Wagle wrote: > I now have to TEST to find those crazy backwards-incompatibility bugs > before I can upgrade us to 1.6.0. To test, I have to try to imagine what I > and others were assuming about git. And this episode means that I can't > make any assumptions about the sanity of any changes since March, which is > the version I'm thinking of upgrading. All changes of this kind, including this one, should be carefully described in the release notes. Since you say you are effectively a Git packager, you really should be one of the persons who do actually read them. :-) You can't ask us to stop making any incompatible changes - Git is still too young for that and it's UI got evolved, not designed. But we do document the changes we do, even though we might do a better job *spreading* the word. Petr "Pasky" Baudis ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 21:41 ` Perry Wagle 2008-08-28 21:53 ` Petr Baudis @ 2008-08-28 21:59 ` Jeff King 2008-08-28 22:33 ` Perry Wagle 1 sibling, 1 reply; 193+ messages in thread From: Jeff King @ 2008-08-28 21:59 UTC (permalink / raw) To: Perry Wagle Cc: Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Thu, Aug 28, 2008 at 02:41:52PM -0700, Perry Wagle wrote: >>> But, my problem is not git<DASH> vs git<SPACE>, but the slap-dash way >>> upward compatibility was broken and the "water over the dam" slippery >>> slope rationalizations that refuse to consider reverting. "You" will >>> do >>> it again in the future since you are declaring success here. And >>> "you" >>> have likely done it in the past 6 months. >> >> I don't think Junio is declaring success. In fact, I think he has sent >> several messages saying (paraphrasing of course): > > I did not name anyone, and put "you" in quotes to try to not even imply I > was pointing at one person. Several people have declared success, but > Junio wasn't one of them. I think (?) that he was just the unwilling > gunman. 8) Sorry, I thought you meant "the git community has put these bugs into git" in the past 6 months. And I don't think that is true. > I now have to TEST to find those crazy backwards-incompatibility bugs > before I can upgrade us to 1.6.0. To test, I have to try to imagine what > I and others were assuming about git. And this episode means that I can't > make any assumptions about the sanity of any changes since March, which is > the version I'm thinking of upgrading. > > But note that THIS upward compatibility bug has been declared to not be a > bug. Will any others receive the same stamp? > > So please put on your engineer hat, and stop talking about "specious > claims" and hurting feelings. My engineer hat _is_ on. Here is the logic that led to my use of the phrase "specious claims": - you are claiming that there are backwards incompatibility changes lurking in git (or at least that is what I believe you to mean) - there has been _one_ such problem, and the person responsible for vetting such changes has solicited suggestions for doing better in the future. I don't think that is indicative of a pattern of such changes. - But let's say you have lost some faith in the git development process due to _this_ bug. But let's look at the history of this bug. It has been discussed several times for the past 2 years, along with a mention in the release notes several versions ago. It was not a surprise to anybody who has been developing git. So yes, maybe there _are_ other bugs just like it lurking. But wouldn't it stand to reason that those bugs have _also_ been discussed and mentioned in the release notes, or that the developers would know about them? In other words, I can see you losing enough faith to say "wow, the git developers don't communicate very well and I need to vet their changes and notes more carefully". I don't think it is reasonable to say that there are likely to be other, totally unknown backwards incompatible changes. So 1. I find your claim that such bugs exist to have little evidence to back it up. 2. As an engineer, I have seen evidence of one problem (insufficient communication) but not of another (introduction of incompatibilities without on-list discussion). So I would choose to focus my resources on fixing the problem I have seen. > Heck, I even got Linus himself to ask if us people were on drugs, and > I didn't take it personally. At least I'm saying something that can > be disputed, and not ad hominem like Linus. 8) Sorry, but I'm not impressed by your getting Linus to yell at you. It's like shooting fish in a barrel. :) > How to better notify them is to do it on a major release, like Git 2.0. > THEN, they expect upward compatibility to break. Now that _is_ a reasonable suggestion. This change _did_ wait until the jump to 1.6.0, which we thought of as a major version jump (just as 1.4 to 1.5 introduced a few minor but documented changes). I don't think there is a plan for "git 2.0" short of serious incompatibilities in the repo format (i.e., you can't use 2.x tools on 1.x repos and vice versa). So perhaps our numbering should be more emphatic. -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 21:59 ` Jeff King @ 2008-08-28 22:33 ` Perry Wagle 2008-08-28 23:04 ` Jeff King ` (2 more replies) 0 siblings, 3 replies; 193+ messages in thread From: Perry Wagle @ 2008-08-28 22:33 UTC (permalink / raw) To: Jeff King Cc: Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Aug 28, 2008, at 2:59 PM, Jeff King wrote: >> I now have to TEST to find those crazy backwards-incompatibility bugs >> before I can upgrade us to 1.6.0. To test, I have to try to >> imagine what >> I and others were assuming about git. And this episode means that >> I can't >> make any assumptions about the sanity of any changes since March, >> which is >> the version I'm thinking of upgrading. >> >> But note that THIS upward compatibility bug has been declared to >> not be a >> bug. Will any others receive the same stamp? >> >> So please put on your engineer hat, and stop talking about "specious >> claims" and hurting feelings. > > My engineer hat _is_ on. Here is the logic that led to my use of the > phrase "specious claims": Cool. Thanks! (seriously) > - you are claiming that there are backwards incompatibility changes > lurking in git (or at least that is what I believe you to mean) I'm saying that I don't know and will have to do complete exhaustive testing to be sure (my faith in git has been severely shaken). I already tested every step for months, and to do it "right", I have to do that all over again. I don't have the time, so I have to do severe approximations. One of the fixes is to see if I can get people to stop making frivolous changes: "ooo! we have to rename everything in the API because lists, I mean hashtables, with 143 entries in them are offensive!". If there was more reasoning than that, it was not displayed in this thread. > - there has been _one_ such problem, and the person responsible for > vetting such changes has solicited suggestions for doing better in > the future. I don't think that is indicative of a pattern of such > changes. Ok. My suggestion is that it shouldn't have been done in the first place, and we should now revert. But others are saying over and over "its done! live with it!". I came in late. What did I miss in the last 6 months. Sounds like people have lots of practice with these water-over-the-dam's, surely this isn't the first time? > - But let's say you have lost some faith in the git development > process due to _this_ bug. But let's look at the history of this > bug. It has been discussed several times for the past 2 years, > along > with a mention in the release notes several versions ago. It was > not > a surprise to anybody who has been developing git. In March 2008, the sample git-hooks and git-web used git<DASH> commands. That was the last I looked at git until Tuesday of this week. > So yes, maybe there _are_ other bugs just like it lurking. But > wouldn't it stand to reason that those bugs have _also_ been > discussed and mentioned in the release notes, or that the > developers > would know about them? This is declared to not be a bug, even though it breaks existing scripts, even those published in the main branch of git itself. > In other words, I can see you losing enough faith to say "wow, the > git developers don't communicate very well and I need to vet their > changes and notes more carefully". I don't think it is reasonable > to > say that there are likely to be other, totally unknown backwards > incompatible changes. I'm going by the reasoning shown in this thread. Why not? I'm looking for a way not to have to do exhaustive testing on those scripts, so would love to hear it. > So > > 1. I find your claim that such bugs exist to have little evidence to > back it up. Induction. If it happened once, it probably happened more than once. This wasn't a show stopper problem. It wasn't broke, but it was "fixed" anyway. > 2. As an engineer, I have seen evidence of one problem (insufficient > communication) but not of another (introduction of > incompatibilities without on-list discussion). So I would choose > to > focus my resources on fixing the problem I have seen. I don't know what I missed, and am not sure how to search for in in ten thousand messages or so since March. My style is to anticipate problems. But I'll figure it out. Part of that figure out process is posting to this thread. >> Heck, I even got Linus himself to ask if us people were on drugs, and >> I didn't take it personally. At least I'm saying something that can >> be disputed, and not ad hominem like Linus. 8) > > Sorry, but I'm not impressed by your getting Linus to yell at you. > It's > like shooting fish in a barrel. :) Yeah, well, that was supposed to be both a joke and to indicate that I'm not sitting here with steam coming out my ears. Linus has his solution, that doesn't work for me. He hasn't listened to my several attempts to say why, and he's mad because he thinks I'm not listening. But I expect he's a busy guy with 10,000 emails a day to respond to, so them's the breaks. >> How to better notify them is to do it on a major release, like Git >> 2.0. >> THEN, they expect upward compatibility to break. > > Now that _is_ a reasonable suggestion. This change _did_ wait until > the > jump to 1.6.0, which we thought of as a major version jump (just as > 1.4 > to 1.5 introduced a few minor but documented changes). I don't think > there is a plan for "git 2.0" short of serious incompatibilities in > the > repo format (i.e., you can't use 2.x tools on 1.x repos and vice > versa). > So perhaps our numbering should be more emphatic. I think I hear you. Since git is young, I should expect incompatibilities with minor version changes, and not demand that they be held off for major version changes. That seems very plausible. But I think I'll still remain wary because 1.6 introduced a nearly complete renaming of the API for what, in this thread anyway, completely silly reasons. If there are good reasons, I haven't seen them. -- Perry ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 22:33 ` Perry Wagle @ 2008-08-28 23:04 ` Jeff King 2008-08-28 23:22 ` Perry Wagle ` (2 more replies) 2008-08-28 23:12 ` Perry Wagle 2008-08-28 23:31 ` Jakub Narebski 2 siblings, 3 replies; 193+ messages in thread From: Jeff King @ 2008-08-28 23:04 UTC (permalink / raw) To: Perry Wagle Cc: Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Thu, Aug 28, 2008 at 03:33:26PM -0700, Perry Wagle wrote: > Ok. My suggestion is that it shouldn't have been done in the first > place, and we should now revert. But others are saying over and over > "its done! live with it!". I came in late. What did I miss in the last > 6 months. Sounds like people have lots of practice with these > water-over-the-dam's, surely this isn't the first time? No, it really is the first time. > In March 2008, the sample git-hooks and git-web used git<DASH> commands. > That was the last I looked at git until Tuesday of this week. Yes, and some of the test scripts still have git-* in them. I think in that respect, the git community has been very bad about eating our own dog food. >> So yes, maybe there _are_ other bugs just like it lurking. But >> wouldn't it stand to reason that those bugs have _also_ been >> discussed and mentioned in the release notes, or that the developers >> would know about them? > > This is declared to not be a bug, even though it breaks existing scripts, > even those published in the main branch of git itself. I think the bug is not in the change, but in the deprecation process and communication. But I think the definition of "bug" is vague enough to simply be in the eye of the beholder. > I'm going by the reasoning shown in this thread. Why not? I'm looking > for a way not to have to do exhaustive testing on those scripts, so would > love to hear it. Ultimately you must be the judge of what and how much to test on your systems. But if you are asking if there are other similar compatibility bugs in 1.6.0, then my opinion, as somebody who follows the git list quite closely and contributes some code, is that no, there are not. >> 1. I find your claim that such bugs exist to have little evidence to >> back it up. > > Induction. If it happened once, it probably happened more than once. > This wasn't a show stopper problem. It wasn't broke, but it was "fixed" > anyway. Induction in this manner is not a very rigorous argument (we're being engineers, right?). I gave several reasons already why the probability is low that another such bug exists, mostly related to the lack of indicators. > I don't know what I missed, and am not sure how to search for in in ten > thousand messages or so since March. My style is to anticipate problems. Sure, I wouldn't want to go back and read all of the messages either. But this was mentioned in the release notes, too. Why don't you start with them? > I think I hear you. Since git is young, I should expect > incompatibilities with minor version changes, and not demand that they be > held off for major version changes. That seems very plausible. That isn't quite what I meant. What I meant was that our idea of a major version number is the middle number. That is, the time to introduce a few minor incompatibilities is when that number jumps (but they should be documented for a significant time period ahead of time, which this was). I don't expect to jump to "git 2.0" basically ever. Just as I don't really expect Linux 3.0 anytime soon. But I, of course, am not in charge of such things, so you may take that with a grain of salt. > But I think I'll still remain wary because 1.6 introduced a nearly > complete renaming of the API for what, in this thread anyway, completely > silly reasons. If there are good reasons, I haven't seen them. I think the reasons have been mentioned a few times. Maybe you just didn't think they were good. -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 23:04 ` Jeff King @ 2008-08-28 23:22 ` Perry Wagle 2008-08-28 23:36 ` Jeff King 2008-08-28 23:24 ` Junio C Hamano 2008-08-29 7:51 ` [kernel.org users] [RFD] On deprecating "git-foo" for builtins Andreas Ericsson 2 siblings, 1 reply; 193+ messages in thread From: Perry Wagle @ 2008-08-28 23:22 UTC (permalink / raw) To: Jeff King Cc: Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Aug 28, 2008, at 4:04 PM, Jeff King wrote: > On Thu, Aug 28, 2008 at 03:33:26PM -0700, Perry Wagle wrote: > >> But I think I'll still remain wary because 1.6 introduced a nearly >> complete renaming of the API for what, in this thread anyway, >> completely >> silly reasons. If there are good reasons, I haven't seen them. > > I think the reasons have been mentioned a few times. Maybe you just > didn't think they were good. What I saw was "git<DASH><SPACE> produces a list of 143 commands. Long lists are inefficient. Get rid of it!". Actually the list is a hash table in any reasonable shell. So its only aesthetics? Being able to quickly see the list is very useful. That could be done with git<SPACE><TAB>, except some people want that to be lobotomized to show only a fraction of the total. My mind boggles at that one. But see my other post. I'm over it. -- Perry ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 23:22 ` Perry Wagle @ 2008-08-28 23:36 ` Jeff King 0 siblings, 0 replies; 193+ messages in thread From: Jeff King @ 2008-08-28 23:36 UTC (permalink / raw) To: Perry Wagle; +Cc: git [dropping cc's because I think most people don't care about this bit] On Thu, Aug 28, 2008 at 04:22:12PM -0700, Perry Wagle wrote: > What I saw was "git<DASH><SPACE> produces a list of 143 commands. Long > lists are inefficient. Get rid of it!". Actually the list is a hash > table in any reasonable shell. So its only aesthetics? I saw some talk of efficiency, but it was mainly "100,000 files in one directory makes your filesystem performance suck". But maybe somebody talked about the shell. I think there is "143 is too many, and scares new users". And I think there is "systems with hardlink problems ended up with 100+ copies of the git binary, which is big". For the latter, you could still keep git-* with a much smaller wrapper, of course. > Being able to quickly see the list is very useful. That could be done > with git<SPACE><TAB>, except some people want that to be lobotomized to > show only a fraction of the total. My mind boggles at that one. I think there is a recognition that some of the commands aren't really that useful to end users, but are kept around as helpers or as scripts. For example, the interactive mode of "git add" is implemented in perl (while the rest is implemented in C). So it is purely an implementation issue that the script git-add--interactive exists. Nobody should be calling it directly, but rather going through "git add -i", which will call it as necessary with the right command line options. > But see my other post. I'm over it. Good. :) -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 23:04 ` Jeff King 2008-08-28 23:22 ` Perry Wagle @ 2008-08-28 23:24 ` Junio C Hamano 2008-08-28 23:28 ` Perry Wagle ` (2 more replies) 2008-08-29 7:51 ` [kernel.org users] [RFD] On deprecating "git-foo" for builtins Andreas Ericsson 2 siblings, 3 replies; 193+ messages in thread From: Junio C Hamano @ 2008-08-28 23:24 UTC (permalink / raw) To: Jeff King Cc: Perry Wagle, Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, David Woodhouse, git Jeff King <peff@peff.net> writes: >> In March 2008, the sample git-hooks and git-web used git<DASH> commands. >> That was the last I looked at git until Tuesday of this week. > > Yes, and some of the test scripts still have git-* in them. I think in > that respect, the git community has been very bad about eating our own > dog food. Not at all. For one thing, hooks do run under modified PATH, as already pointed out in the earlier thread. Test scripts are executed in a special environment whose GIT_EXEC_PATH points at the top of the build tree, where all git-foo lives. Before anybody greps in Documentation/ to make pointless noises about some dashed-form git-foo in there when we do not talk about what the user types but about a command as a concept in manual pages, they are left in dashed form deliberately, partly to help manpage browsers crosslink across pages. We could have described typographic convention, Cf. http://thread.gmane.org/gmane.comp.version-control.git/86940/focus=87008 but we ended up not doing so. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 23:24 ` Junio C Hamano @ 2008-08-28 23:28 ` Perry Wagle 2008-08-28 23:30 ` Petr Baudis 2008-08-28 23:41 ` git-* in test scripts (was On deprecating "git-foo" for builtins) Jeff King 2 siblings, 0 replies; 193+ messages in thread From: Perry Wagle @ 2008-08-28 23:28 UTC (permalink / raw) To: Junio C Hamano Cc: Jeff King, Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, David Woodhouse, git My (ahem) implied point (sorry) also was that these "hook" scripts act as examples of how to write git scripts in general, and some of them are written to me run as regular scripts. -- Perry On Aug 28, 2008, at 4:24 PM, Junio C Hamano wrote: > Jeff King <peff@peff.net> writes: > >>> In March 2008, the sample git-hooks and git-web used git<DASH> >>> commands. >>> That was the last I looked at git until Tuesday of this week. >> >> Yes, and some of the test scripts still have git-* in them. I think >> in >> that respect, the git community has been very bad about eating our >> own >> dog food. > > Not at all. > > For one thing, hooks do run under modified PATH, as already pointed > out in > the earlier thread. > > Test scripts are executed in a special environment whose GIT_EXEC_PATH > points at the top of the build tree, where all git-foo lives. > > Before anybody greps in Documentation/ to make pointless noises > about some > dashed-form git-foo in there when we do not talk about what the user > types > but about a command as a concept in manual pages, they are left in > dashed > form deliberately, partly to help manpage browsers crosslink across > pages. > > We could have described typographic convention, > > Cf. > > http://thread.gmane.org/gmane.comp.version-control.git/86940/focus=87008 > > but we ended up not doing so. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 23:24 ` Junio C Hamano 2008-08-28 23:28 ` Perry Wagle @ 2008-08-28 23:30 ` Petr Baudis 2008-08-28 23:41 ` git-* in test scripts (was On deprecating "git-foo" for builtins) Jeff King 2 siblings, 0 replies; 193+ messages in thread From: Petr Baudis @ 2008-08-28 23:30 UTC (permalink / raw) To: Junio C Hamano Cc: Jeff King, Perry Wagle, Teemu Likonen, Linus Torvalds, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, David Woodhouse, git On Thu, Aug 28, 2008 at 04:24:50PM -0700, Junio C Hamano wrote: > Before anybody greps in Documentation/ to make pointless noises about some > dashed-form git-foo in there when we do not talk about what the user types > but about a command as a concept in manual pages, they are left in dashed > form deliberately, partly to help manpage browsers crosslink across pages. What is the other part? And is it really worth the confusion? Are the gazillions cases of dashed-form git-foo in there where we DO talk about what the user types "pointless noises" too? (I have argued further in the other mail but somehow we seem to have gone off the list with that subthread, hmm.) Petr "Pasky" Baudis ^ permalink raw reply [flat|nested] 193+ messages in thread
* git-* in test scripts (was On deprecating "git-foo" for builtins) 2008-08-28 23:24 ` Junio C Hamano 2008-08-28 23:28 ` Perry Wagle 2008-08-28 23:30 ` Petr Baudis @ 2008-08-28 23:41 ` Jeff King 2008-08-29 0:04 ` git-* in test scripts Junio C Hamano 2 siblings, 1 reply; 193+ messages in thread From: Jeff King @ 2008-08-28 23:41 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Thu, Aug 28, 2008 at 04:24:50PM -0700, Junio C Hamano wrote: > Test scripts are executed in a special environment whose GIT_EXEC_PATH > points at the top of the build tree, where all git-foo lives. I am not sure how GIT_EXEC_PATH is relevant. We put the git top-level directory in the PATH, which is why "git-foo" works at all in the test scripts. But the install by default does _not_ put those commands in the PATH. So the test scripts serve as a poor example of how to use git. The commands contained within them would not run in an ordinary git installation. -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: git-* in test scripts 2008-08-28 23:41 ` git-* in test scripts (was On deprecating "git-foo" for builtins) Jeff King @ 2008-08-29 0:04 ` Junio C Hamano 2008-08-29 0:10 ` Jeff King 0 siblings, 1 reply; 193+ messages in thread From: Junio C Hamano @ 2008-08-29 0:04 UTC (permalink / raw) To: Jeff King; +Cc: git Jeff King <peff@peff.net> writes: > On Thu, Aug 28, 2008 at 04:24:50PM -0700, Junio C Hamano wrote: > >> Test scripts are executed in a special environment whose GIT_EXEC_PATH >> points at the top of the build tree, where all git-foo lives. > > I am not sure how GIT_EXEC_PATH is relevant. We put the git top-level > directory in the PATH, which is why "git-foo" works at all in the test > scripts. But the install by default does _not_ put those commands in > the PATH. So the test scripts serve as a poor example of how to use > git. The commands contained within them would not run in an ordinary git > installation. Well, I was merely replying to your message. If you admit that tests are special and a poor example, why did you bring it up? ;-) ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: git-* in test scripts 2008-08-29 0:04 ` git-* in test scripts Junio C Hamano @ 2008-08-29 0:10 ` Jeff King 0 siblings, 0 replies; 193+ messages in thread From: Jeff King @ 2008-08-29 0:10 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Thu, Aug 28, 2008 at 05:04:46PM -0700, Junio C Hamano wrote: > Jeff King <peff@peff.net> writes: > > > On Thu, Aug 28, 2008 at 04:24:50PM -0700, Junio C Hamano wrote: > > > >> Test scripts are executed in a special environment whose GIT_EXEC_PATH > >> points at the top of the build tree, where all git-foo lives. > > > > I am not sure how GIT_EXEC_PATH is relevant. We put the git top-level > > directory in the PATH, which is why "git-foo" works at all in the test > > scripts. But the install by default does _not_ put those commands in > > the PATH. So the test scripts serve as a poor example of how to use > > git. The commands contained within them would not run in an ordinary git > > installation. > > Well, I was merely replying to your message. If you admit that tests are > special and a poor example, why did you bring it up? ;-) I don't quite follow you. I think that the tests are actively being used by people to see how they should invoke git, but they are very bad for that, because they are still using the dashed form. So either the people should stop doing that, or the tests should stop using the dashed form. I think the latter is much easier for us to control. I sent a patch for this probably a year ago, but nobody seemed interested. I'm sure it is hopelessly out of date at this point (it was not as easy as a mechanical change because there are other things that look like git-*, like filename arguments to commands). -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 23:04 ` Jeff King 2008-08-28 23:22 ` Perry Wagle 2008-08-28 23:24 ` Junio C Hamano @ 2008-08-29 7:51 ` Andreas Ericsson 2008-08-29 8:05 ` Matthieu Moy 2 siblings, 1 reply; 193+ messages in thread From: Andreas Ericsson @ 2008-08-29 7:51 UTC (permalink / raw) To: Jeff King Cc: Perry Wagle, Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git Jeff King wrote: > On Thu, Aug 28, 2008 at 03:33:26PM -0700, Perry Wagle wrote: > >> I'm going by the reasoning shown in this thread. Why not? I'm looking >> for a way not to have to do exhaustive testing on those scripts, so would >> love to hear it. > > Ultimately you must be the judge of what and how much to test on your > systems. But if you are asking if there are other similar compatibility > bugs in 1.6.0, then my opinion, as somebody who follows the git list > quite closely and contributes some code, is that no, there are not. > There's one, actually. The default pack-index version is increased now, so really, really old clients (pre-1.4.5) won't be able to understand the packs generated by default by a new server. I haven't examined how and when this affect clients, although I believe only those using an ancient client that fetch pre-created packs over dumb transport (http or rsync) repo packed with pack.indexversion = 2, or with 1.6.0 without a pack.indexversion setting at all, will suffer. Encountering that particular scenario should be very rare indeed. Apart from that, I agree with Jeff about there not being any problems regarding compatibility, and I wholeheartedly agree with the hint to start reading the releasenotes. As for suggesting future improvements, perhaps relnotes entries with the slightest chance of breaking anything for anyone could be marked "COMPAT" or something, so Perry and the likes of him can find them easily. I also agree with the suggestion that git itself should be free of a deprecated way of doing things at the deprecation date. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-29 7:51 ` [kernel.org users] [RFD] On deprecating "git-foo" for builtins Andreas Ericsson @ 2008-08-29 8:05 ` Matthieu Moy 2008-08-29 8:23 ` Andreas Ericsson 2008-08-29 8:27 ` Matthias Kestenholz 0 siblings, 2 replies; 193+ messages in thread From: Matthieu Moy @ 2008-08-29 8:05 UTC (permalink / raw) To: Andreas Ericsson Cc: Jeff King, Perry Wagle, Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git Andreas Ericsson <ae@op5.se> writes: > There's one, actually. The default pack-index version is increased now, > so really, really old clients (pre-1.4.5) won't be able to understand > the packs generated by default by a new server. AAUI, the pack itself is sent over the network, but the index is generated locally when receiving the pack, so this shouldn't be a problem. -- Matthieu ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-29 8:05 ` Matthieu Moy @ 2008-08-29 8:23 ` Andreas Ericsson 2008-08-29 8:27 ` Matthias Kestenholz 1 sibling, 0 replies; 193+ messages in thread From: Andreas Ericsson @ 2008-08-29 8:23 UTC (permalink / raw) To: Matthieu Moy Cc: Jeff King, Perry Wagle, Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git Matthieu Moy wrote: > Andreas Ericsson <ae@op5.se> writes: > >> There's one, actually. The default pack-index version is increased now, >> so really, really old clients (pre-1.4.5) won't be able to understand >> the packs generated by default by a new server. > > AAUI, the pack itself is sent over the network, but the index is > generated locally when receiving the pack, so this shouldn't be a > problem. > Which is why I later in the same message pointed out that this should only happen when using dumb protocols where the pack isn't reindexed after it has been fetched. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-29 8:05 ` Matthieu Moy 2008-08-29 8:23 ` Andreas Ericsson @ 2008-08-29 8:27 ` Matthias Kestenholz 2008-08-29 9:02 ` Matthieu Moy 1 sibling, 1 reply; 193+ messages in thread From: Matthias Kestenholz @ 2008-08-29 8:27 UTC (permalink / raw) To: Matthieu Moy Cc: Andreas Ericsson, Jeff King, Perry Wagle, Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Fri, Aug 29, 2008 at 10:05 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote: > Andreas Ericsson <ae@op5.se> writes: > >> There's one, actually. The default pack-index version is increased now, >> so really, really old clients (pre-1.4.5) won't be able to understand >> the packs generated by default by a new server. > > AAUI, the pack itself is sent over the network, but the index is > generated locally when receiving the pack, so this shouldn't be a > problem. > If you use the git or ssh protocol, then yes. If you use dumb protocols such as HTTP or rsync, no. Matthias ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-29 8:27 ` Matthias Kestenholz @ 2008-08-29 9:02 ` Matthieu Moy 0 siblings, 0 replies; 193+ messages in thread From: Matthieu Moy @ 2008-08-29 9:02 UTC (permalink / raw) To: Matthias Kestenholz; +Cc: git "Matthias Kestenholz" <mk@spinlock.ch> writes: >> AAUI, the pack itself is sent over the network, but the index is >> generated locally when receiving the pack, so this shouldn't be a >> problem. > > If you use the git or ssh protocol, then yes. If you use dumb protocols such as > HTTP or rsync, no. Thanks for the clarification, and sorry for the noise then ;-). -- Matthieu ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 22:33 ` Perry Wagle 2008-08-28 23:04 ` Jeff King @ 2008-08-28 23:12 ` Perry Wagle 2008-08-29 15:24 ` Aidan Van Dyk 2008-08-28 23:31 ` Jakub Narebski 2 siblings, 1 reply; 193+ messages in thread From: Perry Wagle @ 2008-08-28 23:12 UTC (permalink / raw) To: Perry Wagle Cc: Jeff King, Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git Jeff King has convinced me that it's perfectly legitimate to introduce non-upward compatibilities in minor version releases of "young" software. My introduction to the problem was Tuesday of this week and this thread. The reasoning that I generally saw in this thread was insane, and it scared me. With some of the feedback I received, I now see a bigger picture where these decisions aren't so willy-nilly. I think the lesson here, however, it that the correct way to have done this is to first remove all the git<DASH>'s from the source, demos, sample, documentation, etc. Second, BIG PAUSE (full minor version release cycle?) Then, third, get rid of git<DASH> in <prefix>/bin. The doctor expects my full recovery tomorrow. 8) Thanks! -- Perry ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 23:12 ` Perry Wagle @ 2008-08-29 15:24 ` Aidan Van Dyk 2008-08-29 16:11 ` Felipe Contreras 0 siblings, 1 reply; 193+ messages in thread From: Aidan Van Dyk @ 2008-08-29 15:24 UTC (permalink / raw) To: Perry Wagle Cc: Jeff King, Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git [-- Attachment #1: Type: text/plain, Size: 1987 bytes --] * Perry Wagle <wagle@cs.indiana.edu> [080801 00:00]: > Jeff King has convinced me that it's perfectly legitimate to introduce > non-upward compatibilities in minor version releases of "young" > software. This is the gist of the problem. You keep hammering about a "non-upwards compatibilities in minor version releases", yet you have *not* pointed out one such in-compatibility in a minor version release.. Remember, in git, 1.6 is a "major version" release, with release notes, etc. 1.5.X is a "minor version" release. 1.5.X.Y is a "patch" release. It's a pretty normal versioning scheme. Git 1.5.X -> Git 1.6.X is a major release upgrade. And the Git 1.5 release notes have claimed for a while that git-<cmd> executibles are going to be moved out of the default path for a while. And the Git 1.6 release notes claimed they were... *And* git developpers have admitted that communication about that pending change was obviously insufficient... But that's a hard problem... How do developers make sure that users are reading release notes? *Especially* in a world where software is packaged up by systems/distros/etc. It's a problem that hits software across the board, linux kernel, PostgreSQL, glibc, gcc, X.org, HylaFAX, and yes, git. Git 1.5.4 has had the "git-exec-dir in path" deprecated for months. How can we do a better job of letting *users* know of the documented stuff in the release notes? Can you imagine the outcry if git was made to look for the config value core.hasreadreleasenotes.<version> on every invocation, and if it wasn't set, forced the releasenotes throught the pager? That way, you woudl have known 6 months ago that git had published release-notes saying that git-exec-dir change was going to happen... -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-29 15:24 ` Aidan Van Dyk @ 2008-08-29 16:11 ` Felipe Contreras 2008-08-29 16:24 ` Aidan Van Dyk 0 siblings, 1 reply; 193+ messages in thread From: Felipe Contreras @ 2008-08-29 16:11 UTC (permalink / raw) To: Aidan Van Dyk Cc: Perry Wagle, Jeff King, Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Fri, Aug 29, 2008 at 6:24 PM, Aidan Van Dyk <aidan@highrise.ca> wrote: > * Perry Wagle <wagle@cs.indiana.edu> [080801 00:00]: >> Jeff King has convinced me that it's perfectly legitimate to introduce >> non-upward compatibilities in minor version releases of "young" >> software. > > This is the gist of the problem. You keep hammering about a > "non-upwards compatibilities in minor version releases", yet you have > *not* pointed out one such in-compatibility in a minor version release.. > > Remember, in git, 1.6 is a "major version" release, with release notes, etc. > 1.5.X is a "minor version" release. > 1.5.X.Y is a "patch" release. What is X (2.0)? -- Felipe Contreras ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-29 16:11 ` Felipe Contreras @ 2008-08-29 16:24 ` Aidan Van Dyk 2008-08-29 16:28 ` Felipe Contreras 0 siblings, 1 reply; 193+ messages in thread From: Aidan Van Dyk @ 2008-08-29 16:24 UTC (permalink / raw) To: Felipe Contreras; +Cc: git [-- Attachment #1: Type: text/plain, Size: 1195 bytes --] * Felipe Contreras <felipe.contreras@gmail.com> [080829 12:11]: > On Fri, Aug 29, 2008 at 6:24 PM, Aidan Van Dyk <aidan@highrise.ca> wrote: > > * Perry Wagle <wagle@cs.indiana.edu> [080801 00:00]: > >> Jeff King has convinced me that it's perfectly legitimate to introduce > >> non-upward compatibilities in minor version releases of "young" > >> software. > > > > This is the gist of the problem. You keep hammering about a > > "non-upwards compatibilities in minor version releases", yet you have > > *not* pointed out one such in-compatibility in a minor version release.. > > > > Remember, in git, 1.6 is a "major version" release, with release notes, etc. > > 1.5.X is a "minor version" release. > > 1.5.X.Y is a "patch" release. > > What is X (2.0)? X would be a digit, like 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9, as in the git 1.5 releases: 1.5.0 1.5.1 1.5.2 1.5.3 1.5.4 1.5.4 1.5.6 And now also: 1.6.0, being the first of the 1.6 releases... a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-29 16:24 ` Aidan Van Dyk @ 2008-08-29 16:28 ` Felipe Contreras 2008-08-29 16:41 ` Aidan Van Dyk 2008-08-30 8:13 ` Andreas Ericsson 0 siblings, 2 replies; 193+ messages in thread From: Felipe Contreras @ 2008-08-29 16:28 UTC (permalink / raw) To: Aidan Van Dyk; +Cc: git On Fri, Aug 29, 2008 at 7:24 PM, Aidan Van Dyk <aidan@highrise.ca> wrote: > * Felipe Contreras <felipe.contreras@gmail.com> [080829 12:11]: >> On Fri, Aug 29, 2008 at 6:24 PM, Aidan Van Dyk <aidan@highrise.ca> wrote: >> > * Perry Wagle <wagle@cs.indiana.edu> [080801 00:00]: >> >> Jeff King has convinced me that it's perfectly legitimate to introduce >> >> non-upward compatibilities in minor version releases of "young" >> >> software. >> > >> > This is the gist of the problem. You keep hammering about a >> > "non-upwards compatibilities in minor version releases", yet you have >> > *not* pointed out one such in-compatibility in a minor version release.. >> > >> > Remember, in git, 1.6 is a "major version" release, with release notes, etc. >> > 1.5.X is a "minor version" release. >> > 1.5.X.Y is a "patch" release. >> >> What is X (2.0)? > > X would be a digit, like 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9, as in the git > 1.5 releases: > 1.5.0 > 1.5.1 > 1.5.2 > 1.5.3 > 1.5.4 > 1.5.4 > 1.5.6 > > And now also: > 1.6.0, being the first of the 1.6 releases... I meant 'X.0.0', if 1.X is major, what is X.0? Huge? -- Felipe Contreras ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-29 16:28 ` Felipe Contreras @ 2008-08-29 16:41 ` Aidan Van Dyk 2008-08-30 8:13 ` Andreas Ericsson 1 sibling, 0 replies; 193+ messages in thread From: Aidan Van Dyk @ 2008-08-29 16:41 UTC (permalink / raw) To: Felipe Contreras; +Cc: git [-- Attachment #1: Type: text/plain, Size: 385 bytes --] * Felipe Contreras <felipe.contreras@gmail.com> [080829 12:28]: > I meant 'X.0.0', if 1.X is major, what is X.0? Huge? Backwards compatible? ;-) -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-29 16:28 ` Felipe Contreras 2008-08-29 16:41 ` Aidan Van Dyk @ 2008-08-30 8:13 ` Andreas Ericsson 1 sibling, 0 replies; 193+ messages in thread From: Andreas Ericsson @ 2008-08-30 8:13 UTC (permalink / raw) To: Felipe Contreras; +Cc: Aidan Van Dyk, git Felipe Contreras wrote: > On Fri, Aug 29, 2008 at 7:24 PM, Aidan Van Dyk <aidan@highrise.ca> wrote: >> * Felipe Contreras <felipe.contreras@gmail.com> [080829 12:11]: >>> On Fri, Aug 29, 2008 at 6:24 PM, Aidan Van Dyk <aidan@highrise.ca> wrote: >>>> * Perry Wagle <wagle@cs.indiana.edu> [080801 00:00]: >>>>> Jeff King has convinced me that it's perfectly legitimate to introduce >>>>> non-upward compatibilities in minor version releases of "young" >>>>> software. >>>> This is the gist of the problem. You keep hammering about a >>>> "non-upwards compatibilities in minor version releases", yet you have >>>> *not* pointed out one such in-compatibility in a minor version release.. >>>> >>>> Remember, in git, 1.6 is a "major version" release, with release notes, etc. >>>> 1.5.X is a "minor version" release. >>>> 1.5.X.Y is a "patch" release. >>> What is X (2.0)? >> X would be a digit, like 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9, as in the git >> 1.5 releases: >> 1.5.0 >> 1.5.1 >> 1.5.2 >> 1.5.3 >> 1.5.4 >> 1.5.4 >> 1.5.6 >> >> And now also: >> 1.6.0, being the first of the 1.6 releases... > > I meant 'X.0.0', if 1.X is major, what is X.0? Huge? > X.0 is "technically backwards incompatible". If, for example, SHA1 turns out to be horribly broken, git might have to be updated to use something else instead. Such a switch would require a version bump from 1.x to 2.x. That might come some day anyway, assuming we decide to make a flag-day and just remove older-version compatibility code from git or some such. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 22:33 ` Perry Wagle 2008-08-28 23:04 ` Jeff King 2008-08-28 23:12 ` Perry Wagle @ 2008-08-28 23:31 ` Jakub Narebski 2 siblings, 0 replies; 193+ messages in thread From: Jakub Narebski @ 2008-08-28 23:31 UTC (permalink / raw) To: Perry Wagle Cc: Jeff King, Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git Perry Wagle <wagle@cs.indiana.edu> writes: > On Aug 28, 2008, at 2:59 PM, Jeff King wrote: > >>> I now have to TEST to find those crazy backwards-incompatibility >>> bugs before I can upgrade us to 1.6.0. To test, I have to try to >>> imagine what I and others were assuming about git. And this >>> episode means that I can't make any assumptions about the sanity >>> of any changes since March, which is the version I'm thinking of >>> upgrading. >>> >>> But note that THIS upward compatibility bug has been declared to >>> not be a bug. Will any others receive the same stamp? >>> >>> So please put on your engineer hat, and stop talking about "specious >>> claims" and hurting feelings. >> - there has been _one_ such problem, and the person responsible for >> vetting such changes has solicited suggestions for doing better in >> the future. I don't think that is indicative of a pattern of such >> changes. > > Ok. My suggestion is that it shouldn't have been done in the first > place, and we should now revert. But others are saying over and over > "its done! live with it!". I came in late. What did I miss in the > last 6 months. Sounds like people have lots of practice with these > water-over-the-dam's, surely this isn't the first time? Errr... what last 6 months? Using "git <cmd>" over "git-<cmd>" (also in scripts) was recommended for a long, long time' much more than those 6 months. Besides, the question stated in this thread was not whether to move "git-*" commands outside $(bindir) (usually '/usr/bin'), but whether to not create or not links (or symlinks, or hardcopy) in gitexecdir. >> - But let's say you have lost some faith in the git development >> process due to _this_ bug. But let's look at the history of this >> bug. It has been discussed several times for the past 2 years, along >> with a mention in the release notes several versions ago. It was not >> a surprise to anybody who has been developing git. > > In March 2008, the sample git-hooks and git-web used git<DASH> > commands. That was the last I looked at git until Tuesday of this > week. As I said earlier in this thread, if by git-web you mean gitweb this is simply not true. _At least_ since commit 25691fb (gitweb: Use --git-dir parameter instead of setting $ENV{'GIT_DIR'}) gitweb used dashless form. > But I think I'll still remain wary because 1.6 introduced a nearly > complete renaming of the API for what, in this thread anyway, > completely silly reasons. If there are good reasons, I haven't seen > them. IIRC the reasons are git wrapper options linke --paginate or --git-dir, equal treatment of git aliases, and cluttering of bindir (which might be ~/bin). -- Jakub Narebski Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 21:23 ` Jeff King 2008-08-28 21:41 ` Perry Wagle @ 2008-08-29 9:33 ` Wincent Colaiuta 2008-08-30 13:24 ` Steven Rostedt 1 sibling, 1 reply; 193+ messages in thread From: Wincent Colaiuta @ 2008-08-29 9:33 UTC (permalink / raw) To: Jeff King Cc: Perry Wagle, Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Steven Rostedt, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git El 28/8/2008, a las 23:23, Jeff King escribió: > I don't think Junio is declaring success. In fact, I think he has sent > several messages saying (paraphrasing of course): > > - this was obviously not done in the best manner possible, because of > the number of people complaining One thing we mustn't lose sight of is that the number of people complaining is that it is utterly insignificant compared to the seething hordes that have complained about the number of git- commands in /usr/bin over the years. We're talking about a dozen or so compared to hundreds. And the change is likely to save us from hundreds more in the future. Cheers, Wincent ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-29 9:33 ` Wincent Colaiuta @ 2008-08-30 13:24 ` Steven Rostedt 2008-08-30 13:50 ` Teemu Likonen 0 siblings, 1 reply; 193+ messages in thread From: Steven Rostedt @ 2008-08-30 13:24 UTC (permalink / raw) To: Wincent Colaiuta Cc: Jeff King, Perry Wagle, Teemu Likonen, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Fri, 29 Aug 2008, Wincent Colaiuta wrote: > El 28/8/2008, a las 23:23, Jeff King escribi?: > > > I don't think Junio is declaring success. In fact, I think he has sent > > several messages saying (paraphrasing of course): > > > > - this was obviously not done in the best manner possible, because of > > the number of people complaining > > One thing we mustn't lose sight of is that the number of people complaining is > that it is utterly insignificant compared to the seething hordes that have > complained about the number of git- commands in /usr/bin over the years. We're > talking about a dozen or so compared to hundreds. And the change is likely to > save us from hundreds more in the future. I have to admit, the first time I saw the git-<tab> result, my first reaction was WTF! But given time, I became use to it, and actually _preferred_ the dash version. So I belonged to both camps. I complained about all the dash options, and I also complained about the dash options going away ;-) Grant you, my complaints were not loud, I just utter some grumbles to git developers that I knew. Lets not look at the number of complaints, but the level each complaint is. My first reaction to the git-<tab><tab> was more of a shock than anything else. So my complaint was very short lived, like someone cutting me off on the highway. But after getting use to the dash version, and having that go away, makes me need to retrain myself to do things another way. This feels more like losing a pet, and complaining about that. This is a much more painful change than having to live with hordes of git commands. -- Steve ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-30 13:24 ` Steven Rostedt @ 2008-08-30 13:50 ` Teemu Likonen 2008-08-30 14:08 ` Steven Rostedt 0 siblings, 1 reply; 193+ messages in thread From: Teemu Likonen @ 2008-08-30 13:50 UTC (permalink / raw) To: Steven Rostedt Cc: Wincent Colaiuta, Jeff King, Perry Wagle, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git Steven Rostedt wrote (2008-08-30 09:24 -0400): > But after getting use to the dash version, and having that go away, > makes me need to retrain myself to do things another way. This feels > more like losing a pet, and complaining about that. This is a much > more painful change than having to live with hordes of git commands. Don't worry, you didn't lose your pet. You have actually two pets now and it has become easier to play with both of them. Just shout PATH="$PATH:$(git --exec-path)" and the older pet will come. However, it's preferred that you mostly show the new one to your neighbours. :-) ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-30 13:50 ` Teemu Likonen @ 2008-08-30 14:08 ` Steven Rostedt 0 siblings, 0 replies; 193+ messages in thread From: Steven Rostedt @ 2008-08-30 14:08 UTC (permalink / raw) To: Teemu Likonen Cc: Wincent Colaiuta, Jeff King, Perry Wagle, Linus Torvalds, Petr Baudis, Kristian H??gsberg, Matthias Kestenholz, Ulrich Windl, Andi Kleen, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Sat, 30 Aug 2008, Teemu Likonen wrote: > Steven Rostedt wrote (2008-08-30 09:24 -0400): > > > But after getting use to the dash version, and having that go away, > > makes me need to retrain myself to do things another way. This feels > > more like losing a pet, and complaining about that. This is a much > > more painful change than having to live with hordes of git commands. > > Don't worry, you didn't lose your pet. You have actually two pets now > and it has become easier to play with both of them. Just shout > > PATH="$PATH:$(git --exec-path)" > > and the older pet will come. However, it's preferred that you mostly > show the new one to your neighbours. Heh, yeah, I saw this. I was just letting people know that the number of complaints do not always measure the level people are complaining about. The complaint I did about seeing the 140 git-* commands was more of a knee-jerk reaction, as suppose to the complaint about git-* going away, which would have been something that would affect me every time I hit '-'. Remember, before Linus stated that the 'git --exec-path' is not going to be deprecated, that was soon to disappear too. -- Steve ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 16:25 ` Petr Baudis 2008-08-26 16:45 ` Andi Kleen @ 2008-08-26 17:07 ` Jeff King 2008-08-26 17:42 ` Teemu Likonen 1 sibling, 1 reply; 193+ messages in thread From: Jeff King @ 2008-08-26 17:07 UTC (permalink / raw) To: Petr Baudis Cc: Matthias Kestenholz, David Woodhouse, Kristian H??gsberg, Junio C Hamano, Johannes Schindelin, git, users On Tue, Aug 26, 2008 at 06:25:13PM +0200, Petr Baudis wrote: > > git-<tab><tab> ... what? 140-something commands? I'll better start looking > > for alternatives _right now_! > > Actually, this is the only realistic argument I can remember at all. > Are there any others? I couldn't come up with any - but I didn't do much > history digging: others seem to be equally in dark, though. The three reasons I can recall are: - too many commands on completion - confusion between "git-*" and "git *" equivalence, and inability to perform some operations with "git-*" (like git --no-pager). - I might be wrong, but I think there was discussion of a hardlink-challenged platform where we wasted space by copying the 'git' binary. Taking git-* out of /usr/bin is the first step to removing the hardlinks entirely. -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 17:07 ` Jeff King @ 2008-08-26 17:42 ` Teemu Likonen 0 siblings, 0 replies; 193+ messages in thread From: Teemu Likonen @ 2008-08-26 17:42 UTC (permalink / raw) To: Jeff King Cc: Petr Baudis, Matthias Kestenholz, David Woodhouse, Kristian Høgsberg, Junio C Hamano, Johannes Schindelin, git, users Jeff King wrote (2008-08-26 13:07 -0400): > On Tue, Aug 26, 2008 at 06:25:13PM +0200, Petr Baudis wrote: > > > > git-<tab><tab> ... what? 140-something commands? I'll better start > > > looking for alternatives _right now_! > > > > Actually, this is the only realistic argument I can remember at all. > > Are there any others? I couldn't come up with any - but I didn't do > > much history digging: others seem to be equally in dark, though. > > The three reasons I can recall are: Don't know about "original" reasons but filling users' ~/bin isn't nice either. I always install all of the self-built git under $HOME. Since "make install" (by default) used to fill ~/bin with those 140 git-* executables I already configured git to install itself to a custom directory. I had to use $GIT_EXEC_PATH and create some symlinks but with 1.6.0 I don't have to do this anymore. Me happy. Setting $GIT_EXEC_PATH wasn't a big deal and I can't see it being a big deal now, for some other people, to extend their $PATH to include every imaginable git-* executable in the system. BTW I'd also vote for reducing the number of commands printed with "git <tab><tab>" bash-completion. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 15:59 ` David Woodhouse 2008-08-26 16:04 ` Matthias Kestenholz @ 2008-08-26 16:17 ` Kristian Høgsberg 2008-08-26 16:23 ` Jean Delvare 2008-08-26 17:03 ` Linus Torvalds 3 siblings, 0 replies; 193+ messages in thread From: Kristian Høgsberg @ 2008-08-26 16:17 UTC (permalink / raw) To: David Woodhouse Cc: Jeff King, Junio C Hamano, Johannes Schindelin, git, users On Tue, 2008-08-26 at 16:59 +0100, David Woodhouse wrote: > On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote: > > It's pretty normal to see opponents of a decision like this complain > > loudly when it lands on their system, whereas the silent majority in > > favour will be happy to see the change finally implemented but reluctant > > to stir up the discussion again. > > > > I don't think new arguments are brought to the discussion, just new > > people, who are temporarily inconvened by a change towards sanity. > > Nice emotive response, especially the subtle but unsubstantiated 'silent > majority in favour' bit -- but you forgot the part where you were > supposed to actually point out a tangible benefit which is achieved by > breaking compatibility like this. Oh get off your high horse, this entire thread is pretty much all bullshit and emotions. Not every arbitrary decision deserves to be set in stone and be defended under the banner of backwards compatibility. Kristian ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 15:59 ` David Woodhouse 2008-08-26 16:04 ` Matthias Kestenholz 2008-08-26 16:17 ` Kristian Høgsberg @ 2008-08-26 16:23 ` Jean Delvare 2008-08-26 16:50 ` Takashi Iwai 2008-08-26 20:14 ` H. Peter Anvin 2008-08-26 17:03 ` Linus Torvalds 3 siblings, 2 replies; 193+ messages in thread From: Jean Delvare @ 2008-08-26 16:23 UTC (permalink / raw) To: David Woodhouse Cc: Kristian Høgsberg, Jeff King, git, Johannes Schindelin, Junio C Hamano, users On Tue, 26 Aug 2008 16:59:58 +0100, David Woodhouse wrote: > On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote: > > It's pretty normal to see opponents of a decision like this complain > > loudly when it lands on their system, whereas the silent majority in > > favour will be happy to see the change finally implemented but reluctant > > to stir up the discussion again. > > > > I don't think new arguments are brought to the discussion, just new > > people, who are temporarily inconvened by a change towards sanity. > > Nice emotive response, especially the subtle but unsubstantiated 'silent > majority in favour' bit -- but you forgot the part where you were > supposed to actually point out a tangible benefit which is achieved by > breaking compatibility like this. > > And no, reducing the size of /usr/bin by a tiny fraction isn't really a > worthwhile benefit -- in reality, the 'silent majority' really couldn't > give a monkey's left testicle about that, and breakage caused by the > gratuitous change _far_ outweighs any minuscule improvement. Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but to the silent majority I am a proud member of, it was. (I'm not saying that the path that was taken to get there was optimal, just that the goal was sound.) I just can't think of any other tool which installs over 100 binaries (or scripts, that's the same) in /usr/bin. Can you? This is simply insane. If all tools did what git did, you'd have maybe 100,000 files in /usr/bin (that is, if your filesystem supports that) and your system would be pretty slow. So I'm very glad to see git come back to reason. If nothing else, just so that other tool authors don't think it's the right way to do it. > It's particularly silly because we could have just made these aliases > optional but present by default, so those few nutters who _really_ spend > their days worrying about such stuff can do without them. -- Jean Delvare ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 16:23 ` Jean Delvare @ 2008-08-26 16:50 ` Takashi Iwai 2008-08-26 17:20 ` Jean Delvare 2008-08-26 20:14 ` H. Peter Anvin 1 sibling, 1 reply; 193+ messages in thread From: Takashi Iwai @ 2008-08-26 16:50 UTC (permalink / raw) To: Jean Delvare Cc: David Woodhouse, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, git At Tue, 26 Aug 2008 18:23:49 +0200, Jean Delvare wrote: > > On Tue, 26 Aug 2008 16:59:58 +0100, David Woodhouse wrote: > > On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote: > > > It's pretty normal to see opponents of a decision like this complain > > > loudly when it lands on their system, whereas the silent majority in > > > favour will be happy to see the change finally implemented but reluctant > > > to stir up the discussion again. > > > > > > I don't think new arguments are brought to the discussion, just new > > > people, who are temporarily inconvened by a change towards sanity. > > > > Nice emotive response, especially the subtle but unsubstantiated 'silent > > majority in favour' bit -- but you forgot the part where you were > > supposed to actually point out a tangible benefit which is achieved by > > breaking compatibility like this. > > > > And no, reducing the size of /usr/bin by a tiny fraction isn't really a > > worthwhile benefit -- in reality, the 'silent majority' really couldn't > > give a monkey's left testicle about that, and breakage caused by the > > gratuitous change _far_ outweighs any minuscule improvement. > > Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but > to the silent majority I am a proud member of, it was. (I'm not saying > that the path that was taken to get there was optimal, just that the > goal was sound.) > > I just can't think of any other tool which installs over 100 binaries > (or scripts, that's the same) in /usr/bin. Can you? netpbm has almost 300 in /usr/bin. Takashi ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 16:50 ` Takashi Iwai @ 2008-08-26 17:20 ` Jean Delvare 2008-08-27 7:42 ` Andreas Ericsson 0 siblings, 1 reply; 193+ messages in thread From: Jean Delvare @ 2008-08-26 17:20 UTC (permalink / raw) To: Takashi Iwai Cc: David Woodhouse, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, git On Tue, 26 Aug 2008 18:50:25 +0200, Takashi Iwai wrote: > At Tue, 26 Aug 2008 18:23:49 +0200, > Jean Delvare wrote: > > > > On Tue, 26 Aug 2008 16:59:58 +0100, David Woodhouse wrote: > > > On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote: > > > > It's pretty normal to see opponents of a decision like this complain > > > > loudly when it lands on their system, whereas the silent majority in > > > > favour will be happy to see the change finally implemented but reluctant > > > > to stir up the discussion again. > > > > > > > > I don't think new arguments are brought to the discussion, just new > > > > people, who are temporarily inconvened by a change towards sanity. > > > > > > Nice emotive response, especially the subtle but unsubstantiated 'silent > > > majority in favour' bit -- but you forgot the part where you were > > > supposed to actually point out a tangible benefit which is achieved by > > > breaking compatibility like this. > > > > > > And no, reducing the size of /usr/bin by a tiny fraction isn't really a > > > worthwhile benefit -- in reality, the 'silent majority' really couldn't > > > give a monkey's left testicle about that, and breakage caused by the > > > gratuitous change _far_ outweighs any minuscule improvement. > > > > Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but > > to the silent majority I am a proud member of, it was. (I'm not saying > > that the path that was taken to get there was optimal, just that the > > goal was sound.) > > > > I just can't think of any other tool which installs over 100 binaries > > (or scripts, that's the same) in /usr/bin. Can you? > > netpbm has almost 300 in /usr/bin. Ouch. (I guess I shouldn't have asked.) Does netpbm do anything convert (ImageMagick) doesn't? I'd be happy to get rid of netpbm. (Sorry for getting off-topic.) -- Jean Delvare ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 17:20 ` Jean Delvare @ 2008-08-27 7:42 ` Andreas Ericsson 2008-08-27 8:21 ` Jean Delvare 0 siblings, 1 reply; 193+ messages in thread From: Andreas Ericsson @ 2008-08-27 7:42 UTC (permalink / raw) To: Jean Delvare Cc: Takashi Iwai, David Woodhouse, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, git Jean Delvare wrote: > On Tue, 26 Aug 2008 18:50:25 +0200, Takashi Iwai wrote: >> At Tue, 26 Aug 2008 18:23:49 +0200, >> Jean Delvare wrote: >>> On Tue, 26 Aug 2008 16:59:58 +0100, David Woodhouse wrote: >>>> On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote: >>>>> It's pretty normal to see opponents of a decision like this complain >>>>> loudly when it lands on their system, whereas the silent majority in >>>>> favour will be happy to see the change finally implemented but reluctant >>>>> to stir up the discussion again. >>>>> >>>>> I don't think new arguments are brought to the discussion, just new >>>>> people, who are temporarily inconvened by a change towards sanity. >>>> Nice emotive response, especially the subtle but unsubstantiated 'silent >>>> majority in favour' bit -- but you forgot the part where you were >>>> supposed to actually point out a tangible benefit which is achieved by >>>> breaking compatibility like this. >>>> >>>> And no, reducing the size of /usr/bin by a tiny fraction isn't really a >>>> worthwhile benefit -- in reality, the 'silent majority' really couldn't >>>> give a monkey's left testicle about that, and breakage caused by the >>>> gratuitous change _far_ outweighs any minuscule improvement. >>> Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but >>> to the silent majority I am a proud member of, it was. (I'm not saying >>> that the path that was taken to get there was optimal, just that the >>> goal was sound.) >>> >>> I just can't think of any other tool which installs over 100 binaries >>> (or scripts, that's the same) in /usr/bin. Can you? >> netpbm has almost 300 in /usr/bin. > > Ouch. (I guess I shouldn't have asked.) > > Does netpbm do anything convert (ImageMagick) doesn't? I'd be happy to > get rid of netpbm. > netpbm-progs (the rpm containing all the 320 programs in /usr/bin) is required for xmlto to function properly, which in turn is necessary to build the git documentation. This is on Fedora 9, btw. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 7:42 ` Andreas Ericsson @ 2008-08-27 8:21 ` Jean Delvare 2008-08-27 15:14 ` Geert Uytterhoeven 0 siblings, 1 reply; 193+ messages in thread From: Jean Delvare @ 2008-08-27 8:21 UTC (permalink / raw) To: Andreas Ericsson Cc: Takashi Iwai, David Woodhouse, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, git On Wed, 27 Aug 2008 09:42:44 +0200, Andreas Ericsson wrote: > Jean Delvare wrote: > > On Tue, 26 Aug 2008 18:50:25 +0200, Takashi Iwai wrote: > >> netpbm has almost 300 in /usr/bin. > > > > Ouch. (I guess I shouldn't have asked.) > > > > Does netpbm do anything convert (ImageMagick) doesn't? I'd be happy to > > get rid of netpbm. > > > > netpbm-progs (the rpm containing all the 320 programs in /usr/bin) is > required for xmlto to function properly, which in turn is necessary > to build the git documentation. > > This is on Fedora 9, btw. On openSuse systems it is required by sax2-gui only. But just because it is used by these 2 packages doesn't mean that ImageMagick's convert can't be used instead. Someone would need to check what exactly xmlto and sax2-gui use in netpbm and whether convert could be used instead. I'd do if I only I had the time... :/ -- Jean Delvare ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 8:21 ` Jean Delvare @ 2008-08-27 15:14 ` Geert Uytterhoeven 0 siblings, 0 replies; 193+ messages in thread From: Geert Uytterhoeven @ 2008-08-27 15:14 UTC (permalink / raw) To: Jean Delvare Cc: Andreas Ericsson, Jeff King, Takashi Iwai, Schindelin, users, Johannes, Kristian Høgsberg, Junio C Hamano, David Woodhouse, git [-- Attachment #1: Type: TEXT/PLAIN, Size: 1731 bytes --] On Wed, 27 Aug 2008, Jean Delvare wrote: > On Wed, 27 Aug 2008 09:42:44 +0200, Andreas Ericsson wrote: > > Jean Delvare wrote: > > > On Tue, 26 Aug 2008 18:50:25 +0200, Takashi Iwai wrote: > > >> netpbm has almost 300 in /usr/bin. > > > > > > Ouch. (I guess I shouldn't have asked.) > > > > > > Does netpbm do anything convert (ImageMagick) doesn't? I'd be happy to > > > get rid of netpbm. > > > > netpbm-progs (the rpm containing all the 320 programs in /usr/bin) is > > required for xmlto to function properly, which in turn is necessary > > to build the git documentation. > > > > This is on Fedora 9, btw. > > On openSuse systems it is required by sax2-gui only. But just because > it is used by these 2 packages doesn't mean that ImageMagick's convert > can't be used instead. Someone would need to check what exactly xmlto > and sax2-gui use in netpbm and whether convert could be used instead. > I'd do if I only I had the time... :/ Great, let's start a witch (nazi? ;-) hunt on any package installing more than $n binaries in /usr/bin, and any packages depending on it... Get used to the `choice' you and I have between netpbm and ImageMagick (and whatever other image manipulation tool), just like the choice between `git<space><subcmd>' and `git-<subcmd>'. Now, let's get back to topic... With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone: +32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: Geert.Uytterhoeven@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 16:23 ` Jean Delvare 2008-08-26 16:50 ` Takashi Iwai @ 2008-08-26 20:14 ` H. Peter Anvin 2008-08-27 7:42 ` Jean Delvare 2008-08-27 8:32 ` [kernel.org users] " Andreas Ericsson 1 sibling, 2 replies; 193+ messages in thread From: H. Peter Anvin @ 2008-08-26 20:14 UTC (permalink / raw) To: Jean Delvare Cc: David Woodhouse, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, git Jean Delvare wrote: > > Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but > to the silent majority I am a proud member of, it was. (I'm not saying > that the path that was taken to get there was optimal, just that the > goal was sound.) > You keep trying to use the Nixon argument ("silent majority.") You *do* know that it was a rhetorical device used by Nixon's speechwriters to push ahead with policies despite compact opposition, don't you? As far as I can tell, most of the arguments in favour came from fanbois of $OTHER_SCM which went along the lines of "why does git need all this stuff in /usr/bin, when $OTHER_SCM doesn't?" It had nothing to do with reality, of course; it was just a difference between git and $OTHER_SCM which they choose to pick on. -hpa ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [RFD] On deprecating "git-foo" for builtins 2008-08-26 20:14 ` H. Peter Anvin @ 2008-08-27 7:42 ` Jean Delvare 2008-08-27 8:32 ` [kernel.org users] " Andreas Ericsson 1 sibling, 0 replies; 193+ messages in thread From: Jean Delvare @ 2008-08-27 7:42 UTC (permalink / raw) To: H. Peter Anvin Cc: erg, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git Hi Peter, On Tue, 26 Aug 2008 13:14:59 -0700, H. Peter Anvin wrote: > Jean Delvare wrote: > > > > Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but > > to the silent majority I am a proud member of, it was. (I'm not saying > > that the path that was taken to get there was optimal, just that the > > goal was sound.) > > You keep trying to use the Nixon argument ("silent majority.") You *do* > know that it was a rhetorical device used by Nixon's speechwriters to > push ahead with policies despite compact opposition, don't you? No, I don't. What I know is that people who are happy about a decision usually don't tell about it and just take it for good and granted and move to something else. You almost always only hear people who are unhappy about decisions. Which means that comparing the amount of noise made by the two groups is not fair. For a fair comparison, you need to ask before doing the change, or if you have already done it, you have to revert it and see if it generates more complaints than the original change did (and even that is not totally fair, as some people will complain because of the double change rather than the decision itself.) Anyway, the "silent majority" is no longer silent. If it were, this discussion thread wouldn't be 60 posts long. > As far as I can tell, most of the arguments in favour came from fanbois > of $OTHER_SCM which went along the lines of "why does git need all this > stuff in /usr/bin, when $OTHER_SCM doesn't?" It had nothing to do with > reality, of course; it was just a difference between git and $OTHER_SCM > which they choose to pick on. I see no point in limiting ourselves to SCMs. There are many other categories of software which have internal commands. I'm using many of these every day: trac, quilt, lftp. The fact is that none of these have a hundred extra entries in /usr/bin as git does. trac has one, quilt has two, lftp has three. So, git does (or used to do) things in a way that differs from most other tools do. OTOH, speaking of SCMs, I clearly remember of an old SCM (was it RCS?) which exposed internal commands "ci" and "co" in the PATH and that caused great frustration to me several times (notice how near the C and V are on the keyboard.) I was very happy to see that this namespace pollution was gone with CVS. Not so happy to see that it was partly back with SVN (9 binaries in /usr/bin). And frankly unhappy to see that it was one order of magnitude worse with git. OK, I'm done with this discussion now. I'm sure everyone involved has better things to spend their time on. -- Jean Delvare ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 20:14 ` H. Peter Anvin 2008-08-27 7:42 ` Jean Delvare @ 2008-08-27 8:32 ` Andreas Ericsson 1 sibling, 0 replies; 193+ messages in thread From: Andreas Ericsson @ 2008-08-27 8:32 UTC (permalink / raw) To: H. Peter Anvin Cc: Jean Delvare, David Woodhouse, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, git H. Peter Anvin wrote: > Jean Delvare wrote: >> >> Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but >> to the silent majority I am a proud member of, it was. (I'm not saying >> that the path that was taken to get there was optimal, just that the >> goal was sound.) >> > > You keep trying to use the Nixon argument ("silent majority.") You *do* > know that it was a rhetorical device used by Nixon's speechwriters to > push ahead with policies despite compact opposition, don't you? > > As far as I can tell, most of the arguments in favour came from fanbois > of $OTHER_SCM which went along the lines of "why does git need all this > stuff in /usr/bin, when $OTHER_SCM doesn't?" It had nothing to do with > reality, of course; it was just a difference between git and $OTHER_SCM > which they choose to pick on. > Well, some new users both here and on #git have been slightly bewildered about the number of commands the default bash-completion show when typing git<tab><tab>. If anything, the move is long overdue, or should have waited until 2.0 where people would expect to have to re-learn quite a lot. There were, initially, two drawbacks with having the git-<commands> outside the users $PATH. The first was performance when used from scripts, which was addressed in November 2005 when the git wrapper was rewritten in C, prior to the 1.0 release. The second is the shell-completion, which was added in September 2006, prior to the 1.5 release. In retrospect, it would probably have been a good thing to make the move with the 1.0 release (which would likely have caused the bash and zsh completion scripts to pop into existence a lot earlier than 1.4.2), or in 1.5, when both reasons for keeping the commands in the path were simply not there anymore. 1.5 was also informally nicknamed "the UI release", so it would have sort of fitted in there, while 1.0 was the first "this is how git will work for the foreseeable future" release, so anything before 1.0 could be considered beta software with a very flexible and fast-moving UI. Worth remembering for the future perhaps, although I know it's easy to overlook the fact that the inertia of the userbase grows exponentially with the headcount of the same. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 15:59 ` David Woodhouse ` (2 preceding siblings ...) 2008-08-26 16:23 ` Jean Delvare @ 2008-08-26 17:03 ` Linus Torvalds 2008-08-26 17:29 ` Bruce Stephens ` (3 more replies) 3 siblings, 4 replies; 193+ messages in thread From: Linus Torvalds @ 2008-08-26 17:03 UTC (permalink / raw) To: David Woodhouse Cc: Kristian Høgsberg, Jeff King, git, Johannes Schindelin, Junio C Hamano, users On Tue, 26 Aug 2008, David Woodhouse wrote: > > Nice emotive response, especially the subtle but unsubstantiated 'silent > majority in favour' bit -- but you forgot the part where you were > supposed to actually point out a tangible benefit which is achieved by > breaking compatibility like this. Umm. The 'git-xyzzy' thing has been one of the #1 complaints since pretty much day#1. The number of people complaining about it going away has literally been _much_ smaller than the people who complained about it being there. Also, like it or not, it's done. So the argument about "compatibility" is TOTAL AND UTTER BULLSHIT. There is no compatibility, because we already released a major version without them. So live with it, and just add the PATH="$PATH:$(git --exec-path)" as a "compatibility layer" to your own setup already. There is no downside, and I think there _is_ a big upside, and no, it's not just about "/usr/bin" being smaller. In case you wonder, the upside is: - new people don't even learn the mistakes - the people who _did_ complain are happier - this model allows a per-user-preference model even on the same machine (ie even on something like master.kernel.org, everybody can choose _individually_ whether they want to see 'git-xyzzy' or not!) and there really is zero downside apart from the _trivial_ downside of you just having to add a single PATH thing to your .bashrc or something. Linus ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 17:03 ` Linus Torvalds @ 2008-08-26 17:29 ` Bruce Stephens 2008-08-26 17:35 ` Petr Baudis 2008-08-26 17:34 ` Takashi Iwai ` (2 subsequent siblings) 3 siblings, 1 reply; 193+ messages in thread From: Bruce Stephens @ 2008-08-26 17:29 UTC (permalink / raw) To: Linus Torvalds Cc: David Woodhouse, Kristian Høgsberg, Jeff King, git, Johannes Schindelin, Junio C Hamano, users Linus Torvalds <torvalds@linux-foundation.org> writes: [...] > In case you wonder, the upside is: > > - new people don't even learn the mistakes > > - the people who _did_ complain are happier > > - this model allows a per-user-preference model even on the same machine > (ie even on something like master.kernel.org, everybody can choose > _individually_ whether they want to see 'git-xyzzy' or not!) And - it means git aliases have the same form as builtins - it means git on Windows has the same interface (Arguably the latter point ought to be "forces Unix users to use the same interface as on Windows", but the git-foo forms have been deprecated on all platforms for a while. Making Unix and Windows the same seems a worthwhile goal, though presumably it's irrelevant for linux kernel people.) ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 17:29 ` Bruce Stephens @ 2008-08-26 17:35 ` Petr Baudis 2008-08-26 17:38 ` Bruce Stephens 2008-08-28 15:21 ` Johannes Schindelin 0 siblings, 2 replies; 193+ messages in thread From: Petr Baudis @ 2008-08-26 17:35 UTC (permalink / raw) To: Bruce Stephens Cc: Linus Torvalds, David Woodhouse, Kristian H?gsberg, Jeff King, git, Johannes Schindelin, Junio C Hamano, users On Tue, Aug 26, 2008 at 06:29:03PM +0100, Bruce Stephens wrote: > - it means git on Windows has the same interface > > (Arguably the latter point ought to be "forces Unix users to use the > same interface as on Windows", but the git-foo forms have been > deprecated on all platforms for a while. Making Unix and Windows the > same seems a worthwhile goal, though presumably it's irrelevant for > linux kernel people.) I actually checked, and my msysgit installation does hardlinking (or at least pretends to do, and ls -l shows high linkcounts). And somewhat amusingly, it doesn't appear that 1.6.0 will be released for Windows anytime soon, though that's of course not relevant from long term perspective. Petr "Pasky" Baudis ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 17:35 ` Petr Baudis @ 2008-08-26 17:38 ` Bruce Stephens 2008-08-28 15:21 ` Johannes Schindelin 1 sibling, 0 replies; 193+ messages in thread From: Bruce Stephens @ 2008-08-26 17:38 UTC (permalink / raw) To: Petr Baudis Cc: Linus Torvalds, David Woodhouse, Kristian H?gsberg, Jeff King, git, Johannes Schindelin, Junio C Hamano, users Petr Baudis <pasky@suse.cz> writes: [...] > I actually checked, and my msysgit installation does hardlinking (or at > least pretends to do, and ls -l shows high linkcounts). And somewhat > amusingly, it doesn't appear that 1.6.0 will be released for Windows > anytime soon, though that's of course not relevant from long term > perspective. IIRC git.exe knows how to run Tcl scripts (maybe perl and shell-scripts), and on Windows you need to use "git gui" and things because "git-gui" won't work. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 17:35 ` Petr Baudis 2008-08-26 17:38 ` Bruce Stephens @ 2008-08-28 15:21 ` Johannes Schindelin 1 sibling, 0 replies; 193+ messages in thread From: Johannes Schindelin @ 2008-08-28 15:21 UTC (permalink / raw) To: Petr Baudis Cc: Bruce Stephens, Linus Torvalds, David Woodhouse, Kristian H?gsberg, Jeff King, git, Junio C Hamano, users Hi, On Tue, 26 Aug 2008, Petr Baudis wrote: > On Tue, Aug 26, 2008 at 06:29:03PM +0100, Bruce Stephens wrote: > > - it means git on Windows has the same interface > > > > (Arguably the latter point ought to be "forces Unix users to use the > > same interface as on Windows", but the git-foo forms have been > > deprecated on all platforms for a while. Making Unix and Windows the > > same seems a worthwhile goal, though presumably it's irrelevant for > > linux kernel people.) > > I actually checked, and my msysgit installation does hardlinking (or at > least pretends to do, and ls -l shows high linkcounts). And somewhat > amusingly, it doesn't appear that 1.6.0 will be released for Windows > anytime soon, though that's of course not relevant from long term > perspective. That is correct. Even more amusingly, it cannot be released ATM because of a breakage _caused_ by the move into libexec: on Windows, we _want_ to be as relocatable as possible, i.e. not having an _absolute_ exec path compiled in. So we use a relative one. And that's the rub: from bin/ (for "git") and from libexec/git/ (for almost all others), there is no single relative path to etc/. Funny, eh? Dscho ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 17:03 ` Linus Torvalds 2008-08-26 17:29 ` Bruce Stephens @ 2008-08-26 17:34 ` Takashi Iwai 2008-08-26 18:09 ` Dominik Brodowski 2008-08-27 0:34 ` A Large Angry SCM 3 siblings, 0 replies; 193+ messages in thread From: Takashi Iwai @ 2008-08-26 17:34 UTC (permalink / raw) To: Linus Torvalds Cc: David Woodhouse, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, git At Tue, 26 Aug 2008 10:03:25 -0700 (PDT), Linus Torvalds wrote: > > > > On Tue, 26 Aug 2008, David Woodhouse wrote: > > > > Nice emotive response, especially the subtle but unsubstantiated 'silent > > majority in favour' bit -- but you forgot the part where you were > > supposed to actually point out a tangible benefit which is achieved by > > breaking compatibility like this. > > Umm. The 'git-xyzzy' thing has been one of the #1 complaints since pretty > much day#1. The number of people complaining about it going away has > literally been _much_ smaller than the people who complained about it > being there. > > Also, like it or not, it's done. So the argument about "compatibility" is > TOTAL AND UTTER BULLSHIT. There is no compatibility, because we already > released a major version without them. Well, you can still install git-* to /usr/bin by specifying gitexecdir=/usr/bin at make. So, the compatibility is not lost. It's just a default configuration issue, IMO. Takashi ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 17:03 ` Linus Torvalds 2008-08-26 17:29 ` Bruce Stephens 2008-08-26 17:34 ` Takashi Iwai @ 2008-08-26 18:09 ` Dominik Brodowski 2008-08-26 18:19 ` Linus Torvalds 2008-08-27 0:34 ` A Large Angry SCM 3 siblings, 1 reply; 193+ messages in thread From: Dominik Brodowski @ 2008-08-26 18:09 UTC (permalink / raw) To: Linus Torvalds Cc: David Woodhouse, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, git Linus, On Tue, Aug 26, 2008 at 10:03:25AM -0700, Linus Torvalds wrote: > > Nice emotive response, especially the subtle but unsubstantiated 'silent > > majority in favour' bit -- but you forgot the part where you were > > supposed to actually point out a tangible benefit which is achieved by > > breaking compatibility like this. > > Umm. The 'git-xyzzy' thing has been one of the #1 complaints since pretty > much day#1. But _why_ do they complain? Just whining or real reasons? > Also, like it or not, it's done. So the argument about "compatibility" is > TOTAL AND UTTER BULLSHIT. There is no compatibility, because we already > released a major version without them. Then release a 1.6.0.1. But the major problem is something else: it's that doing PATH="$PATH:$(git --exec-path) is also deprecated, i.e. that workaround is to go away in one of the next releases too. > - new people don't even learn the mistakes But new people read "git-diff-tree" in the man pages, and then wonder why "git-diff-tree" does not work. People read howtos in the Documentation/ directory and wonder why executing "git-diff-tree" does not work. Besides, why it is a "mistake" to use git-xyzyy? Also, note that 1.5.4.x man pages uses git-xyzzy form in many many places, not hinting at all of git-xyzyy being deprecated. > and there really is zero downside apart from the _trivial_ downside of you > just having to add a single PATH thing to your .bashrc or something. downsides: - man pages. man git-add for the command "git add" is a bit... disappointing. - lots of documentation using "git-xyzyy" - the PATH workaround being deprecated Best, Dominik ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 18:09 ` Dominik Brodowski @ 2008-08-26 18:19 ` Linus Torvalds 2008-08-26 18:55 ` Al Viro ` (3 more replies) 0 siblings, 4 replies; 193+ messages in thread From: Linus Torvalds @ 2008-08-26 18:19 UTC (permalink / raw) To: Dominik Brodowski Cc: David Woodhouse, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, git On Tue, 26 Aug 2008, Dominik Brodowski wrote: > > But _why_ do they complain? Just whining or real reasons? Well, considering that I think the people who complain about the 1.6.0 behaviour are whining, what does it matter? People always think their own concerns are so incredibly important. I always thought that git-xyzzy was fine. After all, I _did_ it that way to begin with. But people complained, and the whole alias thing meant that it couldn't be the primary interface _anyway_, so I changed my opinion. I don't actually personally feel all that strongly, but I _do_ think that right now the git-xyzzy proponents are whining. All of their arguments are pure and utter CRAP, considering the triviality of PATH="$PATH:$(git --exec-path)" Really. I repeat that mantra over and over, exactly because it makes all the whining so _pointless_. Why do people still whine about this? Really? None of the whiners have answered that simple PATH mantra, BECAUSE THEY CANNOT. So when you ask "why do they complain", look at both sides. Both sides complain about totally stupid things. but the FACT is that git-1.6.0 can work either way. So the people who complain about having lost git-xyzzy are the ones that are being stupid. At least the ones who complained about "git-<tab><tab>" being scary had a _point_. > Then release a 1.6.0.1. But the major problem is something else: it's that > doing PATH="$PATH:$(git --exec-path) is also deprecated, i.e. that workaround > is to go away in one of the next releases too. NO, IT IS NOT DEPRECATED. That was a plan. I think that plan got scuttled already. Stop whining! Can't you understand that people can change plans based on feedback? Effing whiners. Linus ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 18:19 ` Linus Torvalds @ 2008-08-26 18:55 ` Al Viro 2008-08-26 19:04 ` Linus Torvalds ` (2 more replies) 2008-08-26 21:08 ` Dominik Brodowski ` (2 subsequent siblings) 3 siblings, 3 replies; 193+ messages in thread From: Al Viro @ 2008-08-26 18:55 UTC (permalink / raw) To: Linus Torvalds Cc: Dominik Brodowski, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git On Tue, Aug 26, 2008 at 11:19:28AM -0700, Linus Torvalds wrote: > but the FACT is that git-1.6.0 can work either way. So the people who > complain about having lost git-xyzzy are the ones that are being stupid. > > At least the ones who complained about "git-<tab><tab>" being scary had a > _point_. Well, to be fair, "man git-add for git add is rather unconventional" is a valid point... FWIW, personally I couldn't care less as long as manpages *are* there and we do not end up with something like "oh, just use info / html / some other weird crap; manpages are not suitable(tm), dontcha know" ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 18:55 ` Al Viro @ 2008-08-26 19:04 ` Linus Torvalds 2008-08-26 19:22 ` Al Viro 2008-08-26 19:11 ` Teemu Likonen 2008-08-28 15:24 ` Johannes Schindelin 2 siblings, 1 reply; 193+ messages in thread From: Linus Torvalds @ 2008-08-26 19:04 UTC (permalink / raw) To: Al Viro Cc: Dominik Brodowski, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git On Tue, 26 Aug 2008, Al Viro wrote: > > Well, to be fair, "man git-add for git add is rather unconventional" is > a valid point... On the other hand: - "man" simply cannot currently handle "man git add", even though there's been some noise to teach it. - you can use "git help add" instead, since git itself does understand this. It will just go "man git-add" for you, so that your fingers don't have to type that dash ;) > FWIW, personally I couldn't care less as long as manpages *are* there and > we do not end up with something like "oh, just use info / html / some other > weird crap; manpages are not suitable(tm), dontcha know" I don't think _that_ is going to happen. You're not the only one who wants man-pages. Linus ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 19:04 ` Linus Torvalds @ 2008-08-26 19:22 ` Al Viro 0 siblings, 0 replies; 193+ messages in thread From: Al Viro @ 2008-08-26 19:22 UTC (permalink / raw) To: Linus Torvalds Cc: Dominik Brodowski, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git On Tue, Aug 26, 2008 at 12:04:51PM -0700, Linus Torvalds wrote: > > > On Tue, 26 Aug 2008, Al Viro wrote: > > > > Well, to be fair, "man git-add for git add is rather unconventional" is > > a valid point... > > On the other hand: > > - "man" simply cannot currently handle "man git add", even though there's > been some noise to teach it. > > - you can use "git help add" instead, since git itself does understand > this. It will just go "man git-add" for you, so that your fingers don't > have to type that dash ;) Yeah... Actually, it all boils down to YAsrbBogosity. Namely, rather dumb conventions for $PATH; it would be much saner if the things worked as for $CDPATH. That is, /<whatever> -> use that as-is ./<whatever> -> use that as-is ../<whatever> -> use that as-is <anything else> -> try to use <path element>/<anything else> for each path element. The difference, of course, is that things like git/subcommand would end up as /usr/bin/git/subcommand, nicely gathering related stuff together in obvious place and keeping the size of /usr/bin down. Without the holy wars about irregular syntax, etc., etc. Not that it had been the worst offense against the sanity and taste that went into sh(1)... ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 18:55 ` Al Viro 2008-08-26 19:04 ` Linus Torvalds @ 2008-08-26 19:11 ` Teemu Likonen 2008-08-28 15:24 ` Johannes Schindelin 2 siblings, 0 replies; 193+ messages in thread From: Teemu Likonen @ 2008-08-26 19:11 UTC (permalink / raw) To: Al Viro Cc: Linus Torvalds, Dominik Brodowski, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git Al Viro wrote (2008-08-26 18:55 +0000): > Well, to be fair, "man git-add for git add is rather unconventional" is > a valid point... True. I'd say that for people familiar with other VCS/SCM tools the "$VCS help add" is probably the primary help interface. It works with many tools - git, hg, svn and bzr at least. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 18:55 ` Al Viro 2008-08-26 19:04 ` Linus Torvalds 2008-08-26 19:11 ` Teemu Likonen @ 2008-08-28 15:24 ` Johannes Schindelin 2 siblings, 0 replies; 193+ messages in thread From: Johannes Schindelin @ 2008-08-28 15:24 UTC (permalink / raw) To: Al Viro Cc: Linus Torvalds, Dominik Brodowski, Kristian Høgsberg, users, Jeff King, Junio C Hamano, David Woodhouse, git Hi, On Tue, 26 Aug 2008, Al Viro wrote: > Well, to be fair, "man git-add for git add is rather unconventional" is > a valid point... If you're prepared for even more whining, you could send a patch that inlines all git commands into Documentation/git.txt... Ducks, Dscho ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 18:19 ` Linus Torvalds 2008-08-26 18:55 ` Al Viro @ 2008-08-26 21:08 ` Dominik Brodowski 2008-08-26 21:28 ` Junio C Hamano 2008-08-26 23:21 ` Perry Wagle 3 siblings, 0 replies; 193+ messages in thread From: Dominik Brodowski @ 2008-08-26 21:08 UTC (permalink / raw) To: Linus Torvalds Cc: David Woodhouse, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, git Linus, On Tue, Aug 26, 2008 at 11:19:28AM -0700, Linus Torvalds wrote: > PATH="$PATH:$(git --exec-path)" > > Really. I repeat that mantra over and over, exactly because it makes all > the whining so _pointless_. It does indeed make it pointless, as long this PATH thing is staying. However, some of the arguments (finally!) mentioned in this thread make me worrying otherwise, for they become moot if this PATH thing stays. Also, > NO, IT IS NOT DEPRECATED. this is the first time -- despite repeated questions -- that the deprecation notice got deprecated. > Can't you understand that people can change plans based on feedback? Indeed I can understand it. If people tell about it. Best, Dominik ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 18:19 ` Linus Torvalds 2008-08-26 18:55 ` Al Viro 2008-08-26 21:08 ` Dominik Brodowski @ 2008-08-26 21:28 ` Junio C Hamano 2008-08-26 21:38 ` Linus Torvalds 2008-08-26 23:21 ` Perry Wagle 3 siblings, 1 reply; 193+ messages in thread From: Junio C Hamano @ 2008-08-26 21:28 UTC (permalink / raw) To: Linus Torvalds Cc: Dominik Brodowski, David Woodhouse, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, git Linus Torvalds <torvalds@linux-foundation.org> writes: >> ... But the major problem is something else: it's that >> doing PATH="$PATH:$(git --exec-path) is also deprecated, i.e. that workaround >> is to go away in one of the next releases too. > > NO, IT IS NOT DEPRECATED. > > That was a plan. I think that plan got scuttled already. Stop whining! > > Can't you understand that people can change plans based on feedback? > > Effing whiners. I do not think "the plan got scuttled *already*" before you said so. It was the purpose for this thread to discuss it. You effectively vetoed the plan with your statement just now, and that settles it. We can now officially declare the plan got scuttled and we can all go back to our happy lives ;-). Thanks. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 21:28 ` Junio C Hamano @ 2008-08-26 21:38 ` Linus Torvalds 0 siblings, 0 replies; 193+ messages in thread From: Linus Torvalds @ 2008-08-26 21:38 UTC (permalink / raw) To: Junio C Hamano Cc: Dominik Brodowski, David Woodhouse, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, git On Tue, 26 Aug 2008, Junio C Hamano wrote: > > I do not think "the plan got scuttled *already*" before you said so. It > was the purpose for this thread to discuss it. > > You effectively vetoed the plan with your statement just now, and that > settles it. I wouldn't say I vetoed i, but wasn't it pretty obvious from the whole discussion that a fair number of people want to keep git-xyzzy? So getting rid of git-xyzzy altogether would seem to be stupid, and not listening to users. So I'm not "vetoing" it, but I don't think git maintainers (past _or_ current ;) have been stupid, or unable to listen to people, and as such I think the end result is pretty obvious. Linus ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 18:19 ` Linus Torvalds ` (2 preceding siblings ...) 2008-08-26 21:28 ` Junio C Hamano @ 2008-08-26 23:21 ` Perry Wagle 2008-08-27 15:27 ` Steven Rostedt 3 siblings, 1 reply; 193+ messages in thread From: Perry Wagle @ 2008-08-26 23:21 UTC (permalink / raw) To: Linus Torvalds Cc: Dominik Brodowski, David Woodhouse, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, Junio C Hamano, git On Aug 26, 2008, at 11:19 AM, Linus Torvalds wrote: > I don't actually personally feel all that strongly, but I _do_ think > that > right now the git-xyzzy proponents are whining. All of their > arguments are > pure and utter CRAP, considering the triviality of > > PATH="$PATH:$(git --exec-path)" Scripts. Remote scripts. Scripts running as arbitrary users. I'm trying to upgrade the git that our scripts use, and having the users modify their paths doesn't work. Not that horrible to fix some other way, but still a rude thing to wake up to one day. (ie, today) -- Perry Wagle (wagle@mac.com) ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 23:21 ` Perry Wagle @ 2008-08-27 15:27 ` Steven Rostedt 2008-08-27 23:09 ` Russell King 0 siblings, 1 reply; 193+ messages in thread From: Steven Rostedt @ 2008-08-27 15:27 UTC (permalink / raw) To: Perry Wagle Cc: Linus Torvalds, Kristian Høgsberg, Johannes Schindelin, users, Jeff King, Dominik Brodowski, Junio C Hamano, David Woodhouse, git On Tue, 26 Aug 2008, Perry Wagle wrote: > > I'm trying to upgrade the git that our scripts use, and having the > users modify their paths doesn't work. > > Not that horrible to fix some other way, but still a rude thing to > wake up to one day. (ie, today) > Did you see the yellow bulldozer coming at your house while brushing your teeth? -- Steve ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 15:27 ` Steven Rostedt @ 2008-08-27 23:09 ` Russell King 2008-08-27 23:53 ` Stefan Richter 2008-08-28 1:25 ` Steven Rostedt 0 siblings, 2 replies; 193+ messages in thread From: Russell King @ 2008-08-27 23:09 UTC (permalink / raw) To: Steven Rostedt Cc: Perry Wagle, Kristian Høgsberg, David Woodhouse, Dominik Brodowski, users, Jeff King, Johannes Schindelin, Junio C Hamano, Linus Torvalds, git On Wed, Aug 27, 2008 at 11:27:04AM -0400, Steven Rostedt wrote: > > On Tue, 26 Aug 2008, Perry Wagle wrote: > > > > I'm trying to upgrade the git that our scripts use, and having the > > users modify their paths doesn't work. > > > > Not that horrible to fix some other way, but still a rude thing to > > wake up to one day. (ie, today) > > > > Did you see the yellow bulldozer coming at your house while brushing your > teeth? That is not a valid point of view when you're a git user, and things suddenly change from working one day, to not working the next _and_ you don't know why the commands you were using have suddenly vanished. And there is no documentation seemingly available to tell you what to use instead. And the available documentation tells you that the commands you were using are still there. And no warnings before hand that the commands you were using were deprecated. *That* is what is soo abhorrent about this whole business. How would you feel if, tomorrow, 'ls', 'tar' etc all gave you "command not found", 'man ls' still gave you a man page for ls(1) but the command was now actually called 'listfiles' instead ? Just put 'alias ls=listfiles' in your .bashrc ! -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 23:09 ` Russell King @ 2008-08-27 23:53 ` Stefan Richter 2008-08-28 19:19 ` Russell King 2008-08-28 1:25 ` Steven Rostedt 1 sibling, 1 reply; 193+ messages in thread From: Stefan Richter @ 2008-08-27 23:53 UTC (permalink / raw) To: Russell King Cc: Steven Rostedt, Kristian Høgsberg, Linus Torvalds, Dominik Brodowski, users, Jeff King, Perry Wagle, Johannes Schindelin, Junio C Hamano, David Woodhouse, git Russell King wrote: > And no warnings before hand that the commands you were using were > deprecated. (a) They weren't deprecated, they were moved into a different directory. (b) There have been several announcements of the 1.6.0 prereleases and the 1.6.0 release crossposted. Of course somebody forgot to tell you what you will learn from these release notes. Unfair. (c) There do happen unannounced software updates on shell servers over which you don't have control. Ask for your money back. (d) "-" -> " "? Molehill. -- Stefan Richter -=====-==--- =--- ===-- http://arcgraph.de/sr/ ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 23:53 ` Stefan Richter @ 2008-08-28 19:19 ` Russell King 2008-08-28 20:10 ` Junio C Hamano 2008-08-28 20:57 ` Stefan Richter 0 siblings, 2 replies; 193+ messages in thread From: Russell King @ 2008-08-28 19:19 UTC (permalink / raw) To: Stefan Richter Cc: Steven Rostedt, Kristian Høgsberg, Linus Torvalds, Dominik Brodowski, users, Jeff King, Perry Wagle, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Thu, Aug 28, 2008 at 01:53:50AM +0200, Stefan Richter wrote: > Russell King wrote: > >And no warnings before hand that the commands you were using were > >deprecated. > > (a) They weren't deprecated, they were moved into a different directory. I think Junio will tell you differently on the "deprecation" bit. > (b) There have been several announcements of the 1.6.0 prereleases and > the 1.6.0 release crossposted. Of course somebody forgot to tell you > what you will learn from these release notes. Unfair. Cross posting to high traffic mailing lists doesn't guarantee that it'll be read. It's the wrong place to do it. Arguably, though, the lack of information to users on the system affected is not git maintainers fault. It's the fault of the admins on that system not having read the release notes themselves, and warning their users (for whom git is a *critical* bit of software) that an upgrade is going to take place, and they should read such-and-such. Like a note in the system MOTD. > (c) There do happen unannounced software updates on shell servers over > which you don't have control. Ask for your money back. > > (d) "-" -> " "? Molehill. "ls" -> "listfiles" - how would you feel about that change happening behind your back? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 19:19 ` Russell King @ 2008-08-28 20:10 ` Junio C Hamano 2008-08-28 20:30 ` Matthew Wilcox 2008-08-28 20:36 ` Petr Baudis 2008-08-28 20:57 ` Stefan Richter 1 sibling, 2 replies; 193+ messages in thread From: Junio C Hamano @ 2008-08-28 20:10 UTC (permalink / raw) To: Russell King Cc: Stefan Richter, Steven Rostedt, Kristian Høgsberg, Linus Torvalds, Dominik Brodowski, users, Jeff King, Perry Wagle, Johannes Schindelin, David Woodhouse, git Russell King <rmk@arm.linux.org.uk> writes: > On Thu, Aug 28, 2008 at 01:53:50AM +0200, Stefan Richter wrote: >> Russell King wrote: >> >And no warnings before hand that the commands you were using were >> >deprecated. >> >> (a) They weren't deprecated, they were moved into a different directory. > > I think Junio will tell you differently on the "deprecation" bit. The short answer is "no, not anymore". I might have ;-), if you asked me a few days ago, and the topic of this thread was exactly to decide the answer to that question, which was concluded with $gmane/93793. >> (b) There have been several announcements of the 1.6.0 prereleases and >> the 1.6.0 release crossposted. Of course somebody forgot to tell you >> what you will learn from these release notes. Unfair. > > Cross posting to high traffic mailing lists doesn't guarantee that > it'll be read. It's the wrong place to do it. > > Arguably, though, the lack of information to users on the system affected > is not git maintainers fault. It's the fault of the admins on that system > not having read the release notes themselves, and warning their users (for > whom git is a *critical* bit of software) that an upgrade is going to take > place, and they should read such-and-such. > > Like a note in the system MOTD. I've heard enough of "the changes in 1.6.0 was underadvertised and caused users pain". I am now aware that git has more mature and its userbase has broadened beyond populations that read release notes (I rarely read release notes to updates to vim or coreutils either, and that is showing the maturity of the packages -- nothing to complain about and I am not complaining). But so far nobody gave "here is how I would have advertised it", until you wrote above. Thanks. But that is not something _I_ could have done (and no, "I wouldn't have accepted the change" is not an option at this point). Are there things that the maintainer could have done better? I think it is fair to say that I have vetoed and am still vetoing many "UI clean-ups" that propose to change things in a way that "should have been this way for consistency's sake from day one, if there were no existing user base". During discussions to shoot down such proposals, I take opinions from early adopters (that's you, kernel, wine and x.org people) very seriously, perhaps to the point that outsiders would feel I am giving them disproportionately large vetoing power. Sadly, those "opinions from eraly adopters" are less and less "real" but more "I'd imagine the early adopters would say..." these days. The process would work better if early adopters do their part to help me by speaking up when it matters from time to time. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 20:10 ` Junio C Hamano @ 2008-08-28 20:30 ` Matthew Wilcox 2008-08-28 20:36 ` Petr Baudis 1 sibling, 0 replies; 193+ messages in thread From: Matthew Wilcox @ 2008-08-28 20:30 UTC (permalink / raw) To: Junio C Hamano Cc: Russell King, Kristian H??gsberg, David Woodhouse, Johannes Schindelin, Dominik Brodowski, users, Jeff King, Perry Wagle, Stefan Richter, Steven Rostedt, Linus Torvalds, git On Thu, Aug 28, 2008 at 01:10:14PM -0700, Junio C Hamano wrote: > I think it is fair to say that I have vetoed and am still vetoing many "UI > clean-ups" that propose to change things in a way that "should have been > this way for consistency's sake from day one, if there were no existing > user base". During discussions to shoot down such proposals, I take > opinions from early adopters (that's you, kernel, wine and x.org people) > very seriously, perhaps to the point that outsiders would feel I am giving > them disproportionately large vetoing power. Sadly, those "opinions from > eraly adopters" are less and less "real" but more "I'd imagine the early > adopters would say..." these days. The process would work better if early > adopters do their part to help me by speaking up when it matters from time > to time. I think it's fairly clear by now that we aren't shy about sharing our opinions ... if we're asked for them. So do we need a git-oldtimers mailing list where you can post proposals so we can NACK them? -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 20:10 ` Junio C Hamano 2008-08-28 20:30 ` Matthew Wilcox @ 2008-08-28 20:36 ` Petr Baudis 1 sibling, 0 replies; 193+ messages in thread From: Petr Baudis @ 2008-08-28 20:36 UTC (permalink / raw) To: Junio C Hamano Cc: Russell King, Kristian H??gsberg, David Woodhouse, Johannes Schindelin, Dominik Brodowski, users, Jeff King, Perry Wagle, Stefan Richter, Steven Rostedt, Linus Torvalds, git On Thu, Aug 28, 2008 at 01:10:14PM -0700, Junio C Hamano wrote: > I think it is fair to say that I have vetoed and am still vetoing many "UI > clean-ups" that propose to change things in a way that "should have been > this way for consistency's sake from day one, if there were no existing > user base". During discussions to shoot down such proposals, I take > opinions from early adopters (that's you, kernel, wine and x.org people) > very seriously, perhaps to the point that outsiders would feel I am giving > them disproportionately large vetoing power. Sadly, those "opinions from > eraly adopters" are less and less "real" but more "I'd imagine the early > adopters would say..." these days. The process would work better if early > adopters do their part to help me by speaking up when it matters from time > to time. I think just freezing the UI is not a good answer. Git's UI evolved too wildly and uncontrollably in the early days and I think in the long run, tweaking out at least some of the inconsistencies is good idea, IMHO. Not that I would think there should be any more *major* changes upcoming, I mean mostly small stuff (all that I hate the git-checkout/git-reset dichotomy or git-add/git-rm asymetry, touching this would be just too radical change by now, IMHO). The only problem I can see with the transition were the deprecation messages, as was mentioned much earlier in the thread. If it's going away in few years, Git should start to nag about it now. Then, all whom it concerns _will_ realize this and slowly transition at their own pace. Also, maybe we should require all internal references and documentation updated when *declaring the feature deprecated* (not when removing it), even if it means delaying the phase-out; that was the other major complaint in this thread that is worth remembering, I believe. -- Petr "Pasky" Baudis The next generation of interesting software will be done on the Macintosh, not the IBM PC. -- Bill Gates ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 19:19 ` Russell King 2008-08-28 20:10 ` Junio C Hamano @ 2008-08-28 20:57 ` Stefan Richter 2008-08-28 21:05 ` Perry Wagle 1 sibling, 1 reply; 193+ messages in thread From: Stefan Richter @ 2008-08-28 20:57 UTC (permalink / raw) To: Russell King Cc: Steven Rostedt, Kristian Høgsberg, Linus Torvalds, Dominik Brodowski, Jeff King, Perry Wagle, Johannes Schindelin, Junio C Hamano, David Woodhouse, git Russell King wrote: > On Thu, Aug 28, 2008 at 01:53:50AM +0200, Stefan Richter wrote: >> "-" -> " "? Molehill. > > "ls" -> "listfiles" - how would you feel about that change happening > behind your back? I would feel betrayed, then add another alias to .bashrc, then feel deeply satisfied by my cunning betrayal of the betrayers, knowing that only a true genius hacker could come up with a countermeasure like that. -- Stefan Richter -=====-==--- =--- ===-- http://arcgraph.de/sr/ ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 20:57 ` Stefan Richter @ 2008-08-28 21:05 ` Perry Wagle 0 siblings, 0 replies; 193+ messages in thread From: Perry Wagle @ 2008-08-28 21:05 UTC (permalink / raw) To: Stefan Richter Cc: Russell King, Steven Rostedt, Kristian Høgsberg, Linus Torvalds, Dominik Brodowski, Jeff King, Johannes Schindelin, Junio C Hamano, David Woodhouse, git On Aug 28, 2008, at 1:57 PM, Stefan Richter wrote: > Russell King wrote: >> On Thu, Aug 28, 2008 at 01:53:50AM +0200, Stefan Richter wrote: >>> "-" -> " "? Molehill. >> "ls" -> "listfiles" - how would you feel about that change happening >> behind your back? > > I would feel betrayed, then add another alias to .bashrc, then feel > deeply satisfied by my cunning betrayal of the betrayers, knowing > that only a true genius hacker could come up with a countermeasure > like that. When I started with VMS (ahem) years ago, my buddies handed me eunice (a unix like environment) and a big bag of aliases to make my environment look like unix. I did this for years and was happy. But one day I lost my command shell init scripts, and was left to fend for myself with pure VMS commands. I was completely helpless. Moral: never again will I customize my programming environment to that extent. Your solution is that sort of over-customization. Sticking git's libexec in your path is too. I'm still allergic. -- Perry PS. </offtopic> ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 23:09 ` Russell King 2008-08-27 23:53 ` Stefan Richter @ 2008-08-28 1:25 ` Steven Rostedt 1 sibling, 0 replies; 193+ messages in thread From: Steven Rostedt @ 2008-08-28 1:25 UTC (permalink / raw) To: Russell King Cc: Perry Wagle, Kristian Høgsberg, David Woodhouse, Dominik Brodowski, Jeff King, Johannes Schindelin, Junio C Hamano, Linus Torvalds, git On Thu, 28 Aug 2008, Russell King wrote: > On Wed, Aug 27, 2008 at 11:27:04AM -0400, Steven Rostedt wrote: > > > > On Tue, 26 Aug 2008, Perry Wagle wrote: > > > > > > I'm trying to upgrade the git that our scripts use, and having the > > > users modify their paths doesn't work. > > > > > > Not that horrible to fix some other way, but still a rude thing to > > > wake up to one day. (ie, today) > > > > > > > Did you see the yellow bulldozer coming at your house while brushing your > > teeth? > > That is not a valid point of view when you're a git user, and things > suddenly change from working one day, to not working the next _and_ > you don't know why the commands you were using have suddenly vanished. > > And there is no documentation seemingly available to tell you what to > use instead. I think you may have totally missed my reference to the beginning of "The Hitchhikers Guide to the Galaxy", where Aurther saw the Bulldozer about to destroy his house. As he layed in front of the bulldozer, he was told that he had plenty of time to complain. Aurther replied that the posting was in some strange hidden location. Kind of like what release notes are. But I digress, this thread is totally offtopic for users@kernel.org, can we finally take it off (as I just did). -- Steve > > And the available documentation tells you that the commands you were > using are still there. > > And no warnings before hand that the commands you were using were > deprecated. > > *That* is what is soo abhorrent about this whole business. > > How would you feel if, tomorrow, 'ls', 'tar' etc all gave you "command > not found", 'man ls' still gave you a man page for ls(1) but the > command was now actually called 'listfiles' instead ? > > Just put 'alias ls=listfiles' in your .bashrc ! > > -- > Russell King > Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ > maintainer of: > ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 17:03 ` Linus Torvalds ` (2 preceding siblings ...) 2008-08-26 18:09 ` Dominik Brodowski @ 2008-08-27 0:34 ` A Large Angry SCM 3 siblings, 0 replies; 193+ messages in thread From: A Large Angry SCM @ 2008-08-27 0:34 UTC (permalink / raw) To: Linus Torvalds Cc: David Woodhouse, Kristian Høgsberg, Jeff King, git, Johannes Schindelin, Junio C Hamano, users Linus Torvalds wrote: > > So live with it, and just add the > > PATH="$PATH:$(git --exec-path)" > > as a "compatibility layer" to your own setup already. There is no > downside, and I think there _is_ a big upside, and no, it's not just about > "/usr/bin" being smaller. Actually, this is acceptable since I set gitexecdir to $(bindir) in my make invocation. *BUT* the recent discussion of not creating the hardlinks in git/core/libexec, introducing obnoxious warnings when using the dashed forms, and eventually having the git binary error when invoked as a dashed command is NOT acceptable. The discussion that happened in November and December 2006 was only about about moving the executables out of /usr/bin, not the completely disabling of the dashed forms for those users and distributions that want them. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 15:34 ` Kristian Høgsberg 2008-08-26 15:59 ` David Woodhouse @ 2008-08-27 12:23 ` Krzysztof Halasa 1 sibling, 0 replies; 193+ messages in thread From: Krzysztof Halasa @ 2008-08-27 12:23 UTC (permalink / raw) To: Kristian Høgsberg Cc: Jeff King, git, David Woodhouse, Johannes Schindelin, Junio C Hamano, users Kristian Høgsberg <krh@redhat.com> writes: > It's pretty normal to see opponents of a decision like this complain > loudly when it lands on their system, whereas the silent majority in > favour will be happy to see the change finally implemented but reluctant > to stir up the discussion again. I'm "sure" the silent majority don't care at all. Git is a program mostly for a specialized group of people who are perfectly capable of using either model or customizing the installation at will. It may be a correctness issue with pro and cons for each model (something along the lines of "how many devils..."), but it doesn't matter for the (I'm sure) "silent majority" in practice at all. Writing this email (let alone reading them all) takes more time than customizing git config. -- Krzysztof Halasa ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 14:57 ` Jeff King 2008-08-26 15:34 ` Kristian Høgsberg @ 2008-08-26 20:39 ` Junio C Hamano 2008-08-26 21:03 ` Jeff King ` (3 more replies) 1 sibling, 4 replies; 193+ messages in thread From: Junio C Hamano @ 2008-08-26 20:39 UTC (permalink / raw) To: Jeff King; +Cc: Johannes Schindelin, David Woodhouse, git, users Jeff King <peff@peff.net> writes: > On Mon, Aug 25, 2008 at 04:41:57PM -0700, Junio C Hamano wrote: > >> > Umm. What exactly makes you feel you should ignore the discussions we had >> > around the issues on the git and msysgit mailing list? >> >> Well, this was partly my fault, as I did not make it clear in this part >> that beating the horse that has been dead for two years is not a >> productive way to spend out time. I however did, in the part David did >> not quote, try to make it clear: >> >> That's all history now anyway. We should try to do better the next time, >> which is much more important, and that is the topic of this message. > > I don't want to stir up this discussion too much; I am sure you have > many more important things to be working on. But I did want to make one > observation. > > One side of the argument, I see a lot of "I would prefer it this way." > And on the other side I see a lot of "this discussion is already > history" and "but I do not care personally that much." > > It makes me wonder why nobody has said "no, really, I prefer it without > the programs in /bin." Are they simply confident that the decision has > been made, and don't feel the need to say something? To me, one of the two saddest part of this story is this. I was among the "don't change anything, get used to it just like old timers are already used to" camp, when people said that having many commands in /usr/bin (or $HOME/bin) would scare people and pushed for this change, around the end of 2005 through early 2006. The pros-and-cons wasn't clearly cut-and-dried. Moving out of /usr/bin has slight technical merits (e.g. "bash completion not showing 150+ commands but only selected Porcelains", "not scaring people off", "dashless form is needed if you want to use global options", and "moving away from dashed form will eventually let us get rid of copies on systems without hardlinks even from under /usr/libexec/git-core"). But I do not think the advantage was so great. When I hear something like what David Woodhouse said in this thread, I should be feeling "People -- those of you who claimed to be the silent majority -- see, I told you so! This is a very bad move". But I can't. People who complain _now_ just annoy me even more. Why weren't you defending the backward compatibility with me, which you seem to value it so much, perhaps even more than I did back then? Why are you wasting our time bringing it up again, instead of joining the discussion when it _mattered_ back then? And I still think there is no great reason to pick one way or the other. Having everything in /usr/bin does not have any better reason than "it has been that way from the beginning", and that certainly is not a reason strong enough to revert this anymore, as the opposition now has "the latest and greatest was shipped with the new layout" which is an equally valid argument. Another, even more sad part of this story is that the thread was confused into talking about the change that has already happened, which is a total offtopic, and wasted even more time from people. Read the subject line again, and notice that we are not talking about /usr/bin vs /usr/libexec/git-core; the request-for-discussion was about removing "git-add" and friends from /usr/libexec/git-core/, so that we do not have to even have these many hardlinks there. Except for Linus (and obviously myself who started the thread), I saw nobody expressed any opinion on it. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 20:39 ` Junio C Hamano @ 2008-08-26 21:03 ` Jeff King 2008-08-27 2:24 ` Jay Soffian 2008-08-26 23:36 ` Perry Wagle ` (2 subsequent siblings) 3 siblings, 1 reply; 193+ messages in thread From: Jeff King @ 2008-08-26 21:03 UTC (permalink / raw) To: Junio C Hamano; +Cc: Johannes Schindelin, David Woodhouse, git, users On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote: > But I can't. People who complain _now_ just annoy me even more. Why > weren't you defending the backward compatibility with me, which you seem > to value it so much, perhaps even more than I did back then? Why are you > wasting our time bringing it up again, instead of joining the discussion > when it _mattered_ back then? Yes, I was hoping my message would help provoke them to say "here is why I did not do it back then, and why this should be revisited now". But all it seems to have done is bring up more arguments that should have been given back then. So for that I apologize, since I know that is exactly what you did not want to read. ;) > Read the subject line again, and notice that we are not talking about > /usr/bin vs /usr/libexec/git-core; the request-for-discussion was about > removing "git-add" and friends from /usr/libexec/git-core/, so that we do > not have to even have these many hardlinks there. Except for Linus (and > obviously myself who started the thread), I saw nobody expressed any > opinion on it. I was slightly negative on the change at the time of "/usr/bin vs /usr/libexec/git-core" and I planned to put "git --exec-path" in my PATH. But I gave the new way a try, and I have not been very bothered. So let me say that I really don't care much what happens with libexec, and you can hold me to that when the next flame-war breaks out if such a change is implemented. Now you have three opinions. :) I really was just concerned that we are rejecting legitimate, popular concerns because of a grumpy "you missed the deadline" stance, when perhaps there is a good reason (which I am still waiting to hear) that those concerns missed the deadline. -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 21:03 ` Jeff King @ 2008-08-27 2:24 ` Jay Soffian 2008-08-27 14:49 ` H. Peter Anvin 0 siblings, 1 reply; 193+ messages in thread From: Jay Soffian @ 2008-08-27 2:24 UTC (permalink / raw) To: Jeff King Cc: Junio C Hamano, Johannes Schindelin, David Woodhouse, git, users On Tue, Aug 26, 2008 at 5:03 PM, Jeff King <peff@peff.net> wrote: > I was slightly negative on the change at the time of "/usr/bin vs > /usr/libexec/git-core" and I planned to put "git --exec-path" in my > PATH. But I gave the new way a try, and I have not been very bothered. > So let me say that I really don't care much what happens with libexec, > and you can hold me to that when the next flame-war breaks out if such a > change is implemented. Now you have three opinions. :) +1 on removing the links and I will say this: this change finally motivated me to switch my login shell from tcsh (12 years I've been using it!) to bash so I could use the completions and I'm happier for it. So thank you git. :-) j. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 2:24 ` Jay Soffian @ 2008-08-27 14:49 ` H. Peter Anvin 0 siblings, 0 replies; 193+ messages in thread From: H. Peter Anvin @ 2008-08-27 14:49 UTC (permalink / raw) To: Jay Soffian Cc: Jeff King, git, David Woodhouse, Johannes Schindelin, Junio C Hamano, users Jay Soffian wrote: > On Tue, Aug 26, 2008 at 5:03 PM, Jeff King <peff@peff.net> wrote: >> I was slightly negative on the change at the time of "/usr/bin vs >> /usr/libexec/git-core" and I planned to put "git --exec-path" in my >> PATH. But I gave the new way a try, and I have not been very bothered. >> So let me say that I really don't care much what happens with libexec, >> and you can hold me to that when the next flame-war breaks out if such a >> change is implemented. Now you have three opinions. :) > > +1 on removing the links and I will say this: this change finally > motivated me to switch my login shell from tcsh (12 years I've been > using it!) to bash so I could use the completions and I'm happier for > it. So thank you git. :-) > Speaking as a tcsh user, I'm not switching until bash gets the equivalent functionality as tcsh aliases, in particular the ability to selectively disable wildcard expansion on a command-by-command basis. -hpa ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 20:39 ` Junio C Hamano 2008-08-26 21:03 ` Jeff King @ 2008-08-26 23:36 ` Perry Wagle 2008-08-26 23:45 ` Nicolas Pitre 2008-08-27 0:17 ` Matthew Wilcox 3 siblings, 0 replies; 193+ messages in thread From: Perry Wagle @ 2008-08-26 23:36 UTC (permalink / raw) To: Junio C Hamano Cc: Jeff King, Johannes Schindelin, David Woodhouse, git, users On Aug 26, 2008, at 1:39 PM, Junio C Hamano wrote: > But I can't. People who complain _now_ just annoy me even more. Why > weren't you defending the backward compatibility with me, which you > seem > to value it so much, perhaps even more than I did back then? Why > are you > wasting our time bringing it up again, instead of joining the > discussion > when it _mattered_ back then? I wasn't around back then. I came in a year ago to write some git scripts (mostly for hooks). I saw that lots of scripts (including gitweb and the sample hooks) used the git- form, and some didn't. I found that I liked the git- form, since it permitted command and man page name completion, so I did that. Today I literally wake up to find that I now gotta go fix all those scripts, upgrade git-web, and whatever other *scripts* used the now obsolete git- form. Sorry, I skim the git list every week or three. The doctor says I'll live, and be back to health in a few hours. But there will be a doctor bill. Can I send it to you? 8) -- Perry Wagle (wagle@mac.com) ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 20:39 ` Junio C Hamano 2008-08-26 21:03 ` Jeff King 2008-08-26 23:36 ` Perry Wagle @ 2008-08-26 23:45 ` Nicolas Pitre 2008-08-28 15:32 ` Johannes Schindelin 2008-08-27 0:17 ` Matthew Wilcox 3 siblings, 1 reply; 193+ messages in thread From: Nicolas Pitre @ 2008-08-26 23:45 UTC (permalink / raw) To: Junio C Hamano Cc: Jeff King, Johannes Schindelin, David Woodhouse, git, users On Tue, 26 Aug 2008, Junio C Hamano wrote: > Read the subject line again, and notice that we are not talking about > /usr/bin vs /usr/libexec/git-core; the request-for-discussion was about > removing "git-add" and friends from /usr/libexec/git-core/, so that we do > not have to even have these many hardlinks there. Except for Linus (and > obviously myself who started the thread), I saw nobody expressed any > opinion on it. Don't deprecate git-foo and leave them in $gitexecdir as things are now. That's the best compromise IMHO. Those who want git-foo can have it via several and easy means. Those who want 'git foo' have it by default which IMHO is pretty sane (the other way around is less easy so 'git foo' being the default is the most sensible alternative). Platforms where filesystem links are not available simply don't have to support the git-foo form, period. I doubt users of such platforms will care much. All the rest is only bikeshedding. Nicolas ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 23:45 ` Nicolas Pitre @ 2008-08-28 15:32 ` Johannes Schindelin 0 siblings, 0 replies; 193+ messages in thread From: Johannes Schindelin @ 2008-08-28 15:32 UTC (permalink / raw) To: Nicolas Pitre; +Cc: Junio C Hamano, Jeff King, David Woodhouse, git, users Hi, On Tue, 26 Aug 2008, Nicolas Pitre wrote: > On Tue, 26 Aug 2008, Junio C Hamano wrote: > > > Read the subject line again, and notice that we are not talking about > > /usr/bin vs /usr/libexec/git-core; the request-for-discussion was about > > removing "git-add" and friends from /usr/libexec/git-core/, so that we do > > not have to even have these many hardlinks there. Except for Linus (and > > obviously myself who started the thread), I saw nobody expressed any > > opinion on it. > > Don't deprecate git-foo and leave them in $gitexecdir as things are now. > That's the best compromise IMHO. > > Those who want git-foo can have it via several and easy means. Those > who want 'git foo' have it by default which IMHO is pretty sane (the > other way around is less easy so 'git foo' being the default is the most > sensible alternative). > > Platforms where filesystem links are not available simply don't have to > support the git-foo form, period. I doubt users of such platforms will > care much. > > All the rest is only bikeshedding. Not wanting to be part of a _silent_ majority, I fully agree, loudly. Ciao, Dscho ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 20:39 ` Junio C Hamano ` (2 preceding siblings ...) 2008-08-26 23:45 ` Nicolas Pitre @ 2008-08-27 0:17 ` Matthew Wilcox 2008-08-27 22:52 ` Russell King 2008-08-27 23:38 ` Junio C Hamano 3 siblings, 2 replies; 193+ messages in thread From: Matthew Wilcox @ 2008-08-27 0:17 UTC (permalink / raw) To: Junio C Hamano Cc: Jeff King, David Woodhouse, git, Johannes Schindelin, users On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote: > When I hear something like what David Woodhouse said in this thread, I > should be feeling "People -- those of you who claimed to be the silent > majority -- see, I told you so! This is a very bad move". > > But I can't. People who complain _now_ just annoy me even more. Why > weren't you defending the backward compatibility with me, which you seem > to value it so much, perhaps even more than I did back then? Why are you > wasting our time bringing it up again, instead of joining the discussion > when it _mattered_ back then? We didn't know the conversation was going on. Why should we? We only use the tool, not develop it. I'm also not on the mailing lists for mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or any of the dozens of other programs I use on a daily basis. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 0:17 ` Matthew Wilcox @ 2008-08-27 22:52 ` Russell King 2008-08-28 15:34 ` Johannes Schindelin 2008-08-27 23:38 ` Junio C Hamano 1 sibling, 1 reply; 193+ messages in thread From: Russell King @ 2008-08-27 22:52 UTC (permalink / raw) To: Matthew Wilcox Cc: Junio C Hamano, Jeff King, David Woodhouse, Johannes Schindelin, git, users On Tue, Aug 26, 2008 at 06:17:05PM -0600, Matthew Wilcox wrote: > On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote: > > When I hear something like what David Woodhouse said in this thread, I > > should be feeling "People -- those of you who claimed to be the silent > > majority -- see, I told you so! This is a very bad move". > > > > But I can't. People who complain _now_ just annoy me even more. Why > > weren't you defending the backward compatibility with me, which you seem > > to value it so much, perhaps even more than I did back then? Why are you > > wasting our time bringing it up again, instead of joining the discussion > > when it _mattered_ back then? > > We didn't know the conversation was going on. Why should we? We only > use the tool, not develop it. I'm also not on the mailing lists for > mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or > any of the dozens of other programs I use on a daily basis. Well said Matthew, as a git _user_ I completely agree. I only found out myself when it got installed on master.kernel.org, and things that had worked fine for ages suddenly stopped working with no clear solution. Useless documentation which refers to the commands which didn't seem to be in existence anymore was just, to put it mildly, infuriating, and provided no answer. That said, I've now updated all my scripts to not use the dashed version, including on my local machines (which are still using git 1.5.4.x); the only thing is I can't get out of the habbit of typing 'git-diff-tree -u' if I want to see a single commit, or 'git-diff-files -u' if I want to see (almost) everything in my working directory, or 'git-am'. The solution is trivial for when the dashed commands finally go away. alias git-am='git am' alias git-diff-files='git diff-files' etc. in ~/.bashrc So it's no real big hastle for me anymore. -- Russell King ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 22:52 ` Russell King @ 2008-08-28 15:34 ` Johannes Schindelin 2008-08-28 16:10 ` Matthew Wilcox 0 siblings, 1 reply; 193+ messages in thread From: Johannes Schindelin @ 2008-08-28 15:34 UTC (permalink / raw) To: Russell King Cc: Matthew Wilcox, Junio C Hamano, Jeff King, David Woodhouse, git, users Hi, On Wed, 27 Aug 2008, Russell King wrote: > On Tue, Aug 26, 2008 at 06:17:05PM -0600, Matthew Wilcox wrote: > > On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote: > > > When I hear something like what David Woodhouse said in this thread, I > > > should be feeling "People -- those of you who claimed to be the silent > > > majority -- see, I told you so! This is a very bad move". > > > > > > But I can't. People who complain _now_ just annoy me even more. Why > > > weren't you defending the backward compatibility with me, which you seem > > > to value it so much, perhaps even more than I did back then? Why are you > > > wasting our time bringing it up again, instead of joining the discussion > > > when it _mattered_ back then? > > > > We didn't know the conversation was going on. Why should we? We only > > use the tool, not develop it. I'm also not on the mailing lists for > > mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or > > any of the dozens of other programs I use on a daily basis. > > Well said Matthew, as a git _user_ I completely agree. So are you effectively saying that we should have asked on all the mailing list of existing and potential Git users to ask their opinions? Giggling, Dscho ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 15:34 ` Johannes Schindelin @ 2008-08-28 16:10 ` Matthew Wilcox 2008-08-28 19:18 ` Johannes Schindelin 0 siblings, 1 reply; 193+ messages in thread From: Matthew Wilcox @ 2008-08-28 16:10 UTC (permalink / raw) To: Johannes Schindelin Cc: Russell King, Junio C Hamano, Jeff King, David Woodhouse, git, users On Thu, Aug 28, 2008 at 05:34:43PM +0200, Johannes Schindelin wrote: > On Wed, 27 Aug 2008, Russell King wrote: > > On Tue, Aug 26, 2008 at 06:17:05PM -0600, Matthew Wilcox wrote: > > > We didn't know the conversation was going on. Why should we? We only > > > use the tool, not develop it. I'm also not on the mailing lists for > > > mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or > > > any of the dozens of other programs I use on a daily basis. > > > > Well said Matthew, as a git _user_ I completely agree. > > So are you effectively saying that we should have asked on all the mailing > list of existing and potential Git users to ask their opinions? No. I'm effectively saying that *you shouldn't break backwards compatibility*. Ever. It only annoys people. Including: - The maintainer who has to listen to all this whining - Everyone who gets this thread cc'd in their inbox - People who hadn't been informed of the new way of doing things - People who thought they'd got their own way and now have to suffer the 'silent majority' speaking up. - Linus -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 16:10 ` Matthew Wilcox @ 2008-08-28 19:18 ` Johannes Schindelin 2008-08-28 19:27 ` Matthew Wilcox 0 siblings, 1 reply; 193+ messages in thread From: Johannes Schindelin @ 2008-08-28 19:18 UTC (permalink / raw) To: Matthew Wilcox Cc: Russell King, Junio C Hamano, Jeff King, David Woodhouse, git, users Hi, On Thu, 28 Aug 2008, Matthew Wilcox wrote: > On Thu, Aug 28, 2008 at 05:34:43PM +0200, Johannes Schindelin wrote: > > On Wed, 27 Aug 2008, Russell King wrote: > > > On Tue, Aug 26, 2008 at 06:17:05PM -0600, Matthew Wilcox wrote: > > > > We didn't know the conversation was going on. Why should we? We only > > > > use the tool, not develop it. I'm also not on the mailing lists for > > > > mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or > > > > any of the dozens of other programs I use on a daily basis. > > > > > > Well said Matthew, as a git _user_ I completely agree. > > > > So are you effectively saying that we should have asked on all the mailing > > list of existing and potential Git users to ask their opinions? > > No. I'm effectively saying that *you shouldn't break backwards > compatibility*. Ever. It only annoys people. This is something that comes out of a male cow, and from his back exit. You are saying that something that was deprecated loooong time ago should be kept for backwards compatibility reasons. That cannot hold, and you know that. Anyway, you even failed to address my complaint, namely that Russell did not give us a _chance_. He did not read the mailing list on which the issue was discussed -- and again, it is not a compatibility issue. But he wanted to be notified. Like they say, you cannot have your cake and eat it, too. As to everybody who still wants to complain that git-xyyx is so much better than "git xyyx": face it, it's the better solution for almost everybody except for you. Cope with it. Oh, and I am sorry if it broke your scripts, but they are easy to fix. I know, because I had to fix mine, too. Ciao, Dscho ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 19:18 ` Johannes Schindelin @ 2008-08-28 19:27 ` Matthew Wilcox 0 siblings, 0 replies; 193+ messages in thread From: Matthew Wilcox @ 2008-08-28 19:27 UTC (permalink / raw) To: Johannes Schindelin Cc: Russell King, Junio C Hamano, Jeff King, David Woodhouse, git, users On Thu, Aug 28, 2008 at 09:18:53PM +0200, Johannes Schindelin wrote: > > No. I'm effectively saying that *you shouldn't break backwards > > compatibility*. Ever. It only annoys people. > > This is something that comes out of a male cow, and from his back exit. OK, I'm done. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 0:17 ` Matthew Wilcox 2008-08-27 22:52 ` Russell King @ 2008-08-27 23:38 ` Junio C Hamano 2008-08-28 0:09 ` Felipe Contreras 2008-08-28 7:14 ` David Woodhouse 1 sibling, 2 replies; 193+ messages in thread From: Junio C Hamano @ 2008-08-27 23:38 UTC (permalink / raw) To: Matthew Wilcox Cc: Jeff King, David Woodhouse, git, Johannes Schindelin, users Matthew Wilcox <matthew@wil.cx> writes: > On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote: >> When I hear something like what David Woodhouse said in this thread, I >> should be feeling "People -- those of you who claimed to be the silent >> majority -- see, I told you so! This is a very bad move". >> >> But I can't. People who complain _now_ just annoy me even more. Why >> weren't you defending the backward compatibility with me, which you seem >> to value it so much, perhaps even more than I did back then? Why are you >> wasting our time bringing it up again, instead of joining the discussion >> when it _mattered_ back then? > > We didn't know the conversation was going on. Why should we? We only > use the tool, not develop it. I'm also not on the mailing lists for > mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or > any of the dozens of other programs I use on a daily basis. Oh, I wasn't talking to you, or "we as git users". The user side of the discussion has long been over in another thread titled "[kernel.org users] README and ChangeLog files" that was started by HPA, and everybody now knows that the conclusion of the discussion was that 1.6.0 transition was underadvertised to the end-user community and caused pain. Sorry about that, but let's leave it behind. What has happend has happened. The discussion in this thread was about how to go forward from here, now the transition is over. One of the future directions the transition was aiming at was removal of git-foo form for built-ins even from the libexec area -- I was complaining about David's beating an offtopic dead horse in the above, because it was throwing the thread in an off-track direction, distracting everybody from discussing what was more important, discussing constructively if/how to proceed from here. Now the primary topic of what to do about built-ins have already settled. We _will_ keep git-foo commands in the libexec area. We won't be removing them. So there is no need to worry. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 23:38 ` Junio C Hamano @ 2008-08-28 0:09 ` Felipe Contreras 2008-08-28 0:44 ` Jeff Garzik 2008-08-28 7:14 ` David Woodhouse 1 sibling, 1 reply; 193+ messages in thread From: Felipe Contreras @ 2008-08-28 0:09 UTC (permalink / raw) To: Junio C Hamano Cc: Matthew Wilcox, Jeff King, David Woodhouse, git, Johannes Schindelin, users On Thu, Aug 28, 2008 at 2:38 AM, Junio C Hamano <gitster@pobox.com> wrote: > Matthew Wilcox <matthew@wil.cx> writes: > >> On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote: >>> When I hear something like what David Woodhouse said in this thread, I >>> should be feeling "People -- those of you who claimed to be the silent >>> majority -- see, I told you so! This is a very bad move". >>> >>> But I can't. People who complain _now_ just annoy me even more. Why >>> weren't you defending the backward compatibility with me, which you seem >>> to value it so much, perhaps even more than I did back then? Why are you >>> wasting our time bringing it up again, instead of joining the discussion >>> when it _mattered_ back then? >> >> We didn't know the conversation was going on. Why should we? We only >> use the tool, not develop it. I'm also not on the mailing lists for >> mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or >> any of the dozens of other programs I use on a daily basis. > > Oh, I wasn't talking to you, or "we as git users". The user side of the > discussion has long been over in another thread titled "[kernel.org users] > README and ChangeLog files" that was started by HPA, and everybody now > knows that the conclusion of the discussion was that 1.6.0 transition was > underadvertised to the end-user community and caused pain. Sorry about > that, but let's leave it behind. What has happend has happened. > > The discussion in this thread was about how to go forward from here, now > the transition is over. One of the future directions the transition was > aiming at was removal of git-foo form for built-ins even from the libexec > area -- I was complaining about David's beating an offtopic dead horse in > the above, because it was throwing the thread in an off-track direction, > distracting everybody from discussing what was more important, discussing > constructively if/how to proceed from here. > > Now the primary topic of what to do about built-ins have already settled. > We _will_ keep git-foo commands in the libexec area. We won't be removing > them. > > So there is no need to worry. Still, if this is the decision, all the documentation should be updated, and people should be discouraged to mention the git-foo commands ever again, otherwise new users would get confused. -- Felipe Contreras ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 0:09 ` Felipe Contreras @ 2008-08-28 0:44 ` Jeff Garzik 0 siblings, 0 replies; 193+ messages in thread From: Jeff Garzik @ 2008-08-28 0:44 UTC (permalink / raw) To: Felipe Contreras Cc: Junio C Hamano, Matthew Wilcox, Johannes Schindelin, users, Jeff King, David Woodhouse, git Felipe Contreras wrote: > Still, if this is the decision, all the documentation should be > updated, and people should be discouraged to mention the git-foo > commands ever again, otherwise new users would get confused. True. I scanned my Kernel Hackers' Guide to Git and made sure to kill a few straggling references to dash commands: http://linux.yyz.us/git-howto.html Even though my fingers still want to type git DASH foo, feedback from gitsters caused me to purge most dash references from the guide a while ago. I'm surprised the git docs were not updated at the same time I was being hectored <grin> Anyway, it's a fair point and lets definite get the straggling docs converted and consistent. Comments on the above URL welcome, even if unrelated to the current topic at hand. Thanks, Jeff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-27 23:38 ` Junio C Hamano 2008-08-28 0:09 ` Felipe Contreras @ 2008-08-28 7:14 ` David Woodhouse 2008-08-28 8:17 ` Junio C Hamano 1 sibling, 1 reply; 193+ messages in thread From: David Woodhouse @ 2008-08-28 7:14 UTC (permalink / raw) To: Junio C Hamano; +Cc: Matthew Wilcox, Jeff King, git, Johannes Schindelin, users On Wed, 2008-08-27 at 16:38 -0700, Junio C Hamano wrote: > The discussion in this thread was about how to go forward from here, now > the transition is over. One of the future directions the transition was > aiming at was removal of git-foo form for built-ins even from the libexec > area -- I was complaining about David's beating an offtopic dead horse in > the above, because it was throwing the thread in an off-track direction, > distracting everybody from discussing what was more important, discussing > constructively if/how to proceed from here. I'm sorry you feel that way. The reason I didn't object back then was almost certainly because I didn't notice the discussion. I open the git mailing list folder so infrequently I might as well not be subscribed. But even if I _had_ seen the discussion, I might not have replied. Life's too short to undertake a reasoned critique of every crack-addled 'plan' you see on the Internet. I'm not going to bother arguing with the next person who asserts that we should turn Linux into a microkernel and write it in C++, and I would have treated some idiotic plan to break git in this way with just the same level of interest. > Now the primary topic of what to do about built-ins have already settled. > We _will_ keep git-foo commands in the libexec area. We won't be removing > them. Excellent. All we need to do is make sure the distributions all set $(gitexecdir) to /usr/bin when they upgrade to 1.6.0 -- and could you also fix it on master.kernel.org please? I believe we currently have to override $(gitexecdir) at make time -- could we have it as an option to ./configure, please? -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 7:14 ` David Woodhouse @ 2008-08-28 8:17 ` Junio C Hamano 2008-08-28 8:32 ` David Woodhouse 0 siblings, 1 reply; 193+ messages in thread From: Junio C Hamano @ 2008-08-28 8:17 UTC (permalink / raw) To: David Woodhouse Cc: Jeff King, users, Johannes Schindelin, git, Matthew Wilcox David Woodhouse <dwmw2@infradead.org> writes: > Excellent. All we need to do is make sure the distributions all set > $(gitexecdir) to /usr/bin when they upgrade to 1.6.0 -- and could you > also fix it on master.kernel.org please? Are you trying to irritate me even more? Although I personally did not particularly like the "out of /usr/bin" move, this was done by user request. I now am hated for doing something I was dragged into doing, not because I wanted the change, but only because many others wanted it, and you are dreaming that another pointless change will be made in the other direction? Get a clue already. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 8:17 ` Junio C Hamano @ 2008-08-28 8:32 ` David Woodhouse 2008-08-28 8:57 ` Felipe Contreras ` (2 more replies) 0 siblings, 3 replies; 193+ messages in thread From: David Woodhouse @ 2008-08-28 8:32 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jeff King, Matthew Wilcox, git, Johannes Schindelin, users On Thu, 2008-08-28 at 01:17 -0700, Junio C Hamano wrote: > David Woodhouse <dwmw2@infradead.org> writes: > > > Excellent. All we need to do is make sure the distributions all set > > $(gitexecdir) to /usr/bin when they upgrade to 1.6.0 -- and could you > > also fix it on master.kernel.org please? > > Are you trying to irritate me even more? Not at all; I'm sorry if that's the effect. > Although I personally did not particularly like the "out of /usr/bin" move, > this was done by user request. I now am hated for doing something I was > dragged into doing, not because I wanted the change, but only because many > others wanted it, and you are dreaming that another pointless change will > be made in the other direction? I'm not asking you to make another change in upstream git. You've told us the workaround (gitexecdir=/usr/bin), and that workaround is no longer going to be deprecated, which is great. It's just up to us to ensure that we use that workaround when we build git for ourselves, and to ensure that our distributions also build packages using that workaround. Since I believe you're building the git packages used on kernel.org, I was just asking you to apply the workaround when you build _those_ packages, that's all. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 8:32 ` David Woodhouse @ 2008-08-28 8:57 ` Felipe Contreras 2008-08-28 11:54 ` Al Viro 2008-08-28 14:06 ` Nicolas Pitre 2008-08-28 16:17 ` Linus Torvalds 2 siblings, 1 reply; 193+ messages in thread From: Felipe Contreras @ 2008-08-28 8:57 UTC (permalink / raw) To: David Woodhouse Cc: Junio C Hamano, Jeff King, Matthew Wilcox, git, Johannes Schindelin, users On Thu, Aug 28, 2008 at 11:32 AM, David Woodhouse <dwmw2@infradead.org> wrote: > On Thu, 2008-08-28 at 01:17 -0700, Junio C Hamano wrote: >> David Woodhouse <dwmw2@infradead.org> writes: >> >> > Excellent. All we need to do is make sure the distributions all set >> > $(gitexecdir) to /usr/bin when they upgrade to 1.6.0 -- and could you >> > also fix it on master.kernel.org please? >> >> Are you trying to irritate me even more? > > Not at all; I'm sorry if that's the effect. > >> Although I personally did not particularly like the "out of /usr/bin" move, >> this was done by user request. I now am hated for doing something I was >> dragged into doing, not because I wanted the change, but only because many >> others wanted it, and you are dreaming that another pointless change will >> be made in the other direction? > > I'm not asking you to make another change in upstream git. You've told > us the workaround (gitexecdir=/usr/bin), and that workaround is no > longer going to be deprecated, which is great. It's just up to us to > ensure that we use that workaround when we build git for ourselves, and > to ensure that our distributions also build packages using that > workaround. > > Since I believe you're building the git packages used on kernel.org, I > was just asking you to apply the workaround when you build _those_ > packages, that's all. You are getting it wrong. If *you* want the git-foo form, then *you* add the git exec dir to your PATH. The masses should forget about the git-foo form. If you push people into using git-foo then you are not following git guidelines; you would be pushing your own agenda. -- Felipe Contreras ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 8:57 ` Felipe Contreras @ 2008-08-28 11:54 ` Al Viro 2008-08-28 13:15 ` Felipe Contreras 0 siblings, 1 reply; 193+ messages in thread From: Al Viro @ 2008-08-28 11:54 UTC (permalink / raw) To: Felipe Contreras Cc: David Woodhouse, Matthew Wilcox, Johannes Schindelin, users, Jeff King, Junio C Hamano, git On Thu, Aug 28, 2008 at 11:57:56AM +0300, Felipe Contreras wrote: > The masses should forget about the git-foo form. If you push people > into using git-foo then you are not following git guidelines; you > would be pushing your own agenda. Egads... For sarcasm it's far too heavy-handed and if that's for real... What's next, verbal diarrhea about Diluting the Message(tm)? ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 11:54 ` Al Viro @ 2008-08-28 13:15 ` Felipe Contreras 2008-08-28 13:34 ` Felipe Contreras 0 siblings, 1 reply; 193+ messages in thread From: Felipe Contreras @ 2008-08-28 13:15 UTC (permalink / raw) To: Al Viro Cc: David Woodhouse, Matthew Wilcox, Johannes Schindelin, users, Jeff King, Junio C Hamano, git On Thu, Aug 28, 2008 at 2:54 PM, Al Viro <viro@hera.kernel.org> wrote: > On Thu, Aug 28, 2008 at 11:57:56AM +0300, Felipe Contreras wrote: > >> The masses should forget about the git-foo form. If you push people >> into using git-foo then you are not following git guidelines; you >> would be pushing your own agenda. > > Egads... For sarcasm it's far too heavy-handed and if that's for real... > What's next, verbal diarrhea about Diluting the Message(tm)? Sorry, I guess I should have made it clearer. I haven't made my mind about git-foo vs "git foo", but a decision has been made to deprecate git-foo, and allow it as an option for the people that really want to use it, right? So there must have been a reason to deprecate git-foo, if people keep using git-foo, and distributions keep allowing it, what's the point of deprecation? It's ok if they keep that usage to themselves, like 'alias ll = ls -l', but it's not something to assume everybody uses. So either we take back the decision and keep discussing if it's a good idea to deprecate git-foo, or we go forward and discourage git-foo completely. Anything in the middle would just confuse people more, and wouldn't achieve the purpose of deprecation. If some script is relying on git-foo, and it has been deprecated, it should be fixed. Best regards. -- Felipe Contreras ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 13:15 ` Felipe Contreras @ 2008-08-28 13:34 ` Felipe Contreras 2008-08-28 13:45 ` Paolo Ciarrocchi 2008-08-28 16:37 ` Linus Torvalds 0 siblings, 2 replies; 193+ messages in thread From: Felipe Contreras @ 2008-08-28 13:34 UTC (permalink / raw) To: Al Viro Cc: David Woodhouse, Matthew Wilcox, Johannes Schindelin, users, Jeff King, Junio C Hamano, git On Thu, Aug 28, 2008 at 4:15 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote: > On Thu, Aug 28, 2008 at 2:54 PM, Al Viro <viro@hera.kernel.org> wrote: >> On Thu, Aug 28, 2008 at 11:57:56AM +0300, Felipe Contreras wrote: >> >>> The masses should forget about the git-foo form. If you push people >>> into using git-foo then you are not following git guidelines; you >>> would be pushing your own agenda. >> >> Egads... For sarcasm it's far too heavy-handed and if that's for real... >> What's next, verbal diarrhea about Diluting the Message(tm)? > > Sorry, I guess I should have made it clearer. > > I haven't made my mind about git-foo vs "git foo", but a decision has > been made to deprecate git-foo, and allow it as an option for the > people that really want to use it, right? > > So there must have been a reason to deprecate git-foo, if people keep > using git-foo, and distributions keep allowing it, what's the point of > deprecation? It's ok if they keep that usage to themselves, like > 'alias ll = ls -l', but it's not something to assume everybody uses. > > So either we take back the decision and keep discussing if it's a good > idea to deprecate git-foo, or we go forward and discourage git-foo > completely. > > Anything in the middle would just confuse people more, and wouldn't > achieve the purpose of deprecation. > > If some script is relying on git-foo, and it has been deprecated, it > should be fixed. Actually, now I think I understand the point of David Woodhouse better. If the git-foo was supposed to be deprecated in 1.6.0, it should still work by default, but something to strongly discourage it like a warning should have been added. When it becomes truly obsolete, then people can rely on git exec-dir, which will be disabled by default. So is it deprecated or obsolete? -- Felipe Contreras ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 13:34 ` Felipe Contreras @ 2008-08-28 13:45 ` Paolo Ciarrocchi 2008-08-28 16:37 ` Linus Torvalds 1 sibling, 0 replies; 193+ messages in thread From: Paolo Ciarrocchi @ 2008-08-28 13:45 UTC (permalink / raw) To: Felipe Contreras Cc: Al Viro, David Woodhouse, Matthew Wilcox, Johannes Schindelin, users, Jeff King, Junio C Hamano, git On Thu, Aug 28, 2008 at 3:34 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote: > On Thu, Aug 28, 2008 at 4:15 PM, Felipe Contreras > <felipe.contreras@gmail.com> wrote: >> On Thu, Aug 28, 2008 at 2:54 PM, Al Viro <viro@hera.kernel.org> wrote: >>> On Thu, Aug 28, 2008 at 11:57:56AM +0300, Felipe Contreras wrote: >>> >>>> The masses should forget about the git-foo form. If you push people >>>> into using git-foo then you are not following git guidelines; you >>>> would be pushing your own agenda. >>> >>> Egads... For sarcasm it's far too heavy-handed and if that's for real... >>> What's next, verbal diarrhea about Diluting the Message(tm)? >> >> Sorry, I guess I should have made it clearer. >> >> I haven't made my mind about git-foo vs "git foo", but a decision has >> been made to deprecate git-foo, and allow it as an option for the >> people that really want to use it, right? >> >> So there must have been a reason to deprecate git-foo, if people keep >> using git-foo, and distributions keep allowing it, what's the point of >> deprecation? It's ok if they keep that usage to themselves, like >> 'alias ll = ls -l', but it's not something to assume everybody uses. >> >> So either we take back the decision and keep discussing if it's a good >> idea to deprecate git-foo, or we go forward and discourage git-foo >> completely. >> >> Anything in the middle would just confuse people more, and wouldn't >> achieve the purpose of deprecation. >> >> If some script is relying on git-foo, and it has been deprecated, it >> should be fixed. > > Actually, now I think I understand the point of David Woodhouse better. > > If the git-foo was supposed to be deprecated in 1.6.0, it should still > work by default, but something to strongly discourage it like a > warning should have been added. > > When it becomes truly obsolete, then people can rely on git exec-dir, > which will be disabled by default. > > So is it deprecated or obsolete? I quote Junio: --8<--- We have deprecated the dashed form in early 2006, and announced that 1.6.0 will remove them from $PATH in the 1.5.4 release notes, with instructions on how to update their scripts before 1.6.0 happens. Many people knew about this transition, but they didn't do anything about it. Since 2005, git has matured enough that majority of people are using it without building one themselves, without a chance to even read Release Notes --8<--- Ciao, -- Paolo http://paolo.ciarrocchi.googlepages.com/ ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 13:34 ` Felipe Contreras 2008-08-28 13:45 ` Paolo Ciarrocchi @ 2008-08-28 16:37 ` Linus Torvalds 2008-08-28 20:42 ` Perry Wagle 2008-08-29 14:12 ` Felipe Contreras 1 sibling, 2 replies; 193+ messages in thread From: Linus Torvalds @ 2008-08-28 16:37 UTC (permalink / raw) To: Felipe Contreras Cc: Al Viro, Matthew Wilcox, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git On Thu, 28 Aug 2008, Felipe Contreras wrote: > > If the git-foo was supposed to be deprecated in 1.6.0 Itw as deprecated over a _year_ ago. > When it becomes truly obsolete, then people can rely on git exec-dir, > which will be disabled by default. It _is_ obsolete, but there's a trivial compatibility thing. Are you happy now? How hard is it to really understand? Linus ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 16:37 ` Linus Torvalds @ 2008-08-28 20:42 ` Perry Wagle 2008-08-28 23:03 ` Jakub Narebski 2008-08-29 14:12 ` Felipe Contreras 1 sibling, 1 reply; 193+ messages in thread From: Perry Wagle @ 2008-08-28 20:42 UTC (permalink / raw) To: Linus Torvalds Cc: Felipe Contreras, Al Viro, Matthew Wilcox, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git On Aug 28, 2008, at 9:37 AM, Linus Torvalds wrote: > On Thu, 28 Aug 2008, Felipe Contreras wrote: >> >> If the git-foo was supposed to be deprecated in 1.6.0 > > Itw as deprecated over a _year_ ago. No, it wasn't. As of March 2008, git<DASH> was still in the sample hooks and in git-web. That was the last time I did anything with git scripting. It was something between then and now that the <DASH>'s were finally removed. Oh wait: dhcp-2:git wagle$ grep -r --color git- . | wc -l 6580 dhcp-2:git wagle$ No, I'm not going to figure out which are okay, and which aren't. I'll just assume that they are all okay, but leave you to wonder. -- Perry PS. Okay, fine! Here's as far as I got before getting bored: grep -r git- . | cat -v | sed "s/^.*\(git-[^ :\")\[($\']*\).*$/ \1/" | sort | uniq ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 20:42 ` Perry Wagle @ 2008-08-28 23:03 ` Jakub Narebski 2008-08-28 23:14 ` Perry Wagle 0 siblings, 1 reply; 193+ messages in thread From: Jakub Narebski @ 2008-08-28 23:03 UTC (permalink / raw) To: Perry Wagle Cc: Linus Torvalds, Felipe Contreras, Al Viro, Matthew Wilcox, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git Perry Wagle <wagle@cs.indiana.edu> writes: > On Aug 28, 2008, at 9:37 AM, Linus Torvalds wrote: >> On Thu, 28 Aug 2008, Felipe Contreras wrote: >>> >>> If the git-foo was supposed to be deprecated in 1.6.0 >> >> Itw as deprecated over a _year_ ago. > > No, it wasn't. As of March 2008, git<DASH> was still in the sample > hooks and in git-web. [...] If by "git-web" you mean "gitweb", the git web interface in Perl, this is simply not true. From the commit 25691fb (gitweb: Use --git-dir parameter instead of setting $ENV{'GIT_DIR'}) _at least_ gitweb uses "git <comd>" and not "git-cmd" form. And this commit was on 28 August 2006, so in March 2008 gitweb didn't use git<DASH> form... Check your facts, please... -- Jakub Narebski Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 23:03 ` Jakub Narebski @ 2008-08-28 23:14 ` Perry Wagle 2008-08-28 23:45 ` Jeff King 0 siblings, 1 reply; 193+ messages in thread From: Perry Wagle @ 2008-08-28 23:14 UTC (permalink / raw) To: Jakub Narebski Cc: Linus Torvalds, Felipe Contreras, Al Viro, Matthew Wilcox, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git I did: pwagle@starscream:/usr/lib/cgi-bin$ ls -l total 352 -rw-r--r-- 1 root root 164 2008-03-07 12:03 git-favicon.png -rw-r--r-- 1 root root 208 2008-03-07 12:03 git-logo.png -rwxr-xr-x 1 root root 167729 2008-03-07 12:03 gitweb.cgi -rw-r--r-- 1 root root 7112 2008-03-07 12:03 gitweb.css -rwxr-xr-x 1 root root 167932 2008-03-07 12:03 gitweb.perl pwagle@starscream:/usr/lib/cgi-bin$ grep git- * | wc -l 68 pwagle@starscream:/usr/lib/cgi-bin$ On Aug 28, 2008, at 4:03 PM, Jakub Narebski wrote: > Perry Wagle <wagle@cs.indiana.edu> writes: > >> On Aug 28, 2008, at 9:37 AM, Linus Torvalds wrote: >>> On Thu, 28 Aug 2008, Felipe Contreras wrote: >>>> >>>> If the git-foo was supposed to be deprecated in 1.6.0 >>> >>> Itw as deprecated over a _year_ ago. >> >> No, it wasn't. As of March 2008, git<DASH> was still in the sample >> hooks and in git-web. [...] > > If by "git-web" you mean "gitweb", the git web interface in Perl, this > is simply not true. From the commit 25691fb (gitweb: Use --git-dir > parameter instead of setting $ENV{'GIT_DIR'}) _at least_ gitweb uses > "git <comd>" and not "git-cmd" form. And this commit was on 28 August > 2006, so in March 2008 gitweb didn't use git<DASH> form... > > Check your facts, please... > > -- > Jakub Narebski > Poland > ShadeHawk on #git > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 23:14 ` Perry Wagle @ 2008-08-28 23:45 ` Jeff King 2008-08-28 23:55 ` Perry Wagle 0 siblings, 1 reply; 193+ messages in thread From: Jeff King @ 2008-08-28 23:45 UTC (permalink / raw) To: Perry Wagle; +Cc: Jakub Narebski, git On Thu, Aug 28, 2008 at 04:14:14PM -0700, Perry Wagle wrote: > I did: > > pwagle@starscream:/usr/lib/cgi-bin$ ls -l > total 352 > -rw-r--r-- 1 root root 164 2008-03-07 12:03 git-favicon.png > -rw-r--r-- 1 root root 208 2008-03-07 12:03 git-logo.png > -rwxr-xr-x 1 root root 167729 2008-03-07 12:03 gitweb.cgi > -rw-r--r-- 1 root root 7112 2008-03-07 12:03 gitweb.css > -rwxr-xr-x 1 root root 167932 2008-03-07 12:03 gitweb.perl > pwagle@starscream:/usr/lib/cgi-bin$ grep git- * | wc -l > 68 > pwagle@starscream:/usr/lib/cgi-bin$ 1. Your numbers are doubled because gitweb.cgi is the built form of gitweb.perl. 2. Look at the grep output. They are all in comments or messages. Perhaps the messages should say "open git diff failed" instead of "open git-diff failed". But the "git-foo" form has been kept as a typographical convention because it makes more sense from a language perspective (just as you would hyphenate some compound words, or an adjective phrase). Perhaps that is a mistake, given the confusion. -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 23:45 ` Jeff King @ 2008-08-28 23:55 ` Perry Wagle 0 siblings, 0 replies; 193+ messages in thread From: Perry Wagle @ 2008-08-28 23:55 UTC (permalink / raw) To: Jeff King; +Cc: Jakub Narebski, git Okay, thanks for the analysis! He pulled a minor remark out and said I didn't look, when I had. I have other things to do this week, but this thread is now, so I gotta do the ballpark measurements now (with some hope of reversing a upward compatibility breakage, which isn't important any more, see my other post). Later I go in and s/git<DASH>/ git<SPACE>/g in my one-true-editor 8) and see for sure how many I actually need to change. Gitweb wasn't my main problem, just one I had to think about when I can sit down and test the upgrade to 1.6.0. -- Perry On Aug 28, 2008, at 4:45 PM, Jeff King wrote: > On Thu, Aug 28, 2008 at 04:14:14PM -0700, Perry Wagle wrote: > >> I did: >> >> pwagle@starscream:/usr/lib/cgi-bin$ ls -l >> total 352 >> -rw-r--r-- 1 root root 164 2008-03-07 12:03 git-favicon.png >> -rw-r--r-- 1 root root 208 2008-03-07 12:03 git-logo.png >> -rwxr-xr-x 1 root root 167729 2008-03-07 12:03 gitweb.cgi >> -rw-r--r-- 1 root root 7112 2008-03-07 12:03 gitweb.css >> -rwxr-xr-x 1 root root 167932 2008-03-07 12:03 gitweb.perl >> pwagle@starscream:/usr/lib/cgi-bin$ grep git- * | wc -l >> 68 >> pwagle@starscream:/usr/lib/cgi-bin$ > > 1. Your numbers are doubled because gitweb.cgi is the built form of > gitweb.perl. > > 2. Look at the grep output. They are all in comments or messages. > Perhaps the messages should say "open git diff failed" instead of > "open > git-diff failed". But the "git-foo" form has been kept as a > typographical convention because it makes more sense from a language > perspective (just as you would hyphenate some compound words, or an > adjective phrase). Perhaps that is a mistake, given the confusion. > > -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 16:37 ` Linus Torvalds 2008-08-28 20:42 ` Perry Wagle @ 2008-08-29 14:12 ` Felipe Contreras 1 sibling, 0 replies; 193+ messages in thread From: Felipe Contreras @ 2008-08-29 14:12 UTC (permalink / raw) To: Linus Torvalds Cc: Al Viro, Matthew Wilcox, Johannes Schindelin, users, Jeff King, Junio C Hamano, David Woodhouse, git On Thu, Aug 28, 2008 at 7:37 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > On Thu, 28 Aug 2008, Felipe Contreras wrote: >> >> If the git-foo was supposed to be deprecated in 1.6.0 > > Itw as deprecated over a _year_ ago. > >> When it becomes truly obsolete, then people can rely on git exec-dir, >> which will be disabled by default. > > It _is_ obsolete, but there's a trivial compatibility thing. > > Are you happy now? How hard is it to really understand? It only takes one word; obsolete. I haven't heard that git-foo is obsolete until now, all I heard is that it was deprecated. Maybe I should have paid more attention but that's not the point. What other projects do is make very visible when something is deprecated, like a big, annoying, unbearable warning. Next time you deprecated a command it might be a good idea to add the warning each time the command is used, and obsolete it later on. Also, if it's a big change like this git- stuff, then do a major version bump. If you had marked 1.6 as 2.0, and added warnings when you deprecated the git-foo stuff then the users would have no excuse. It would have been obvious and this huge thread would have been avoided. Personally I'm subscribed to the mailing and I read the release notes of 1.6, but I didn't register that change. I install my git stuff to /opt/git, so when I was using git-foo I was using the old commands that come from Fedora. It wasn't until I read this thread that I noticed. Don't expect users to be a aware of what's happening on the project, many wouldn't even notice that there was a minor version bump. Julio, I guess that recommendation goes for you. Best regards. -- Felipe Contreras ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 8:32 ` David Woodhouse 2008-08-28 8:57 ` Felipe Contreras @ 2008-08-28 14:06 ` Nicolas Pitre 2008-08-28 14:13 ` Nicolas Pitre 2008-08-28 16:17 ` Linus Torvalds 2 siblings, 1 reply; 193+ messages in thread From: Nicolas Pitre @ 2008-08-28 14:06 UTC (permalink / raw) To: David Woodhouse Cc: Junio C Hamano, Jeff King, Matthew Wilcox, git, Johannes Schindelin, users On Thu, 28 Aug 2008, David Woodhouse wrote: > On Thu, 2008-08-28 at 01:17 -0700, Junio C Hamano wrote: > > David Woodhouse <dwmw2@infradead.org> writes: > > > > > Excellent. All we need to do is make sure the distributions all set > > > $(gitexecdir) to /usr/bin when they upgrade to 1.6.0 -- and could you > > > also fix it on master.kernel.org please? > > > > Are you trying to irritate me even more? > > Not at all; I'm sorry if that's the effect. > > > Although I personally did not particularly like the "out of /usr/bin" move, > > this was done by user request. I now am hated for doing something I was > > dragged into doing, not because I wanted the change, but only because many > > others wanted it, and you are dreaming that another pointless change will > > be made in the other direction? > > I'm not asking you to make another change in upstream git. You've told > us the workaround (gitexecdir=/usr/bin), and that workaround is no > longer going to be deprecated, which is great. It's just up to us to > ensure that we use that workaround when we build git for ourselves, and > to ensure that our distributions also build packages using that > workaround. ... effectively denying all those who asked for "git " from _easily_ getting it. OTOH, you can _trivially_ add $(git --exec-path) to your $PATH and forget about it. Nicolas ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 14:06 ` Nicolas Pitre @ 2008-08-28 14:13 ` Nicolas Pitre 0 siblings, 0 replies; 193+ messages in thread From: Nicolas Pitre @ 2008-08-28 14:13 UTC (permalink / raw) To: David Woodhouse Cc: Junio C Hamano, Jeff King, Matthew Wilcox, git, Johannes Schindelin, users On Thu, 28 Aug 2008, Nicolas Pitre wrote: > On Thu, 28 Aug 2008, David Woodhouse wrote: > > > I'm not asking you to make another change in upstream git. You've told > > us the workaround (gitexecdir=/usr/bin), and that workaround is no > > longer going to be deprecated, which is great. It's just up to us to > > ensure that we use that workaround when we build git for ourselves, and > > to ensure that our distributions also build packages using that > > workaround. > > ... effectively denying all those who asked for "git " from _easily_ > getting it. By this I mean "git-" out of /usr/bin, before someone replies saying that "git " is always available. Nicolas ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-28 8:32 ` David Woodhouse 2008-08-28 8:57 ` Felipe Contreras 2008-08-28 14:06 ` Nicolas Pitre @ 2008-08-28 16:17 ` Linus Torvalds 2 siblings, 0 replies; 193+ messages in thread From: Linus Torvalds @ 2008-08-28 16:17 UTC (permalink / raw) To: David Woodhouse Cc: Junio C Hamano, Jeff King, users, Johannes Schindelin, git, Matthew Wilcox On Thu, 28 Aug 2008, David Woodhouse wrote: > > I'm not asking you to make another change in upstream git. You've told > us the workaround (gitexecdir=/usr/bin) No. That's your _personal_ workaround. Others DO NOT WANT IT. I, for example, no longer want git-xyzzy in my path. So the real workaround is - you compile YOUR OWN VERSION instead of trying to force your stupid opinion on everybody by forcing the default for distros to be _idiotic_, and then you can do that gitexecdir=/usr/bin and wallow in your own shitty inability to teach yourself not to do the dash. - or you do - in a _personal_ file - that PATH="$PATH:$(git --exec-path)" thing, and forget about it, and never ever have to worry about how git was compiled and installed. The second is obviously the much superior model, exactly because it allows those people who do _not_ want to see git-xyzzy to work on the same machine. > Since I believe you're building the git packages used on kernel.org, I > was just asking you to apply the workaround when you build _those_ > packages, that's all. Don't be silly. Why are you grand poo-bah? Why cannot you just add your PATH to your .bash_profile? Get over it already. Why the hell are you _still_ whining, after I have told you to do that PATH thing at least ten times already? Linus ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-25 11:49 ` David Woodhouse ` (3 preceding siblings ...) 2008-08-25 18:19 ` Johannes Schindelin @ 2008-08-26 2:58 ` A Large Angry SCM 2008-08-26 7:17 ` Jean Delvare 4 siblings, 1 reply; 193+ messages in thread From: A Large Angry SCM @ 2008-08-26 2:58 UTC (permalink / raw) To: David Woodhouse; +Cc: Junio C Hamano, git, users David Woodhouse wrote: > > (C) Just don't do it. Leave the git-foo commands as they were. They > weren't actually hurting anyone, and you don't actually _gain_ > anything by removing them. For those occasional nutters who > _really_ care about the size of /usr/bin, give them the _option_ > of a 'make install' without installing the aliases. Acked-by: A Large Angry SCM <gitzilla@gmail.com> ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 2:58 ` A Large Angry SCM @ 2008-08-26 7:17 ` Jean Delvare 2008-08-26 11:12 ` A Large Angry SCM 2008-08-26 14:46 ` Jeff King 0 siblings, 2 replies; 193+ messages in thread From: Jean Delvare @ 2008-08-26 7:17 UTC (permalink / raw) To: gitzilla; +Cc: David Woodhouse, git, Junio C Hamano, users On Mon, 25 Aug 2008 22:58:37 -0400, A Large Angry SCM wrote: > David Woodhouse wrote: > > > > (C) Just don't do it. Leave the git-foo commands as they were. They > > weren't actually hurting anyone, and you don't actually _gain_ > > anything by removing them. For those occasional nutters who > > _really_ care about the size of /usr/bin, give them the _option_ > > of a 'make install' without installing the aliases. > > Acked-by: A Large Angry SCM <gitzilla@gmail.com> Such statements from anonymous people have zero value, sorry. -- Jean Delvare ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 7:17 ` Jean Delvare @ 2008-08-26 11:12 ` A Large Angry SCM 2008-08-26 11:56 ` Stefan Richter 2008-08-26 14:28 ` Shawn O. Pearce 2008-08-26 14:46 ` Jeff King 1 sibling, 2 replies; 193+ messages in thread From: A Large Angry SCM @ 2008-08-26 11:12 UTC (permalink / raw) To: Jean Delvare; +Cc: David Woodhouse, git, Junio C Hamano, users Jean Delvare wrote: > On Mon, 25 Aug 2008 22:58:37 -0400, A Large Angry SCM wrote: >> David Woodhouse wrote: >>> (C) Just don't do it. Leave the git-foo commands as they were. They >>> weren't actually hurting anyone, and you don't actually _gain_ >>> anything by removing them. For those occasional nutters who >>> _really_ care about the size of /usr/bin, give them the _option_ >>> of a 'make install' without installing the aliases. >> Acked-by: A Large Angry SCM <gitzilla@gmail.com> > > Such statements from anonymous people have zero value, sorry. > Do some research; I haven't been anonymous since 2005. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 11:12 ` A Large Angry SCM @ 2008-08-26 11:56 ` Stefan Richter 2008-08-26 21:00 ` Steven Rostedt 2008-08-26 14:28 ` Shawn O. Pearce 1 sibling, 1 reply; 193+ messages in thread From: Stefan Richter @ 2008-08-26 11:56 UTC (permalink / raw) To: gitzilla; +Cc: Jean Delvare, David Woodhouse, Junio C Hamano, git, users A Large Angry SCM wrote: > Jean Delvare wrote: >> On Mon, 25 Aug 2008 22:58:37 -0400, A Large Angry SCM wrote: >>> David Woodhouse wrote: >>>> (C) Just don't do it. Leave the git-foo commands as they were. They >>>> weren't actually hurting anyone, and you don't actually _gain_ >>>> anything by removing them. For those occasional nutters who >>>> _really_ care about the size of /usr/bin, give them the _option_ >>>> of a 'make install' without installing the aliases. >>> Acked-by: A Large Angry SCM <gitzilla@gmail.com> [...] > Do some research; [...] ...the plan to move git-foo out of /usr/bin has been discussed and wrapped up quite a while ago (am I confident to say without being subscriber of git@vger.k'org myself). Instead of unhelpful complaints after the fact, you could try which of the many available alternatives work for you: Extended PATH, shell aliases, command line completion setup, links in ~/bin, or so many other possibilities of varying degree of sophistication. If none of these fix whatever issues you experience, there is surely opportunity to discuss details on the git list. -- Stefan Richter -=====-==--- =--- ==-=- http://arcgraph.de/sr/ ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 11:56 ` Stefan Richter @ 2008-08-26 21:00 ` Steven Rostedt 0 siblings, 0 replies; 193+ messages in thread From: Steven Rostedt @ 2008-08-26 21:00 UTC (permalink / raw) To: Stefan Richter Cc: gitzilla, Jean Delvare, David Woodhouse, git, Junio C Hamano, users On Tue, 26 Aug 2008, Stefan Richter wrote: > A Large Angry SCM wrote: > > Jean Delvare wrote: > >> On Mon, 25 Aug 2008 22:58:37 -0400, A Large Angry SCM wrote: > >>> David Woodhouse wrote: > >>>> (C) Just don't do it. Leave the git-foo commands as they were. They > >>>> weren't actually hurting anyone, and you don't actually _gain_ > >>>> anything by removing them. For those occasional nutters who > >>>> _really_ care about the size of /usr/bin, give them the _option_ > >>>> of a 'make install' without installing the aliases. > >>> Acked-by: A Large Angry SCM <gitzilla@gmail.com> > [...] > > Do some research; [...] > > ...the plan to move git-foo out of /usr/bin has been discussed and > wrapped up quite a while ago (am I confident to say without being > subscriber of git@vger.k'org myself). > I'm sorry, but this thread reminds me of the day Aurther Dent's house was going to be destroyed for a by-way. ;-) -- Steve ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 11:12 ` A Large Angry SCM 2008-08-26 11:56 ` Stefan Richter @ 2008-08-26 14:28 ` Shawn O. Pearce 1 sibling, 0 replies; 193+ messages in thread From: Shawn O. Pearce @ 2008-08-26 14:28 UTC (permalink / raw) To: A Large Angry SCM; +Cc: git A Large Angry SCM <gitzilla@gmail.com> wrote: > Jean Delvare wrote: >>> >>> Acked-by: A Large Angry SCM <gitzilla@gmail.com> >> >> Such statements from anonymous people have zero value, sorry. >> > > Do some research; I haven't been anonymous since 2005. At which point one has to ask himself, "self, why I am still hiding behind an anonymous name?" -- Shawn. ^ permalink raw reply [flat|nested] 193+ messages in thread
* Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins 2008-08-26 7:17 ` Jean Delvare 2008-08-26 11:12 ` A Large Angry SCM @ 2008-08-26 14:46 ` Jeff King 1 sibling, 0 replies; 193+ messages in thread From: Jeff King @ 2008-08-26 14:46 UTC (permalink / raw) To: Jean Delvare; +Cc: gitzilla, git, users On Tue, Aug 26, 2008 at 09:17:01AM +0200, Jean Delvare wrote: > > Acked-by: A Large Angry SCM <gitzilla@gmail.com> > > Such statements from anonymous people have zero value, sorry. I think it depends on how you define "anonymous". I don't know gitzilla's legal name, and nor do I care. But I have seen the reputation he or she has established through postings on the git list over the past few years, and that gives the statement non-zero value. And I don't know who _you_ are, even though you are presumably using your real name (probably because this message is cross-posted, and you have some reputation on users@kernel.org, with which I am not familiar). -Peff ^ permalink raw reply [flat|nested] 193+ messages in thread
end of thread, other threads:[~2008-09-04 4:59 UTC | newest] Thread overview: 193+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-08-24 3:33 [RFD] On deprecating "git-foo" for builtins Junio C Hamano 2008-08-24 4:23 ` [kernel.org users] " Linus Torvalds 2008-08-24 4:54 ` Imran M Yousuf 2008-08-24 8:40 ` Stefan Richter 2008-08-25 11:49 ` David Woodhouse 2008-08-25 12:17 ` Geert Uytterhoeven 2008-08-25 12:43 ` Andi Kleen 2008-08-26 3:00 ` A Large Angry SCM 2008-08-25 13:22 ` Ben Collins 2008-08-25 14:38 ` Felipe Contreras 2008-08-25 18:19 ` Johannes Schindelin 2008-08-25 23:41 ` Junio C Hamano 2008-08-26 12:27 ` David Woodhouse 2008-08-26 14:57 ` Jeff King 2008-08-26 15:34 ` Kristian Høgsberg 2008-08-26 15:59 ` David Woodhouse 2008-08-26 16:04 ` Matthias Kestenholz 2008-08-26 16:25 ` Petr Baudis 2008-08-26 16:45 ` Andi Kleen 2008-08-26 17:04 ` Jeff King 2008-08-26 17:05 ` Linus Torvalds 2008-08-26 17:27 ` Andi Kleen 2008-08-27 6:04 ` Ulrich Windl 2008-08-26 17:10 ` Petr Baudis 2008-08-26 17:11 ` [PATCH] bash completion: Hide more plumbing commands Petr Baudis 2008-08-26 17:24 ` Shawn O. Pearce 2008-08-26 17:43 ` Jakub Narebski 2008-08-26 18:25 ` Junio C Hamano 2008-08-26 18:27 ` Shawn O. Pearce 2008-08-26 19:04 ` Daniel Barkalow 2008-08-26 19:07 ` Shawn O. Pearce 2008-08-26 19:23 ` Daniel Barkalow 2008-09-03 22:23 ` Petr Baudis 2008-09-03 22:31 ` Petr Baudis 2008-08-26 17:38 ` Jakub Narebski 2008-09-03 17:56 ` Petr Baudis 2008-09-04 4:57 ` Junio C Hamano 2008-08-26 21:53 ` Matthieu Moy 2008-08-27 9:09 ` Karl Hasselström 2008-08-26 17:12 ` [kernel.org users] [RFD] On deprecating "git-foo" for builtins Shawn O. Pearce 2008-08-26 17:16 ` Jeff King 2008-08-26 17:47 ` Nguyen Thai Ngoc Duy 2008-08-26 21:06 ` Willy Tarreau 2008-08-27 20:24 ` Jeff Garzik 2008-08-27 20:27 ` Jeff King 2008-08-27 20:38 ` Jeff Garzik 2008-08-27 20:53 ` Jeff King 2008-08-27 21:05 ` Matthew Wilcox 2008-08-27 21:13 ` Adrian Bunk 2008-08-27 21:22 ` Jeff King 2008-08-27 22:29 ` Adrian Bunk 2008-08-27 21:23 ` Linus Torvalds 2008-08-27 23:49 ` Jeff Garzik 2008-08-28 6:51 ` Ingo Molnar 2008-08-28 7:46 ` git-show vs git-log (or: git show vs git log) Dominik Brodowski 2008-08-28 14:44 ` [kernel.org users] [RFD] On deprecating "git-foo" for builtins Alex Riesen 2008-08-28 5:43 ` Mike Hommey 2008-08-27 20:50 ` Linus Torvalds 2008-08-27 6:00 ` Ulrich Windl 2008-08-27 7:59 ` H. Peter Anvin 2008-08-27 19:14 ` Matthew Wilcox 2008-08-27 19:43 ` Perry Wagle 2008-08-27 19:50 ` Jeff King 2008-08-27 19:54 ` Perry Wagle 2008-08-27 20:43 ` H. Peter Anvin 2008-08-27 21:19 ` Steven Rostedt 2008-08-27 23:27 ` Junio C Hamano 2008-08-27 23:53 ` Perry Wagle 2008-08-28 0:05 ` Perry Wagle 2008-08-28 9:04 ` Petr Baudis 2008-08-28 10:33 ` Perry Wagle 2008-08-28 10:42 ` David Woodhouse 2008-08-28 19:56 ` Perry Wagle 2008-08-28 10:47 ` Petr Baudis 2008-08-28 16:35 ` Linus Torvalds 2008-08-28 19:24 ` Perry Wagle 2008-08-28 19:52 ` Teemu Likonen 2008-08-28 20:23 ` Perry Wagle 2008-08-28 20:44 ` Petr Baudis 2008-08-28 20:57 ` Perry Wagle 2008-08-28 21:23 ` Jeff King 2008-08-28 21:41 ` Perry Wagle 2008-08-28 21:53 ` Petr Baudis 2008-08-28 21:59 ` Jeff King 2008-08-28 22:33 ` Perry Wagle 2008-08-28 23:04 ` Jeff King 2008-08-28 23:22 ` Perry Wagle 2008-08-28 23:36 ` Jeff King 2008-08-28 23:24 ` Junio C Hamano 2008-08-28 23:28 ` Perry Wagle 2008-08-28 23:30 ` Petr Baudis 2008-08-28 23:41 ` git-* in test scripts (was On deprecating "git-foo" for builtins) Jeff King 2008-08-29 0:04 ` git-* in test scripts Junio C Hamano 2008-08-29 0:10 ` Jeff King 2008-08-29 7:51 ` [kernel.org users] [RFD] On deprecating "git-foo" for builtins Andreas Ericsson 2008-08-29 8:05 ` Matthieu Moy 2008-08-29 8:23 ` Andreas Ericsson 2008-08-29 8:27 ` Matthias Kestenholz 2008-08-29 9:02 ` Matthieu Moy 2008-08-28 23:12 ` Perry Wagle 2008-08-29 15:24 ` Aidan Van Dyk 2008-08-29 16:11 ` Felipe Contreras 2008-08-29 16:24 ` Aidan Van Dyk 2008-08-29 16:28 ` Felipe Contreras 2008-08-29 16:41 ` Aidan Van Dyk 2008-08-30 8:13 ` Andreas Ericsson 2008-08-28 23:31 ` Jakub Narebski 2008-08-29 9:33 ` Wincent Colaiuta 2008-08-30 13:24 ` Steven Rostedt 2008-08-30 13:50 ` Teemu Likonen 2008-08-30 14:08 ` Steven Rostedt 2008-08-26 17:07 ` Jeff King 2008-08-26 17:42 ` Teemu Likonen 2008-08-26 16:17 ` Kristian Høgsberg 2008-08-26 16:23 ` Jean Delvare 2008-08-26 16:50 ` Takashi Iwai 2008-08-26 17:20 ` Jean Delvare 2008-08-27 7:42 ` Andreas Ericsson 2008-08-27 8:21 ` Jean Delvare 2008-08-27 15:14 ` Geert Uytterhoeven 2008-08-26 20:14 ` H. Peter Anvin 2008-08-27 7:42 ` Jean Delvare 2008-08-27 8:32 ` [kernel.org users] " Andreas Ericsson 2008-08-26 17:03 ` Linus Torvalds 2008-08-26 17:29 ` Bruce Stephens 2008-08-26 17:35 ` Petr Baudis 2008-08-26 17:38 ` Bruce Stephens 2008-08-28 15:21 ` Johannes Schindelin 2008-08-26 17:34 ` Takashi Iwai 2008-08-26 18:09 ` Dominik Brodowski 2008-08-26 18:19 ` Linus Torvalds 2008-08-26 18:55 ` Al Viro 2008-08-26 19:04 ` Linus Torvalds 2008-08-26 19:22 ` Al Viro 2008-08-26 19:11 ` Teemu Likonen 2008-08-28 15:24 ` Johannes Schindelin 2008-08-26 21:08 ` Dominik Brodowski 2008-08-26 21:28 ` Junio C Hamano 2008-08-26 21:38 ` Linus Torvalds 2008-08-26 23:21 ` Perry Wagle 2008-08-27 15:27 ` Steven Rostedt 2008-08-27 23:09 ` Russell King 2008-08-27 23:53 ` Stefan Richter 2008-08-28 19:19 ` Russell King 2008-08-28 20:10 ` Junio C Hamano 2008-08-28 20:30 ` Matthew Wilcox 2008-08-28 20:36 ` Petr Baudis 2008-08-28 20:57 ` Stefan Richter 2008-08-28 21:05 ` Perry Wagle 2008-08-28 1:25 ` Steven Rostedt 2008-08-27 0:34 ` A Large Angry SCM 2008-08-27 12:23 ` Krzysztof Halasa 2008-08-26 20:39 ` Junio C Hamano 2008-08-26 21:03 ` Jeff King 2008-08-27 2:24 ` Jay Soffian 2008-08-27 14:49 ` H. Peter Anvin 2008-08-26 23:36 ` Perry Wagle 2008-08-26 23:45 ` Nicolas Pitre 2008-08-28 15:32 ` Johannes Schindelin 2008-08-27 0:17 ` Matthew Wilcox 2008-08-27 22:52 ` Russell King 2008-08-28 15:34 ` Johannes Schindelin 2008-08-28 16:10 ` Matthew Wilcox 2008-08-28 19:18 ` Johannes Schindelin 2008-08-28 19:27 ` Matthew Wilcox 2008-08-27 23:38 ` Junio C Hamano 2008-08-28 0:09 ` Felipe Contreras 2008-08-28 0:44 ` Jeff Garzik 2008-08-28 7:14 ` David Woodhouse 2008-08-28 8:17 ` Junio C Hamano 2008-08-28 8:32 ` David Woodhouse 2008-08-28 8:57 ` Felipe Contreras 2008-08-28 11:54 ` Al Viro 2008-08-28 13:15 ` Felipe Contreras 2008-08-28 13:34 ` Felipe Contreras 2008-08-28 13:45 ` Paolo Ciarrocchi 2008-08-28 16:37 ` Linus Torvalds 2008-08-28 20:42 ` Perry Wagle 2008-08-28 23:03 ` Jakub Narebski 2008-08-28 23:14 ` Perry Wagle 2008-08-28 23:45 ` Jeff King 2008-08-28 23:55 ` Perry Wagle 2008-08-29 14:12 ` Felipe Contreras 2008-08-28 14:06 ` Nicolas Pitre 2008-08-28 14:13 ` Nicolas Pitre 2008-08-28 16:17 ` Linus Torvalds 2008-08-26 2:58 ` A Large Angry SCM 2008-08-26 7:17 ` Jean Delvare 2008-08-26 11:12 ` A Large Angry SCM 2008-08-26 11:56 ` Stefan Richter 2008-08-26 21:00 ` Steven Rostedt 2008-08-26 14:28 ` Shawn O. Pearce 2008-08-26 14:46 ` Jeff King
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 NNTP newsgroup(s).