* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Brian Gernhardt @ 2007-10-17 18:40 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Morten Welinder, git, spearce
In-Reply-To: <8c5c35580710170839l4b31a4fao5b41efafc5a83883@mail.gmail.com>
I wish I got this much attention the first time I tried to get this
problem fixed. ;-)
On Oct 17, 2007, at 11:39 AM, Lars Hjemli wrote:
> This makes me wonder: what about all the other instances of die() in
> git-cvsserver? Or in any of the other perl scripts, for that matter?
> Should they all be fixed, or is it this particular test that is wrong?
The reason this comes up is because t/test-lib.sh:test_expect_failure
() thinks codes > 128 (or negative values if you want to look at it
that way) are bad tests. I believe this is because many shells use
these codes to indicate things like "command not found" or other
probably unexpected failures.
Other than that, does it matter what die() returns, as long as it's
non-zero?
~~Brian
^ permalink raw reply
* Re: On Tabs and Spaces
From: Tom Tobin @ 2007-10-17 18:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0710170849590.26902@woody.linux-foundation.org>
On Wed, 2007-10-17 at 08:53 -0700, Linus Torvalds wrote:
>
> On Wed, 17 Oct 2007, Luke Lu wrote:
> >
> > Well, we just established that all-space is perfect, look-wise.
>
> But we also established that an all-space model is not stable, because any
> unix developers will start adding tabs instead of spaces.
Damn unix developers! They just can't be controlled!
... seriously now. You're trying on one hand to enforce a particular
indentation rule (use tabs for indentations, assume tabs are 8
characters wide, use spaces for partial indentation) — which assumes
unix developers *can* follow a project's rules for coding style — and
yet you're arguing *against* all-spaces because unix developers *can't*
follow rules.
Or is "unix developers" code for "my sample size of one"?
> > As I mentioned, an all-space policy is trivial to enforce.
>
> Hell no, it's not.
>
> More importantly, I can guarantee that certain developers will refuse to
> be part of such a project with such an idiotic design that eats disk-space
> for no gain, and makes it impossible for me to use my normal editor.
Interesting how you waver between "certain developers" and "me". I'm
convinced at this point that your argument comes down to "I can't use my
favorite text editor with all-spaces, therefore all-spaces sucks".
As for *disk space*? When we can measure cheap drives in sizable
fractions of *terabytes*, this simply isn't a serious argument.
> > But I still haven't seen any compelling arguments against the "all space"
> > case, other than "people will screw it up into mixed spaces", which is really
> > a straw man, as many multi-platform projects enforced the all-space policy
> > easily by using a pre-commit hook in maintainers' repository.
>
> Hey, you start your own projct, and you can enforce whatever idiotic rules
> you want to.
Yeah, can you believe some projects actually *survive* with an
all-spaces indentation rule? And ::gasp:: even *thrive*?
> But in the meantime, all-tab indentations are equally good, and are the
> defacto rule. So *you* are the one who should show compelling arguments
> for changing, and so far you haven't shown any.
>
> Really: what is the problem with hardtabs? Absolutely none.
Problems have been outlined, but since everything for you comes down to
"anything that comes between me and microemacs sucks", rational
discussion breaks down.
Thank goodness the git community (not to mention the Linux community!)
is larger than you; they exist in no small part due to your programming
skill and initial open-sourcing, but certainly in *spite* of your
personality otherwise.
^ permalink raw reply
* [QGIT4 PATCH] Add --no-color option to several calls to git
From: Yaacov Akiba Slama @ 2007-10-17 17:44 UTC (permalink / raw)
To: Git Mailing List; +Cc: Marco Costalba, Yaacov Akiba Slama
Setting "diff.color = true" in the configuration makes
the output of several git commands use color codes.
The color codes aren't parsed by qgit, so adds the --no-color" option
to the calls of these git commmands.
Signed-off-by: Yaacov Akiba Slama <ya@slamail.org>
---
src/git.cpp | 18 +++++++++---------
src/git_startup.cpp | 6 +++---
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/git.cpp b/src/git.cpp
index 6cb9c7d..ef7d736 100644
--- a/src/git.cpp
+++ b/src/git.cpp
@@ -776,18 +776,18 @@ MyProcess* Git::getDiff(SCRef sha, QObject* receiver, SCRef diffToSha, bool comb
QString runCmd;
if (sha != ZERO_SHA) {
- runCmd = "git diff-tree -r --patch-with-stat ";
+ runCmd = "git diff-tree --no-color -r --patch-with-stat ";
runCmd.append(combined ? "-c " : "-C -m "); // TODO rename for combined
runCmd.append(diffToSha + " " + sha); // diffToSha could be empty
} else
- runCmd = "git diff-index -r -m --patch-with-stat HEAD";
+ runCmd = "git diff-index --no-color -r -m --patch-with-stat HEAD";
return runAsync(runCmd, receiver);
}
const QString Git::getWorkDirDiff(SCRef fileName) {
- QString runCmd("git diff-index -r -z -m -p --full-index --no-commit-id HEAD"), runOutput;
+ QString runCmd("git diff-index --no-color -r -z -m -p --full-index --no-commit-id HEAD"), runOutput;
if (!fileName.isEmpty())
runCmd.append(" -- " + quote(fileName));
@@ -998,7 +998,7 @@ bool Git::isSameFiles(SCRef tree1Sha, SCRef tree2Sha) {
if (isParentOf(tree2Sha, tree1Sha))
return !isTreeModified(tree1Sha);
- const QString runCmd("git diff-tree -r " + tree1Sha + " " + tree2Sha);
+ const QString runCmd("git diff-tree --no-color -r " + tree1Sha + " " + tree2Sha);
QString runOutput;
if (!run(runCmd, &runOutput))
return false;
@@ -1209,7 +1209,7 @@ const RevFile* Git::getAllMergeFiles(const Rev* r) {
if (revsFiles.contains(mySha))
return revsFiles[mySha];
- QString runCmd("git diff-tree -r -m -C " + r->sha()), runOutput;
+ QString runCmd("git diff-tree --no-color -r -m -C " + r->sha()), runOutput;
if (!run(runCmd, &runOutput))
return NULL;
@@ -1230,7 +1230,7 @@ const RevFile* Git::getFiles(SCRef sha, SCRef diffToSha, bool allFiles, SCRef pa
if (!diffToSha.isEmpty() && (sha != ZERO_SHA)) {
- QString runCmd("git diff-tree -r -m -C ");
+ QString runCmd("git diff-tree --no-color -r -m -C ");
runCmd.append(diffToSha + " " + sha);
if (!path.isEmpty())
runCmd.append(" " + path);
@@ -1250,7 +1250,7 @@ const RevFile* Git::getFiles(SCRef sha, SCRef diffToSha, bool allFiles, SCRef pa
dbs("ASSERT in Git::getFiles, ZERO_SHA not found");
return NULL;
}
- QString runCmd("git diff-tree -r -c -C " + sha), runOutput;
+ QString runCmd("git diff-tree --no-color -r -c -C " + sha), runOutput;
if (!run(runCmd, &runOutput))
return NULL;
@@ -1337,7 +1337,7 @@ bool Git::getPatchFilter(SCRef exp, bool isRegExp, ShaSet& shaSet) {
if (buf.isEmpty())
return true;
- QString runCmd("git diff-tree -r -s --stdin "), runOutput;
+ QString runCmd("git diff-tree --no-color -r -s --stdin "), runOutput;
if (isRegExp)
runCmd.append("--pickaxe-regex ");
@@ -1386,7 +1386,7 @@ bool Git::formatPatch(SCList shaList, SCRef dirPath, SCRef remoteDir) {
QSettings settings;
const QString FPArgs(settings.value(PATCH_ARGS_KEY).toString());
- QString runCmd("git format-patch");
+ QString runCmd("git format-patch --no-color");
if (testFlag(NUMBERS_F) && !remote)
runCmd.append(" -n");
diff --git a/src/git_startup.cpp b/src/git_startup.cpp
index 95a9474..a281173 100644
--- a/src/git_startup.cpp
+++ b/src/git_startup.cpp
@@ -480,7 +480,7 @@ bool Git::startParseProc(SCList initCmd, FileHistory* fh, SCRef buf) {
bool Git::startRevList(SCList args, FileHistory* fh) {
- const QString baseCmd("git log --log-size --parents --boundary --pretty=raw -z");
+ const QString baseCmd("git log --no-color --log-size --parents --boundary --pretty=raw -z");
QStringList initCmd(baseCmd.split(' '));
if (!isMainHistory(fh))
/*
@@ -505,7 +505,7 @@ bool Git::startUnappliedList() {
// WARNING: with this command 'git log' could send spurious
// revs so we need some filter out logic during loading
- QStringList cmd(QString("git log --parents --pretty=raw -z ^HEAD").split(' '));
+ QStringList cmd(QString("git log --no-color --parents --pretty=raw -z ^HEAD").split(' '));
cmd << unAppliedShaList;
return startParseProc(cmd, revData, QString());
}
@@ -835,7 +835,7 @@ void Git::loadFileNames() {
}
if (!diffTreeBuf.isEmpty()) {
filesLoadingPending = filesLoadingCurSha = "";
- const QString runCmd("git diff-tree -r -C --stdin");
+ const QString runCmd("git diff-tree --no-color -r -C --stdin");
runAsync(runCmd, this, diffTreeBuf);
}
indexTree();
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH 0/7] Bisect dunno
From: Johannes Schindelin @ 2007-10-17 18:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Christian Couder, Junio Hamano, git
In-Reply-To: <20071017073538.GB13801@spearce.org>
Hi,
On Wed, 17 Oct 2007, Shawn O. Pearce wrote:
> Christian Couder <chriscool@tuxfamily.org> wrote:
> > Here is my bisect dunno patch series again.
> > The changes since last time are the following:
>
> I now have this series queued in my pu branch. It passes the tests
> it comes with, and doesn't appear to break anything, but apparently
> there is also still some debate about what a dunno should be called
> ("unknown", "void", "ugly", "dunno", "skip" ...).
AFAICT these are all bikeshed painting arguments, not technical arguments.
I was initially opposed to having --bisect-all, wanting to have
--bisect-dunno <ref>...
But in the end, the people doing the work decide, and therefore I am fine
with --bisect-all, especially since it seems clean enough for me.
As for all those "dunno is no English"... I'd first merge the technical
part (i.e. what you have now in pu), and then let the discussion about
which synonyms to choose continue, until a consensus is formed about other
names (if there is a consensus at all!).
IMHO there is no reason to hold of the fine work of Christian, just
because there are non-technical arguments still in the air.
I want bisect dunno. Even if there is another name later.
Ciao,
Dscho
^ permalink raw reply
* Re: On Tabs and Spaces
From: Johannes Schindelin @ 2007-10-17 18:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Luke Lu, Christer Weinigel, Tom Tobin, git
In-Reply-To: <alpine.LFD.0.999.0710170849590.26902@woody.linux-foundation.org>
Hi,
On Wed, 17 Oct 2007, Linus Torvalds wrote:
> On Wed, 17 Oct 2007, Luke Lu wrote:
>
> > As I mentioned, an all-space policy is trivial to enforce.
>
> Hell no, it's not.
>
> More importantly, I can guarantee that certain developers will refuse to
> be part of such a project with such an idiotic design that eats
> disk-space for no gain, and makes it impossible for me to use my normal
> editor.
Yes. Me, for one.
But heck, _everyone_ is free to fork. That is one of the missions of git:
"fork!". You can maintain you tab-less fork, until people flock to you,
deciding to use your repo instead of Junio's, or Shawn's. If enough
people decide, you will have more followers than the others.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 07/25] parse-options: make some arguments optional, add callbacks.
From: Johannes Schindelin @ 2007-10-17 18:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Pierre Habouzit, René Scharfe, git, Nicolas Pitre
In-Reply-To: <20071017044405.GV13801@spearce.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1102 bytes --]
Hi,
On Wed, 17 Oct 2007, Shawn O. Pearce wrote:
> Pierre Habouzit <madcoder@debian.org> wrote:
> > On Tue, Oct 16, 2007 at 04:38:36PM +0000, René Scharfe wrote:
> > > Pierre Habouzit schrieb:
> > > > This bit is to allow to aggregate options with arguments together when
> > > > the argument is numeric.
> > > >
> > > > +#if 0
> > > > + /* can be used to understand -A1B1 like -A1 -B1 */
> > > > + if (flag & OPT_SHORT && opt->opt && isdigit(*opt->opt)) {
> > > > + *(int *)opt->value = strtol(opt->opt, (char **)&opt->opt, 10);
> > > > + return 0;
> > > > + }
> > > > +#endif
> > >
> > > I don't like it, it complicates number options with unit suffixes (e.g.
> > > --windows-memory of git-pack-objects).
> ...
> > This is a very strong argument _against_ this chunk IMO.
>
> Since everyone (including myself)
... except for me ...
> is apparently strongly against this hunk I removed it when I
> cherry-picked this series from Pierre into my tree. The series will be
> in my pu tonight, but minus this hunk.
I can live without this hunk.
Ciao,
Dscho
^ permalink raw reply
* [QGIT4 PATCH] Add --no-color option to several calls to git
From: Yaacov Akiba Slama @ 2007-10-17 17:54 UTC (permalink / raw)
To: git; +Cc: Marco Costalba, Yaacov Akiba Slama
Setting "diff.color = true" in the configuration makes
the output of several git commands use color codes.
The color codes aren't parsed by qgit, so adds the --no-color" option
to the calls of these git commmands.
Signed-off-by: Yaacov Akiba Slama <ya@slamail.org>
---
src/git.cpp | 18 +++++++++---------
src/git_startup.cpp | 6 +++---
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/git.cpp b/src/git.cpp
index 6cb9c7d..ef7d736 100644
--- a/src/git.cpp
+++ b/src/git.cpp
@@ -776,18 +776,18 @@ MyProcess* Git::getDiff(SCRef sha, QObject* receiver, SCRef diffToSha, bool comb
QString runCmd;
if (sha != ZERO_SHA) {
- runCmd = "git diff-tree -r --patch-with-stat ";
+ runCmd = "git diff-tree --no-color -r --patch-with-stat ";
runCmd.append(combined ? "-c " : "-C -m "); // TODO rename for combined
runCmd.append(diffToSha + " " + sha); // diffToSha could be empty
} else
- runCmd = "git diff-index -r -m --patch-with-stat HEAD";
+ runCmd = "git diff-index --no-color -r -m --patch-with-stat HEAD";
return runAsync(runCmd, receiver);
}
const QString Git::getWorkDirDiff(SCRef fileName) {
- QString runCmd("git diff-index -r -z -m -p --full-index --no-commit-id HEAD"), runOutput;
+ QString runCmd("git diff-index --no-color -r -z -m -p --full-index --no-commit-id HEAD"), runOutput;
if (!fileName.isEmpty())
runCmd.append(" -- " + quote(fileName));
@@ -998,7 +998,7 @@ bool Git::isSameFiles(SCRef tree1Sha, SCRef tree2Sha) {
if (isParentOf(tree2Sha, tree1Sha))
return !isTreeModified(tree1Sha);
- const QString runCmd("git diff-tree -r " + tree1Sha + " " + tree2Sha);
+ const QString runCmd("git diff-tree --no-color -r " + tree1Sha + " " + tree2Sha);
QString runOutput;
if (!run(runCmd, &runOutput))
return false;
@@ -1209,7 +1209,7 @@ const RevFile* Git::getAllMergeFiles(const Rev* r) {
if (revsFiles.contains(mySha))
return revsFiles[mySha];
- QString runCmd("git diff-tree -r -m -C " + r->sha()), runOutput;
+ QString runCmd("git diff-tree --no-color -r -m -C " + r->sha()), runOutput;
if (!run(runCmd, &runOutput))
return NULL;
@@ -1230,7 +1230,7 @@ const RevFile* Git::getFiles(SCRef sha, SCRef diffToSha, bool allFiles, SCRef pa
if (!diffToSha.isEmpty() && (sha != ZERO_SHA)) {
- QString runCmd("git diff-tree -r -m -C ");
+ QString runCmd("git diff-tree --no-color -r -m -C ");
runCmd.append(diffToSha + " " + sha);
if (!path.isEmpty())
runCmd.append(" " + path);
@@ -1250,7 +1250,7 @@ const RevFile* Git::getFiles(SCRef sha, SCRef diffToSha, bool allFiles, SCRef pa
dbs("ASSERT in Git::getFiles, ZERO_SHA not found");
return NULL;
}
- QString runCmd("git diff-tree -r -c -C " + sha), runOutput;
+ QString runCmd("git diff-tree --no-color -r -c -C " + sha), runOutput;
if (!run(runCmd, &runOutput))
return NULL;
@@ -1337,7 +1337,7 @@ bool Git::getPatchFilter(SCRef exp, bool isRegExp, ShaSet& shaSet) {
if (buf.isEmpty())
return true;
- QString runCmd("git diff-tree -r -s --stdin "), runOutput;
+ QString runCmd("git diff-tree --no-color -r -s --stdin "), runOutput;
if (isRegExp)
runCmd.append("--pickaxe-regex ");
@@ -1386,7 +1386,7 @@ bool Git::formatPatch(SCList shaList, SCRef dirPath, SCRef remoteDir) {
QSettings settings;
const QString FPArgs(settings.value(PATCH_ARGS_KEY).toString());
- QString runCmd("git format-patch");
+ QString runCmd("git format-patch --no-color");
if (testFlag(NUMBERS_F) && !remote)
runCmd.append(" -n");
diff --git a/src/git_startup.cpp b/src/git_startup.cpp
index 95a9474..a281173 100644
--- a/src/git_startup.cpp
+++ b/src/git_startup.cpp
@@ -480,7 +480,7 @@ bool Git::startParseProc(SCList initCmd, FileHistory* fh, SCRef buf) {
bool Git::startRevList(SCList args, FileHistory* fh) {
- const QString baseCmd("git log --log-size --parents --boundary --pretty=raw -z");
+ const QString baseCmd("git log --no-color --log-size --parents --boundary --pretty=raw -z");
QStringList initCmd(baseCmd.split(' '));
if (!isMainHistory(fh))
/*
@@ -505,7 +505,7 @@ bool Git::startUnappliedList() {
// WARNING: with this command 'git log' could send spurious
// revs so we need some filter out logic during loading
- QStringList cmd(QString("git log --parents --pretty=raw -z ^HEAD").split(' '));
+ QStringList cmd(QString("git log --no-color --parents --pretty=raw -z ^HEAD").split(' '));
cmd << unAppliedShaList;
return startParseProc(cmd, revData, QString());
}
@@ -835,7 +835,7 @@ void Git::loadFileNames() {
}
if (!diffTreeBuf.isEmpty()) {
filesLoadingPending = filesLoadingCurSha = "";
- const QString runCmd("git diff-tree -r -C --stdin");
+ const QString runCmd("git diff-tree --no-color -r -C --stdin");
runAsync(runCmd, this, diffTreeBuf);
}
indexTree();
--
1.5.3.4
^ permalink raw reply related
* Re: On Tabs and Spaces
From: Sean @ 2007-10-17 17:51 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86sl49g1w1.fsf@lola.quinscape.zz>
On Wed, October 17, 2007 12:08 pm, David Kastrup said:
>
> All-space indentation renders the binary delta algorithm git uses for
> compression of packs slow and partly inoperative (all sequences of 16
> spaces share the same finger print, and the number of identical finger
> prints for which the file information is kept is reduced to 64).
You seem to have identified a weakness in Git's design rather than
an argument against using all-space indentation. Personally I find it
counter-productive and annoying to work in space-indented source code.
But let's be honest, this "issue" is mostly about familiarity and
comfort rather than some deep objective truth.
Sean
^ permalink raw reply
* Re: On Tabs and Spaces
From: Nicolas Pitre @ 2007-10-17 17:44 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86sl49g1w1.fsf@lola.quinscape.zz>
On Wed, 17 Oct 2007, David Kastrup wrote:
> Luke Lu <git@vicaya.com> writes:
>
> > But I still haven't seen any compelling arguments against the "all
> > space" case, other than "people will screw it up into mixed spaces",
> > which is really a straw man, as many multi-platform projects
> > enforced the all-space policy easily by using a pre-commit hook in
> > maintainers' repository.
>
> All-space indentation renders the binary delta algorithm git uses for
> compression of packs slow and partly inoperative (all sequences of 16
> spaces share the same finger print, and the number of identical finger
> prints for which the file information is kept is reduced to 64).
But sequences of 16 spaces are unlikely to land on 16-byte boundaries
all the time in the file so adjacent data to those 16-space blocks will
still provide good hashing.
> > The only downside of all-space is a moderate space bloat in source,
> > which is insignificant, all things considered.
>
> It will also slow down git's packing and make it produce worse
> results.
If that was effectively the case then it is Git that had to be fixed and
not the way people write code. Git should cope with the data it is fed
and not the other way around.
And this is completely orthogonal to the policy of using hard tabs or
spaces in source code, so I'm clearly _not_ providing any argument to
that discussion one way or the other here.
Nicolas
^ permalink raw reply
* Re: [PATCH 2/2] Quoting paths in tests
From: David Kastrup @ 2007-10-17 17:15 UTC (permalink / raw)
To: git
In-Reply-To: <6E65762D-FBC4-4A7C-97A9-20F6744E25DE@steelskies.com>
Jonathan del Strother <maillist@steelskies.com> writes:
> On 17 Oct 2007, at 12:32, Johannes Sixt wrote:
>
>> Jonathan del Strother schrieb:
>>> --- a/t/lib-git-svn.sh
>>> +++ b/t/lib-git-svn.sh
>>> @@ -25,7 +25,7 @@ perl -w -e "
>>> use SVN::Core;
>>> use SVN::Repos;
>>> \$SVN::Core::VERSION gt '1.1.0' or exit(42);
>>> -system(qw/svnadmin create --fs-type fsfs/, '$svnrepo') == 0 or
>>> exit(41);
>>> +system(qw/svnadmin create --fs-type fsfs/, \"$svnrepo\") == 0 or
>>> exit(41);
>>
>> Here you have to work harder: The reason is that this is part of a
>> perl expression (as opposed to an eval'd string), which does not
>> have access to $svnrepo of the shell by which it is invoked. The
>> original version failed if there were single-quotes in $svnrepo, the
>> new version fails if it contains double-quotes.
> ...
>>
>> May I recommend that you run the test suite in a directory named
>> like this:
>>
>> $ mkdir \"\ \$GIT_DIR\ \'
>> $ ls
>> " $GIT_DIR '
>
>
> Eww. I'm struggling a bit with paths this perverse, actually.
>
> For instance, git_editor in git-sh-setup expects the editor path to be
> pre-quoted. So in t3404, you need to produce escaped double quotes &
> dollar signs, resulting in unpleasantness like this :
>
> VISUAL="`pwd`/fake-editor.sh"
> VISUAL=${VISUAL//\"/\\\"}
> VISUAL=${VISUAL//$/\\\$}
> VISUAL=\"$VISUAL\"
> export VISUAL
EDITORPWD="`pwd`"
VISUAL='$EDITORPWD/fake-editor.sh'
export EDITORPWD VISUAL
--
David Kastrup
^ permalink raw reply
* [PATCH 0/2 v3] mergetool
From: Steffen Prohaska @ 2007-10-17 17:16 UTC (permalink / raw)
To: git
So here they are again.
Steffen
^ permalink raw reply
* Re: [PATCH 0/2 v3] mergetool
From: Steffen Prohaska @ 2007-10-17 17:20 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <11926413722362-git-send-email-prohaska@zib.de>
On Oct 17, 2007, at 7:16 PM, Steffen Prohaska wrote:
> So here they are again.
[ half of the message is missing. First time I used compose ;) ]
I haven't found these two patches in Shawn's nor Lars' repo.
I believe they would be pretty useful on Windows. They apply
to spearce/master.
Steffen
^ permalink raw reply
* [PATCH 1/2 v3] mergetool: use path to mergetool in config var mergetool.<tool>.path
From: Steffen Prohaska @ 2007-10-17 17:16 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
In-Reply-To: <11926413722362-git-send-email-prohaska@zib.de>
This commit adds a mechanism to provide absolute paths to the
external programs called by 'git mergetool'. A path can be
specified in the configuation variable mergetool.<tool>.path.
The configuration variable is similar to how we name branches
and remotes. It is extensible if we need to specify more details
about a tool.
The mechanism is especially useful on Windows, where external
programs are unlikely to be in PATH.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/git-mergetool.txt | 6 ++
git-mergetool.sh | 97 +++++++++++++++++++++-----------------
2 files changed, 60 insertions(+), 43 deletions(-)
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 6c32c6d..78b2f43 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -31,6 +31,12 @@ If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable merge.tool. If the
configuration variable merge.tool is not set, 'git mergetool'
will pick a suitable default.
++
+You can explicitly provide a full path to the tool by setting the
+configuration variable mergetool.<tool>.path. For example, you
+can configure the absolute path to kdiff3 by setting
+mergetool.kdiff3.path. Otherwise, 'git mergetool' assumes the tool
+is available in PATH.
Author
------
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 9f4f313..1e4583f 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -192,10 +192,10 @@ merge_file () {
case "$merge_tool" in
kdiff3)
if base_present ; then
- (kdiff3 --auto --L1 "$path (Base)" --L2 "$path (Local)" --L3 "$path (Remote)" \
+ ("$merge_tool_path" --auto --L1 "$path (Base)" --L2 "$path (Local)" --L3 "$path (Remote)" \
-o "$path" -- "$BASE" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
else
- (kdiff3 --auto --L1 "$path (Local)" --L2 "$path (Remote)" \
+ ("$merge_tool_path" --auto --L1 "$path (Local)" --L2 "$path (Remote)" \
-o "$path" -- "$LOCAL" "$REMOTE" > /dev/null 2>&1)
fi
status=$?
@@ -203,35 +203,35 @@ merge_file () {
;;
tkdiff)
if base_present ; then
- tkdiff -a "$BASE" -o "$path" -- "$LOCAL" "$REMOTE"
+ "$merge_tool_path" -a "$BASE" -o "$path" -- "$LOCAL" "$REMOTE"
else
- tkdiff -o "$path" -- "$LOCAL" "$REMOTE"
+ "$merge_tool_path" -o "$path" -- "$LOCAL" "$REMOTE"
fi
status=$?
save_backup
;;
meld|vimdiff)
touch "$BACKUP"
- $merge_tool -- "$LOCAL" "$path" "$REMOTE"
+ "$merge_tool_path" -- "$LOCAL" "$path" "$REMOTE"
check_unchanged
save_backup
;;
gvimdiff)
touch "$BACKUP"
- gvimdiff -f -- "$LOCAL" "$path" "$REMOTE"
+ "$merge_tool_path" -f -- "$LOCAL" "$path" "$REMOTE"
check_unchanged
save_backup
;;
xxdiff)
touch "$BACKUP"
if base_present ; then
- xxdiff -X --show-merged-pane \
+ "$merge_tool_path" -X --show-merged-pane \
-R 'Accel.SaveAsMerged: "Ctrl-S"' \
-R 'Accel.Search: "Ctrl+F"' \
-R 'Accel.SearchForward: "Ctrl-G"' \
--merged-file "$path" -- "$LOCAL" "$BASE" "$REMOTE"
else
- xxdiff -X --show-merged-pane \
+ "$merge_tool_path" -X --show-merged-pane \
-R 'Accel.SaveAsMerged: "Ctrl-S"' \
-R 'Accel.Search: "Ctrl+F"' \
-R 'Accel.SearchForward: "Ctrl-G"' \
@@ -243,18 +243,18 @@ merge_file () {
opendiff)
touch "$BACKUP"
if base_present; then
- opendiff "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$path" | cat
+ "$merge_tool_path" "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$path" | cat
else
- opendiff "$LOCAL" "$REMOTE" -merge "$path" | cat
+ "$merge_tool_path" "$LOCAL" "$REMOTE" -merge "$path" | cat
fi
check_unchanged
save_backup
;;
emerge)
if base_present ; then
- emacs -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$path")"
+ "$merge_tool_path" -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$path")"
else
- emacs -f emerge-files-command "$LOCAL" "$REMOTE" "$(basename "$path")"
+ "$merge_tool_path" -f emerge-files-command "$LOCAL" "$REMOTE" "$(basename "$path")"
fi
status=$?
save_backup
@@ -297,17 +297,38 @@ do
shift
done
+valid_tool() {
+ case "$1" in
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff)
+ ;; # happy
+ *)
+ return 1
+ ;;
+ esac
+}
+
+init_merge_tool_path() {
+ merge_tool_path=`git config mergetool.$1.path`
+ if test -z "$merge_tool_path" ; then
+ case "$merge_tool" in
+ emerge)
+ merge_tool_path=emacs
+ ;;
+ *)
+ merge_tool_path=$merge_tool
+ ;;
+ esac
+ fi
+}
+
+
if test -z "$merge_tool"; then
merge_tool=`git config merge.tool`
- case "$merge_tool" in
- kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | "")
- ;; # happy
- *)
+ test -n "$merge_tool" || valid_tool "$merge_tool" || {
echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
echo >&2 "Resetting to default..."
unset merge_tool
- ;;
- esac
+ }
fi
if test -z "$merge_tool" ; then
@@ -329,40 +350,30 @@ if test -z "$merge_tool" ; then
merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
echo "merge tool candidates: $merge_tool_candidates"
for i in $merge_tool_candidates; do
- if test $i = emerge ; then
- cmd=emacs
- else
- cmd=$i
- fi
- if type $cmd > /dev/null 2>&1; then
+ init_merge_tool_path $i
+ if type "$merge_tool_path" > /dev/null 2>&1; then
merge_tool=$i
break
fi
done
if test -z "$merge_tool" ; then
- echo "No available merge resolution programs available."
+ echo "No known merge resolution program available."
exit 1
fi
+else
+ valid_tool "$merge_tool" || {
+ echo >&2 "Unknown merge_tool $merge_tool"
+ exit 1
+ }
+
+ init_merge_tool_path "$merge_tool"
+
+ if ! type "$merge_tool_path" > /dev/null 2>&1; then
+ echo "The merge tool $merge_tool is not available as '$merge_tool_path'"
+ exit 1
+ fi
fi
-case "$merge_tool" in
- kdiff3|tkdiff|meld|xxdiff|vimdiff|gvimdiff|opendiff)
- if ! type "$merge_tool" > /dev/null 2>&1; then
- echo "The merge tool $merge_tool is not available"
- exit 1
- fi
- ;;
- emerge)
- if ! type "emacs" > /dev/null 2>&1; then
- echo "Emacs is not available"
- exit 1
- fi
- ;;
- *)
- echo "Unknown merge tool: $merge_tool"
- exit 1
- ;;
-esac
if test $# -eq 0 ; then
files=`git ls-files -u | sed -e 's/^[^ ]* //' | sort -u`
--
1.5.3.4.222.g2830
^ permalink raw reply related
* [PATCH 2/2 v3] mergetool: add support for ECMerge
From: Steffen Prohaska @ 2007-10-17 17:16 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
In-Reply-To: <11926413723666-git-send-email-prohaska@zib.de>
Add support to mergetool for ECMerge available from
http://www.elliecomputing.com/Products/merge_overview.asp
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/git-mergetool.txt | 2 +-
git-mergetool.sh | 12 +++++++++++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 78b2f43..a26c260 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -25,7 +25,7 @@ OPTIONS
-t or --tool=<tool>::
Use the merge resolution program specified by <tool>.
Valid merge tools are:
- kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, and opendiff
+ kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
+
If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable merge.tool. If the
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 1e4583f..fdf4912 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -250,6 +250,16 @@ merge_file () {
check_unchanged
save_backup
;;
+ ecmerge)
+ touch "$BACKUP"
+ if base_present; then
+ "$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" --mode=merge3 --to="$path"
+ else
+ "$merge_tool_path" "$LOCAL" "$REMOTE" --mode=merge2 --to="$path"
+ fi
+ check_unchanged
+ save_backup
+ ;;
emerge)
if base_present ; then
"$merge_tool_path" -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$path")"
@@ -299,7 +309,7 @@ done
valid_tool() {
case "$1" in
- kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff)
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
;; # happy
*)
return 1
--
1.5.3.4.222.g2830
^ permalink raw reply related
* Re: [PATCH 2/2] Quoting paths in tests
From: Jonathan del Strother @ 2007-10-17 17:07 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4715F2E6.1000708@viscovery.net>
On 17 Oct 2007, at 12:32, Johannes Sixt wrote:
> Jonathan del Strother schrieb:
>> --- a/t/lib-git-svn.sh
>> +++ b/t/lib-git-svn.sh
>> @@ -25,7 +25,7 @@ perl -w -e "
>> use SVN::Core;
>> use SVN::Repos;
>> \$SVN::Core::VERSION gt '1.1.0' or exit(42);
>> -system(qw/svnadmin create --fs-type fsfs/, '$svnrepo') == 0 or
>> exit(41);
>> +system(qw/svnadmin create --fs-type fsfs/, \"$svnrepo\") == 0 or
>> exit(41);
>
> Here you have to work harder: The reason is that this is part of a
> perl expression (as opposed to an eval'd string), which does not
> have access to $svnrepo of the shell by which it is invoked. The
> original version failed if there were single-quotes in $svnrepo, the
> new version fails if it contains double-quotes.
...
>
> May I recommend that you run the test suite in a directory named
> like this:
>
> $ mkdir \"\ \$GIT_DIR\ \'
> $ ls
> " $GIT_DIR '
Eww. I'm struggling a bit with paths this perverse, actually.
For instance, git_editor in git-sh-setup expects the editor path to be
pre-quoted. So in t3404, you need to produce escaped double quotes &
dollar signs, resulting in unpleasantness like this :
VISUAL="`pwd`/fake-editor.sh"
VISUAL=${VISUAL//\"/\\\"}
VISUAL=${VISUAL//$/\\\$}
VISUAL=\"$VISUAL\"
export VISUAL
And I'm struggling to come up with neat ways of rewriting things like,
eg, this bit from t5500 -
test_expect_success "clone shallow" "git-clone --depth 2 \"file://
`pwd`/.\" shallow"
- to handle paths like that properly.
Suggestions?
Jon
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: David Kastrup @ 2007-10-17 16:13 UTC (permalink / raw)
To: git
In-Reply-To: <200710171810.56215.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> tisdag 16 oktober 2007 skrev David Kastrup:
>> "David Symonds" <dsymonds@gmail.com> writes:
>>
>> > On 16/10/2007, David Kastrup <dak@gnu.org> wrote:
>> >> Geert Bosch <bosch@adacore.com> writes:
>> >>
>> >> > On Oct 15, 2007, at 13:53, David Symonds wrote:
>> >> >> That's also why I suggested "skip"; you might not be able to test a
>> >> >> particular commit, but you might also not *want* to test a particular
>> >> >> commit for some reason.
>> >> >
>> >> > Skip seems a great choice: it directly expresses the wish to
>> >> > not consider a certain commit. The reason is unimportant.
>> >>
>> >> But it is an _action_, while "good" and "bad" are properties.
>> >
>> > "skipped", then.
>>
>> "good" and "bad" are descriptive. "to be skipped" would be necessary
>> to fit it.
>
> Yet another very short word: void.
It is not "yet another": I already explained why it does not fit.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Karl Hasselström @ 2007-10-17 16:17 UTC (permalink / raw)
To: Robin Rosenberg
Cc: David Kastrup, David Symonds, Geert Bosch, Wincent Colaiuta,
Johan Herland, git, Marius Storm-Olsen, Christian Couder,
René Scharfe, Junio Hamano, Johannes Schindelin
In-Reply-To: <200710171810.56215.robin.rosenberg.lists@dewire.com>
On 2007-10-17 18:10:55 +0200, Robin Rosenberg wrote:
> Yet another very short word: void.
My vote is for "supercalifragilisticexpialidocious". It's clearly
superior to the 1500 other suggestions in this thread.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: On Tabs and Spaces
From: David Kastrup @ 2007-10-17 16:08 UTC (permalink / raw)
To: git
In-Reply-To: <3A9408D5-2667-43A6-A0CE-C0720B3A3987@vicaya.com>
Luke Lu <git@vicaya.com> writes:
> But I still haven't seen any compelling arguments against the "all
> space" case, other than "people will screw it up into mixed spaces",
> which is really a straw man, as many multi-platform projects
> enforced the all-space policy easily by using a pre-commit hook in
> maintainers' repository.
All-space indentation renders the binary delta algorithm git uses for
compression of packs slow and partly inoperative (all sequences of 16
spaces share the same finger print, and the number of identical finger
prints for which the file information is kept is reduced to 64).
> The only downside of all-space is a moderate space bloat in source,
> which is insignificant, all things considered.
It will also slow down git's packing and make it produce worse
results.
> I agree that "8-character tabs are the gold standard", only for the
> tabstop==8 part but not the indent==tab part. For me the question
> is: is it really so unreasonable to just say "all-space is the holy
> grail"?
Yes.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Robin Rosenberg @ 2007-10-17 16:10 UTC (permalink / raw)
To: David Kastrup
Cc: David Symonds, Geert Bosch, Wincent Colaiuta, Johan Herland, git,
Marius Storm-Olsen, Christian Couder, René Scharfe,
Junio Hamano, Johannes Schindelin
In-Reply-To: <856417h9cj.fsf@lola.goethe.zz>
tisdag 16 oktober 2007 skrev David Kastrup:
> "David Symonds" <dsymonds@gmail.com> writes:
>
> > On 16/10/2007, David Kastrup <dak@gnu.org> wrote:
> >> Geert Bosch <bosch@adacore.com> writes:
> >>
> >> > On Oct 15, 2007, at 13:53, David Symonds wrote:
> >> >> That's also why I suggested "skip"; you might not be able to test a
> >> >> particular commit, but you might also not *want* to test a particular
> >> >> commit for some reason.
> >> >
> >> > Skip seems a great choice: it directly expresses the wish to
> >> > not consider a certain commit. The reason is unimportant.
> >>
> >> But it is an _action_, while "good" and "bad" are properties.
> >
> > "skipped", then.
>
> "good" and "bad" are descriptive. "to be skipped" would be necessary
> to fit it.
Yet another very short word: void.
I'm thinking about ticket copies that sometimes are marked "void" so you cannot use it.
-- robin
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git - Had a few questions on Qgit; I like the GUI.
From: Robin Rosenberg @ 2007-10-17 16:00 UTC (permalink / raw)
To: Marco Costalba
Cc: pete, piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <e5bfff550710170030y7778e96ax146acea7a0e57a67@mail.gmail.com>
onsdag 17 oktober 2007 skrev Marco Costalba:
> On 10/17/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
> >
> > While I'm looking at the diffs for a file if I pull down External Diff
> > it launches 'kcompare' but for a file with a large change it seems
> > to be running extremely slow.
>
> qgit does not intergarte Kompare functionality, it just prepares the
> files and spawns a Kompare process.
>
> So there's seem nothing qgit can do about Kompare speed. You can try
> with different diff viewers, meld,...etc..
You could avoid the temporary files if you just pipe the diff to kompare. That
would require an option to tell qgit that the external viewer can read a git diff.
At the time qgit 1.5 was written, kompare could not handle git diffs.
-- robin
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-17 15:53 UTC (permalink / raw)
To: Luke Lu; +Cc: Christer Weinigel, Tom Tobin, git
In-Reply-To: <3A9408D5-2667-43A6-A0CE-C0720B3A3987@vicaya.com>
On Wed, 17 Oct 2007, Luke Lu wrote:
>
> Well, we just established that all-space is perfect, look-wise.
But we also established that an all-space model is not stable, because any
unix developers will start adding tabs instead of spaces.
> As I mentioned, an all-space policy is trivial to enforce.
Hell no, it's not.
More importantly, I can guarantee that certain developers will refuse to
be part of such a project with such an idiotic design that eats disk-space
for no gain, and makes it impossible for me to use my normal editor.
> But I still haven't seen any compelling arguments against the "all space"
> case, other than "people will screw it up into mixed spaces", which is really
> a straw man, as many multi-platform projects enforced the all-space policy
> easily by using a pre-commit hook in maintainers' repository.
Hey, you start your own projct, and you can enforce whatever idiotic rules
you want to.
But in the meantime, all-tab indentations are equally good, and are the
defacto rule. So *you* are the one who should show compelling arguments
for changing, and so far you haven't shown any.
Really: what is the problem with hardtabs? Absolutely none.
Linus
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Andreas Ericsson @ 2007-10-17 15:50 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550710162357r2c3744b1me5138edf24a56090@mail.gmail.com>
Marco Costalba wrote:
> On 10/16/07, Andreas Ericsson <ae@op5.se> wrote:
>> Marco Costalba wrote:
>>> On 10/16/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>>>
>>>> Would it be worthwhile
>>>> to install Qt4 from src and try to use qgit-2.0?
>>>>
>>> Yes it is. There are a lot of new featrures, is almost as stable as
>>> the previous and if you are interested in file history (annotations)
>>> in qgit-2.0 this feature has been greatly speeded up.
>>>
>> The only thing I really, really, really don't like about qgit4 is the
>> fact that it fudges up the commit-message. I've been trying for two
>> days to get rid of the HTML output, but I just can't get it done
>> without the signed-off-by email being enclosed in <> tags.
>>
>
> You mean when you commit some changes or when you brows the revisions?
>
When I browse the revisions.
> If it is the highlighted title that annoy you I can try to remove the
> background color, or set as plain text as an option.
>
That does annoy me indeed, but the primary annoyance is the fact that
the subject is no longer listed with the rest of the commit message, but
rather above the ancestry links.
>> view without the colored box a lot more). The little arrows in the
>> commit window are also fairly annoying, as one quite quickly understands
>> that up-/down-arrows work much better for that sort of stuff anyway.
>>
>
> Little arrows should already be removable from settings->browse->'Show
> smart labels' , you can also add lateral tabs with
> settings->browse->'Show tabbed revisions' if you like.
>
Sweet. I'll have to look into it. Thanks for your gentle instruction, and
a great product :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Lars Hjemli @ 2007-10-17 15:39 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Morten Welinder, git, spearce
In-Reply-To: <DC3D43FD-F03D-4E0A-9C2B-DE56F9C16D60@silverinsanity.com>
On 10/17/07, Brian Gernhardt <benji@silverinsanity.com> wrote:
> The problem is that die can exit with varying exit codes, and exit
> codes >= 128 make the test suite assume something has gone wrong with
> the test.
This makes me wonder: what about all the other instances of die() in
git-cvsserver? Or in any of the other perl scripts, for that matter?
Should they all be fixed, or is it this particular test that is wrong?
--
larsh
^ permalink raw reply
* Re: git-gc --prune interferes cogito?
From: Petr Baudis @ 2007-10-17 15:38 UTC (permalink / raw)
To: MichaelTiloDressel@t-online.de; +Cc: git
In-Reply-To: <1IiA7L-1AWmmW0@fwd35.aul.t-online.de>
Hi,
On Wed, Oct 17, 2007 at 04:43:27PM +0200, MichaelTiloDressel@t-online.de wrote:
> I'm using git-1.5.3.2 and cogito-0.18.1.
>
> After I did a git-gc --prune cg-status didn't show my branches anymore.
> git-branch -a still showed the branches.
> I think that git-gc removed all files from .git/refs/heads/ except for
> origin. Git seams to be fine with the branches in
> .git/logs/refs/heads/.
>
> So should git-gc not be used together with cogito?
Cogito doesn't support packed heads - I guess setting gc.packrefs to
false should fix the issue. Cogito should support packed tags, I guess;
I don't know if there's a way to make git-gc pack only tags.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Brian Gernhardt @ 2007-10-17 15:16 UTC (permalink / raw)
To: Morten Welinder; +Cc: git, spearce
In-Reply-To: <118833cc0710170739i179e7389k1e44f70086ca88be@mail.gmail.com>
On Oct 17, 2007, at 10:39 AM, Morten Welinder wrote:
>> made it into your repo. It fixes test failures on my machine
>> that have
>> been plauging me for months.
>
> That sounds more like a reason to fix the test. "die" is the perl
> standard way of reporting an error. It will print the error message
> on stderr, not on stdout like your version does.
>
> IMHO, of course.
The problem is that die can exit with varying exit codes, and exit
codes >= 128 make the test suite assume something has gone wrong with
the test. In particular, because $! (errcode) and $? (previous shell
command return) are both 0, it returns 255. Or at least that's how
it works out on my system. I'm not sure why it doesn't do that on
others.
But the test is expecting a failure here and it appears to be failing
in the correct way, just with an error code test-lib.sh doesn't
like. I asked on list the best way to fix it and Frank Lichtenheld
said (and nobody objected until now) that this was the best way to
fix it.
Also, the not printing on STRERR is identical to another section of
code just below mine:
> unless ($line eq 'anonymous') {
> print "E Only anonymous user allowed via pserver\n";
> print "I HATE YOU\n";
> exit 1;
> }
However, amending my patch to print to STDERR is not difficult.
~~ Brian Gernhardt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox