"Shawn O. Pearce" [off-list ref] writes:
As a porcelain author I'm finding it difficult to keep track of
what features I can use in git-gui. Newer versions of Git have
newer capabilities but they don't always immediately get newer
version numbers that I can easily test for.
This is a simple plumbing option that lets a porcelain ask the
plumbing for its capabilities, at which point the porcelain can
work around anything missing, or recommend to the user that they
upgrade their plumbing layer.
Signed-off-by: Shawn O. Pearce <redacted>
---
Johannes Schindelin [off-list ref] wrote:
>
> On Wed, 30 May 2007, Alex Riesen wrote:
>
> > git-version --features?
>
> Melikes.
Good?
Hmmm. I am not sure if you want list-features in the features
list -- how are you going to test for it?
Also I still do not understand why you want redirect-stderr.
Are you writing for a shell-less environment?
Junio C Hamano [off-list ref] wrote:
"Shawn O. Pearce" [off-list ref] writes:
quoted
As a porcelain author I'm finding it difficult to keep track of
what features I can use in git-gui. Newer versions of Git have
newer capabilities but they don't always immediately get newer
version numbers that I can easily test for.
This is a simple plumbing option that lets a porcelain ask the
plumbing for its capabilities, at which point the porcelain can
work around anything missing, or recommend to the user that they
upgrade their plumbing layer.
Signed-off-by: Shawn O. Pearce <redacted>
---
Johannes Schindelin [off-list ref] wrote:
>
> On Wed, 30 May 2007, Alex Riesen wrote:
>
> > git-version --features?
>
> Melikes.
Good?
Hmmm. I am not sure if you want list-features in the features
list -- how are you going to test for it?
Yes, its a recursive definition. But its also a feature that won't
ever be removed; if list-features is here then the list-features
feature is also here. Makes the test in t0000 a lot easier, and
its not a huge deal to say "yes, the feature that i implement is
here too". ;-)
Also I still do not understand why you want redirect-stderr.
Are you writing for a shell-less environment?
The redirect-stderr thing grew out of the MinGW port camp.
Apparently they cannot use (or its hard to use) an important little
tool called `cat` over there.
Why cat? Tcl is so horribly broken that to get data for both stdout
and stderr through a pipe I have to do something sick like:
git fetch 2>&1 | cat
because in Tcl its actually:
set rdr [open "| git fetch |& cat" r]
The |& means 2>&1| in normal shell. But that means I have to have
a process after it to receive the data. Normally that's cat.
But MinGW doesn't have cat. (Nor do they have dog, but neither
does Linux...). So I need a way to redirect output.
Dscho's patch to git.c to give me `git --redirect-stderr` is quite
simple, and makes my life in git-gui easier. I can just require
that to use git-gui on MinGW you must have the 'redirect-stderr'
feature supported in your plumbing layer. On non-MinGW systems I
can fallback to "&| cat" if its not supported.
--
Shawn.
"Shawn O. Pearce" wrote:
Why cat? Tcl is so horribly broken that to get data for both stdout
and stderr through a pipe I have to do something sick like:
git fetch 2>&1 | cat
because in Tcl its actually:
set rdr [open "| git fetch |& cat" r]
The |& means 2>&1| in normal shell. But that means I have to have
a process after it to receive the data. Normally that's cat.
But MinGW doesn't have cat. (Nor do they have dog, but neither
does Linux...). So I need a way to redirect output.
Are you planning for the future? Currently, the MinGW port works only
with MSYS installed and $MSYS/bin in your PATH because the shell scripts
need an assorted set of POSIX tools. MSYS does ship 'cat', of course.
-- Hannes