* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Brian Gernhardt @ 2007-10-17 19:15 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git, spearce
In-Reply-To: <20071017190646.GC9041@planck.djpig.de>
On Oct 17, 2007, at 3:06 PM, Frank Lichtenheld wrote:
> I have this in my repo and will submit this with the other git-
> cvsserver
> changes. I was just waiting for either Junio to return or someone else
> stepping up.
Ah. I had missed that. I just dug up the patch when switching to
Shawn's repo gave me those old testing errors. Had thought it had
gotten lost in the shuffle.
Never mind me then,
~~ Brian
^ permalink raw reply
* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Frank Lichtenheld @ 2007-10-17 19:08 UTC (permalink / raw)
To: Morten Welinder; +Cc: Brian Gernhardt, git, spearce
In-Reply-To: <118833cc0710170739i179e7389k1e44f70086ca88be@mail.gmail.com>
On Wed, Oct 17, 2007 at 10:39:52AM -0400, 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.
Please note that git-cvsserver is special in that its output will never
be displayed directly to the user but is always interpreted first by
the client. So print "E something" is acutally in some cases more
correct than print STDERR something.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Frank Lichtenheld @ 2007-10-17 19:06 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git, spearce
In-Reply-To: <20071017140547.GA21691@Hermes.cust.hotspot.t-mobile.com>
On Wed, Oct 17, 2007 at 10:05:47AM -0400, Brian Gernhardt wrote:
> This was causing test failures because die was exiting 255.
>
> Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
> ---
>
> Shawn, I sent this in a couple weeks ago but it looks like it never
> made it into your repo. It fixes test failures on my machine that have
> been plauging me for months.
I have this in my repo and will submit this with the other git-cvsserver
changes. I was just waiting for either Junio to return or someone else
stepping up.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH 04/25] Rework make_usage to print the usage message immediately
From: Alex Riesen @ 2007-10-17 19:06 UTC (permalink / raw)
To: Pierre Habouzit, git, Shawn O. Pearce
In-Reply-To: <20071016221555.GB31695@olympe.madism.org>
Pierre Habouzit, Wed, Oct 17, 2007 00:15:55 +0200:
> > Why stderr, BTW? For instance, the output from "git help" is on
> > stdout. To be fair, I don't know why it is stdout there either.
> because it's what usage() does already ?
fair enough.
^ permalink raw reply
* Re: git-gc --prune interferes cogito?
From: Michael Dressel @ 2007-10-17 18:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20071017153841.GL18279@machine.or.cz>
Hi,
On Wed, 17 Oct 2007, Petr Baudis wrote:
> 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.
>
Thank you. I tried it at home too where I had an older version of git.
With the older git version git-gc --prune didn't disturbe cogito.
I upgradet to git version 1.5.3.4 and tried gc.packrefs=false and it
seams to be ok forr cogito.
Cheers,
Michael
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-17 18:54 UTC (permalink / raw)
To: Tom Tobin; +Cc: git
In-Reply-To: <1192645509.6640.21.camel@athena>
On Wed, 17 Oct 2007, Tom Tobin wrote:
>
> Or is "unix developers" code for "my sample size of one"?
Well, let's put it this way: that "sample" is the one that started the
project.
I got to pick the license. Are you going to argue about that too? I got to
pick the way I wrote the code. Are you going to continue arguing about
that?
The fact is, I don't see the people arguing for spaces having actually
*done* anything for git. So why are you arguing?
> 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".
Umm. And I've *told* you that.
The whole point is:
- every single damn editor out there can handle tabs.
- it's the default
- end of story.
What's so hard to understand?
> As for *disk space*? When we can measure cheap drives in sizable
> fractions of *terabytes*, this simply isn't a serious argument.
That disk-space translates into memory usage too, and into just being
technically the *inferior* choice.
How hard is that to accept? If you have a choice between a technically
better solution, and a technically worse one, why are you arguing for the
worse one?
> Yeah, can you believe some projects actually *survive* with an
> all-spaces indentation rule? And ::gasp:: even *thrive*?
Hey, Ḯ'm not saying that others shouldn't use spaces. I'm saying that
*git* should not, the same way the Linux kernel does not and will not.
Why? Because tabs are better. You (or anybody else) have simply never
given any argument against that very simple argument. You try to push an
inferior solution.
> Problems have been outlined, but since everything for you comes down to
> "anything that comes between me and microemacs sucks", rational
> discussion breaks down.
Don't talk about "rational discussion", since you don't even *have* any.
The starting point for any rational decision would be to explain why
changing tabs to spaces would actually improve anything at all. And you
have yet to show *any* such argument, while I've shown arguments to the
reverse.
One big one being: the person who started the project and still actually
*does* something for it actually cares.
In contrast, your argument seems to be "I've not actually done anything,
but I want to paint the bikeshed pink".
Linus
^ permalink raw reply
* 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
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