* Re: [PATCH 1/2 v3] mergetool: use path to mergetool in config var mergetool.<tool>.path
From: Shawn O. Pearce @ 2007-10-18 5:27 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11926413723666-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> This commit adds a mechanism to provide absolute paths to the
> external programs called by 'git mergetool'. ...
...
> @@ -297,17 +297,38 @@ do
> shift
> done
>
> +valid_tool() {
> + case "$1" in
> + kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff)
> + ;; # happy
> + *)
> + return 1
> + ;;
> + esac
> +}
...
> + test -n "$merge_tool" || valid_tool "$merge_tool" || {
Wouldn't an empty $merge_tool string be caught above in the
valid_tool function where it falls through and returns 1?
So isn't test -n here redundant?
--
Shawn.
^ permalink raw reply
* Re: bug: origin refs updated too soon locally
From: Jeff King @ 2007-10-18 5:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Perry Wagle, git
In-Reply-To: <20071018045358.GB14735@spearce.org>
On Thu, Oct 18, 2007 at 12:53:58AM -0400, Shawn O. Pearce wrote:
> This is probably easier to do after the db/fetch-pack topic is
> merged as the improvements there might make this easier. But I
> could be wrong. Be nice if someone proved me wrong by writing up
> a patch for git-send-pack.
It doesn't look too bad...patch series in a few minutes.
-Peff
^ permalink raw reply
* Re: backup or mirror a repository
From: Dmitry Potapov @ 2007-10-18 5:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dan Farina, Junio C Hamano, git
In-Reply-To: <7vsl4zqp8l.fsf@gitster.siamese.dyndns.org>
On Thu, Sep 27, 2007 at 11:27:06PM -0700, Junio C Hamano wrote:
> The "git remote add --mirror" setup is about setting up the
> local repository _AS_ the backup of the remote. In other words,
> the contents come from the remote by fetching from it and safely
> kept away from disaster on the local side. And for that,
> "remote prune" is a perfect thing to do.
I have tried to do that but I am getting a warning:
$ git remote prune origin
Warning: unrecognized mapping in remotes.origin.fetch: +refs/*:refs/*
and no branch is removed.
I suspect that the change that introduced --mirror option for the 'add'
command did not adjust the prune procedure to handle the new situation
properly. Or is just me doing something wrong?
Anyway, because the official released git still does not have --mirror
and it could be difficult to convince the admin to use the bleading edge
version of Git for secure backup, I wrote a simple script instead, which
provides the same functionality but using the released version of Git.
Maybe, someone else finds it useful.
$ cat git-mirror
#!/bin/sh
usage() {
echo >&2 "Usage: $0 URL"
exit 1
}
set -e
test $# -eq 1 || usage
URL="$1"
# Initialize Git bare directory
git --bare init
# Initialize the mirror
git remote add origin "$URL"
git fetch
rmdir refs/heads
ln -s remotes/origin refs/heads
# Adding creating a script that will be run by cron
cat <<EOF > git-mirror-sync
cd "$PWD"
git fetch
git remote prune origin
EOF
chmod +x git-mirror-sync
# Adding git-mirror-sync to cron
echo "Please, add $PWD/git-mirror-sync to cron"
#########################################################
Dmitry
^ permalink raw reply
* Re: pulling Already up-to-date linux-2.6 repo takes ~8 minutes?
From: Mike Galbraith @ 2007-10-18 5:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1192684150.7390.15.camel@Homer.simpson.net>
On Thu, 2007-10-18 at 07:09 +0200, Mike Galbraith wrote:
> > I'd suggest making your life a little bit easier. Consider creating
> > a remote that points to Linus:
> >
> > $ git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > $ git checkout -b master ; # or any other branch
> > $ git config branch.master.remote linus
> > $ git config branch.master.merge refs/heads/master
Dang. git was happy with everything above except the checkout -b
master, so I can't get off the dangling limb I'm on, and onto a solid
branch.
root@Homer: git checkout -b master
git checkout: branch master already exists
root@Homer: git branch
* (no branch)
master
root@Homer: time git pull
remote: Generating pack...
remote: Counting objects: 18672
remote: Done counting 55975 objects.
remote: Result has 48507 objects.
remote: Deltifying 48507 objects...
remote: 100% (48507/48507) done
Indexing 48507 objects...
remote: Total 48507 (delta 38878), reused 44654 (delta 35166)
100% (48507/48507) done
Resolving 38878 deltas...
100% (38878/38878) done
3419 objects were added to complete this thin pack.
* refs/remotes/origin/master: fast forward to branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
old..new: 86a71db..d85714d
You are not currently on a branch; you must explicitly
specify which branch you wish to merge:
git pull <remote> <branch>
real 8m12.676s
user 0m29.621s
sys 0m2.763s
^ permalink raw reply
* Re: pulling Already up-to-date linux-2.6 repo takes ~8 minutes?
From: Mike Galbraith @ 2007-10-18 5:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1192685971.7390.21.camel@Homer.simpson.net>
On Thu, 2007-10-18 at 07:39 +0200, Mike Galbraith wrote:
> On Thu, 2007-10-18 at 07:09 +0200, Mike Galbraith wrote:
>
> > > I'd suggest making your life a little bit easier. Consider creating
> > > a remote that points to Linus:
> > >
> > > $ git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > > $ git checkout -b master ; # or any other branch
> > > $ git config branch.master.remote linus
> > > $ git config branch.master.merge refs/heads/master
>
> Dang. git was happy with everything above except the checkout -b
> master, so I can't get off the dangling limb I'm on, and onto a solid
> branch.
Pff. -f.
Thanks, ~4 second pull is MUCH better :)
-Mike
^ permalink raw reply
* Re: On Tabs and Spaces
From: Mike Hommey @ 2007-10-18 5:42 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <k5pll7rb.fsf@blue.sea.net>
On Thu, Oct 18, 2007 at 01:02:32AM +0300, Jari Aalto wrote:
> * Wed 2007-10-17 Michael Witten <mfwitten@MIT.EDU>
> * Message-Id: E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu
> > On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote:
> >
> >> But I still haven't seen any compelling arguments against the "all
> >> space" case
> >
> > Overhead!
> >
> > If you use 8 spaces instead of one tab,
> > that's using up 7x more space!
>
> Software is the right place to worry about optimization. We should trust
> SCM to make proper and efficient deltas. If not, algorithms need
> improvemnts.
>
> Any cross platform development or electronic exchange is guaranteed to
> be interpreted correctly when policy enforces "only spaces"
>
> As we have already seen in numerous times in this thread, using tabs
> will - eventually - be interpreted in some editor, in some display, in
> some encironment using some tools ... incorrectly or different than the
> author intended. Simply because editors are configurable and we cannot
> know what settings they may have when they load the file in.
>
> There is no such problem with spaces.
There is such problem with spaces. A lot of editors will just insert
tabs to indent a new line when the previous you were typing begins with
enough spaces, in which case you end up with spaces and tabs mixed all
the way. It ends up being worse than all tabs.
Mike
^ permalink raw reply
* Re: pulling Already up-to-date linux-2.6 repo takes ~8 minutes?
From: Shawn O. Pearce @ 2007-10-18 5:48 UTC (permalink / raw)
To: Mike Galbraith; +Cc: git
In-Reply-To: <1192685971.7390.21.camel@Homer.simpson.net>
Mike Galbraith <efault@gmx.de> wrote:
> Dang. git was happy with everything above except the checkout -b
> master, so I can't get off the dangling limb I'm on, and onto a solid
> branch.
>
> root@Homer: git checkout -b master
> git checkout: branch master already exists
> root@Homer: git branch
> * (no branch)
> master
Look to see if there's anything on your current master branch that
you don't want/need anymore:
$ git log ..master
If that comes up empty (no output) or you mean to discard those
changes then you can just force create the branch and check it out:
$ git branch -f master
$ git checkout master
On the other hand if you want to keep those changes then you should
consider creating a different branch than master, or merging master
first:
$ git merge master
> root@Homer: time git pull
> remote: Total 48507 (delta 38878), reused 44654 (delta 35166)
...
Well, you downloaded everything again. However...
> 3419 objects were added to complete this thin pack.
> * refs/remotes/origin/master: fast forward to branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
> old..new: 86a71db..d85714d
This time we actually stored a remote tracking branch.
So although we didn't actually merge Linus' current version into
your detached HEAD we did save it under a remote tracking branch
(named "origin/master") so the next time you run git-pull we won't
actually need to download that data again. We already have it,
and know we have it.
Its just not in your current branch.
> You are not currently on a branch; you must explicitly
> specify which branch you wish to merge:
> git pull <remote> <branch>
If you finish switching to a real branch with a configured remote
and merge entry then this message should go away and you should be
able to efficiently pull Linus' tree into your own.
--
Shawn.
^ permalink raw reply
* Re: pulling Already up-to-date linux-2.6 repo takes ~8 minutes?
From: Mike Galbraith @ 2007-10-18 5:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071018054834.GH14735@spearce.org>
On Thu, 2007-10-18 at 01:48 -0400, Shawn O. Pearce wrote:
> Look to see if there's anything on your current master branch that
> you don't want/need anymore:
>
> $ git log ..master
git trees here are meant to be absolutely virgin, so...
> If that comes up empty (no output) or you mean to discard those
> changes then you can just force create the branch and check it out:
>
> $ git branch -f master
> $ git checkout master
Thanks again, I'm off my dangling limb.
-Mike
^ permalink raw reply
* Re: pulling Already up-to-date linux-2.6 repo takes ~8 minutes?
From: Shawn O. Pearce @ 2007-10-18 5:57 UTC (permalink / raw)
To: Mike Galbraith; +Cc: git
In-Reply-To: <1192686882.9097.2.camel@Homer.simpson.net>
Mike Galbraith <efault@gmx.de> wrote:
> On Thu, 2007-10-18 at 01:48 -0400, Shawn O. Pearce wrote:
>
> > Look to see if there's anything on your current master branch that
> > you don't want/need anymore:
> >
> > $ git log ..master
>
> git trees here are meant to be absolutely virgin, so...
Whaa? You found something that's better for manging the kernel
sources then Git? ;-)
> Thanks again, I'm off my dangling limb.
Good to hear. I hate being out on a limb and not having a rope to
climb down with.
--
Shawn.
^ permalink raw reply
* Re: On Tabs and Spaces
From: Andreas Ericsson @ 2007-10-18 6:02 UTC (permalink / raw)
To: Christer Weinigel; +Cc: Johannes Schindelin, Linus Torvalds, Tom Tobin, git
In-Reply-To: <20071018023103.5d27ee35@localhost.localdomain>
Christer Weinigel wrote:
>
> /Christer (pissing contensts are silly, so why the hell am I getting
> involved in one?)
Because the right to an opinion is so fundamental to us that when someone
claims yours is stupid for reasons you (or me, or anyone) find unfair, we
stand up and say so. It's not a sign of being stupid. It's a sign of being
protective about a very basic democratic right, and oss people are usually
very protective about those. Freedom of everything comes easier to people
than "force christianity on the world, but keep your sources open!".
Linus is definitely not the most polite of people out there. Had he been
less than top-ranked in the meritocracy he would have been utterly and
totally annihilated on several mailing lists a really long time ago. At
the same time, he's entitled to his opinion the same way everyone is, and
he's entitled to express it any way he wants. When he's *really* off the
mark, people will tell him so. Or ignore him totally, like an embarrassing
grandfather who's just gotten too drunk at the christmas dinner and started
fondling his grandsons girlfriend. However, the same goes for everyone else,
and Linus *is* fond of telling people "so". If nothing else, it saves
time to head off dead ends right at the start.
Linus isn't sacrosankt, just enough of a corner-stone that people will keep
listening to him even if he's wildly offending.
tabs-vs-spaces is not, I feel, a discussion that has a great impact in
the world, so being "really off the mark" is not really possible there.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: pulling Already up-to-date linux-2.6 repo takes ~8 minutes?
From: Mike Galbraith @ 2007-10-18 6:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071018055729.GI14735@spearce.org>
On Thu, 2007-10-18 at 01:57 -0400, Shawn O. Pearce wrote:
> Mike Galbraith <efault@gmx.de> wrote:
> > On Thu, 2007-10-18 at 01:48 -0400, Shawn O. Pearce wrote:
> >
> > > Look to see if there's anything on your current master branch that
> > > you don't want/need anymore:
> > >
> > > $ git log ..master
> >
> > git trees here are meant to be absolutely virgin, so...
>
> Whaa? You found something that's better for manging the kernel
> sources then Git? ;-)
cp vi diff patch :) I'm crawling toward the 20th century though. The
tiny bit of git functionality I do use is pretty darn spiffy.
-Mike
^ permalink raw reply
* Re: [PATCH 2/2] Quoting paths in tests
From: Johannes Sixt @ 2007-10-18 6:08 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: git
In-Reply-To: <6E65762D-FBC4-4A7C-97A9-20F6744E25DE@steelskies.com>
Jonathan del Strother schrieb:
>
> 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.
You can rewrite this expression as
perl -w -e '$svnrepo = shift;
...
$SVN::Core::Version gt "1.1.0" ...
system(qw/svnadmin create --fs-type fsfs/, $svnrepo) == 0 ...
...
' >&3 2>&4 "$svnrepo"
i.e. you pass the repository name as an argument to the scriptlet.
>> 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//$/\\\$}
This is a bashism - that's a big no-no.
> 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.
These examples expand `pwd` too early. Can't you just put everything inside
single-quotes? Although I'm not sure about VISUAL: Is it invoked with $PWD
that is different from $PWD when VISUAL is defined? If so, then you can
hardly delay `pwd`...
I know I'm a bit anal with my criticism. I reviewed your patch because I
think fixing for paths with whitespace is worthwhile. However, I also think
any fix should go the full way and not only shift the problems into a
different corner. Maybe a word from $maintainer would be in order ;)
-- Hannes
^ permalink raw reply
* [PATCH] t5516: test update of local refs on push
From: Jeff King @ 2007-10-18 6:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Perry Wagle
In-Reply-To: <20071018045358.GB14735@spearce.org>
The first test (updating local refs) should succeed, but the
second one (not updating on error) currently fails.
Signed-off-by: Jeff King <peff@peff.net>
---
t/t5516-fetch-push.sh | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index ca46aaf..dd329d7 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -244,4 +244,32 @@ test_expect_success 'push with colon-less refspec (4)' '
'
+test_expect_success 'push updates local refs' '
+
+ rm -rf parent child &&
+ mkdir parent && cd parent && git init &&
+ echo one >foo && git add foo && git commit -m one &&
+ cd .. &&
+ git clone parent child && cd child &&
+ echo two >foo && git commit -a -m two &&
+ git push &&
+ test $(git rev-parse master) = $(git rev-parse remotes/origin/master)
+
+'
+
+test_expect_success 'push does not update local refs on failure' '
+
+ rm -rf parent child &&
+ mkdir parent && cd parent && git init &&
+ echo one >foo && git add foo && git commit -m one &&
+ echo exit 1 >.git/hooks/pre-receive &&
+ chmod +x .git/hooks/pre-receive &&
+ cd .. &&
+ git clone parent child && cd child &&
+ echo two >foo && git commit -a -m two || exit 1
+ git push && exit 1
+ test $(git rev-parse master) != $(git rev-parse remotes/origin/master)
+
+'
+
test_done
--
1.5.3.4.1162.gc3e8e-dirty
^ permalink raw reply related
* [PATCH 2/2] send-pack: don't update tracking refs on error
From: Jeff King @ 2007-10-18 6:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Perry Wagle
In-Reply-To: <20071018045358.GB14735@spearce.org>
Previously, we updated the tracking refs (which match refs we
are pushing) while generating the list of refs to send.
However, at that point we don't know whether the refs were
accepted.
Instead, we now wait until we get a response code from the
server. If an error was indicated, we don't update any local
tracking refs. Technically some refs could have been updated
on the remote, but since the local ref update is just an
optimization to avoid an extra fetch, we are better off
erring on the side of correctness.
The user-visible message is now generated much later in the
program, and has been tweaked to make more sense.
Signed-off-by: Jeff King <peff@peff.net>
---
send-pack.c | 50 ++++++++++++++++++++++++++++++++++----------------
1 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index f74e66a..25d5c25 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -177,6 +177,35 @@ static int receive_status(int in)
return ret;
}
+static void update_tracking_ref(struct remote *remote, struct ref *ref)
+{
+ struct refspec rs;
+ int will_delete_ref;
+
+ rs.src = ref->name;
+ rs.dst = NULL;
+
+ if (!ref->peer_ref)
+ return;
+
+ will_delete_ref = is_null_sha1(ref->peer_ref->new_sha1);
+
+ if (!will_delete_ref &&
+ !hashcmp(ref->old_sha1, ref->peer_ref->new_sha1))
+ return;
+
+ if (!remote_find_tracking(remote, &rs)) {
+ fprintf(stderr, "updating local tracking ref '%s'\n", rs.dst);
+ if (is_null_sha1(ref->peer_ref->new_sha1)) {
+ if (delete_ref(rs.dst, NULL))
+ error("Failed to delete");
+ } else
+ update_ref("update by push", rs.dst,
+ ref->new_sha1, NULL, 0, 0);
+ free(rs.dst);
+ }
+}
+
static int send_pack(int in, int out, struct remote *remote, int nr_refspec, char **refspec)
{
struct ref *ref;
@@ -302,22 +331,6 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
fprintf(stderr, "\n from %s\n to %s\n",
old_hex, new_hex);
}
- if (remote) {
- struct refspec rs;
- rs.src = ref->name;
- rs.dst = NULL;
- if (!remote_find_tracking(remote, &rs)) {
- fprintf(stderr, " Also local %s\n", rs.dst);
- if (will_delete_ref) {
- if (delete_ref(rs.dst, NULL)) {
- error("Failed to delete");
- }
- } else
- update_ref("update by push", rs.dst,
- ref->new_sha1, NULL, 0, 0);
- free(rs.dst);
- }
- }
}
packet_flush(out);
@@ -330,6 +343,11 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
ret = -4;
}
+ if (remote && ret == 0) {
+ for (ref = remote_refs; ref; ref = ref->next)
+ update_tracking_ref(remote, ref);
+ }
+
if (!new_refs && ret == 0)
fprintf(stderr, "Everything up-to-date\n");
return ret;
--
1.5.3.4.1162.gc3e8e-dirty
^ permalink raw reply related
* Re: [PATCH] t5516: test update of local refs on push
From: Jeff King @ 2007-10-18 6:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Perry Wagle
In-Reply-To: <20071018061746.GA29531@coredump.intra.peff.net>
On Thu, Oct 18, 2007 at 02:17:46AM -0400, Jeff King wrote:
> The first test (updating local refs) should succeed, but the
> second one (not updating on error) currently fails.
Oops, this should of course be labeled as 1/2.
For the fix, I didn't need anything from 'next', after all, and 2/2 also
works fine there (it was almost literally a code move).
-Peff
^ permalink raw reply
* Re: On Tabs and Spaces
From: David Kastrup @ 2007-10-18 6:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Christer Weinigel, Tom Tobin, git
In-Reply-To: <alpine.LFD.0.999.0710171438551.26902@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Maybe it's a character flaw. I'll respect people who do something
> interesting, but re-implementing CVS (and badly, at that)
I seem to remember somebody who started out reimplementing Unix, and
badly, at that. With the help of many other people, this thing
finally became portable to more than i386 and more than AT drives.
Took quite a long time. The ancient floppy disk code still has the
renown of being one of the worst pieces of drivers all around.
If you find this silly, so do I. That's the point.
> or talking about syntactic changes to other peoples projects is not
> going to fill me with respect.
>
> In short, I'll give respect when somebody is shown to be *worth*
> that respect. But respect really has to be earned, not just
> "assumed", otherwise it's pointless.
Cooperation is easier if one is of the opinion rather that disrespect
has to be earned: otherwise you alienate potential contributors before
they even had a chance to contribute.
This difference in approach is one of the things I can't help admiring
in Junio. And I don't think it is to the detriment of git.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* git-svn help for authorsfile
From: Dongsheng Song @ 2007-10-18 6:26 UTC (permalink / raw)
To: git
In general, all svn projects share the same authorsfile, e.g.
[svn]
authorsfile=/path/to/authorsfile
[svn-remote "project-a"]
url = http://server.org/svn
branches = branches/*/project-a:refs/remotes/project-a/branches/*
tags = tags/*/project-a:refs/remotes/project-a/tags/*
trunk = trunk/project-a:refs/remotes/project-a/trunk
[svn-remote "project-b"]
url = http://server.org/svn
branches = branches/*/project-b:refs/remotes/project-b/branches/*
tags = tags/*/project-b:refs/remotes/project-b/tags/*
trunk = trunk/project-b:refs/remotes/project-b/trunk
But if project-a and project-b has same svn id, map to different
user/email, how do I do?
Can we move authorsfile from svn to svn-remote section ?
Thanks for some help,
---
Dongsheng
^ permalink raw reply
* [PATCH] git-blame shouldn't crash if run in an unmerged tree
From: Shawn O. Pearce @ 2007-10-18 6:34 UTC (permalink / raw)
To: Linus Torvalds, git; +Cc: B.Steinbrink
I'm applying this patch to my maint tree tonight as it does resolve
the issue for now. What surprised me was the file that we were
crashing out on wasn't even the file we wanted to get the blame
data for. :-\
--8>--
From: Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCH] git-blame shouldn't crash if run in an unmerged tree
If we are in the middle of resolving a merge conflict there may be
one or more files whose entries in the index represent an unmerged
state (index entries in the higher-order stages).
Attempting to run git-blame on any file in such a working directory
resulted in "fatal: internal error: ce_mode is 0" as we use the magic
marker for an unmerged entry is 0 (set up by things like diff-lib.c's
do_diff_cache() and builtin-read-tree.c's read_tree_unmerged())
and the ce_match_stat_basic() function gets upset about this.
I'm not entirely sure that the whole "ce_mode = 0" case is a good
idea to begin with, and maybe the right thing to do is to remove
that horrid freakish special case, but removing the internal error
seems to be the simplest fix for now.
Linus
[sp: Thanks to Björn Steinbrink for the test case]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
read-cache.c | 2 +
t/t8004-blame.sh | 73 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 75 insertions(+), 0 deletions(-)
create mode 100755 t/t8004-blame.sh
diff --git a/read-cache.c b/read-cache.c
index 536f4d0..928e8fa 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -149,6 +149,8 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
else if (ce_compare_gitlink(ce))
changed |= DATA_CHANGED;
return changed;
+ case 0: /* Special case: unmerged file in index */
+ return MODE_CHANGED | DATA_CHANGED | TYPE_CHANGED;
default:
die("internal error: ce_mode is %o", ntohl(ce->ce_mode));
}
diff --git a/t/t8004-blame.sh b/t/t8004-blame.sh
new file mode 100755
index 0000000..ba19ac1
--- /dev/null
+++ b/t/t8004-blame.sh
@@ -0,0 +1,73 @@
+#!/bin/sh
+
+# Based on a test case submitted by Björn Steinbrink.
+
+test_description='git blame on conflicted files'
+. ./test-lib.sh
+
+test_expect_success 'setup first case' '
+ # Create the old file
+ echo "Old line" > file1 &&
+ git add file1 &&
+ git commit --author "Old Line <ol@localhost>" -m file1.a &&
+
+ # Branch
+ git checkout -b foo &&
+
+ # Do an ugly move and change
+ git rm file1 &&
+ echo "New line ..." > file2 &&
+ echo "... and more" >> file2 &&
+ git add file2 &&
+ git commit --author "U Gly <ug@localhost>" -m ugly &&
+
+ # Back to master and change something
+ git checkout master &&
+ echo "
+
+bla" >> file1 &&
+ git commit --author "Old Line <ol@localhost>" -a -m file1.b &&
+
+ # Back to foo and merge master
+ git checkout foo &&
+ if git merge master; then
+ echo needed conflict here
+ exit 1
+ else
+ echo merge failed - resolving automatically
+ fi &&
+ echo "New line ...
+... and more
+
+bla
+Even more" > file2 &&
+ git rm file1 &&
+ git commit --author "M Result <mr@localhost>" -a -m merged &&
+
+ # Back to master and change file1 again
+ git checkout master &&
+ sed s/bla/foo/ <file1 >X &&
+ rm file1 &&
+ mv X file1 &&
+ git commit --author "No Bla <nb@localhost>" -a -m replace &&
+
+ # Try to merge into foo again
+ git checkout foo &&
+ if git merge master; then
+ echo needed conflict here
+ exit 1
+ else
+ echo merge failed - test is setup
+ fi
+'
+
+test_expect_success \
+ 'blame runs on unconflicted file while other file has conflicts' '
+ git blame file2
+'
+
+test_expect_success 'blame runs on conflicted file in stages 1,3' '
+ git blame file1
+'
+
+test_done
--
1.5.3.4.1231.gac645
^ permalink raw reply related
* Re: [PATCH] t5516: test update of local refs on push
From: Shawn O. Pearce @ 2007-10-18 6:59 UTC (permalink / raw)
To: Jeff King; +Cc: git, Perry Wagle
In-Reply-To: <20071018062136.GB11938@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Thu, Oct 18, 2007 at 02:17:46AM -0400, Jeff King wrote:
> > The first test (updating local refs) should succeed, but the
> > second one (not updating on error) currently fails.
>
> Oops, this should of course be labeled as 1/2.
>
> For the fix, I didn't need anything from 'next', after all, and 2/2 also
> works fine there (it was almost literally a code move).
Yay. I like it when I'm proven wrong. Especially by a short patch.
:)
This will be in next tonight. Give it a few days, then probably
graduate up to master.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Make the output of "git svn clone" less confusing.
From: Shawn O. Pearce @ 2007-10-18 7:06 UTC (permalink / raw)
To: Eric Wong; +Cc: David Kågedal, git
In-Reply-To: <87k5poflp5.fsf@lysator.liu.se>
David Kgedal <davidk@lysator.liu.se> wrote:
> The problem is that the first thing it prints is
>
> Initialized empty Git repository in .git/
>
> even if actually created a subdirectory and changed into it first. But to the
> user, it looks like it is creating a .git/ dir in the directory he/she is
> started git from.
Eric, ack/nack?
> ---
> git-svn.perl | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> This change makes it more chatty, which might not be a good thing. But
> I think the previous output was worse.
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 777e436..d4450ca 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -286,6 +286,7 @@ sub do_git_init_db {
>
> sub init_subdir {
> my $repo_path = shift or return;
> + print "Creating directory $repo_path\n";
> mkpath([$repo_path]) unless -d $repo_path;
> chdir $repo_path or die "Couldn't chdir to $repo_path: $!\n";
> $ENV{GIT_DIR} = '.git';
> --
> 1.5.3.4.213.gb3127-dirty
--
Shawn.
^ permalink raw reply
* Re: On Tabs and Spaces
From: David Kågedal @ 2007-10-18 7:12 UTC (permalink / raw)
To: git
In-Reply-To: <20071018023103.5d27ee35@localhost.localdomain>
Christer Weinigel <christer@weinigel.se> writes:
> I usually have no need to use git since my employer doesn't use it.
That is actually not true. My employer doesn't use it either (we use
svn). But that doesn't stop me from using it all the time. git is an
excellent offline svn client.
(hej wingel)
--
David Kågedal
^ permalink raw reply
* Re: On Tabs and Spaces
From: David Kågedal @ 2007-10-18 7:15 UTC (permalink / raw)
To: git
In-Reply-To: <47168E70.4070305@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Jari Aalto wrote:
>> * Wed 2007-10-17 Michael Witten <mfwitten@MIT.EDU>
>> * Message-Id: E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu
>>> On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote:
>>>
>>>> But I still haven't seen any compelling arguments against the "all
>>>> space" case
>>> Overhead!
>>>
>>> If you use 8 spaces instead of one tab,
>>> that's using up 7x more space!
>>
>> Software is the right place to worry about optimization. We should trust
>> SCM to make proper and efficient deltas. If not, algorithms need
>> improvemnts.
>>
>> Any cross platform development or electronic exchange is guaranteed to
>> be interpreted correctly when policy enforces "only spaces"
>>
>> As we have already seen in numerous times in this thread, using tabs
>> will - eventually - be interpreted in some editor, in some display, in
>> some encironment using some tools ... incorrectly or different than the
>> author intended. Simply because editors are configurable and we cannot
>> know what settings they may have when they load the file in.
>>
>
> And simply because nearly all (unix) editors still insert a hard tab
> when pressing the tab key, and *mixing* tabs and spaces makes the
> situation *really* unbearable, one really shouldn't use all spaces.
I guess that means that you consider emacs to be an obscure or
non-unix editor?
When you press TAB while editing program code in emacs it doesn't
insert a hard tab. It reindents the current line according to the
indentation rules. The whitespace at the beginning of the line is
filled with spaces and/or tabs, depending on the indent-tabs-mode
setting.
--
David Kågedal
^ permalink raw reply
* Re: [PATCH 1/2 v3] mergetool: use path to mergetool in config var mergetool.<tool>.path
From: Steffen Prohaska @ 2007-10-18 7:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071018052724.GA27813@spearce.org>
On Oct 18, 2007, at 7:27 AM, Shawn O. Pearce wrote:
> Steffen Prohaska <prohaska@zib.de> wrote:
>> This commit adds a mechanism to provide absolute paths to the
>> external programs called by 'git mergetool'. ...
> ...
>> @@ -297,17 +297,38 @@ do
>> shift
>> done
>>
>> +valid_tool() {
>> + case "$1" in
>> + kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff |
>> gvimdiff)
>> + ;; # happy
>> + *)
>> + return 1
>> + ;;
>> + esac
>> +}
> ...
>> + test -n "$merge_tool" || valid_tool "$merge_tool" || {
>
> Wouldn't an empty $merge_tool string be caught above in the
> valid_tool function where it falls through and returns 1?
> So isn't test -n here redundant?
Sharp eyes, thanks.
Correct is
test -z "$merge_tool" || valid_tool "$merge_tool" || {
No merge tool or a valid merge tool is allowed at this place.
If the tool's already empty there's no need to tell the user
that it will be reset to empty.
I'll send a v4 version.
Steffen
^ permalink raw reply
* [PATCH 1/2 v4] mergetool: use path to mergetool in config var mergetool.<tool>.path
From: Steffen Prohaska @ 2007-10-18 7:53 UTC (permalink / raw)
To: spearce; +Cc: git, Steffen Prohaska
In-Reply-To: <923DDB10-C9E9-4797-9FC1-D31DEEBE75B7@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..987aeda 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 -z "$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 1/2 v3] mergetool: use path to mergetool in config var mergetool.<tool>.path
From: Shawn O. Pearce @ 2007-10-18 8:00 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <923DDB10-C9E9-4797-9FC1-D31DEEBE75B7@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> On Oct 18, 2007, at 7:27 AM, Shawn O. Pearce wrote:
> >...
> >>+ test -n "$merge_tool" || valid_tool "$merge_tool" || {
> >
> >Wouldn't an empty $merge_tool string be caught above in the
> >valid_tool function where it falls through and returns 1?
> >So isn't test -n here redundant?
>
> Sharp eyes, thanks.
>
> Correct is
>
> test -z "$merge_tool" || valid_tool "$merge_tool" || {
>
> No merge tool or a valid merge tool is allowed at this place.
> If the tool's already empty there's no need to tell the user
> that it will be reset to empty.
>
> I'll send a v4 version.
Thanks but its a little late. I'm about to push maint/master/next/pu
and this series is in next. While testing it I found another
bug related to init_tool_merge_tool_path() not having $merge_tool
initialized and thus causing it to never select a default tool if
the user didn't have one configured.
Here's what I'm actually about to push out:
--8>--
From e3fa2c761fdc490494e8e0855bcee4d7e58ada6a Mon Sep 17 00:00:00 2001
From: Steffen Prohaska <prohaska@zib.de>
Date: Wed, 17 Oct 2007 19:16:11 +0200
Subject: [PATCH] mergetool: use path to mergetool in config var mergetool.<tool>.path
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.
[sp: Fixed a few minor issues prior to applying]
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
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..4f89cbe 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 "$1" in
+ emerge)
+ merge_tool_path=emacs
+ ;;
+ *)
+ merge_tool_path=$1
+ ;;
+ 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
- *)
+ if ! valid_tool "$merge_tool"; then
echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
echo >&2 "Resetting to default..."
unset merge_tool
- ;;
- esac
+ fi
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
+ if ! valid_tool "$merge_tool"; then
+ echo >&2 "Unknown merge_tool $merge_tool"
+ exit 1
+ fi
+
+ 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.1231.gac645
--
Shawn.
^ permalink raw reply related
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