* Re: git-svn: handling merge-base failures
From: Eric Wong @ 2009-12-23 20:57 UTC (permalink / raw)
To: Andrew Myrick; +Cc: git, Sam Vilain
In-Reply-To: <940F72F6-8FE5-42AE-84A1-8C4A77B57188@apple.com>
Andrew Myrick <amyrick@apple.com> wrote:
> On Dec 23, 2009, at 12:09 PM, Eric Wong wrote:
> > Andrew Myrick <amyrick@apple.com> wrote:
> >> One of my projects is failing to clone because merge-base is failing
> >> on one of the revisions; the branch is a partial branch, so merge-base
> >> can't find a common ancestor with trunk. I'd like to catch the
> >> exception that command_oneline should throw when merge-base fails, but
> >> my perl is very rusty and I'm struggling to get git-svn.perl to grok
> >> the Git::Error::Command class. What is the appropriate way to import
> >> that class? Or more generally, is there a better solution to handling
> >> this error case?
> >
> > Hi Andrew,
> >
> > Git::Error::Command should be imported with the rest of Git.pm
> >
> > It's a special way of doing exceptions in Perl which I don't see much
> > point of... Looking at git-send-email as an example, it does this:
> >
> > use Error qw(:try);
> > use Git;
> >
> > try {
> > # something that will throw
> > } catch Git::Error::Command with {
> > # error handling
> > }
>
> I looked at git-send-email's example, but I wanted to do a bit more:
>
> try {
> # command_oneline(...);
> } catch Git::Error::Command with {
> $E = shift;
> if ($E->value() == 1) {
> # do something
> } else {
> # do something else
> }
> }
>
> This is used in perl/Git.pm, but when I tried it in git-svn.perl, it
> fails with the error "Can't locate object method 'value' via package
> 'Git::SVN'".
That's strange. I'm at a bit of a loss here so I'll wait for somebody
with more Perl knowledge than myself.
What happens when you dump @_ in your catch block?
use Data::Dumper;
try {
} catch Git::Error::Command with {
print STDERR Dumper(\@_);
}
> Presumably $@ contains the Git::Error::Command object, which leaves me
> in the same spot, unfortunately.
>
> > But yes, it is Perl after all and TMTOWTDI :)
>
> Is there ever :)
Yes I'm lost here, too, so in these cases I default to putting
print statements everywhere and Data::Dumper :)
--
Eric Wong
^ permalink raw reply
* Re: git tag --contains <commit> -n=1 ?
From: NODA, Kai @ 2009-12-23 20:37 UTC (permalink / raw)
To: git
In-Reply-To: <m2fx71pq0p.fsf@whitebox.home>
Thank you for your reply, Andreas
Andreas Schwab wrote:
...
>> Here I wonder whether "head -1" is generally correct or not when I want
>> the oldest tag.
>
> Since the output of git tag is sorted by name, generally not.
Wow, I didn't know that.
But then, under the assumption that tags have names like verNNN,
that behavior ensures me that "head -1" works as intended.
Maybe I look at its implementation ( refs.c:do_for_each_ref , right?)
but this seems a tough code to comprehend, especially around
packed/loose/extra ...
Thanks,
Kai
^ permalink raw reply
* Re: git-svn: handling merge-base failures
From: Andrew Myrick @ 2009-12-23 20:18 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Sam Vilain
In-Reply-To: <20091223200936.GA13735@dcvr.yhbt.net>
On Dec 23, 2009, at 12:09 PM, Eric Wong wrote:
> Andrew Myrick <amyrick@apple.com> wrote:
>> One of my projects is failing to clone because merge-base is failing
>> on one of the revisions; the branch is a partial branch, so merge-base
>> can't find a common ancestor with trunk. I'd like to catch the
>> exception that command_oneline should throw when merge-base fails, but
>> my perl is very rusty and I'm struggling to get git-svn.perl to grok
>> the Git::Error::Command class. What is the appropriate way to import
>> that class? Or more generally, is there a better solution to handling
>> this error case?
>
> Hi Andrew,
>
> Git::Error::Command should be imported with the rest of Git.pm
>
> It's a special way of doing exceptions in Perl which I don't see much
> point of... Looking at git-send-email as an example, it does this:
>
> use Error qw(:try);
> use Git;
>
> try {
> # something that will throw
> } catch Git::Error::Command with {
> # error handling
> }
I looked at git-send-email's example, but I wanted to do a bit more:
try {
# command_oneline(...);
} catch Git::Error::Command with {
$E = shift;
if ($E->value() == 1) {
# do something
} else {
# do something else
}
}
This is used in perl/Git.pm, but when I tried it in git-svn.perl, it fails with the error "Can't locate object method 'value' via package 'Git::SVN'".
>
> A more standard approach in Perl is just:
>
> eval {
> # something that will die
> };
> if ($@) {
> # error handling
> }
>
Presumably $@ contains the Git::Error::Command object, which leaves me in the same spot, unfortunately.
> But yes, it is Perl after all and TMTOWTDI :)
Is there ever :)
-Andrew
^ permalink raw reply
* Re: git-svn: handling merge-base failures
From: Eric Wong @ 2009-12-23 20:09 UTC (permalink / raw)
To: Andrew Myrick; +Cc: git, Sam Vilain
In-Reply-To: <931B0483-7628-488E-BB9F-C40346353149@apple.com>
Andrew Myrick <amyrick@apple.com> wrote:
> One of my projects is failing to clone because merge-base is failing
> on one of the revisions; the branch is a partial branch, so merge-base
> can't find a common ancestor with trunk. I'd like to catch the
> exception that command_oneline should throw when merge-base fails, but
> my perl is very rusty and I'm struggling to get git-svn.perl to grok
> the Git::Error::Command class. What is the appropriate way to import
> that class? Or more generally, is there a better solution to handling
> this error case?
Hi Andrew,
Git::Error::Command should be imported with the rest of Git.pm
It's a special way of doing exceptions in Perl which I don't see much
point of... Looking at git-send-email as an example, it does this:
use Error qw(:try);
use Git;
try {
# something that will throw
} catch Git::Error::Command with {
# error handling
}
A more standard approach in Perl is just:
eval {
# something that will die
};
if ($@) {
# error handling
}
But yes, it is Perl after all and TMTOWTDI :)
--
Eric Wong
^ permalink raw reply
* Re: [BUG REPORT] git-svn fails to create branches if ssh+svn gets used as protocol.
From: Eric Wong @ 2009-12-23 20:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Florian Köberle, Robert Zeh
In-Reply-To: <4B326EE3.5060409@fkoeberle.de>
Florian Köberle <florian@fkoeberle.de> wrote:
> Hello Eric,
>
> your patch works great. I created successfully a branch on a svn+ssh://
> repository using the patched git-svn.
>
> Thank you for the patch and the fast reply. I hope the patch find it's
> way into the next release.
Hi Florian, thanks for the report and testing the fix.
I've just pushed the that commit and Robert's test for Junio to pull at
git://git.bogomips.org/git-svn
Eric Wong (1):
git svn: branch/tag commands detect username in URLs
Robert Zeh (1):
git svn: add test for a git svn gc followed by a git svn mkdirs
--
Eric Wong
^ permalink raw reply
* git-svn: handling merge-base failures
From: Andrew Myrick @ 2009-12-23 19:54 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Sam Vilain
One of my projects is failing to clone because merge-base is failing on one of the revisions; the branch is a partial branch, so merge-base can't find a common ancestor with trunk. I'd like to catch the exception that command_oneline should throw when merge-base fails, but my perl is very rusty and I'm struggling to get git-svn.perl to grok the Git::Error::Command class. What is the appropriate way to import that class? Or more generally, is there a better solution to handling this error case?
-Andrew
^ permalink raw reply
* Re: [BUG REPORT] git-svn fails to create branches if ssh+svn gets used as protocol.
From: Florian Köberle @ 2009-12-23 19:26 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20091223072500.GB4323@dcvr.yhbt.net>
Hello Eric,
your patch works great. I created successfully a branch on a svn+ssh://
repository using the patched git-svn.
Thank you for the patch and the fast reply. I hope the patch find it's
way into the next release.
Best regards,
Florian
Eric Wong wrote:
> Florian Köberle <florian@fkoeberle.de> wrote:
>
>> Hello
>>
>> I haven't seen a link to a bug tracker so I am sending this bug report
>> to the mailing list, I hope it's okay.
>>
>
> Hi Florian,
>
> The mailing list is the bug tracker here :)
>
>
>> If you try to run
>> $ git svn branch foo
>> in a project using a svn+ssh url, you get the following error log:
>>
>> Copying svn+ssh://example.org/svn/project/trunk at r1000 to
>> svn+ssh://me@example.org/svn/project/branches/foo...
>> Trying to use an unsupported feature: Source and dest appear not to be
>> in the same repository (src: 'svn+ssh://example.org/svn/project/trunk';
>> dst: 'svn+ssh://me@example.org/svn/project/branches/foo') at
>> /home/florian/libexec/git-core/git-svn line 722
>>
>> It fails as the username is missing in the source url. If you modify the
>> git-svn script and add the username it works. The bug can be reproduced
>> with git-svn version 1.6.5.7 (svn 1.5.1).
>>
>
> Thanks for the info, the following patch should help.
>
> I rarely get around to testing against svn+ssh servers myself
> (and they don't appear too common compared to http/https).
>
> Let us know how it goes, thanks!
>
> From b2bc7e330209659c20d02ee0ba3785f9f59fd0b2 Mon Sep 17 00:00:00 2001
> From: Eric Wong <normalperson@yhbt.net>
> Date: Tue, 22 Dec 2009 22:40:18 -0800
> Subject: [PATCH] git svn: branch/tag commands detect username in URLs
>
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
> ---
> git-svn.perl | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index dba0d12..650c9e5 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -663,7 +663,8 @@ sub cmd_branch {
> }
> $head ||= 'HEAD';
>
> - my ($src, $rev, undef, $gs) = working_head_info($head);
> + my (undef, $rev, undef, $gs) = working_head_info($head);
> + my $src = $gs->full_url;
>
> my $remote = Git::SVN::read_all_remotes()->{$gs->{repo_id}};
> my $allglobs = $remote->{ $_tag ? 'tags' : 'branches' };
>
^ permalink raw reply
* Re: Fatal errors on git rm (Operation not permitted)
From: Junio C Hamano @ 2009-12-23 18:33 UTC (permalink / raw)
To: Xiaolong Tang; +Cc: git
In-Reply-To: <m2oclp36zl.wl%xiaolong.snake@gmail.com>
Xiaolong Tang <xiaolong.snake@gmail.com> writes:
> Finally, I decide to remove this package from my laptop repository, but
> end up with the following errors:
>
> git rm -rf git-emacs
> rm 'lib/emacs/lisp/git-emacs'
> fatal: git rm: 'lib/emacs/lisp/git-emacs': Operation not permitted
We don't say "Operation not permitted" ourselves; it is coming from your C
library's strerror(3) when we got EPERM error back. The reason you get
EPERM can vary depending on your platform and what you did to your
directories yourself, but googling for "Operation not permitted" and
randomly reading a few might give you hints.
^ permalink raw reply
* Re: [PATCH RFC 4/4] rebase -i: add --refs option to rewrite heads within branch
From: Junio C Hamano @ 2009-12-23 18:11 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Greg Price, Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <4B31DA96.1050608@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Greg Price venit, vidit, dixit 23.12.2009 08:03:
> ...
>> Huh, that's an interesting idea. I hadn't thought of that. This
>> feature could be nice. But I am not sure what it would look like.
>> How might the user indicate that they want both "side" and "topic" to
>> be rebased? I suppose we could extend the familiar command line
>> git rebase <upstream> [<branch>]
>> to the form
>> git rebase <upstream> [...<branches>...]
>> so that your example would be
>> $ git rebase -i --rewrite-heads master topic side
>> If we choose this approach, it might even be independent of
>> --rewrite-refs, though the implementation would presumably rely on the
>> "ref" command. Was this interface what you were thinking, or do you
>> have another idea?
>
> If I may jump in: I imagine this to be the more common use case, i.e.:
> You have a part of the DAG which you want to rebase, with all kinds of
> refs (branches, tags) pointing to commits in that part of the DAG. If
> you rebase that part of the DAG you typically want some refs rewritten
> (such as the head of the branch you're rebasing) but maybe not others
> (say a release tag or branch). remote refs should never be rebased. So,
> one would need an easy way to specify one ref, all or anything in between...
And warn (or perhaps reject without --force) if the sub-DAG you would
rebase contains an already tagged commit, especially if you are treating
tags as immutable, even the ones you haven't published.
I actually don't think "rebasing side branches while rebasing this branch"
was such a good idea---we have filter-branch for that already ;-).
^ permalink raw reply
* Fatal errors on git rm (Operation not permitted)
From: Xiaolong Tang @ 2009-12-23 18:01 UTC (permalink / raw)
To: git
Hi all,
I am running into a trouble with git commands.
I have a repository in my laptop to keep all system settings.
Specifically, the repository is illustrated as below:
reproot/
.git
.gitignore
`-- lib
`-- emacs
`-- lisp
|-- dictionary
...
|-- git-emacs
| |-- ...
| |-- ...
| |-- ...
..
|-- remember
To ease the updating of these third-party Emacs packages (e.g. dictionary, git-emacs, remember and so on), I prefer to get them via version control commands.
For example, git-emacs is created via this command:
git://github.com/tsgates/git-emacs
This strategy seems to work well when I include (within my laptop repository) those packages which are not managed via git.
On the contrary, the trouble arises from including another git repository.
For example, when I try to clone my laptop repository into my desktop, the package "git-emacs" only shows up as an empty directory in the newly repository.
Then when I go back to my laptop repository, there is nothing I can do.
Finally, I decide to remove this package from my laptop repository, but end up with the following errors:
git rm -rf git-emacs
rm 'lib/emacs/lisp/git-emacs'
fatal: git rm: 'lib/emacs/lisp/git-emacs': Operation not permitted
The similar errors happen with removing remember(another package under git) too.
11:53:37->git rm -rf remember
rm 'lib/emacs/lisp/remember'
fatal: git rm: 'lib/emacs/lisp/remember': Operation not permitted
So, below are my questions:
What is the real cause of such kind of problem?
How could I fix it?
PS: I did not use git submodule command.
Thanks!
Xiaolong
^ permalink raw reply
* Fatal errors on git rm (Operation not permitted)
From: Xiaolong Tang @ 2009-12-23 17:58 UTC (permalink / raw)
To: git
Hi all,
I am running into a trouble with git commands.
I have a repository in my laptop to keep all system settings.
Specifally, the reposiroty is illustrated as below:
reproot/
.git
.gitignore
`-- lib
`-- emacs
`-- lisp
|-- dictionary
...
|-- git-emacs
| |-- ...
| |-- ...
| |-- ...
..
|-- remember
To ease the updating of these third-party eamcs packages (e.g. dictionary, git-emacs, remember and so on), I perfer to get them via version control commands.
For example, git-emacs is created via this command:
git://github.com/tsgates/git-emacs
This strategy seems to work well when I include (within my laptop repository) those packages which are not managed via git.
On the contrary, the trouble arises from including another git repository.
For example, when I try to clone my laptop repository into my desktop, the package "git-emacs" only shows up as an empty directory in the newly repository.
Then when I go back to my laptop repository, there is nothing I can do.
Finally, I decide to remove this package from my laptop repository, but end up with the following errors:
git rm -rf git-emacs
rm 'lib/emacs/lisp/git-emacs'
fatal: git rm: 'lib/emacs/lisp/git-emacs': Operation not permitted
The similar errors happen with remvoing remember(another package under git) too.
11:53:37->git rm -rf remember
rm 'lib/emacs/lisp/remember'
fatal: git rm: 'lib/emacs/lisp/remember': Operation not permitted
So, below are my questions:
What is the real cause of such kind of problem?
How could I fix it?
PS: I did not use git submodule command.
Thanks!
Xiaolong
^ permalink raw reply
* Re: [PATCH RFC 4/4] rebase -i: add --refs option to rewrite heads within branch
From: Greg Price @ 2009-12-23 17:34 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <4B31DA96.1050608@drmicha.warpmail.net>
On Wed, Dec 23, 2009 at 3:53 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> If I may jump in: I imagine this to be the more common use case, i.e.:
> You have a part of the DAG which you want to rebase, with all kinds of
> refs (branches, tags) pointing to commits in that part of the DAG. If
> you rebase that part of the DAG you typically want some refs rewritten
> (such as the head of the branch you're rebasing) but maybe not others
> (say a release tag or branch). remote refs should never be rebased. So,
> one would need an easy way to specify one ref, all or anything in between...
I see the interactive aspect as the backstop that gives the user total
flexibility, whatever command-line interface we choose. So, for
example, a user might find it easiest to pass --rewrite-heads so that
all heads on the given part of the DAG are inserted as "ref" commands
in the appropriate places, and then go through and remove from the
TODO file any exceptions.
But I agree it is worth making convenient shortcuts by which the user
can specify their intention precisely on the command line itself. And
in any case, if we are to satisfy this latter use case we need a way
of specifying a part of the DAG to rebase that is not only ancestors
of a single commit. What do you think of the
"--rewrite-refs=refs/heads/,refs/tags/" and "git rebase -i master
topic side" proposals in my reply to Junio?
Greg
^ permalink raw reply
* Patch which adds syslog support to git-shell
From: Gerhard Gappmeier @ 2009-12-23 17:32 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 717 bytes --]
Hi
I'm not sure if this is the right list, but here is my first GIT patch.
I had a problem with git-shell and wanted to analyze it.
Unfortunately it does not contain any trace capabilities.
So I cloned git and added some basic syslog support.
After that I recognized that the current git version just works ;-)
but the syslog functionality is always a nice thing I think.
So here is the patch.
Merry X-Mas.
--
mit freundlichen Grüßen / best regards
Gerhard Gappmeier
ascolab GmbH - automation system communication laboratory
Tel.: +49 9131 691 123
Fax: +49 9131 691 128
Web: http://www.ascolab.com
GPG Key-Id: 5AAC50C4
GPG Fingerprint: 967A 15F1 2788 164D CCA3 6C46 07CD 6F82 5AAC 50C4
[-- Attachment #1.2: 0001-Added-syslog-functionality-to-git-shell.patch --]
[-- Type: text/x-patch, Size: 6536 bytes --]
From 0683e3a249419620abcf4363086cd53ec34972e8 Mon Sep 17 00:00:00 2001
From: Gerhard Gappmeier <gerhard.gappmeier@ascolab.com>
Date: Wed, 23 Dec 2009 17:19:34 +0100
Subject: [PATCH] Added syslog functionality to git-shell.
---
shell.c | 192 ++++++++++++++++++++++++++++++++++++++-------------------------
1 files changed, 115 insertions(+), 77 deletions(-)
diff --git a/shell.c b/shell.c
index e4864e0..4cdf385 100644
--- a/shell.c
+++ b/shell.c
@@ -1,103 +1,141 @@
+#include <syslog.h>
+#include <errno.h>
#include "cache.h"
#include "quote.h"
#include "exec_cmd.h"
#include "strbuf.h"
+/* Syslog defines */
+#define GIT_SYSLOG_IDENT "git-shell"
+#define GIT_SYSLOG_OPTION 0
+#define GIT_SYSLOG_FACILITY LOG_LOCAL0
+
static int do_generic_cmd(const char *me, char *arg)
{
- const char *my_argv[4];
+ const char *my_argv[4];
+ int ret = 0;
+
+ setup_path();
+ if (!arg || !(arg = sq_dequote(arg))) {
+ syslog(LOG_INFO, "bad argument");
+ die("bad argument");
+ }
+ if (prefixcmp(me, "git-")) {
+ syslog(LOG_INFO, "bad command");
+ die("bad command");
+ }
+
+ my_argv[0] = me + 4;
+ my_argv[1] = arg;
+ my_argv[2] = NULL;
- setup_path();
- if (!arg || !(arg = sq_dequote(arg)))
- die("bad argument");
- if (prefixcmp(me, "git-"))
- die("bad command");
+ syslog(LOG_INFO, "Executing '%s' '%s'.", my_argv[0], my_argv[1]);
- my_argv[0] = me + 4;
- my_argv[1] = arg;
- my_argv[2] = NULL;
+ ret = execv_git_cmd(my_argv);
+ if (ret == -1) {
+ syslog(LOG_ERR, " execv_git_cmd failed: %s\n", strerror(errno));
+ }
- return execv_git_cmd(my_argv);
+ return ret;
}
static int do_cvs_cmd(const char *me, char *arg)
{
- const char *cvsserver_argv[3] = {
- "cvsserver", "server", NULL
- };
+ const char *cvsserver_argv[3] = {
+ "cvsserver", "server", NULL
+ };
+ int ret = 0;
+
+ if (!arg || strcmp(arg, "server")) {
+ syslog(LOG_INFO, "git-cvsserver only handles server: %s", arg);
+ die("git-cvsserver only handles server: %s", arg);
+ }
+
+ setup_path();
- if (!arg || strcmp(arg, "server"))
- die("git-cvsserver only handles server: %s", arg);
+ syslog(LOG_INFO, "Executing '%s' '%s'.", cvsserver_argv[0], cvsserver_argv[1]);
- setup_path();
- return execv_git_cmd(cvsserver_argv);
+ ret = execv_git_cmd(cvsserver_argv);
+ if (ret == -1) {
+ syslog(LOG_ERR, " execv_git_cmd failed: %s\n", strerror(errno));
+ }
+
+ return ret;
}
static struct commands {
- const char *name;
- int (*exec)(const char *me, char *arg);
+ const char *name;
+ int (*exec)(const char *me, char *arg);
} cmd_list[] = {
- { "git-receive-pack", do_generic_cmd },
- { "git-upload-pack", do_generic_cmd },
- { "git-upload-archive", do_generic_cmd },
- { "cvs", do_cvs_cmd },
- { NULL },
+ { "git-receive-pack", do_generic_cmd },
+ { "git-upload-pack", do_generic_cmd },
+ { "git-upload-archive", do_generic_cmd },
+ { "cvs", do_cvs_cmd },
+ { NULL },
};
int main(int argc, char **argv)
{
- char *prog;
- struct commands *cmd;
- int devnull_fd;
-
- /*
- * Always open file descriptors 0/1/2 to avoid clobbering files
- * in die(). It also avoids not messing up when the pipes are
- * dup'ed onto stdin/stdout/stderr in the child processes we spawn.
- */
- devnull_fd = open("/dev/null", O_RDWR);
- while (devnull_fd >= 0 && devnull_fd <= 2)
- devnull_fd = dup(devnull_fd);
- if (devnull_fd == -1)
- die_errno("opening /dev/null failed");
- close (devnull_fd);
-
- /*
- * Special hack to pretend to be a CVS server
- */
- if (argc == 2 && !strcmp(argv[1], "cvs server"))
- argv--;
-
- /*
- * We do not accept anything but "-c" followed by "cmd arg",
- * where "cmd" is a very limited subset of git commands.
- */
- else if (argc != 3 || strcmp(argv[1], "-c"))
- die("What do you think I am? A shell?");
-
- prog = argv[2];
- if (!strncmp(prog, "git", 3) && isspace(prog[3]))
- /* Accept "git foo" as if the caller said "git-foo". */
- prog[3] = '-';
-
- for (cmd = cmd_list ; cmd->name ; cmd++) {
- int len = strlen(cmd->name);
- char *arg;
- if (strncmp(cmd->name, prog, len))
- continue;
- arg = NULL;
- switch (prog[len]) {
- case '\0':
- arg = NULL;
- break;
- case ' ':
- arg = prog + len + 1;
- break;
- default:
- continue;
- }
- exit(cmd->exec(cmd->name, arg));
- }
- die("unrecognized command '%s'", prog);
+ char *prog;
+ struct commands *cmd;
+ int devnull_fd;
+
+ /* Open syslog. */
+ openlog(GIT_SYSLOG_IDENT, GIT_SYSLOG_OPTION, GIT_SYSLOG_FACILITY);
+
+ /*
+ * Always open file descriptors 0/1/2 to avoid clobbering files
+ * in die(). It also avoids not messing up when the pipes are
+ * dup'ed onto stdin/stdout/stderr in the child processes we spawn.
+ */
+ devnull_fd = open("/dev/null", O_RDWR);
+ while (devnull_fd >= 0 && devnull_fd <= 2)
+ devnull_fd = dup(devnull_fd);
+ if (devnull_fd == -1)
+ die_errno("opening /dev/null failed");
+ close (devnull_fd);
+
+ /*
+ * Special hack to pretend to be a CVS server
+ */
+ if (argc == 2 && !strcmp(argv[1], "cvs server"))
+ argv--;
+
+ /*
+ * We do not accept anything but "-c" followed by "cmd arg",
+ * where "cmd" is a very limited subset of git commands.
+ */
+ else if (argc != 3 || strcmp(argv[1], "-c")) {
+ syslog(LOG_WARNING, "Invalid parameter '%s'", argv[1]);
+ die("What do you think I am? A shell?");
+ }
+
+ prog = argv[2];
+ if (!strncmp(prog, "git", 3) && isspace(prog[3]))
+ /* Accept "git foo" as if the caller said "git-foo". */
+ prog[3] = '-';
+
+ for (cmd = cmd_list ; cmd->name ; cmd++) {
+ int len = strlen(cmd->name);
+ char *arg;
+ if (strncmp(cmd->name, prog, len))
+ continue;
+ arg = NULL;
+ switch (prog[len]) {
+ case '\0':
+ arg = NULL;
+ break;
+ case ' ':
+ arg = prog + len + 1;
+ break;
+ default:
+ continue;
+ }
+ exit(cmd->exec(cmd->name, arg));
+ }
+
+ syslog(LOG_WARNING, "Somebody tried to execute an unallowed command '%s'", prog);
+ die("unrecognized command '%s'", prog);
}
+
--
1.6.4.4
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: git tag --contains <commit> -n=1 ?
From: Andreas Schwab @ 2009-12-23 17:19 UTC (permalink / raw)
To: NODA, Kai; +Cc: git
In-Reply-To: <4B324327.5010809@gmail.com>
"NODA, Kai" <nodakai@gmail.com> writes:
> Here I wonder whether "head -1" is generally correct or not when I want
> the oldest tag.
Since the output of git tag is sorted by name, generally not.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* git tag --contains <commit> -n=1 ?
From: NODA, Kai @ 2009-12-23 16:19 UTC (permalink / raw)
To: git
Hi,
I'm thinking how to find the oldest tag containing a specified commit.
Eg.
$ cd /usr/src/linux-linus/Documentation
$ for i in *.txt; do
for> echo $i
for> hash=`git log -1 --format=format:%H -- $i`
for> git tag --contains $hash -l 'v2.6.[0-9][0-9]'|head -1
for> done
DMA-API.txt
v2.6.31
DMA-ISA-LPC.txt
v2.6.20
DMA-attributes.txt
v2.6.27
...
Here I wonder whether "head -1" is generally correct or not when I want
the oldest tag.
Moreover, as "git tag --contains ..." takes considerable time, I will
be happy if I can set the maximum number in searching tags containing
a commit. Or are there already some (better) ways to achieve this?
Any advice is welcome.
Thanks,
Kai
^ permalink raw reply
* Re: Atomicity of git-push operation.
From: Shawn O. Pearce @ 2009-12-23 15:25 UTC (permalink / raw)
To: Jan Zalcman; +Cc: git
In-Reply-To: <4B32044A.7010601@9livesdata.com>
Jan Zalcman <zalcman@9livesdata.com> wrote:
> I have a simple question about "push" operation but I couldn't find an
> answer: is git-push (also with --tags flag) atomic ? Especially: if refs
> changing (during push) is atomic ?
Yes, its atomic, at the per-ref level.
If you push 3 refs, and one of them updates during the push, the
other two will push successfully, but the one that was updated will
be rejected.
--
Shawn.
^ permalink raw reply
* Re: [PATCH RFC 4/4] rebase -i: add --refs option to rewrite heads within branch
From: Johannes Schindelin @ 2009-12-23 13:28 UTC (permalink / raw)
To: Greg Price; +Cc: Junio C Hamano, git
In-Reply-To: <1ac2d430912222303k6180baa6j291bb4d18c7a4968@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 966 bytes --]
Hi,
On Wed, 23 Dec 2009, Greg Price wrote:
> On Tue, Dec 22, 2009 at 6:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> > - This seems to rewrite only branch heads; don't you want to allow
> > users to rewrite lightweight tags and possibly annotated ones as
> > well, by perhaps giving "--rewrite-refs=refs/heads/" or
> > "--rewrite-refs=refs/" to limit what parts of the ref namespace to
> > consider rewriting?
>
> Sure. I specifically left out tags because I generally think of a tag
> as something immutable that it would not make sense to rewrite.
I do agree: if you plan to rewrite a ref, you _should_ make it a branch
anyway.
A tag is not meant to be updated easily, in fact, we explicitely lack
tools to do so (and it is quite hard to get updated tags from a repository
where the tags changed anyway). So rewriting tags is something that
causes only trouble.
Why should rebase -i cause that trouble all of a sudden?
Ciao,
Dscho
^ permalink raw reply
* Atomicity of git-push operation.
From: Jan Zalcman @ 2009-12-23 11:51 UTC (permalink / raw)
To: git
Hi,
I have a simple question about "push" operation but I couldn't find an
answer: is git-push (also with --tags flag) atomic ? Especially: if refs
changing (during push) is atomic ?
Thanks,
Janek
^ permalink raw reply
* [PATCH] git-gui: handle really long error messages in updateindex.
From: Pat Thoyts @ 2009-12-20 2:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, msysgit
As reported to msysGit (bug #340) it is possible to get some very long
error messages when updating the index. The use of a label to display
this prevents scrolling the output. This patch replaces the label with
a scrollable text widget configured to look like a label.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
---
lib/index.tcl | 34 ++++++++++++++++++----------------
1 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/lib/index.tcl b/lib/index.tcl
index d33896a..0b58bd8 100644
--- a/lib/index.tcl
+++ b/lib/index.tcl
@@ -14,29 +14,31 @@ proc _close_updateindex {fd after} {
toplevel $w
wm title $w [strcat "[appname] ([reponame]): " [mc "Index Error"]]
wm geometry $w "+[winfo rootx .]+[winfo rooty .]"
- pack [label $w.msg \
- -justify left \
- -anchor w \
- -text [strcat \
- [mc "Updating the Git index failed. A rescan will be automatically started to resynchronize git-gui."] \
- "\n\n$err"] \
- ] -anchor w
-
- frame $w.buttons
- button $w.buttons.continue \
+ set s [mc "Updating the Git index failed. A rescan will be automatically started to resynchronize git-gui."]
+ text $w.msg -yscrollcommand [list $w.vs set] \
+ -width [string length $s] -relief flat \
+ -borderwidth 0 -highlightthickness 0 \
+ -background [$w cget -background]
+ $w.msg tag configure bold -font font_uibold -justify center
+ scrollbar $w.vs -command [list $w.msg yview]
+ $w.msg insert end $s bold \n\n$err {}
+ $w.msg configure -state disabled
+
+ button $w.continue \
-text [mc "Continue"] \
-command [list destroy $w]
- pack $w.buttons.continue -side right -padx 5
- button $w.buttons.unlock \
+ button $w.unlock \
-text [mc "Unlock Index"] \
-command "destroy $w; _delete_indexlock"
- pack $w.buttons.unlock -side right
- pack $w.buttons -side bottom -fill x -pady 10 -padx 10
+ grid $w.msg - $w.vs -sticky news
+ grid $w.unlock $w.continue - -sticky se -padx 2 -pady 2
+ grid columnconfigure $w 0 -weight 1
+ grid rowconfigure $w 0 -weight 1
wm protocol $w WM_DELETE_WINDOW update
- bind $w.buttons.continue <Visibility> "
+ bind $w.continue <Visibility> "
grab $w
- focus $w.buttons.continue
+ focus %W
"
tkwait window $w
--
1.6.2
^ permalink raw reply related
* Re: [PATCH RFC 4/4] rebase -i: add --refs option to rewrite heads within branch
From: Michael J Gruber @ 2009-12-23 8:53 UTC (permalink / raw)
To: Greg Price; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <1ac2d430912222303k6180baa6j291bb4d18c7a4968@mail.gmail.com>
Greg Price venit, vidit, dixit 23.12.2009 08:03:
> On Tue, Dec 22, 2009 at 6:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> - As decoration is a fairly expensive operation (which is the reason why
>> loading_ref_decorations() is called lazily by format_decoration() in
>> the first place, especially in repositories with tons of refs), you
>> shouldn't give --format=%D to rev-list when the new feature is not
>> asked for.
>
> OK, will do.
>
>
>> - This seems to rewrite only branch heads; don't you want to allow users
>> to rewrite lightweight tags and possibly annotated ones as well, by
>> perhaps giving "--rewrite-refs=refs/heads/" or "--rewrite-refs=refs/"
>> to limit what parts of the ref namespace to consider rewriting?
>
> Sure. I specifically left out tags because I generally think of a tag
> as something immutable that it would not make sense to rewrite. But
> people use Git in different ways and it makes sense to give the option
> of rewriting tags as well as heads.
>
> I do worry that passing --rewrite-refs=refs/ will set up remote refs
> for rewriting, which is likely to be confusing if the user does not
> notice them and remove them from the TODO. Perhaps it makes sense to
> accept forms like "--rewrite-refs=refs/heads/,refs/tags/" or
> "--rewrite-refs=refs/heads/ --rewrite-refs=refs/tags/". Is there a
> Git convention for accepting a sequence of arguments like this to an
> option -- one of these, or something else?
>
>
>> On the other hand, if the "partN" markers in your example workflow are
>> primarily meant to be used to mark places on a branch (as opposed to
>> arbitrary branch tips that independent development starting from them can
>> further continue), it would make a lot more sense to use lightweight or
>> annotated tags for them, and instead of "--refs" that rewrites only other
>> branch tips, it might make a lot more sense to have "--rewrite-tags" that
>> rewrites tags that point at the commits that are rewritten, without
>> touching any branch tip.
>
> I think of them as a topic branch developing one feature, then another
> branch developing a related follow-on feature, etc. I would also feel
> odd rewriting tags as a routine operation, or calling a ref a tag when
> I expect to rewrite it. So I do think they're best recorded as branch
> tips rather than tags.
>
>
>> Obviously the series also needs tests.
>
> Yes.
>
>
>> I also have to wonder if this feature should also handle a case like this:
>>
>> side
>> |
>> V
>> *
>> /
>> part1 * topic
>> | / |
>> v / v
>> A--*--*--*--*--*--*
>> \
>> B <--master
>>
>> ===>
>>
>> side
>> |
>> V
>> *
>> /
>> part1 * topic
>> A | / |
>> \ v / v
>> B--*--*--*--*--*--*
>> ^ [
>> |
>> master
>>
>> especially if it were to be specific to branch management.
>
> Huh, that's an interesting idea. I hadn't thought of that. This
> feature could be nice. But I am not sure what it would look like.
> How might the user indicate that they want both "side" and "topic" to
> be rebased? I suppose we could extend the familiar command line
> git rebase <upstream> [<branch>]
> to the form
> git rebase <upstream> [...<branches>...]
> so that your example would be
> $ git rebase -i --rewrite-heads master topic side
> If we choose this approach, it might even be independent of
> --rewrite-refs, though the implementation would presumably rely on the
> "ref" command. Was this interface what you were thinking, or do you
> have another idea?
>
> Greg
If I may jump in: I imagine this to be the more common use case, i.e.:
You have a part of the DAG which you want to rebase, with all kinds of
refs (branches, tags) pointing to commits in that part of the DAG. If
you rebase that part of the DAG you typically want some refs rewritten
(such as the head of the branch you're rebasing) but maybe not others
(say a release tag or branch). remote refs should never be rebased. So,
one would need an easy way to specify one ref, all or anything in between...
Michael
^ permalink raw reply
* Re: [BUG REPORT] git-svn fails to create branches if ssh+svn gets used as protocol.
From: Eric Wong @ 2009-12-23 7:25 UTC (permalink / raw)
To: Florian Köberle; +Cc: git
In-Reply-To: <4B309730.5070509@fkoeberle.de>
Florian Köberle <florian@fkoeberle.de> wrote:
> Hello
>
> I haven't seen a link to a bug tracker so I am sending this bug report
> to the mailing list, I hope it's okay.
Hi Florian,
The mailing list is the bug tracker here :)
> If you try to run
> $ git svn branch foo
> in a project using a svn+ssh url, you get the following error log:
>
> Copying svn+ssh://example.org/svn/project/trunk at r1000 to
> svn+ssh://me@example.org/svn/project/branches/foo...
> Trying to use an unsupported feature: Source and dest appear not to be
> in the same repository (src: 'svn+ssh://example.org/svn/project/trunk';
> dst: 'svn+ssh://me@example.org/svn/project/branches/foo') at
> /home/florian/libexec/git-core/git-svn line 722
>
> It fails as the username is missing in the source url. If you modify the
> git-svn script and add the username it works. The bug can be reproduced
> with git-svn version 1.6.5.7 (svn 1.5.1).
Thanks for the info, the following patch should help.
I rarely get around to testing against svn+ssh servers myself
(and they don't appear too common compared to http/https).
Let us know how it goes, thanks!
From b2bc7e330209659c20d02ee0ba3785f9f59fd0b2 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Tue, 22 Dec 2009 22:40:18 -0800
Subject: [PATCH] git svn: branch/tag commands detect username in URLs
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index dba0d12..650c9e5 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -663,7 +663,8 @@ sub cmd_branch {
}
$head ||= 'HEAD';
- my ($src, $rev, undef, $gs) = working_head_info($head);
+ my (undef, $rev, undef, $gs) = working_head_info($head);
+ my $src = $gs->full_url;
my $remote = Git::SVN::read_all_remotes()->{$gs->{repo_id}};
my $allglobs = $remote->{ $_tag ? 'tags' : 'branches' };
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH RFC 4/4] rebase -i: add --refs option to rewrite heads within branch
From: Greg Price @ 2009-12-23 7:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vzl5awpf1.fsf@alter.siamese.dyndns.org>
On Tue, Dec 22, 2009 at 6:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
> - As decoration is a fairly expensive operation (which is the reason why
> loading_ref_decorations() is called lazily by format_decoration() in
> the first place, especially in repositories with tons of refs), you
> shouldn't give --format=%D to rev-list when the new feature is not
> asked for.
OK, will do.
> - This seems to rewrite only branch heads; don't you want to allow users
> to rewrite lightweight tags and possibly annotated ones as well, by
> perhaps giving "--rewrite-refs=refs/heads/" or "--rewrite-refs=refs/"
> to limit what parts of the ref namespace to consider rewriting?
Sure. I specifically left out tags because I generally think of a tag
as something immutable that it would not make sense to rewrite. But
people use Git in different ways and it makes sense to give the option
of rewriting tags as well as heads.
I do worry that passing --rewrite-refs=refs/ will set up remote refs
for rewriting, which is likely to be confusing if the user does not
notice them and remove them from the TODO. Perhaps it makes sense to
accept forms like "--rewrite-refs=refs/heads/,refs/tags/" or
"--rewrite-refs=refs/heads/ --rewrite-refs=refs/tags/". Is there a
Git convention for accepting a sequence of arguments like this to an
option -- one of these, or something else?
> On the other hand, if the "partN" markers in your example workflow are
> primarily meant to be used to mark places on a branch (as opposed to
> arbitrary branch tips that independent development starting from them can
> further continue), it would make a lot more sense to use lightweight or
> annotated tags for them, and instead of "--refs" that rewrites only other
> branch tips, it might make a lot more sense to have "--rewrite-tags" that
> rewrites tags that point at the commits that are rewritten, without
> touching any branch tip.
I think of them as a topic branch developing one feature, then another
branch developing a related follow-on feature, etc. I would also feel
odd rewriting tags as a routine operation, or calling a ref a tag when
I expect to rewrite it. So I do think they're best recorded as branch
tips rather than tags.
> Obviously the series also needs tests.
Yes.
> I also have to wonder if this feature should also handle a case like this:
>
> side
> |
> V
> *
> /
> part1 * topic
> | / |
> v / v
> A--*--*--*--*--*--*
> \
> B <--master
>
> ===>
>
> side
> |
> V
> *
> /
> part1 * topic
> A | / |
> \ v / v
> B--*--*--*--*--*--*
> ^ [
> |
> master
>
> especially if it were to be specific to branch management.
Huh, that's an interesting idea. I hadn't thought of that. This
feature could be nice. But I am not sure what it would look like.
How might the user indicate that they want both "side" and "topic" to
be rebased? I suppose we could extend the familiar command line
git rebase <upstream> [<branch>]
to the form
git rebase <upstream> [...<branches>...]
so that your example would be
$ git rebase -i --rewrite-heads master topic side
If we choose this approach, it might even be independent of
--rewrite-refs, though the implementation would presumably rely on the
"ref" command. Was this interface what you were thinking, or do you
have another idea?
Greg
^ permalink raw reply
* Re: [PATCH] git svn: add (failing) test for a git svn gc followed by a git svn mkdirs
From: Eric Wong @ 2009-12-23 6:18 UTC (permalink / raw)
To: Robert Zeh; +Cc: git
In-Reply-To: <57d579150912222008j19b16b1aq88ebd0938c2553e9@mail.gmail.com>
Robert Zeh <robert.a.zeh@gmail.com> wrote:
> git svn gc will compress the unhandled.log files that git svn mkdirs reads,
> causing git svn mkdirs to skip directory creation.
> ---
> t/t9152-svn-empty-dirs-after-gc.sh | 41 ++++++++++++++++++++++++++++++++++++
> 1 files changed, 41 insertions(+), 0 deletions(-)
> create mode 100755 t/t9152-svn-empty-dirs-after-gc.sh
Hi Robert,
I actually got impatient over the weekend and committed a test case and
fix. I believe I Cc-ed you on it... But your test case might be
cleaner, but yes, same things Junio said.
--
Eric Wong
^ permalink raw reply
* [RFC PATCH 2/2] git-difftool: Add '--gui' for selecting a GUI tool
From: David Aguilar @ 2009-12-23 5:27 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <1261546034-7780-1-git-send-email-davvid@gmail.com>
Users might prefer to have git-difftool use a different
tool when run from a Git GUI.
This teaches git-difftool to honor 'diff.guitool' when
the '--gui' option is specified. This allows users to
configure their preferred command-line diff tool in
'diff.tool' and a GUI diff tool in 'diff.guitool'.
Reference: http://article.gmane.org/gmane.comp.version-control.git/133386
Signed-off-by: David Aguilar <davvid@gmail.com>
---
This is an RFC patch for a number of reasons.
* We're in RC freeze
* This introduces a new 'diff.guitool' variable.
I don't know if the name of the variable is desirable as-is.
So, I figured it's best to mark it as an RFC for now.
Documentation/git-difftool.txt | 9 +++++++++
git-difftool.perl | 13 ++++++++++++-
t/t7800-difftool.sh | 12 ++++++++++++
3 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 8e9aed6..a5bce62 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -58,6 +58,12 @@ is set to the name of the temporary file containing the contents
of the diff post-image. `$BASE` is provided for compatibility
with custom merge tool commands and has the same value as `$LOCAL`.
+-g::
+--gui::
+ When 'git-difftool' is invoked with the `-g` or `--gui` option
+ the default diff tool will be read from the configured
+ `diff.guitool` variable instead of `diff.tool`.
+
See linkgit:git-diff[1] for the full list of supported options.
CONFIG VARIABLES
@@ -68,6 +74,9 @@ difftool equivalents have not been defined.
diff.tool::
The default diff tool to use.
+diff.guitool::
+ The default diff tool to use when `--gui` is specified.
+
difftool.<tool>.path::
Override the path for the given tool. This is useful in case
your tool is not in the PATH.
diff --git a/git-difftool.perl b/git-difftool.perl
index ba5e60a..8c836e4 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -15,13 +15,16 @@ use warnings;
use Cwd qw(abs_path);
use File::Basename qw(dirname);
+require Git;
+
my $DIR = abs_path(dirname($0));
sub usage
{
print << 'USAGE';
-usage: git difftool [--tool=<tool>] [-y|--no-prompt] ["git diff" options]
+usage: git difftool [-g|--gui] [-t|--tool=<tool>] [-y|--no-prompt]
+ ["git diff" options]
USAGE
exit 1;
}
@@ -63,6 +66,14 @@ sub generate_command
$ENV{GIT_DIFF_TOOL} = substr($arg, 7);
next;
}
+ if ($arg eq '-g' || $arg eq '--gui') {
+ my $tool = Git::command_oneline('config',
+ 'diff.guitool');
+ if (length($tool)) {
+ $ENV{GIT_DIFF_TOOL} = $tool;
+ }
+ next;
+ }
if ($arg eq '-y' || $arg eq '--no-prompt') {
$ENV{GIT_DIFFTOOL_NO_PROMPT} = 'true';
delete $ENV{GIT_DIFFTOOL_PROMPT};
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index 707a0f5..9bf6c98 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -19,6 +19,7 @@ remove_config_vars()
{
# Unset all config variables used by git-difftool
git config --unset diff.tool
+ git config --unset diff.guitool
git config --unset difftool.test-tool.cmd
git config --unset difftool.prompt
git config --unset merge.tool
@@ -77,6 +78,17 @@ test_expect_success 'difftool ignores bad --tool values' '
test "$diff" = ""
'
+test_expect_success 'difftool honors --gui' '
+ git config merge.tool bogus-tool &&
+ git config diff.tool bogus-tool &&
+ git config diff.guitool test-tool &&
+
+ diff=$(git difftool --no-prompt --gui branch) &&
+ test "$diff" = "branch" &&
+
+ restore_test_defaults
+'
+
# Specify the diff tool using $GIT_DIFF_TOOL
test_expect_success 'GIT_DIFF_TOOL variable' '
git config --unset diff.tool
--
1.6.2.5
^ permalink raw reply related
* [PATCH 1/2] t7800-difftool: Set a bogus tool for use by tests
From: David Aguilar @ 2009-12-23 5:27 UTC (permalink / raw)
To: git; +Cc: gitster
If a difftool test has an error then running the git test suite
may end up invoking a GUI diff tool. We now guard against this
by setting a difftool.bogus-tool.cmd variable.
The tests already used --tool=bogus-tool in various places so
this is simply ensuring that nothing ever falls back and
finds a real diff tool.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
t/t7800-difftool.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index fff6a6d..707a0f5 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -36,6 +36,7 @@ restore_test_defaults()
unset GIT_DIFFTOOL_NO_PROMPT
git config diff.tool test-tool &&
git config difftool.test-tool.cmd 'cat $LOCAL'
+ git config difftool.bogus-tool.cmd false
}
prompt_given()
@@ -71,7 +72,7 @@ test_expect_success 'custom commands' '
# Ensures that git-difftool ignores bogus --tool values
test_expect_success 'difftool ignores bad --tool values' '
- diff=$(git difftool --no-prompt --tool=bogus-tool branch)
+ diff=$(git difftool --no-prompt --tool=bad-tool branch)
test "$?" = 1 &&
test "$diff" = ""
'
--
1.6.2.5
^ 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