* Re: fatal: git grep: cannot generate relative filenames containing '..'
From: Junio C Hamano @ 2009-01-16 2:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: George Spelvin, git
In-Reply-To: <alpine.DEB.1.00.0901160307290.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 15 Jan 2009, George Spelvin wrote:
>
>> Could someone fix this some day?
>
> Yes, someone could.
Or perhaps someone did more than two years ago with --full-name?
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Johannes Schindelin @ 2009-01-16 2:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vmydsovs5.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 15 Jan 2009, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> >> That is, it links to marc (not gmane?) but finds no matches...
> >
> > what mailing list post should it point to?
I found gmane to be much nicer to click through than marc.
> I think Dscho's point is that you shouldn't be generating these links
> that lead to nowhere ;-).
Almost.
I wondered what the point was, and I would _welcome_ links that pointed to
the mails containing the patches (identified either by patch ids or by
manual editing; best would be to have both methods at the same time).
Ciao,
Dscho
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Petr Baudis @ 2009-01-16 2:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901160315170.3586@pacific.mpi-cbg.de>
On Fri, Jan 16, 2009 at 03:17:14AM +0100, Johannes Schindelin wrote:
> On Thu, 15 Jan 2009, Junio C Hamano wrote:
>
> > Petr Baudis <pasky@suse.cz> writes:
> >
> > >> That is, it links to marc (not gmane?) but finds no matches...
> > >
> > > what mailing list post should it point to?
>
> I found gmane to be much nicer to click through than marc.
IIRC I found no way to actually make a gmane link since it requires POST
query for the searches or something.
> > I think Dscho's point is that you shouldn't be generating these links
> > that lead to nowhere ;-).
>
> Almost.
>
> I wondered what the point was, and I would _welcome_ links that pointed to
> the mails containing the patches (identified either by patch ids or by
> manual editing; best would be to have both methods at the same time).
Well, but you already have that, or at least an approximation. Do you
think the approximation is inadequate? I would expect linking to a
commit showing the inadequacy - I don't see how a false positive is
inadequate at all, actually; even if we had a separate database with the
mapping, for no records I think falling back to linking to a mailing
list search still makes more sense than showing no link.
I was not actually planning to carry the patch over the next gitweb
update since I got no feedback on it (IIRC) since I implemented it.
--
Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Jacob Helwig @ 2009-01-16 2:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20090116022408.GG12275@machine.or.cz>
On Thu, Jan 15, 2009 at 18:24, Petr Baudis <pasky@suse.cz> wrote:
>
> IIRC I found no way to actually make a gmane link since it requires POST
> query for the searches or something.
>
$ cat bin/gmane-links.pl
#!/usr/bin/perl
use strict;
use warnings;
use Mail::Summary::Tools::ArchiveLink::Gmane;
unless ($ARGV[0]) {
print STDERR "Must provide a message-id.\n";
exit 1;
}
my $link = Mail::Summary::Tools::ArchiveLink::Gmane->new(message_id =>
$ARGV[0]);
print "Thread: " . $link->thread_uri() . "\n";
print "Message: " . $link->message_uri() . "\n";
^ permalink raw reply
* How to exclude some files when using git-archive?
From: Ping Yin @ 2009-01-16 2:40 UTC (permalink / raw)
To: Git Mailing List
I want to exclude .gitignore from the archive, but hasn't find a easy way
Ping Yin
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Junio C Hamano @ 2009-01-16 2:41 UTC (permalink / raw)
To: Jacob Helwig; +Cc: Petr Baudis, Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <8c9a060901151832l71464185qf9f88afede6f550d@mail.gmail.com>
"Jacob Helwig" <jacob.helwig@gmail.com> writes:
> On Thu, Jan 15, 2009 at 18:24, Petr Baudis <pasky@suse.cz> wrote:
>>
>> IIRC I found no way to actually make a gmane link since it requires POST
>> query for the searches or something.
>>
>
> $ cat bin/gmane-links.pl
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> use Mail::Summary::Tools::ArchiveLink::Gmane;
>
> unless ($ARGV[0]) {
> print STDERR "Must provide a message-id.\n";
> exit 1;
> }
>
> my $link = Mail::Summary::Tools::ArchiveLink::Gmane->new(message_id =>
> $ARGV[0]);
>
> print "Thread: " . $link->thread_uri() . "\n";
> print "Message: " . $link->message_uri() . "\n";
Not quite, if message_id means what I think it means.
Pasky searches for the title of the message, and he does not have the
Message-ID header of the original message.
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Junio C Hamano @ 2009-01-16 2:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, git
In-Reply-To: <20090116022408.GG12275@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I was not actually planning to carry the patch over the next gitweb
> update since I got no feedback on it (IIRC) since I implemented it.
Heh, now you got it.
And I do not think you advertised it since you implemented it, so no
feedback does not necessarily mean no interest. FWIW, I think looking for
a message that has similar words in the mail archive is a nifty feature to
have.
^ permalink raw reply
* Re: How to exclude some files when using git-archive?
From: Junio C Hamano @ 2009-01-16 2:44 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320901151840l18257501x62a3fa1fe9701dc@mail.gmail.com>
Ping Yin <pkufranky@gmail.com> writes:
> I want to exclude .gitignore from the archive, but hasn't find a easy way
>
> Ping Yin
"man gitattributes", then look for export-ignore?
^ permalink raw reply
* Re: [PATCH 3/3] implement pattern matching in ce_path_match
From: Junio C Hamano @ 2009-01-16 2:51 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, johannes
In-Reply-To: <7vljtd20m6.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Clemens Buchacher <drizzd@aon.at> writes:
>
>> With this patch ce_path_match uses match_pathspec in order to perform
>> pattern matching.
>
> We have two conflicting definitions of pattern matching in our system.
> I'd make it more explicit which kind of pattern matching you are talking
> about here.
>
> The family of operations based on the diff-tree machinery (e.g. path
> limited revision walking "git log A..B -- dir1/dir2") define the pattern
> matching as "leading path match (exact match is just a special case of
> this)". Other operations that work on paths in the work tree and the
> index (e.g. grep, ls-files) uses "leading path match, but fall back to
> globbing".
>
> In the longer term we really should unify them by teaching the former to
> fall back to globbing without getting undue performance hit, and this
> patch may be a step in the right direction. There are optimizations that
> assume the "leading path" semantics to trim the input early and avoid
> opening and descending into a tree object if pathspec patterns cannot
> possibly match (see tree-diff.c::tree_entry_interesting() for an example),
> and we need to teach them to notice a glob wildcard in an earlier part of
> a pathspec and to descend into some trees that they would have skipped
> with the old definition of pathspec.
Actually there was an earlier attempt that resulted in the pathspec
matching tree traverser builtin-grep uses. Even though it has to work
with trees (when grepping inside a tree-ish) and has optimizations not to
open unnecessary subtrees similar to the one the diff-tree machinery has,
it also knows how to handle globs. If we were to pick one of existing
implementations for the longer term unification, I think that is probably
the one we should build on top of.
^ permalink raw reply
* Re: fatal: git grep: cannot generate relative filenames containing '..'
From: George Spelvin @ 2009-01-16 3:27 UTC (permalink / raw)
To: Johannes.Schindelin, gitster; +Cc: linux, git
In-Reply-To: <7vhc40ov78.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Or perhaps someone did more than two years ago with --full-name?
Thank you for pointing that out! It's a bit of a handful to type,
but at least it makes what I want to do possible without having to
write a wrapper script. And I can reduce the typing with an alias.
I'm still trying to figure out why the basic form doesn't work,
though. Is there something more subtle than that fact that the
filename simplification in grep_sha1 and grep_file might do the
wrong thing? If I comment out the check in cmd_grep(), it seems
to work, although it prints out some funky filenames.
That seems like a straightforward thing to fix. Basically, strip
off the common part of the prefix and name, and for every remaining
component in the prefix, prepend a ../ to the name.
I don't mind doing the coding, but can someone who groks the
code more fully tell me if I'm missing something major?
^ permalink raw reply
* how to edit commit message in history
From: bill lam @ 2009-01-16 3:57 UTC (permalink / raw)
To: git
I made some typos in commit messages, how to edit them without
affecting everything else?
Thanks in advance.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩311 無名氏 雜詩
盡寒食雨草萋萋 著麥苗風柳映堤 等是有家歸未得 杜鵑休向耳邊啼
^ permalink raw reply
* Re: how to edit commit message in history
From: Jike Song @ 2009-01-16 4:09 UTC (permalink / raw)
To: git
In-Reply-To: <20090116035714.GA6984@b2j>
On Fri, Jan 16, 2009 at 11:57 AM, bill lam <cbill.lam@gmail.com> wrote:
> I made some typos in commit messages, how to edit them without
> affecting everything else?
>
> Thanks in advance.
say, it's commit HEAD~2 to be revised.
git rebase -i HEAD~3
In your editor, you all see something like this:
pick db79377 2nd
pick fa9ced8 3rd
pick b842e49 4nd
# Rebase 1423d77..b842e49 onto 1423d77
#
# Commands:
# p, pick = use commit
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
Now change "pick" to "edit" with your typo commit, save it and exit.
You will see something like this:
$ git-rebase -i HEAD~3
Stopped at db79377... 2nd
You can amend the commit now, with
git commit --amend
Once you are satisfied with your changes, run
git rebase --continue
Just follow the instructions.
--
Thanks,
Jike
^ permalink raw reply
* Re: fatal: git grep: cannot generate relative filenames containing '..'
From: George Spelvin @ 2009-01-16 4:24 UTC (permalink / raw)
To: Johannes.Schindelin, gitster; +Cc: linux, git
In-Reply-To: <20090116032708.21156.qmail@science.horizon.com>
> I don't mind doing the coding, but can someone who groks the
> code more fully tell me if I'm missing something major?
Here's a first draft, that Works For Me(tm). Does anyone see anything
broken about it?
(This code released into the public domain, copyright abandoned. You may
do anything you like with it, including evil things, as long as you
don't bother me asking for additional permissions.)
diff --git a/builtin-grep.c b/builtin-grep.c
index bebf15c..5727a8b 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -90,12 +90,74 @@ static int pathspec_matches(const char **paths, const char *name)
return 0;
}
+/*
+ * Write a filename like "/usr/src/linux/include/linux/zlib.h" as
+ * a path relative to some prefix like "/usr/src/linux/kernel/"
+ * (The prefix always includes a trailing slash.)
+ * label_len, if non-zero, describes a leading portion on the name
+ * (typically of the form "HEAD^^:") which should not be stripped off.
+ *
+ * The result is in one of three places:
+ * - It may be a pointer into the supplied name in the simplest case,
+ * - It may be returned in a static buffer if it is of reaonable size, or
+ * - It may be in a malloced buffer if it is large.
+ * A pointer to be passed to free() is returned in *to_free, which
+ * is set to NULL if the return value is not to be freed, or is equal
+ * to the return value if it is. (It could be simply a boolean, but doing
+ * it this way eliminates a test in the caller.)
+ */
+static const char *make_relative(unsigned label_len, const char *prefix, unsigned prefix_len, const char *name, void **to_free)
+{
+ static char name_buf[PATH_MAX];
+ char *cp;
+ unsigned n, match_len = 0, slashes = 0;
+ unsigned name_len;
+
+ for (n = 0; n < prefix_len; n++) {
+ if (prefix[n] != name[label_len+n]) {
+ for (; n < prefix_len; n++)
+ slashes += (prefix[n] == '/');
+ break;
+ }
+ if (prefix[n] == '/')
+ match_len = n+1;
+ }
+
+ /* Can we return a substring of the input string? */
+ if (!slashes && (!label_len || !match_len)) {
+ *to_free = NULL;
+ return name + match_len;
+ }
+
+ /* Nope, assemble the full response */
+
+ /* Output buffer will be tag + "../"*slashes + name + '\0' */
+ name_len = strlen(name + label_len + match_len) + 1;
+ n = label_len + 3*slashes + name_len + 1;
+ if (n <= ARRAY_SIZE(name_buf)) {
+ cp = name_buf;
+ *to_free = NULL;
+ } else {
+ *to_free = cp = xmalloc(n);
+ }
+
+ /* Now fill in the buffer */
+ memcpy(cp, name, label_len);
+ n = label_len;
+ while (slashes--) {
+ memcpy(cp+n, "../", 3);
+ n += 3;
+ }
+ memcpy(cp+n, name+label_len+match_len, name_len);
+ return cp;
+}
+
static int grep_sha1(struct grep_opt *opt, const unsigned char *sha1, const char *name, int tree_name_len)
{
unsigned long size;
char *data;
enum object_type type;
- char *to_free = NULL;
+ void *to_free = NULL;
int hit;
data = read_sha1_file(sha1, &type, &size);
@@ -103,24 +165,9 @@ static int grep_sha1(struct grep_opt *opt, const unsigned char *sha1, const char
error("'%s': unable to read %s", name, sha1_to_hex(sha1));
return 0;
}
- if (opt->relative && opt->prefix_length) {
- static char name_buf[PATH_MAX];
- char *cp;
- int name_len = strlen(name) - opt->prefix_length + 1;
-
- if (!tree_name_len)
- name += opt->prefix_length;
- else {
- if (ARRAY_SIZE(name_buf) <= name_len)
- cp = to_free = xmalloc(name_len);
- else
- cp = name_buf;
- memcpy(cp, name, tree_name_len);
- strcpy(cp + tree_name_len,
- name + tree_name_len + opt->prefix_length);
- name = cp;
- }
- }
+ if (opt->relative)
+ name = make_relative(tree_name_len, opt->prefix,
+ opt->prefix_length, name, &to_free);
hit = grep_buffer(opt, name, data, size);
free(data);
free(to_free);
@@ -132,6 +179,7 @@ static int grep_file(struct grep_opt *opt, const char *filename)
struct stat st;
int i;
char *data;
+ void *to_free = NULL;
size_t sz;
if (lstat(filename, &st) < 0) {
@@ -156,10 +204,12 @@ static int grep_file(struct grep_opt *opt, const char *filename)
return 0;
}
close(i);
- if (opt->relative && opt->prefix_length)
- filename += opt->prefix_length;
+ if (opt->relative)
+ filename = make_relative(0, opt->prefix, opt->prefix_length,
+ filename, &to_free);
i = grep_buffer(opt, filename, data, sz);
free(data);
+ free(to_free);
return i;
}
@@ -528,7 +578,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
int i;
memset(&opt, 0, sizeof(opt));
- opt.prefix_length = (prefix && *prefix) ? strlen(prefix) : 0;
+ opt.prefix = prefix;
+ opt.prefix_length = prefix ? strlen(prefix) : 0;
opt.relative = 1;
opt.pathname = 1;
opt.pattern_tail = &opt.pattern_list;
@@ -787,17 +838,10 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
verify_filename(prefix, argv[j]);
}
- if (i < argc) {
+ if (i < argc)
paths = get_pathspec(prefix, argv + i);
- if (opt.prefix_length && opt.relative) {
- /* Make sure we do not get outside of paths */
- for (i = 0; paths[i]; i++)
- if (strncmp(prefix, paths[i], opt.prefix_length))
- die("git grep: cannot generate relative filenames containing '..'");
- }
- }
else if (prefix) {
- paths = xcalloc(2, sizeof(const char *));
+ paths = xmalloc(2 * sizeof *paths);
paths[0] = prefix;
paths[1] = NULL;
}
diff --git a/grep.h b/grep.h
index 45a222d..a02dccf 100644
--- a/grep.h
+++ b/grep.h
@@ -56,6 +56,7 @@ struct grep_opt {
struct grep_pat *pattern_list;
struct grep_pat **pattern_tail;
struct grep_expr *pattern_expression;
+ const char *prefix;
int prefix_length;
regex_t regexp;
unsigned linenum:1;
^ permalink raw reply related
* Re: how to edit commit message in history
From: thestar @ 2009-01-16 4:31 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090116035714.GA6984@b2j>
You can't, that would default the whole point of git's sha1 hashes!
If you change a commit, you will change the sha1 hash of that commit,
and every subsequent commit. There is no way around it.
Quoting bill lam <cbill.lam@gmail.com>:
> I made some typos in commit messages, how to edit them without
> affecting everything else?
>
> Thanks in advance.
>
> --
> regards,
> ====================================================
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> 唐詩311 無名氏 雜詩
> 盡寒食雨草萋萋 著麥苗風柳映堤 等是有家歸未得 杜鵑休向耳邊啼
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: git-difftool
From: David Aguilar @ 2009-01-16 5:05 UTC (permalink / raw)
To: markus.heidelberg; +Cc: Matthieu Moy, git
In-Reply-To: <200901152326.47332.markus.heidelberg@web.de>
On Thu, Jan 15, 2009 at 2:26 PM, Markus Heidelberg
<markus.heidelberg@web.de> wrote:
> David Aguilar, 02.01.2009:
>> I now have a git-difftool wrapper script that basically just sets up
>> the environment for git-difftool-helper. git-difftool-helper does all
>> of the merge tool configuration stuff ala
>> http://www.kernel.org/pub/software/scm/git/docs/git-mergetool.html (it
>> uses the same git config variables and thus works with existing custom
>> commands). If you drop them both into the same directory it should
>> work as-is (it munges $PATH).
>>
>> It's not a two-liner (they do all that git config stuff and handle
>> more than just vimdiff) but it does use GIT_EXTERNAL_DIFF now, which
>> makes the script infinitely more useful. This is much nicer now since
>> you can pass any 'git diff' options to git-difftool and it'll handle
>> it correctly.
>>
>> The usage is simpler now too:
>>
>> usage: git difftool [--no-prompt] [--tool=tool] ["git diff" options]
>
> Now isn't this something for contrib, David?
>
> Markus
>
>
It sure is.
BTW the script worked beautifully on *nix.
I later decided to give it a try on Windows and of course it didn't
work right the first time. Once I added a check to use "git.exe"
instead of "git" then it started working again. I'll prepare some
documentation and post a patch later tonight.
Thanks for reminding me,
--
David
(p.s. Markus: sorry for the double-email -- I forgot to cc: the list)
^ permalink raw reply
* Re: How to exclude some files when using git-archive?
From: Ping Yin @ 2009-01-16 5:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v4p00otpb.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 16, 2009 at 10:44 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Ping Yin <pkufranky@gmail.com> writes:
>
>> I want to exclude .gitignore from the archive, but hasn't find a easy way
>>
>> Ping Yin
>
> "man gitattributes", then look for export-ignore?
>
>
Thanks. That's exactly what i want.
One question: It seems the .gitattributes doesn't take effect when
using following command
GIT_DIR=A/.git git archive HEAD > A.tar
where the files with attribute export-ignore are still exported.
Instead, i have to run
cd A && git archive HEAD > A.tar
Ping Yin
^ permalink raw reply
* Is there a way to exclude some file from a diff?
From: Ping Yin @ 2009-01-16 7:04 UTC (permalink / raw)
To: Git Mailing List
Something similar to
git diff --exclude=".gitignore" A..B
There are so many directories, so using "git diff path1 path2" is inapposite.
Ping Yin
^ permalink raw reply
* [PATCH] contrib: add 'git difftool' for launching common merge tools
From: David Aguilar @ 2009-01-16 8:00 UTC (permalink / raw)
To: git; +Cc: gitster, David Aguilar
'git difftool' is a git command that allows you to compare and edit files
between revisions using common merge tools. 'git difftool' does what
'git mergetool' does but its use is for non-merge situations such as
when preparing commits or comparing changes against the index.
It uses the same configuration variables as 'git mergetool' and
provides the same command-line interface as 'git diff'.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
contrib/difftool/git-difftool | 74 +++++++++++
contrib/difftool/git-difftool-helper | 240 ++++++++++++++++++++++++++++++++++
contrib/difftool/git-difftool.txt | 104 +++++++++++++++
3 files changed, 418 insertions(+), 0 deletions(-)
create mode 100755 contrib/difftool/git-difftool
create mode 100755 contrib/difftool/git-difftool-helper
create mode 100644 contrib/difftool/git-difftool.txt
This patch was the result of the following thread on the git-list:
http://thread.gmane.org/gmane.comp.version-control.git/103918
diff --git a/contrib/difftool/git-difftool b/contrib/difftool/git-difftool
new file mode 100755
index 0000000..1fc087c
--- /dev/null
+++ b/contrib/difftool/git-difftool
@@ -0,0 +1,74 @@
+#!/usr/bin/env perl
+# Copyright (c) 2009 David Aguilar
+#
+# This is a wrapper around the GIT_EXTERNAL_DIFF-compatible
+# git-difftool-helper script. This script exports
+# GIT_EXTERNAL_DIFF and GIT_PAGER for use by git, and
+# GIT_NO_PROMPT and GIT_MERGE_TOOL for use by git-difftool-helper.
+# Any arguments that are unknown to this script are forwarded to 'git diff'.
+
+use strict;
+use warnings;
+use Cwd qw(abs_path);
+use File::Basename qw(dirname);
+
+my $DIR = abs_path(dirname($0));
+
+
+sub usage
+{
+ print << 'USAGE';
+
+usage: git difftool [--no-prompt] [--tool=tool] ["git diff" options]
+USAGE
+ exit 1;
+}
+
+sub setup_environment
+{
+ $ENV{PATH} = "$DIR:$ENV{PATH}";
+ $ENV{GIT_PAGER} = '';
+ $ENV{GIT_EXTERNAL_DIFF} = 'git-difftool-helper';
+}
+
+sub exe
+{
+ my $exe = shift;
+ return defined $ENV{COMSPEC} ? "$exe.exe" : $exe;
+}
+
+sub generate_command
+{
+ my @command = (exe('git'), 'diff');
+ my $skip_next = 0;
+ my $idx = -1;
+ for my $arg (@ARGV) {
+ $idx++;
+ if ($skip_next) {
+ $skip_next = 0;
+ next;
+ }
+ if ($arg eq '-t' or $arg eq '--tool') {
+ usage() if $#ARGV <= $idx;
+ $ENV{GIT_MERGE_TOOL} = $ARGV[$idx + 1];
+ $skip_next = 1;
+ next;
+ }
+ if ($arg =~ /^--tool=/) {
+ $ENV{GIT_MERGE_TOOL} = substr($arg, 7);
+ next;
+ }
+ if ($arg eq '--no-prompt') {
+ $ENV{GIT_DIFFTOOL_NO_PROMPT} = 'true';
+ next;
+ }
+ if ($arg eq '-h' or $arg eq '--help') {
+ usage();
+ }
+ push @command, $arg;
+ }
+ return @command
+}
+
+setup_environment();
+exec(generate_command());
diff --git a/contrib/difftool/git-difftool-helper b/contrib/difftool/git-difftool-helper
new file mode 100755
index 0000000..0b266e3
--- /dev/null
+++ b/contrib/difftool/git-difftool-helper
@@ -0,0 +1,240 @@
+#!/bin/sh
+# git-difftool-helper is a GIT_EXTERNAL_DIFF-compatible diff tool launcher.
+# It supports kdiff3, tkdiff, xxdiff, meld, opendiff, emerge, ecmerge,
+# vimdiff, gvimdiff, and custom user-configurable tools.
+# This script is typically launched by using the 'git difftool'
+# convenience command.
+#
+# Copyright (c) 2009 David Aguilar
+
+# Set GIT_DIFFTOOL_NO_PROMPT to bypass the per-file prompt.
+should_prompt () {
+ ! test -n "$GIT_DIFFTOOL_NO_PROMPT"
+}
+
+# Should we keep the backup .orig file?
+keep_backup_mode="$(git config --bool merge.keepBackup || echo true)"
+keep_backup () {
+ test "$keep_backup_mode" = "true"
+}
+
+# This function manages the backup .orig file.
+# A backup $MERGED.orig file is created if changes are detected.
+cleanup_temp_files () {
+ if test -n "$MERGED"; then
+ if keep_backup && test "$MERGED" -nt "$BACKUP"; then
+ test -f "$BACKUP" && mv -- "$BACKUP" "$MERGED.orig"
+ else
+ rm -f -- "$BACKUP"
+ fi
+ fi
+}
+
+# This is called when users Ctrl-C out of git-difftool-helper
+sigint_handler () {
+ echo
+ cleanup_temp_files
+ exit 1
+}
+
+# This function prepares temporary files and launches the appropriate
+# merge tool.
+launch_merge_tool () {
+ # Merged is the filename as it appears in the work tree
+ # Local is the contents of a/filename
+ # Remote is the contents of b/filename
+ # Custom merge tool commands might use $BASE so we provide it
+ MERGED="$1"
+ LOCAL="$2"
+ REMOTE="$3"
+ BASE="$1"
+ ext="$$$(expr "$MERGED" : '.*\(\.[^/]*\)$')"
+ BACKUP="$MERGED.BACKUP.$ext"
+
+ # Create and ensure that we clean up $BACKUP
+ test -f "$MERGED" && cp -- "$MERGED" "$BACKUP"
+ trap sigint_handler SIGINT
+
+ # $LOCAL and $REMOTE are temporary files so prompt
+ # the user with the real $MERGED name before launching $merge_tool.
+ if should_prompt; then
+ printf "\nViewing: '$MERGED'\n"
+ printf "Hit return to launch '%s': " "$merge_tool"
+ read ans
+ fi
+
+ # Run the appropriate merge tool command
+ case "$merge_tool" in
+ kdiff3)
+ basename=$(basename "$MERGED")
+ "$merge_tool_path" --auto \
+ --L1 "$basename (A)" \
+ --L2 "$basename (B)" \
+ -o "$MERGED" "$LOCAL" "$REMOTE" \
+ > /dev/null 2>&1
+ ;;
+
+ tkdiff)
+ "$merge_tool_path" -o "$MERGED" "$LOCAL" "$REMOTE"
+ ;;
+
+ meld|vimdiff)
+ "$merge_tool_path" "$LOCAL" "$REMOTE"
+ ;;
+
+ gvimdiff)
+ "$merge_tool_path" -f "$LOCAL" "$REMOTE"
+ ;;
+
+ xxdiff)
+ "$merge_tool_path" \
+ -X \
+ -R 'Accel.SaveAsMerged: "Ctrl-S"' \
+ -R 'Accel.Search: "Ctrl+F"' \
+ -R 'Accel.SearchForward: "Ctrl-G"' \
+ --merged-file "$MERGED" \
+ "$LOCAL" "$REMOTE"
+ ;;
+
+ opendiff)
+ "$merge_tool_path" "$LOCAL" "$REMOTE" \
+ -merge "$MERGED" | cat
+ ;;
+
+ ecmerge)
+ "$merge_tool_path" "$LOCAL" "$REMOTE" \
+ --default --mode=merge2 --to="$MERGED"
+ ;;
+
+ emerge)
+ "$merge_tool_path" -f emerge-files-command \
+ "$LOCAL" "$REMOTE" "$(basename "$MERGED")"
+ ;;
+
+ *)
+ if test -n "$merge_tool_cmd"; then
+ ( eval $merge_tool_cmd )
+ fi
+ ;;
+ esac
+
+ cleanup_temp_files
+}
+
+# Verifies that mergetool.<tool>.cmd exists
+valid_custom_tool() {
+ merge_tool_cmd="$(git config mergetool.$1.cmd)"
+ test -n "$merge_tool_cmd"
+}
+
+# Verifies that the chosen merge tool is properly setup.
+# Built-in merge tools are always valid.
+valid_tool() {
+ case "$1" in
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
+ ;; # happy
+ *)
+ if ! valid_custom_tool "$1"
+ then
+ return 1
+ fi
+ ;;
+ esac
+}
+
+# Sets up the merge_tool_path variable.
+# This handles the mergetool.<tool>.path configuration.
+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
+}
+
+# Allow the GIT_MERGE_TOOL variable to provide a default value
+test -n "$GIT_MERGE_TOOL" && merge_tool="$GIT_MERGE_TOOL"
+
+# If not merge tool was specified then use the merge.tool
+# configuration variable. If that's invalid then reset merge_tool.
+if test -z "$merge_tool"; then
+ merge_tool=$(git config merge.tool)
+ if test -n "$merge_tool" && ! 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
+ fi
+fi
+
+# Try to guess an appropriate merge tool if no tool has been set.
+if test -z "$merge_tool"; then
+
+ # We have a $DISPLAY so try some common UNIX merge tools
+ if test -n "$DISPLAY"; then
+ merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
+ # If gnome then prefer meld
+ if test -n "$GNOME_DESKTOP_SESSION_ID"; then
+ merge_tool_candidates="meld $merge_tool_candidates"
+ fi
+ # If KDE then prefer kdiff3
+ if test "$KDE_FULL_SESSION" = "true"; then
+ merge_tool_candidates="kdiff3 $merge_tool_candidates"
+ fi
+ fi
+
+ # $EDITOR is emacs so add emerge as a candidate
+ if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
+ merge_tool_candidates="$merge_tool_candidates emerge"
+ fi
+
+ # $EDITOR is vim so add vimdiff as a candidate
+ if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
+ merge_tool_candidates="$merge_tool_candidates vimdiff"
+ fi
+
+ merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
+ echo "merge tool candidates: $merge_tool_candidates"
+
+ # Loop over each candidate and stop when a valid merge tool is found.
+ for i in $merge_tool_candidates
+ do
+ 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 known merge resolution program available."
+ exit 1
+ fi
+
+else
+ # A merge tool has been set, so verify that it's valid.
+ if ! valid_tool "$merge_tool"; then
+ echo >&2 "Unknown merge tool $merge_tool"
+ exit 1
+ fi
+
+ init_merge_tool_path "$merge_tool"
+
+ if test -z "$merge_tool_cmd" && ! 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
+
+
+# Launch the merge tool on each path provided by 'git diff'
+while test $# -gt 6
+do
+ launch_merge_tool "$1" "$2" "$5"
+ shift 7
+done
diff --git a/contrib/difftool/git-difftool.txt b/contrib/difftool/git-difftool.txt
new file mode 100644
index 0000000..3940c70
--- /dev/null
+++ b/contrib/difftool/git-difftool.txt
@@ -0,0 +1,104 @@
+git-difftool(1)
+===============
+
+NAME
+----
+git-difftool - compare changes using common merge tools
+
+SYNOPSIS
+--------
+'git difftool' [--tool=<tool>] [--no-prompt] ['git diff' options]
+
+DESCRIPTION
+-----------
+'git difftool' is a git command that allows you to compare and edit files
+between revisions using common merge tools. At its most basic level,
+'git difftool' does what 'git mergetool' does but its use is for non-merge
+situations such as when preparing commits or comparing changes against
+the index.
+
+'git difftool' is a frontend to 'git diff' and accepts the same
+arguments and options.
+
+See linkgit:git-diff[7] for the full list of supported options.
+
+OPTIONS
+-------
+-t <tool>::
+--tool=<tool>::
+ Use the merge resolution program specified by <tool>.
+ Valid merge tools are:
+ kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
++
+If a merge resolution program is not specified, 'git difftool'
+will use the configuration variable `merge.tool`. If the
+configuration variable `merge.tool` is not set, 'git difftool'
+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 difftool' assumes the
+tool is available in PATH.
++
+Instead of running one of the known merge tool programs,
+'git difftool' can be customized to run an alternative program
+by specifying the command line to invoke in a configuration
+variable `mergetool.<tool>.cmd`.
++
+When 'git difftool' is invoked with this tool (either through the
+`-t` or `--tool` option or the `merge.tool` configuration variable)
+the configured command line will be invoked with the following
+variables available: `$LOCAL` is set to the name of the temporary
+file containing the contents of the diff pre-image and `$REMOTE`
+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`.
+
+--no-prompt::
+ Do not prompt before launching a merge tool.
+
+CONFIG VARIABLES
+----------------
+merge.tool::
+ The default merge tool to use.
++
+See the `--tool=<tool>` option above for more details.
+
+merge.keepBackup::
+ The original, unedited file content can be saved to a file with
+ a `.orig` extension. Defaults to `true` (i.e. keep the backup files).
+
+mergetool.<tool>.path::
+ Override the path for the given tool. This is useful in case
+ your tool is not in the PATH.
+
+mergetool.<tool>.cmd::
+ Specify the command to invoke the specified merge tool.
++
+See the `--tool=<tool>` option above for more details.
+
+
+SEE ALSO
+--------
+linkgit:git-diff[7]::
+ Show changes between commits, commit and working tree, etc
+
+linkgit:git-mergetool[1]::
+ Run merge conflict resolution tools to resolve merge conflicts
+
+linkgit:git-config[7]::
+ Get and set repository or global options
+
+
+AUTHOR
+------
+Written by David Aguilar <davvid@gmail.com>.
+
+Documentation
+--------------
+Documentation by David Aguilar and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
--
1.6.1.149.g7bbd8
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2009, #03; Wed, 14)
From: Kirill Smelkov @ 2009-01-16 8:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4eos3rp.fsf@gitster.siamese.dyndns.org>
On Thu, Jan 15, 2009 at 12:39:06PM -0800, Junio C Hamano wrote:
> Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
>
> > Sorry for the inconvenience, and please pull them all from
> >
> > git://repo.or.cz/git/kirr.git for-junio
> >
> > Kirill Smelkov (4):
> > mailinfo: 'From:' header should be unfold as well
> > mailinfo: more smarter removal of rfc822 comments from 'From'
> > mailinfo: correctly handle multiline 'Subject:' header
> > mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
>
> Sorry, but I cannot _pull_ this one; not because these four patches are
> bad (I haven't looked at them).
>
> They include all the other totally unrelated stuff that happend on the
> master branch since the topic ks/maint-mailinfo-folded forked. I've been
> hoping upon completion of this topic we can merge it down to maint to
> propagate the fix back to v1.6.1.X series.
>
> With this alias:
>
> $ git config alias.lg log --pretty=oneline --abbrev-commit --boundary --left-right
>
> Here are what I have queued so far (and they are in next):
>
> $ git lg master..ks/maint-mailinfo-folded
> >ddfb369... mailinfo: 'From:' header should be unfold as well
> >353aaf2... mailinfo: correctly handle multiline 'Subject:' header
> -141201d... Merge branch 'maint-1.5.6' into maint-1.6.0
>
> $ git lg maint..ks/maint-mailinfo-folded
> >ddfb369... mailinfo: 'From:' header should be unfold as well
> >353aaf2... mailinfo: correctly handle multiline 'Subject:' header
> -141201d... Merge branch 'maint-1.5.6' into maint-1.6.0
>
> 141201d is only three commits ahead of v1.6.0.6 and
>
> $ git lg v1.6.0.6..141201d
>
> will show that we _could_ even issue v1.6.0.7 with the fixes in this topic
> if we cared about this bug deeply enough. If I pull the above to the
> topic, we'll lose the ability to propagate these fixes to the maintenance
> serires.
>
> So please either say "Yes, you are welcome to cherry-pick -- fetching and
> cherry-picking would be easier than e-mail for this kind of patch", or
> "Ok, I'll rebase my series on top of ddfb369".
>
> Well, I just noticed that some of your commits already conflict with the
> two patches that I already have, so I guess we would need at least one
> rebase anyway, so this time around, I'd really prefer you not to say "you
> are welcome to cherry-pick" ;-)
Sure, I've rebased my series on top of ddfb369 :)
git://repo.or.cz/git/kirr.git for-junio-maint
Kirill Smelkov (3):
mailinfo: more smarter removal of rfc822 comments from 'From'
mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
mailinfo: tests for RFC2047 examples
Thanks,
Kirill
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #03; Wed, 14)
From: Junio C Hamano @ 2009-01-16 8:21 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: git
In-Reply-To: <20090116080807.GA10792@landau.phys.spbu.ru>
Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
> On Thu, Jan 15, 2009 at 12:39:06PM -0800, Junio C Hamano wrote:
> ...
>> So please either say "Yes, you are welcome to cherry-pick -- fetching and
>> cherry-picking would be easier than e-mail for this kind of patch", or
>> "Ok, I'll rebase my series on top of ddfb369".
>>
>> Well, I just noticed that some of your commits already conflict with the
>> two patches that I already have, so I guess we would need at least one
>> rebase anyway, so this time around, I'd really prefer you not to say "you
>> are welcome to cherry-pick" ;-)
>
> Sure, I've rebased my series on top of ddfb369 :)
>
> git://repo.or.cz/git/kirr.git for-junio-maint
>
>
> Kirill Smelkov (3):
> mailinfo: more smarter removal of rfc822 comments from 'From'
> mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
> mailinfo: tests for RFC2047 examples
Thanks.
I thought there is somebody on this list who insists his name is of form:
From: A U Thor (MonikeR) <a.u@thor.xz>
and vaguely recall the current code was tweaked to keep that extra moniker
in his (or her?) name. It is too late at night for me to double check but
I suspect the first one in the series may break things for that kind of
names.
^ permalink raw reply
* Weird behaviour of git status
From: Nicolas Morey-Chaisemartin @ 2009-01-16 8:42 UTC (permalink / raw)
To: git@vger.kernel.org
Hello everyone,
I just noticed a weird behaviour in git status.
I have created new files in different directories in my project.
I have added all of them in the index with git add.
When I run "git status" It shows me that all my 3 files are in the index.
However if I run git-status specifying a directory, it returns that the
file in this directory are in the index but the other one isn't.
In my opinion, it should
- either display all the files as in the index (specifying a directory
wouldn't have any effect then)
- treat only file in the specified dir. So "external" files wouldn't be
shown at all.
Thanks
Nicolas
Here are the logs
_________________________
moreychn@uranus-ubuntu:~/workspace/git/osmdc$ git --version
git version 1.6.1
moreychn@uranus-ubuntu:~/workspace/git/osmdc/include$ git status
# On branch v3
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: devmgr_common.h
# new file: devmgr_types.h
# new file: ../src/devmgr_common.c
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: ../src/osmdc_devmgr.h
#
moreychn@uranus-ubuntu:~/workspace/git/osmdc/include$ git status .
# On branch v3
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: devmgr_common.h
# new file: devmgr_types.h
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: ../src/osmdc_devmgr.h
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# ../src/devmgr_common.c
^ permalink raw reply
* Re: [PATCH take 3 0/4] color-words improvements
From: Santi Béjar @ 2009-01-16 9:02 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Boyd Stephen Smith Jr., Teemu Likonen,
Thomas Rast, git
In-Reply-To: <alpine.DEB.1.00.0901160253210.3586@pacific.mpi-cbg.de>
2009/1/16 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Fri, 16 Jan 2009, Santi Béjar wrote:
>
>> If everything works as I think (it's late night :-) with the above two lines:
>>
>> matrix[a,b,c]
>> matrix{d,b,c}
>>
>> the word diff would be
>>
>> matrix<RED>[<GREEN>{<RED>a<GREEN>d<RESET>,b,c<RED>]<GREEN>}<RED>
>
> So I guess that you want something like
>
> [A-Za-z0-9]+|[^A-Za-z0-9 \t]+
>
> Note: I only want to help you finding what you actually want, I am not
> trying to find it for you.
>
Thanks all for the answers.
So, I see, it is a matter of finding the right regexp.
But the only use case for me is of this kind, and I think for the
others too. So maybe an easier way to specify it could be worth. But
I'll write an alias as this is the only regexp I would use, apart from
the default word diff.
Thanks,
Santi
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Jens Seidel @ 2009-01-16 9:03 UTC (permalink / raw)
To: git; +Cc: schacon
In-Reply-To: <20090116015439.GF12275@machine.or.cz>
On Fri, Jan 16, 2009 at 02:54:39AM +0100, Petr Baudis wrote:
> On Thu, Jan 15, 2009 at 04:53:48PM +0100, Johannes Schindelin wrote:
> > sorry to bother you between two games of Go; Could you have a look at the
> > 'mail' link with the commit "Update 1.6.2 draft release notes"? It is not
> > working for me...
> >
> > That is, it links to marc (not gmane?) but finds no matches...
Just a side note: The link to the mailing list on http://git-scm.com/ is also
not optimal as it refers to gmane. I tried to subscribe but found only a link
to http://dir.gmane.org/gmane.comp.version-control.git and no instructions how
to subscribe ...
Jens
^ permalink raw reply
* Re: [PATCH] checkout: implement "-" shortcut name for last branch
From: Thomas Rast @ 2009-01-16 9:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901151510340.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]
Johannes Schindelin wrote:
> - AFAICT your version could never be convinced to resurrect deleted
> branches, without resorting to reflogs anyway.
Speaking of resurrection, there are other possible sources that a
branch tip could be gleaned from. How about the script below? The
advantage is that it can even be used to recover Junio's topic
branches by looking at the merges in 'pu'.
(I'll answer the rest later.)
--- 8< ---
#!/bin/sh
. git-sh-setup
USAGE="<branch>"
test "$#" = 1 || usage
branch="$1"
candidates=
search_reflog () {
next=
git reflog show HEAD |
while read sha ref msg; do
if test -n "$next"; then
next=
echo ${sha%...}
fi
if echo "$msg" | grep -q "^checkout: moving from $branch "; then
next=t
fi
if echo "$msg" | grep -q "^merge $branch:"; then
git rev-list --parents -1 ${sha%...} \
| cut -d' ' -f3
fi
done
}
search_merges () {
git rev-list --pretty=tformat:"%h %p:%s" --all |
grep "Merge branch.*'$branch'.*into" |
while read sha rest; do
parents="$(echo "$rest" | cut -d: -f1)"
case "$parents" in
*' '*' '*)
warn "$branch took part in octopus merge $sha"
warn "check manually!"
;;
*' '*)
echo "$parents" | cut -d' ' -f2
;;
esac
done
}
search_merge_targets () {
git rev-list --pretty=tformat:"%h %s" --all |
grep "Merge branch '[^']*' into $branch$" |
cut -d' ' -f1
}
candidates="$(search_reflog | sort -u)"
if test -z "$candidates"; then
echo "** Searching merges... **"
candidates="$( (search_merges;search_merge_targets) | sort -u)"
fi
echo "** Candidates **"
for cmt in $candidates; do
git --no-pager log --pretty=oneline --abbrev-commit -1 $cmt
done
newest=$(git rev-list -1 $candidates)
if ! git rev-parse --verify --quiet $branch >/dev/null; then
printf "** Restoring $branch to "
git --no-pager log -1 --pretty=tformat:"%h %s" $newest
git branch $branch $newest
else
printf "Most recent among them: "
git --no-pager log -1 --pretty=tformat:"%h %s" $newest
echo "** $branch already exists, doing nothing"
fi
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Weird behaviour of git status
From: Wincent Colaiuta @ 2009-01-16 9:44 UTC (permalink / raw)
To: devel; +Cc: git@vger.kernel.org
In-Reply-To: <4970488B.3010608@morey-chaisemartin.com>
El 16/1/2009, a las 9:42, Nicolas Morey-Chaisemartin escribió:
> Hello everyone,
>
> I just noticed a weird behaviour in git status.
> I have created new files in different directories in my project.
> I have added all of them in the index with git add.
> When I run "git status" It shows me that all my 3 files are in the
> index.
> However if I run git-status specifying a directory, it returns that
> the
> file in this directory are in the index but the other one isn't.
>
> In my opinion, it should
> - either display all the files as in the index (specifying a directory
> wouldn't have any effect then)
> - treat only file in the specified dir. So "external" files wouldn't
> be
> shown at all.
"git status" shows you what would be committed if you ran "git commit"
with the same parameters. So in your example, the output for "git
status ." is exactly as you would expect.
This is stated in the man page.
Cheers,
Wincent
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox