From: Junio C Hamano <hidden> Date: 2016-06-15 22:45:13
Johannes Schindelin [off-list ref] writes:
On Mon, 25 Aug 2008, David Woodhouse wrote:
quoted
On Sat, 2008-08-23 at 20:33 -0700, Junio C Hamano wrote:
quoted
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.
From: David Woodhouse <dwmw2@infradead.org> Date: 2016-06-15 22:45:13
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
From: Jeff King <hidden> Date: 2016-06-15 22:45:13
On Mon, Aug 25, 2008 at 04:41:57PM -0700, Junio C Hamano wrote:
quoted
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
From: Kristian Høgsberg <hidden> Date: 2016-06-15 22:45:13
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:
quoted
quoted
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
From: David Woodhouse <dwmw2@infradead.org> Date: 2016-06-15 22:45:13
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
On Tue, Aug 26, 2008 at 5:59 PM, David Woodhouse [off-list ref] wrote:
On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:
quoted
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.
From: Kristian Høgsberg <hidden> Date: 2016-06-15 22:45:13
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:
quoted
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
From: Jean Delvare <hidden> Date: 2016-06-15 22:45:13
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:
quoted
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.
From: Petr Baudis <hidden> Date: 2016-06-15 22:45:13
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
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:
quoted
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.
At Tue, 26 Aug 2008 18:23:49 +0200,
Jean Delvare wrote:
On Tue, 26 Aug 2008 16:59:58 +0100, David Woodhouse wrote:
quoted
On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:
quoted
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?
From: Jeff King <hidden> Date: 2016-06-15 22:45:13
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
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
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
From: Petr Baudis <hidden> Date: 2016-06-15 22:45:13
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:
quoted
On Tue, Aug 26, 2008 at 06:04:00PM +0200, Matthias Kestenholz wrote:
quoted
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
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
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:45:13
Petr Baudis [off-list ref] wrote:
On Tue, Aug 26, 2008 at 06:45:26PM +0200, Andi Kleen wrote:
quoted
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.
From: Jeff King <hidden> Date: 2016-06-15 22:45:13
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
From: Jean Delvare <hidden> Date: 2016-06-15 22:45:13
On Tue, 26 Aug 2008 18:50:25 +0200, Takashi Iwai wrote:
At Tue, 26 Aug 2008 18:23:49 +0200,
Jean Delvare wrote:
quoted
On Tue, 26 Aug 2008 16:59:58 +0100, David Woodhouse wrote:
quoted
On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:
quoted
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
From: Petr Baudis <hidden> Date: 2016-06-15 22:45:13
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 <redacted>
---
contrib/completion/git-completion.bash | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:45:13
Petr Baudis [off-list ref] 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 <redacted>
Acked-by: Shawn O. Pearce <redacted>
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...
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
At Tue, 26 Aug 2008 10:03:25 -0700 (PDT),
Linus Torvalds wrote:
On Tue, 26 Aug 2008, David Woodhouse wrote:
quoted
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
From: Jakub Narebski <hidden> Date: 2016-06-15 22:45:13
Petr Baudis [off-list ref] writes:
quoted hunk
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 <redacted>
---
contrib/completion/git-completion.bash | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
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.
From: Jakub Narebski <hidden> Date: 2016-06-15 22:45:13
"Shawn O. Pearce" [off-list ref] writes:
Petr Baudis [off-list ref] wrote:
quoted
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 <redacted>
Acked-by: Shawn O. Pearce <redacted>
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
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.
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
Linus,
On Tue, Aug 26, 2008 at 10:03:25AM -0700, Linus Torvalds wrote:
quoted
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
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
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"
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
From: Teemu Likonen <hidden> Date: 2016-06-15 22:45:14
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.
On Tue, Aug 26, 2008 at 12:04:51PM -0700, Linus Torvalds wrote:
On Tue, 26 Aug 2008, Al Viro wrote:
quoted
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)...
From: "H. Peter Anvin" <hpa@kernel.org> Date: 2016-06-15 22:45:14
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
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:
quoted
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
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
From: Perry Wagle <hidden> Date: 2016-06-15 22:45:14
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)
From: A Large Angry SCM <hidden> Date: 2016-06-15 22:45:14
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.
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
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:45:14
Jean Delvare wrote:
On Tue, 26 Aug 2008 18:50:25 +0200, Takashi Iwai wrote:
quoted
At Tue, 26 Aug 2008 18:23:49 +0200,
Jean Delvare wrote:
quoted
On Tue, 26 Aug 2008 16:59:58 +0100, David Woodhouse wrote:
quoted
On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:
quoted
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
From: Jean Delvare <hidden> Date: 2016-06-15 22:45:14
Hi Peter,
On Tue, 26 Aug 2008 13:14:59 -0700, H. Peter Anvin wrote:
Jean Delvare wrote:
quoted
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
From: "H. Peter Anvin" <hpa@kernel.org> Date: 2016-06-15 22:45:14
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
From: Jean Delvare <hidden> Date: 2016-06-15 22:45:14
On Wed, 27 Aug 2008 09:42:44 +0200, Andreas Ericsson wrote:
Jean Delvare wrote:
quoted
On Tue, 26 Aug 2008 18:50:25 +0200, Takashi Iwai wrote:
quoted
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
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:45:14
H. Peter Anvin wrote:
Jean Delvare wrote:
quoted
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
On Wed, 27 Aug 2008 09:42:44 +0200, Andreas Ericsson wrote:
quoted
Jean Delvare wrote:
quoted
On Tue, 26 Aug 2008 18:50:25 +0200, Takashi Iwai wrote:
quoted
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
From: Steven Rostedt <rostedt@goodmis.org> Date: 2016-06-15 22:45:14
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
From: Matthew Wilcox <hidden> Date: 2016-06-15 22:45:14
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."
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
From: Jeff King <hidden> Date: 2016-06-15 22:45:14
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
From: Perry Wagle <hidden> Date: 2016-06-15 22:45:14
On Aug 27, 2008, at 12:50 PM, Jeff King wrote:
On Wed, Aug 27, 2008 at 12:43:23PM -0700, Perry Wagle wrote:
quoted
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
From: Jeff Garzik <hidden> Date: 2016-06-15 22:45:14
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
From: Jeff King <hidden> Date: 2016-06-15 22:45:14
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
From: Jeff Garzik <hidden> Date: 2016-06-15 22:45:14
Jeff King wrote:
On Wed, Aug 27, 2008 at 04:24:19PM -0400, Jeff Garzik wrote:
quoted
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
From: "H. Peter Anvin" <hpa@kernel.org> Date: 2016-06-15 22:45:14
Perry Wagle wrote:
quoted
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.
From: Jeff King <hidden> Date: 2016-06-15 22:45:14
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
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
From: Matthew Wilcox <hidden> Date: 2016-06-15 22:45:14
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."
From: Adrian Bunk <bunk@kernel.org> Date: 2016-06-15 22:45:14
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:
quoted
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
From: Steven Rostedt <rostedt@goodmis.org> Date: 2016-06-15 22:45:14
On Wed, 27 Aug 2008, H. Peter Anvin wrote:
Perry Wagle wrote:
quoted
quoted
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
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
From: Adrian Bunk <bunk@kernel.org> Date: 2016-06-15 22:45:14
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:
quoted
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
From: Russell King <hidden> Date: 2016-06-15 22:45:14
On Wed, Aug 27, 2008 at 11:27:04AM -0400, Steven Rostedt wrote:
On Tue, 26 Aug 2008, Perry Wagle wrote:
quoted
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:
From: Jeff Garzik <hidden> Date: 2016-06-15 22:45:14
Linus Torvalds wrote:
On Wed, 27 Aug 2008, Jeff Garzik wrote:
quoted
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)
From: Stefan Richter <stefanr@s5r6.in-berlin.de> Date: 2016-06-15 22:45:14
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/
From: Steven Rostedt <rostedt@goodmis.org> Date: 2016-06-15 22:45:14
On Thu, 28 Aug 2008, Russell King wrote:
On Wed, Aug 27, 2008 at 11:27:04AM -0400, Steven Rostedt wrote:
quoted
On Tue, 26 Aug 2008, Perry Wagle wrote:
quoted
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:
From: Alex Riesen <hidden> Date: 2016-06-15 22:45:14
2008/8/28 Ingo Molnar [off-list ref]:
* Jeff Garzik [off-list ref] wrote:
quoted
'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).
From: Russell King <hidden> Date: 2016-06-15 22:45:15
On Thu, Aug 28, 2008 at 01:53:50AM +0200, Stefan Richter wrote:
Russell King wrote:
quoted
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:
From: Mike Hommey <hidden> Date: 2016-06-15 22:45:15
On Wed, Aug 27, 2008 at 04:38:13PM -0400, Jeff Garzik wrote:
Jeff King wrote:
quoted
On Wed, Aug 27, 2008 at 04:24:19PM -0400, Jeff Garzik wrote:
quoted
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
From: Stefan Richter <stefanr@s5r6.in-berlin.de> Date: 2016-06-15 22:45:15
Russell King wrote:
On Thu, Aug 28, 2008 at 01:53:50AM +0200, Stefan Richter wrote:
quoted
"-" -> " "? 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/
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
On Thu, Aug 28, 2008 at 08:51:24AM +0200, Ingo Molnar wrote:
quoted
'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)
From: Perry Wagle <hidden> Date: 2016-06-15 22:45:15
On Aug 28, 2008, at 1:57 PM, Stefan Richter wrote:
Russell King wrote:
quoted
On Thu, Aug 28, 2008 at 01:53:50AM +0200, Stefan Richter wrote:
quoted
"-" -> " "? 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>