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...(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
--Acked-by: A Large Angry SCM <gitzilla@gmail.com> --
Such statements from anonymous people have zero value, sorry. -- Jean Delvare --
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 --
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. --
...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/ --
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 --
Hi, 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 --
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. --
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
--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-discuss...
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." --
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. --
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 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 --
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. --
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 --
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 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 --
... 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 --
By this I mean "git-" out of /usr/bin, before someone replies saying that "git " is always available. Nicolas --
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 --
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 --
On Thu, Aug 28, 2008 at 4:15 PM, Felipe Contreras 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 --
It _is_ obsolete, but there's a trivial compatibility thing. Are you happy now? How hard is it to really understand? Linus --
On Thu, Aug 28, 2008 at 7:37 PM, Linus Torvalds 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 --
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
--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
--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 --
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 Thu, Aug 28, 2008 at 3:34 PM, Felipe Contreras 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/ --
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 --
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 --
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 --
Hi, 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 --
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." --
Hi, 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 --
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." --
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 --
Hi, Not wanting to be part of a _silent_ majority, I fully agree, loudly. Ciao, Dscho --
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) --
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 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 --
+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. --
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 --
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 --
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 --
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 --
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 --
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. --
Linus, 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 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 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 --
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 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 --
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) --
Did you see the yellow bulldozer coming at your house while brushing your teeth? -- Steve --
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: --
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). --
(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/ --
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. "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: --
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/ --
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> --
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 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. --
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 --
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." --