* Re: Git User's Survey 2007 summary - git homepage improvements
From: Petr Baudis @ 2007-10-17 12:50 UTC (permalink / raw)
To: Jonas Fonseca
Cc: Shawn O. Pearce, Jan Hudec, Frank Lichtenheld, Jakub Narebski,
git
In-Reply-To: <20071017111136.GB23417@diku.dk>
On Wed, Oct 17, 2007 at 01:11:36PM +0200, Jonas Fonseca wrote:
> If the list decides that it could be a better official name or simply an
> alias (currently the case if I configured it correctly) to git.or.cz (or
> whatever the list comes up with) I will gladly act as a domain sponsor.
I have configured it on my side too. git-scm.org now works. Thanks!
I'd have personally preferred git-vcs.org, but git-scm.org is cool too.
:-)
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: git update index question
From: Gonzalo Garramuno @ 2007-10-17 12:58 UTC (permalink / raw)
To: Lars Hjemli, git
In-Reply-To: <8c5c35580710170549n25c8b692w2466091ea56d641e@mail.gmail.com>
Lars Hjemli wrote:
> On 10/17/07, Gonzalo Garramuno <gga@filmaura.com> wrote:
>> what's the proper way to rebuild git's index file for all the files that
>> were to be committed but weren't due to the abort.
>
> Have you tried 'git commit -a'? It will run update-index on all
> modified files prior to executing the hook.
>
> Btw: If you want to inspect your changes for offending whitespace,
> 'git diff --color' and 'git diff --cached --color' are your friends.
> And if you give up, there is also 'git commit -a --no-verify'.
>
Thanks. I found out the root of my problem was actually something else.
I had incorrectly done a chmod a+x on the pre-commit hook when all my
previous commits had not been using it, so I think the pre-commit was
actually catching not my new fix but what was already in the repository.
git-commit -a had no effect due to that.
But it's good to know about the --no-verify option, thou.
--
Gonzalo Garramuño
Film Aura
A New Dawn in Media Companies
gga@filmaura.com
http://www.filmaura.com
^ permalink raw reply
* Re: git update index question
From: Lars Hjemli @ 2007-10-17 13:30 UTC (permalink / raw)
To: Gonzalo Garramuno; +Cc: git
In-Reply-To: <47160706.2000706@filmaura.com>
On 10/17/07, Gonzalo Garramuno <gga@filmaura.com> wrote:
> I had incorrectly done a chmod a+x on the pre-commit hook when all my
> previous commits had not been using it, so I think the pre-commit was
> actually catching not my new fix but what was already in the repository.
That sounds wrong: the (default) pre-commit hook only verifies the
_new_ content, not the content in HEAD. Is there any chance your
.git/hooks/pre-commit script has been tampered with?
--
larsh
^ permalink raw reply
* Re: SLES 10 git packages
From: Petr Baudis @ 2007-10-17 13:52 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20071016072742.GA11450@cip.informatik.uni-erlangen.de>
Hi,
On Tue, Oct 16, 2007 at 09:27:42AM +0200, Thomas Glanzmann wrote:
> is there someone out there who maintains up2date git packages for SuSE
> Linux Enterprise Server 10?
there seem to be some in the build service:
http://download.opensuse.org/repositories/devel:tools:scm/SLE_10
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* [PATCH] Use exit 1 instead of die when req_Root fails.
From: Brian Gernhardt @ 2007-10-17 14:05 UTC (permalink / raw)
To: git, spearce
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.
git-cvsserver.perl | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 13dbd27..0d55fec 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -145,8 +145,10 @@ if ($state->{method} eq 'pserver') {
}
my $request = $1;
$line = <STDIN>; chomp $line;
- req_Root('root', $line) # reuse Root
- or die "E Invalid root $line \n";
+ unless (req_Root('root', $line)) { # reuse Root
+ print "E Invalid root $line \n";
+ exit 1;
+ }
$line = <STDIN>; chomp $line;
unless ($line eq 'anonymous') {
print "E Only anonymous user allowed via pserver\n";
--
1.5.3.4.206.g0cef9
^ permalink raw reply related
* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Morten Welinder @ 2007-10-17 14:39 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git, spearce
In-Reply-To: <20071017140547.GA21691@Hermes.cust.hotspot.t-mobile.com>
> 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.
Morten
^ permalink raw reply
* Re: SLES 10 git packages
From: Thomas Glanzmann @ 2007-10-17 14:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT
In-Reply-To: <20071017135202.GK18279@machine.or.cz>
Hello Petr,
>> SLES 10 packages
> there seem to be some in the build service:
> http://download.opensuse.org/repositories/devel:tools:scm/SLE_10
thanks a lot for the URL,
Thomas
^ permalink raw reply
* git-gc --prune interferes cogito?
From: MichaelTiloDressel @ 2007-10-17 14:43 UTC (permalink / raw)
To: git
Hi,
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?
Cheers,
Michael
^ 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
* 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: 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: 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: 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 - 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: [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: 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: 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: [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 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
* [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
* [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
* 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 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 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
* 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
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