From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:54
"Nguyen Thai Ngoc Duy" [off-list ref] writes:
On Nov 28, 2007 8:13 AM, Junio C Hamano [off-list ref] wrote:
quoted
In case somebody is thinking about 36e5e70e0f40 (Start deprecating
"git-command" in favor of "git command"), that is a somewhat different
issue. What Linus suggested is not installing git-foo link for built-in
commands _anywhere_ on the filesystem. Not just "out of user's PATH".
That is not deprecating dash form but removing the support for it. We
need to give ample time for users to adjust to such a change.
A little note on this one. I've been using git without builtin links
for a while with my git-box port. There are still some builtin fixups
needed. And because execv_git_cmd() always uses dash form, so it's
impossible to use vanilla git without builtin links.
Thanks for a heads up.
Would people agree with a rough roadmap like this?
- v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the
release notes for the version will warn users that:
(1) using git-foo from the command line, and
(2) using git-foo from your scripts without first prepending the
return value of "git --exec-path" to the PATH
is now officially deprecated (it has been deprecated for a long time
since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with
the default configuration that does not install git-foo form in
user's PATH.
- Post v1.5.4, start cooking gitexecdir=$(libexecdir)/git-core, aiming
for inclusion in v1.5.5, perhaps in Mar-Feb 2008 timeframe.
- The release notes for v1.5.5 will warn users that git-foo will be
removed in v1.6.0 for many commands and it will be merely an accident
if some of them still work.
- Post v1.5.5, start cooking the change that does not install hardlinks
for built-in commands, aiming for inclusion in v1.6.0, by the end of
2008.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:54
Hi,
On Wed, 28 Nov 2007, Junio C Hamano wrote:
"Nguyen Thai Ngoc Duy" [off-list ref] writes:
quoted
On Nov 28, 2007 8:13 AM, Junio C Hamano [off-list ref] wrote:
quoted
In case somebody is thinking about 36e5e70e0f40 (Start deprecating
"git-command" in favor of "git command"), that is a somewhat different
issue. What Linus suggested is not installing git-foo link for built-in
commands _anywhere_ on the filesystem. Not just "out of user's PATH".
That is not deprecating dash form but removing the support for it. We
need to give ample time for users to adjust to such a change.
A little note on this one. I've been using git without builtin links
for a while with my git-box port. There are still some builtin fixups
needed. And because execv_git_cmd() always uses dash form, so it's
impossible to use vanilla git without builtin links.
Thanks for a heads up.
Would people agree with a rough roadmap like this?
- v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the
release notes for the version will warn users that:
(1) using git-foo from the command line, and
(2) using git-foo from your scripts without first prepending the
return value of "git --exec-path" to the PATH
is now officially deprecated (it has been deprecated for a long time
since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with
the default configuration that does not install git-foo form in
user's PATH.
Maybe we can squeeze a step in here where only porcelains are installed in
the bindir?
FWIW I think that we should fix the problem with the builtins being called
via their hard links. But how? As of now, libgit.a has no idea what the
builtins are; this information is buried in git.c.
The fundamental problem is that we cannot move handle_internal_command()
into libgit.a, because it has pointers to all builtin cmd_*() functions.
So maybe the best solution would be to try "git <command>" first, and then
"git-<command>"? But this means another exec() call :-(
Ciao,
Dscho
From: A Large Angry SCM <hidden> Date: 2016-06-15 22:43:54
Junio C Hamano wrote:
[...]
Would people agree with a rough roadmap like this?
- v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the
release notes for the version will warn users that:
(1) using git-foo from the command line, and
(2) using git-foo from your scripts without first prepending the
return value of "git --exec-path" to the PATH
is now officially deprecated (it has been deprecated for a long time
since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with
the default configuration that does not install git-foo form in
user's PATH.
- Post v1.5.4, start cooking gitexecdir=$(libexecdir)/git-core, aiming
for inclusion in v1.5.5, perhaps in Mar-Feb 2008 timeframe.
- The release notes for v1.5.5 will warn users that git-foo will be
removed in v1.6.0 for many commands and it will be merely an accident
if some of them still work.
- Post v1.5.5, start cooking the change that does not install hardlinks
for built-in commands, aiming for inclusion in v1.6.0, by the end of
2008.
So long as there remains the option in the Makefile to install the
"dashed" commands in $(bindir) for those of us that wish it.
On Nov 29, 2007 6:14 AM, Junio C Hamano [off-list ref] wrote:
"Nguyen Thai Ngoc Duy" [off-list ref] writes:
quoted
On Nov 28, 2007 8:13 AM, Junio C Hamano [off-list ref] wrote:
quoted
In case somebody is thinking about 36e5e70e0f40 (Start deprecating
"git-command" in favor of "git command"), that is a somewhat different
issue. What Linus suggested is not installing git-foo link for built-in
commands _anywhere_ on the filesystem. Not just "out of user's PATH".
That is not deprecating dash form but removing the support for it. We
need to give ample time for users to adjust to such a change.
A little note on this one. I've been using git without builtin links
for a while with my git-box port. There are still some builtin fixups
needed. And because execv_git_cmd() always uses dash form, so it's
impossible to use vanilla git without builtin links.
Thanks for a heads up.
Would people agree with a rough roadmap like this?
- v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the
release notes for the version will warn users that:
(1) using git-foo from the command line, and
(2) using git-foo from your scripts without first prepending the
return value of "git --exec-path" to the PATH
is now officially deprecated (it has been deprecated for a long time
since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with
the default configuration that does not install git-foo form in
user's PATH.
- Post v1.5.4, start cooking gitexecdir=$(libexecdir)/git-core, aiming
for inclusion in v1.5.5, perhaps in Mar-Feb 2008 timeframe.
- The release notes for v1.5.5 will warn users that git-foo will be
removed in v1.6.0 for many commands and it will be merely an accident
if some of them still work.
- Post v1.5.5, start cooking the change that does not install hardlinks
for built-in commands, aiming for inclusion in v1.6.0, by the end of
2008.
There won't be a stage when only porcelain git-foos are in $(bindir)?
I could stop working on the relevant patch then.
--
Duy
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:43:54
On Thu, 29 Nov 2007, Nguyen Thai Ngoc Duy wrote:
On Nov 29, 2007 6:14 AM, Junio C Hamano [off-list ref] wrote:
quoted
"Nguyen Thai Ngoc Duy" [off-list ref] writes:
quoted
On Nov 28, 2007 8:13 AM, Junio C Hamano [off-list ref] wrote:
quoted
In case somebody is thinking about 36e5e70e0f40 (Start deprecating
"git-command" in favor of "git command"), that is a somewhat different
issue. What Linus suggested is not installing git-foo link for built-in
commands _anywhere_ on the filesystem. Not just "out of user's PATH".
That is not deprecating dash form but removing the support for it. We
need to give ample time for users to adjust to such a change.
A little note on this one. I've been using git without builtin links
for a while with my git-box port. There are still some builtin fixups
needed. And because execv_git_cmd() always uses dash form, so it's
impossible to use vanilla git without builtin links.
Thanks for a heads up.
Would people agree with a rough roadmap like this?
- v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the
release notes for the version will warn users that:
(1) using git-foo from the command line, and
(2) using git-foo from your scripts without first prepending the
return value of "git --exec-path" to the PATH
is now officially deprecated (it has been deprecated for a long time
since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with
the default configuration that does not install git-foo form in
user's PATH.
- Post v1.5.4, start cooking gitexecdir=$(libexecdir)/git-core, aiming
for inclusion in v1.5.5, perhaps in Mar-Feb 2008 timeframe.
- The release notes for v1.5.5 will warn users that git-foo will be
removed in v1.6.0 for many commands and it will be merely an accident
if some of them still work.
- Post v1.5.5, start cooking the change that does not install hardlinks
for built-in commands, aiming for inclusion in v1.6.0, by the end of
2008.
There won't be a stage when only porcelain git-foos are in $(bindir)?
I could stop working on the relevant patch then.
Well, I personally found your effort really nice. I think Junio is
overly cautious in this case, and I would prefer to see the number of
git commands in the default path drop rather sooner than later.
Nicolas
From: Jeff King <hidden> Date: 2016-06-15 22:43:55
On Wed, Nov 28, 2007 at 03:14:56PM -0800, Junio C Hamano wrote:
- Post v1.5.5, start cooking the change that does not install hardlinks
for built-in commands, aiming for inclusion in v1.6.0, by the end of
2008.
I am against this, unless it is configurable. I think the goal of
reducing user-visible commands is fine, and moving things to
$(libexecdir) is a good way of doing that.
However, I personally still think the 'git-foo' forms are valuable
(because fingers have already been trained, and because
non-bash-programmable completions understand them). And I don't mind
putting $(libexecdir)/git-core in my PATH to retain this behavior; it's
a one-time configuration tweak, and it helps new users with the
overwhelming command set.
But I don't see a point to removing the links entirely. The annoyance
factor for people who want git-* is much higher, and I don't see that it
actually buys us any help for new users (who will no longer care after
everything is hidden in $(libexecdir) anyway).
-Peff
On Nov 29, 2007 10:08 PM, Jeff King [off-list ref] wrote:
On Wed, Nov 28, 2007 at 03:14:56PM -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.6.0, by the end of
2008.
I am against this, unless it is configurable. I think the goal of
reducing user-visible commands is fine, and moving things to
$(libexecdir) is a good way of doing that.
However, I personally still think the 'git-foo' forms are valuable
(because fingers have already been trained, and because
non-bash-programmable completions understand them). And I don't mind
putting $(libexecdir)/git-core in my PATH to retain this behavior; it's
a one-time configuration tweak, and it helps new users with the
overwhelming command set.
But I don't see a point to removing the links entirely. The annoyance
factor for people who want git-* is much higher, and I don't see that it
actually buys us any help for new users (who will no longer care after
everything is hidden in $(libexecdir) anyway).
Maybe only not install hardlinks on systems that do not support it
like Windows? git.exe duplication takes a lot of space.
--
Duy
From: Jeff King <hidden> Date: 2016-06-15 22:43:55
On Fri, Nov 30, 2007 at 03:05:05AM +0700, Nguyen Thai Ngoc Duy wrote:
quoted
But I don't see a point to removing the links entirely. The annoyance
factor for people who want git-* is much higher, and I don't see that it
actually buys us any help for new users (who will no longer care after
everything is hidden in $(libexecdir) anyway).
Maybe only not install hardlinks on systems that do not support it
like Windows? git.exe duplication takes a lot of space.
I think that is totally reasonable, as on those platforms there is
actually something to be gained from removing those hardlinks (you could
also of course make a very thin wrapper for "git-foo" that called "git
foo"; it would still be wasteful, but not as much as copying the whole
git.exe. But that is not worth doing unless people on Windows really
want the dash forms).
-Peff
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:55
Hi,
On Thu, 29 Nov 2007, Jeff King wrote:
On Fri, Nov 30, 2007 at 03:05:05AM +0700, Nguyen Thai Ngoc Duy wrote:
quoted
quoted
But I don't see a point to removing the links entirely. The annoyance
factor for people who want git-* is much higher, and I don't see that it
actually buys us any help for new users (who will no longer care after
everything is hidden in $(libexecdir) anyway).
Maybe only not install hardlinks on systems that do not support it
like Windows? git.exe duplication takes a lot of space.
I think that is totally reasonable, as on those platforms there is
actually something to be gained from removing those hardlinks (you could
also of course make a very thin wrapper for "git-foo" that called "git
foo"; it would still be wasteful, but not as much as copying the whole
git.exe. But that is not worth doing unless people on Windows really
want the dash forms).
Note that one big problem with a few platforms having dash forms and
others not is that you _will_ get scripts and aliases that do not work
everywhere.
Consistency is good.
Ciao,
Dscho
From: Jeff King <hidden> Date: 2016-06-15 22:43:55
On Thu, Nov 29, 2007 at 10:19:16PM +0000, Johannes Schindelin wrote:
quoted
I think that is totally reasonable, as on those platforms there is
actually something to be gained from removing those hardlinks (you could
Note that one big problem with a few platforms having dash forms and
others not is that you _will_ get scripts and aliases that do not work
everywhere.
Consistency is good.
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.
-Peff
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".
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!
Linus