From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:55
Jeff King [off-list ref] writes:
On Thu, Nov 29, 2007 at 04:13:29PM -0800, Junio C Hamano wrote:
quoted
- Post v1.5.5, start cooking the change that does not install hardlinks
for built-in commands, aiming for inclusion in v1.5.6, in May-Jun
2008 timeframe.
I am still against this step, for the reasons mentioned in the mails
leading up to the one you just quoted. I am fine with "does not install
hardlinks for builtin-commands on systems that don't support hardlinks"
(and of course all such hardlinks are in $(libexecdir)/git-core at this
point).
I understand your point was primarily "git-a<tab>". I think it has been
solved for bash and zsh but not for other shells. I think possible and
sensible avenues are (1) punt -- cvs, svn nor hg people do not seem to
have problem with it, or (2) implement completion in your other favorite
shells.
And I think the following from Linus makes sense.
And from a consistency standpoint, that would be a *good* thing. There are
many reasons why the git-xyz format *cannot* be the "consistent" form
(ranging from the flags like --bare and -p to just aliases), so
encouraging people to move to "git xyz" is just a good idea.
Yeah, yeah, the man-pages need the "git-xyz" form, but on the other hand,
rather than "man git-xyz", you can just do "git help xyz" instead, and now
you're consistently avoiding the dash again!
but I am feeling quite feverish today so I may be missing something
obvious.
From: Jeff King <hidden> Date: 2016-06-15 22:43:55
On Thu, Nov 29, 2007 at 04:49:26PM -0800, Junio C Hamano wrote:
I understand your point was primarily "git-a<tab>". I think it has been
solved for bash and zsh but not for other shells. I think possible and
sensible avenues are (1) punt -- cvs, svn nor hg people do not seem to
have problem with it, or (2) implement completion in your other favorite
shells.
My point is that (2) is already implemented for every program (shell or
no) which understands filename completion, and there is a proposal for
taking it away. I would consider that, except I haven't see any claimed
advantages except that the hardlinks are awful under Windows.
I am proposing to have those dashed forms on platforms where it makes
sense, but to treat them as second-class citizens (by putting them in
$(libexecdir), which will address consistency problems.
And I think the following from Linus makes sense.
quoted
And from a consistency standpoint, that would be a *good* thing. There are
many reasons why the git-xyz format *cannot* be the "consistent" form
(ranging from the flags like --bare and -p to just aliases), so
encouraging people to move to "git xyz" is just a good idea.
Yeah, yeah, the man-pages need the "git-xyz" form, but on the other hand,
rather than "man git-xyz", you can just do "git help xyz" instead, and now
you're consistently avoiding the dash again!
but I am feeling quite feverish today so I may be missing something
obvious.
I thought Linus' point was that moving the subcommands was sufficient
for dealing with the consistency issue (i.e., all scripts would move to
"git foo" and only those people who really wanted to would put the
dashed forms in their path). From the same email you quoted, but just
above:
On Thu, 29 Nov 2007, Jeff King wrote:
quoted
Yes, I am fine with the user having to go to extra lengths to use the
dash forms (like adding $(libexecdir) to their path), which I think
should address your consistency concern.
I agree. If we actually start moving the subcommands into a separate
directory, I suspect scripts will be fixed up soon enough. Of course
people *can* do it by just adding the path, but more likely, we'll just
see people start doign "git xyz" instead of "git-xyz".
But now we are arguing about what Linus meant like it is scripture. ;)
-Peff
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:43:55
On Thu, 29 Nov 2007, Jeff King wrote:
On Thu, Nov 29, 2007 at 04:49:26PM -0800, Junio C Hamano wrote:
quoted
I understand your point was primarily "git-a<tab>". I think it has been
solved for bash and zsh but not for other shells. I think possible and
sensible avenues are (1) punt -- cvs, svn nor hg people do not seem to
have problem with it, or (2) implement completion in your other favorite
shells.
My point is that (2) is already implemented for every program (shell or
no) which understands filename completion, and there is a proposal for
taking it away. I would consider that, except I haven't see any claimed
advantages except that the hardlinks are awful under Windows.
Weren't enough complaints about Git having waaaaaaaaaaay too many
commands? Didn't those complaints come about often enough already?
$ git-[tab]
Display all 135 possibilities? (y or n)
Nicolas
From: Jeff King <hidden> Date: 2016-06-15 22:43:55
On Thu, Nov 29, 2007 at 08:13:04PM -0500, Nicolas Pitre wrote:
quoted
My point is that (2) is already implemented for every program (shell or
no) which understands filename completion, and there is a proposal for
taking it away. I would consider that, except I haven't see any claimed
advantages except that the hardlinks are awful under Windows.
Weren't enough complaints about Git having waaaaaaaaaaay too many
commands? Didn't those complaints come about often enough already?
$ git-[tab]
Display all 135 possibilities? (y or n)
Go back and read the thread to which you are responding. I am _not_
arguing against moving those commands to $(libexecdir) where no sane
user will ever see them. That change addresses the issue you are talking
about.
I _am_ arguing against removing them entirely, for those of us who want
to go to the trouble of enabling this (by putting a non-standard entry
into our PATH). Because the issue you are talking about will already
have been dealt with, it is no longer a compelling reason to remove the
hardlinks entirely.
The only reason I have heard to remove them entirely is that Windows
doesn't properly support hardlinks, which I addressed in my other mails
(and to which I have seen no rebuttal).
-Peff
I thought Linus' point was that moving the subcommands was sufficient
for dealing with the consistency issue (i.e., all scripts would move to
"git foo" and only those people who really wanted to would put the
dashed forms in their path).
Yes. I meant that we might as well keep all the git-xyz forms around, but
_only_ in the libexec directory (and make sure that the libexec directory
by default is *not* a binary directory), so that they'd normally not be
visible.
So then, people who want to use the old-fashioned git-xyz forms, because
they just really hate white-space or whatever, could choose to do one of
two things:
- either just change the default libexec directory to be the same as the
binary install directory, and have all the git-xyz things in the same
place they've always been.
- or just add $(gitlibexec) into their path.
but the default (which is what 99% of all people use) would be to not
show them. I also think that it makes sense to avoid wasting diskspace
with duplicate files, so in situations where you don't have hardlinks,
just don't install the git-xyz files at all by default (and again, maybe
we can have a option to the installer to do it for people who really are
very attached to the git-xyz format, and prefer to waste even a lot of
disk on it)
So I just think that the whole idiotic complaint that some people have
(that whole "git-<tab><tab>" shows "Display all 144 possibilities?" and
people are somehow using that as an argument that git is "complex") should
be something we strive to undo. I think the complaint is insane (because
the answer is "well, nobody forces you to _use_ all the power and scripts
we give you!"), but still, it's a complaint, so let's just assume the user
is right, and try to fix it.
So when you do "git-<tab><tab>" it should just beep at you and not show
anything at all by default. And when you do "git <tab><tab>", we should
make sure that the bash expansion (or zsh or whatever) shows a nice
collection of common plumbing, not soemthing really scary.
Linus
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:43:55
On Thu, 29 Nov 2007, Linus Torvalds wrote:
Yes. I meant that we might as well keep all the git-xyz forms around, but
_only_ in the libexec directory (and make sure that the libexec directory
by default is *not* a binary directory), so that they'd normally not be
visible.
So then, people who want to use the old-fashioned git-xyz forms, because
they just really hate white-space or whatever, could choose to do one of
two things:
- either just change the default libexec directory to be the same as the
binary install directory, and have all the git-xyz things in the same
place they've always been.
- or just add $(gitlibexec) into their path.
but the default (which is what 99% of all people use) would be to not
show them. I also think that it makes sense to avoid wasting diskspace
with duplicate files, so in situations where you don't have hardlinks,
just don't install the git-xyz files at all by default (and again, maybe
we can have a option to the installer to do it for people who really are
very attached to the git-xyz format, and prefer to waste even a lot of
disk on it)
So I just think that the whole idiotic complaint that some people have
(that whole "git-<tab><tab>" shows "Display all 144 possibilities?" and
people are somehow using that as an argument that git is "complex") should
be something we strive to undo. I think the complaint is insane (because
the answer is "well, nobody forces you to _use_ all the power and scripts
we give you!"), but still, it's a complaint, so let's just assume the user
is right, and try to fix it.
Absolutely!
And despite Junio's appearance of some cowardliness on this issue :-)
I think we should have this right now instead of later. Like Junio said
himself, this was planned for a while already, and poorly maintained
external scripts are already failing due to other reasons anyway.
Nicolas
The only reason I have heard to remove them entirely is that Windows
doesn't properly support hardlinks, which I addressed in my other
mails
(and to which I have seen no rebuttal).
We don't have a problem with hardlinks for git-* commands in
msysgit. The msysgit installer already creates hardlinks if
installing on NTFS. On non-NTFS partitions, though, it needs
to copy the files.
Note, this doesn't mean we love hardlinks in msysgit. Actually,
msys does _not_ support them in its Unix emulation layer. So,
for daily work git does not have hardlinks. For examples, the
test script skip all hardlink related tests. The installer
handles hardlinks using the Windows API directly and not using
the Unix emulation layer.
We already have a setup that supports exporting only git and
gitk to the a Windows Command Prompt (not the bash that comes
with msysgit). If you choose this setup, a directory that
contains only these two commands will be added to the system
wide PATH. We use this indirection to hide all the the Unix
tools that are included in msysgit (and needed by git) from
the Windows Command Prompt.
Steffen
On Nov 30, 2007, at 3:29 AM, Linus Torvalds wrote:
So I just think that the whole idiotic complaint that some people have
(that whole "git-<tab><tab>" shows "Display all 144 possibilities?"
and
people are somehow using that as an argument that git is "complex")
should
be something we strive to undo. I think the complaint is insane
(because
the answer is "well, nobody forces you to _use_ all the power and
scripts
we give you!"), but still, it's a complaint, so let's just assume
the user
is right, and try to fix it.
So when you do "git-<tab><tab>" it should just beep at you and not
show
anything at all by default. And when you do "git <tab><tab>", we
should
make sure that the bash expansion (or zsh or whatever) shows a nice
collection of common plumbing, not soemthing really scary.
What will happen to gitk?
Shouldn't it be included in the nice collection? gitk is
an essential command. Then, following your reasoning,
"git <tab><tab>" should recommend it, no?
Note, "git gui" already works. gitk would really be the last
git "command" that can't be accessed through "git <command>"
Steffen
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:55
Jeff King wrote:
On Thu, Nov 29, 2007 at 08:13:04PM -0500, Nicolas Pitre wrote:
quoted
quoted
My point is that (2) is already implemented for every program (shell or
no) which understands filename completion, and there is a proposal for
taking it away. I would consider that, except I haven't see any claimed
advantages except that the hardlinks are awful under Windows.
Weren't enough complaints about Git having waaaaaaaaaaay too many
commands? Didn't those complaints come about often enough already?
$ git-[tab]
Display all 135 possibilities? (y or n)
Go back and read the thread to which you are responding. I am _not_
arguing against moving those commands to $(libexecdir) where no sane
user will ever see them. That change addresses the issue you are talking
about.
I _am_ arguing against removing them entirely, for those of us who want
to go to the trouble of enabling this (by putting a non-standard entry
into our PATH). Because the issue you are talking about will already
have been dealt with, it is no longer a compelling reason to remove the
hardlinks entirely.
The only reason I have heard to remove them entirely is that Windows
doesn't properly support hardlinks, which I addressed in my other mails
(and to which I have seen no rebuttal).
It would provide a ui inconsistency between platforms. Several people
pointed that out. It's decidedly a Bad Thing.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Jeff King <hidden> Date: 2016-06-15 22:43:55
On Fri, Nov 30, 2007 at 08:18:16AM +0100, Andreas Ericsson wrote:
quoted
The only reason I have heard to remove them entirely is that Windows
doesn't properly support hardlinks, which I addressed in my other mails
(and to which I have seen no rebuttal).
It would provide a ui inconsistency between platforms. Several people
pointed that out. It's decidedly a Bad Thing.
Which, as I said, I have already addressed (and which Linus has also
expanded upon in this thread). Since those hardlinks would be hidden
from users who did not go to some trouble to find them, there will not
be inconsistency problems. Scripts will have to either go to some effort
to change their PATH, or simply use the correct form, and I expect them
to do the latter.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:43:55
On Fri, Nov 30, 2007 at 06:51:35AM +0100, Steffen Prohaska wrote:
What will happen to gitk?
Shouldn't it be included in the nice collection? gitk is
an essential command. Then, following your reasoning,
"git <tab><tab>" should recommend it, no?
Note, "git gui" already works. gitk would really be the last
git "command" that can't be accessed through "git <command>"
Except for qgit, tig, etc. The only difference being that gitk actually
ships with git.
But I am not opposed to having some "git foo" form for gitk.
-Peff
On Nov 30, 2007 4:12 PM, Jeff King [off-list ref] wrote:
On Fri, Nov 30, 2007 at 06:51:35AM +0100, Steffen Prohaska wrote:
quoted
What will happen to gitk?
Shouldn't it be included in the nice collection? gitk is
an essential command. Then, following your reasoning,
"git <tab><tab>" should recommend it, no?
Note, "git gui" already works. gitk would really be the last
git "command" that can't be accessed through "git <command>"
Except for qgit, tig, etc. The only difference being that gitk actually
ships with git.
But I am not opposed to having some "git foo" form for gitk.
In mercurial "hg view" is actually an old version of gitk modified for hg.
And as "git view" it could be added to the "git help" list.
Santi
On Fri, Nov 30, 2007 at 04:28:21PM +0100, Santi Béjar wrote:
quoted
quoted
But I am not opposed to having some "git foo" form for gitk.
In mercurial "hg view" is actually an old version of gitk modified for hg.
And as "git view" it could be added to the "git help" list.
Unfortunately, there is already a "gitview" program similar to gitk,
although it never made it out of contrib/.
Well, different people will want different viewers *anyway* (ie some will
prefer qgit etc), so how about making "git view" be something that
literally acts as a built-in alias that just defaults to running gitk (if
for no other reason than the fact that gitk is the one that ships with
git, and simply has most users).
There's a few other things that I think we could consider to be good
built-in aliases: things like "git cat" being an alias for "git -p
cat-file -p" etc.
The only difference between a "built-in alias" and a "built-in command"
would be:
- the alias has never even had the "git-xyz" format, and never will
- the alias can be overridden by user aliases unlike "real" git commands
Hmm?
That way we can hide away gitk too (although I do suspect that we might as
well just leave gitk in the path - it's different in naming from all the
git-xyz commands anyway)
Linus
From: Jeff King <hidden> Date: 2016-06-15 22:43:55
On Fri, Nov 30, 2007 at 07:50:47AM -0800, Linus Torvalds wrote:
Well, different people will want different viewers *anyway* (ie some will
prefer qgit etc), so how about making "git view" be something that
literally acts as a built-in alias that just defaults to running gitk (if
for no other reason than the fact that gitk is the one that ships with
git, and simply has most users).
I think that is a good idea, and here's a patch.
-- >8 --
Support builtin aliases
Builtin aliases are "default" alias values that can be
overridden by user-configured aliases.
For example, the first such alias is "view", an alias for
gitk. A user with no further configuration can run
"git view" to use gitk. However, they can also set the
config option "alias.view" to "!tig" to run tig.
---
git.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:55
Hi,
On Fri, 30 Nov 2007, Jeff King wrote:
quoted hunk
Support builtin aliases
Builtin aliases are "default" alias values that can be
overridden by user-configured aliases.
For example, the first such alias is "view", an alias for
gitk. A user with no further configuration can run
"git view" to use gitk. However, they can also set the
config option "alias.view" to "!tig" to run tig.
---
git.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
From: Jeff King <hidden> Date: 2016-06-15 22:43:55
On Fri, Nov 30, 2007 at 11:05:50PM +0000, Johannes Schindelin wrote:
quoted
quoted
quoted
alias_command = (*argv)[0];
git_config(git_alias_config);
+ if (!alias_string)
+ alias_string = builtin_alias(alias_command);
if (alias_string) {
if (alias_string[0] == '!') {
if (*argcp > 1) {
Didn't you mean to put this _before_ the git_config() call? As you wrote
it, the "soft" alias overrides the user-specified one.
No. The "if (!alias_string)" means we only do the lookup if no user
alias was found. Try it.
Ah. To me, that was rather easy to miss, though...
I don't particularly care if it is re-written as:
alias_string = builtin_alias(alias_command);
git_config(git_alias_config);
which should be equivalent. I wrote it the original way to avoid doing
the O(n) search through builtin aliases when it was unnecessary, but
obviously this isn't a performance critical code path.
-Peff
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:55
Hi,
On Fri, 30 Nov 2007, Jeff King wrote:
On Fri, Nov 30, 2007 at 11:05:50PM +0000, Johannes Schindelin wrote:
quoted
quoted
quoted
quoted
alias_command = (*argv)[0];
git_config(git_alias_config);
+ if (!alias_string)
+ alias_string = builtin_alias(alias_command);
if (alias_string) {
if (alias_string[0] == '!') {
if (*argcp > 1) {
Didn't you mean to put this _before_ the git_config() call? As you wrote
it, the "soft" alias overrides the user-specified one.
No. The "if (!alias_string)" means we only do the lookup if no user
alias was found. Try it.
Ah. To me, that was rather easy to miss, though...
I don't particularly care if it is re-written as:
alias_string = builtin_alias(alias_command);
git_config(git_alias_config);
which should be equivalent. I wrote it the original way to avoid doing
the O(n) search through builtin aliases when it was unnecessary, but
obviously this isn't a performance critical code path.
Actually, I felt/feel quite dumb missing it.
Ciao,
Dscho