From: David Kastrup <hidden> Date: 2016-06-15 22:43:53
Jakub Narebski [off-list ref] writes:
If you would write git from scratch now, from the beginning, without
concerns for backwards compatibility, what would you change, or what
would you want to have changed?
Get rid of plumbing at the command line level. It is confusing to
users, and command line arguments, exec calls and I/O streams are not
efficient and reasonably typed mechanisms for the kind of operations
done in plumbing. Instead using a good extensible portable scripting
language (I consider Lua quite suitable in that regard, but it is
conceivable that something with a native list type supporting easy
sorts, merges and selections could be more efficient) and implementing
plumbing in that or in C would have been preferable for creating the
porcelain.
That would keep plumbing out of the hair of users and make it easier to
cobble together extensions and variations with non-trivial internal
dataflow.
Shell scripts have also proven to be a constant hassle with regard to
portability and bugs (like underquoting).
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Jan Hudec <hidden> Date: 2016-06-15 22:43:53
On Mon, Nov 26, 2007 at 18:11:43 +0100, David Kastrup wrote:
Jakub Narebski [off-list ref] writes:
quoted
If you would write git from scratch now, from the beginning, without
concerns for backwards compatibility, what would you change, or what
would you want to have changed?
Get rid of plumbing at the command line level. It is confusing to
No, please. It's extremely useful. It should be a bit more hidden, but it's
a big advantage of git that the plumbing is available.
users, and command line arguments, exec calls and I/O streams are not
efficient and reasonably typed mechanisms for the kind of operations
done in plumbing. Instead using a good extensible portable scripting
language (I consider Lua quite suitable in that regard, but it is
conceivable that something with a native list type supporting easy
sorts, merges and selections could be more efficient) and implementing
plumbing in that or in C would have been preferable for creating the
porcelain.
POSIX shell is really the best extensible portable scripting language
available for the job. Because the whipuptitude is the most important
property and shell is simply best at one-liners. And since you use it
for regular work (running editor, compiler, git porcelain), it is the
obvious choice for whiping up a short function.
That would keep plumbing out of the hair of users and make it easier to
cobble together extensions and variations with non-trivial internal
dataflow.
Shell scripts have also proven to be a constant hassle with regard to
portability and bugs (like underquoting).
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:43:53
On Mon, 26 Nov 2007, David Kastrup wrote:
Get rid of plumbing at the command line level.
We can't get rid of plumbing. It is part of Git probably forever and is
really really convenient for scripting in any language you want.
The only valid argument IMHO is the way too large number of Git commands
directly available from the cmdline.
The solution: make purely plumbing commands _not_ directly available
from the command line. Instead, they can be available through 'git
lowlevel <blah>' instead of 'git <blah>' and only 'git lowlevel' would
stand in your shell default path.
Such a scheme can be implemented in parallel with the current one for a
release while the direct plumbing commands are deprecated in order to
give script authors a transition period to fix their code.
Nicolas
On Mon, Nov 26, 2007 at 18:11:43 +0100, David Kastrup wrote:
quoted
Jakub Narebski [off-list ref] writes:
quoted
If you would write git from scratch now, from the beginning, without
concerns for backwards compatibility, what would you change, or what
would you want to have changed?
Get rid of plumbing at the command line level. It is confusing to
No, please. It's extremely useful. It should be a bit more hidden,
but it's
a big advantage of git that the plumbing is available.
quoted
users, and command line arguments, exec calls and I/O streams are not
efficient and reasonably typed mechanisms for the kind of operations
done in plumbing. Instead using a good extensible portable scripting
language (I consider Lua quite suitable in that regard, but it is
conceivable that something with a native list type supporting easy
sorts, merges and selections could be more efficient) and
implementing
plumbing in that or in C would have been preferable for creating the
porcelain.
POSIX shell is really the best extensible portable scripting language
available for the job. Because the whipuptitude is the most important
property and shell is simply best at one-liners. And since you use it
for regular work (running editor, compiler, git porcelain), it is the
obvious choice for whiping up a short function.
Perl seems pretty portable. If we had a decent, complete libgit, it
would be easy to create bindings for various languages and script Git
in other languages than Shell script.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
From: Jan Hudec <hidden> Date: 2016-06-15 22:43:54
On Mon, Nov 26, 2007 at 21:11:41 +0100, Benoit Sigoure wrote:
On Nov 26, 2007, at 8:27 PM, Jan Hudec wrote:
quoted
On Mon, Nov 26, 2007 at 18:11:43 +0100, David Kastrup wrote:
quoted
Jakub Narebski [off-list ref] writes:
quoted
If you would write git from scratch now, from the beginning, without
concerns for backwards compatibility, what would you change, or what
would you want to have changed?
Get rid of plumbing at the command line level. It is confusing to
No, please. It's extremely useful. It should be a bit more hidden, but
it's
a big advantage of git that the plumbing is available.
quoted
users, and command line arguments, exec calls and I/O streams are not
efficient and reasonably typed mechanisms for the kind of operations
done in plumbing. Instead using a good extensible portable scripting
language (I consider Lua quite suitable in that regard, but it is
conceivable that something with a native list type supporting easy
sorts, merges and selections could be more efficient) and implementing
plumbing in that or in C would have been preferable for creating the
porcelain.
POSIX shell is really the best extensible portable scripting language
available for the job. Because the whipuptitude is the most important
property and shell is simply best at one-liners. And since you use it
for regular work (running editor, compiler, git porcelain), it is the
obvious choice for whiping up a short function.
Perl seems pretty portable. If we had a decent, complete libgit, it would
be easy to create bindings for various languages and script Git in other
languages than Shell script.
Perl might be good for the lower level stuff (and is indeed used for that in
git a lot), but most useful tools on top of git gather few bigish bits
(contents of whole files and such) and pass them to some application. And
this is what shell is really good at.
So yes, more direct interfaces for various languages would certainly be good,
but it would never be a full replacement for the process interface. It is
most generic and for many hacks the easiest thing to use.
--
Jan 'Bulb' Hudec [off-list ref]
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:54
Hi,
On Mon, 26 Nov 2007, Nicolas Pitre wrote:
On Mon, 26 Nov 2007, David Kastrup wrote:
quoted
Get rid of plumbing at the command line level.
We can't get rid of plumbing. It is part of Git probably forever and is
really really convenient for scripting in any language you want.
I agree, but that's not even the complete truth. Git would be not even
half as useful as it is without its scriptability.
So it is not only convenience, but very much a reason that git development
is so fast. That, and that more people than elsewhere let code talk.
Which is also much easier when you have a scriptable system.
Ciao,
Dscho
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:43:54
On Mon, 26 Nov 2007, Johannes Schindelin wrote:
Hi,
On Mon, 26 Nov 2007, Nicolas Pitre wrote:
quoted
On Mon, 26 Nov 2007, David Kastrup wrote:
quoted
Get rid of plumbing at the command line level.
We can't get rid of plumbing. It is part of Git probably forever and is
really really convenient for scripting in any language you want.
I agree, but that's not even the complete truth. Git would be not even
half as useful as it is without its scriptability.
Sure, but this is missing the point.
The issue at hand is about the fact that way too many Git commands are
to be found in the default command path. Diverging on whether or not
plumbing is useful is the wrong question.
Nicolas
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:54
Hi,
On Mon, 26 Nov 2007, Nicolas Pitre wrote:
On Mon, 26 Nov 2007, Johannes Schindelin wrote:
quoted
I agree, but that's not even the complete truth. Git would be not
even half as useful as it is without its scriptability.
Sure, but this is missing the point.
The issue at hand is about the fact that way too many Git commands are
to be found in the default command path. Diverging on whether or not
plumbing is useful is the wrong question.
Ah, thanks. I use a spam filter here, so I did not get the complete
context.
Sorry,
Dscho
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:54
Nicolas Pitre wrote:
On Mon, 26 Nov 2007, David Kastrup wrote:
quoted
Get rid of plumbing at the command line level.
We can't get rid of plumbing. It is part of Git probably forever and is
really really convenient for scripting in any language you want.
The only valid argument IMHO is the way too large number of Git commands
directly available from the cmdline.
The solution: make purely plumbing commands _not_ directly available
from the command line. Instead, they can be available through 'git
lowlevel <blah>' instead of 'git <blah>' and only 'git lowlevel' would
stand in your shell default path.
Such a scheme can be implemented in parallel with the current one for a
release while the direct plumbing commands are deprecated in order to
give script authors a transition period to fix their code.
The "git-cmd" form of writing commands was deemed obsolete round about
the time git.sh was rewritten in C. There's just no reason for it
anymore.
It's unfortunate that git-sh-setup makes it equally valid for scripts to
use either form, as we can never get rid of the dashed form when so many
scripts in the core distribution uses it.
Ah well.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Jakub Narebski <hidden> Date: 2016-06-15 22:43:54
Andreas Ericsson wrote:
The "git-cmd" form of writing commands was deemed obsolete round about
the time git.sh was rewritten in C. There's just no reason for it
anymore.
It's unfortunate that git-sh-setup makes it equally valid for scripts to
use either form, as we can never get rid of the dashed form when so many
scripts in the core distribution uses it.
Ah well.
I think it would be enough to have "git" and perhaps "git-sh-setup"
in PATH, and the rest of git-cmd in EXEC_PATH != PATH.
--
Jakub Narebski
Poland