* Re: NT directory traversal speed on 25K files on Cygwin
From: Andreas Ericsson @ 2006-02-27 9:19 UTC (permalink / raw)
To: git; +Cc: Christopher Faylor, git
In-Reply-To: <20060226231701.GA11961@nospam.com>
Rutger Nijlunsing wrote:
> On Sun, Feb 26, 2006 at 02:55:52PM -0500, Christopher Faylor wrote:
>
>>On Thu, Feb 23, 2006 at 03:07:07PM +0100, Alex Riesen wrote:
>>
>>>filesystem is slow and locked down, and exec-attribute is NOT really
>>>useful even on NTFS (it is somehow related to execute permission and
>>>open files. I still cannot figure out how exactly are they related).
>>
>>Again, it's not clear if you're talking about Windows or Cygwin but
>>under Cygwin, in the default configuration, the exec attribute means the
>>same thing to cygwin as it does to linux.
>
>
> I don't know about native Windows speed, but comparing NutCracker with
> Cygwin on a simple 'find . | wc -l' already gives a clue that looking
> at Cygwin to benchmark NT file inspection IO will give a skewed
> picture:
>
Well, naturally. Cygwin is a userland implementation of a sane
filesystem on top of a less sane one. File IO is bound to be slower when
one FS is emulated on top of another. I think cygwin users are aware of
this and simply accept the speed-for-sanity tradeoff. I know I would.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: the war on trailing whitespace
From: Johannes Schindelin @ 2006-02-27 9:07 UTC (permalink / raw)
To: MIke Galbraith; +Cc: Dave Jones, Linus Torvalds, Andrew Morton, junkio, git
In-Reply-To: <1141008633.7593.13.camel@homer>
Hi,
there is a good reason not to enable the no-whitespace-at-eol checking in
pre-commit by default (at least for *all* files) for git development:
Python.
Just do a "/ $" in git-merge-recursive.py. These whitespaces are not an
error, but a syntactic *requirement*.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] First cut at libifying revlist generation
From: Johannes Schindelin @ 2006-02-27 9:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vpsl93395.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 26 Feb 2006, Junio C Hamano wrote:
> Johannes gets a test-pilot star for this. This also means we need a bit
> better set of tests.
Well, I don't deserve this. I cheated.
In my personal version of git, there are a few subtle things different
than in the official version. Most of them, I sent out already, and they
were rejected, such as
http://article.gmane.org/gmane.comp.version-control.git/10718, which
helped me tremendously in identyfing the bug.
But there is also a test case in my version, which was a failure,
originally. I wrote it to demonstrate that the stupid version of
git-fetch was stupid. It did not demonstrate that, but rather quite a bit
of (my) normal usage. That is the reason it takes a really long time for a
test case, and that in turn is the reason I did not dare to submit it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add a Documentation/git-tools.txt
From: Alexandre Julliard @ 2006-02-27 8:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, git
In-Reply-To: <7vslq57mzn.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Also is the emacs one really pcl-cvs? I thought it was modeled
> after pcl-cvs, but this is a different implementation to deal
> with git. If Alexandre does not have a name for it, I'd say
> we'll list it as "git.el".
It doesn't really have a specific name, so yes, "git.el" is fine.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Re: [PATCH] Add a Documentation/git-tools.txt
From: Marco Costalba @ 2006-02-27 6:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Alexandre Julliard
In-Reply-To: <7vslq57mzn.fsf@assigned-by-dhcp.cox.net>
On 2/26/06, Junio C Hamano <junkio@cox.net> wrote:
> >
> > Please consider for apply.
>
> Thanks. I've considered it, but it is seriously linewrapped.
>
Sorry for this. It is ok 80 columns max?
> > + - *pcl-cvs* (contrib/)
> > +
> > + This is an Emacs interface for git. The user interface is
> > modeled on
> > + pcl-cvs.
>
> Also is the emacs one really pcl-cvs? I thought it was modeled
> after pcl-cvs, but this is a different implementation to deal
> with git. If Alexandre does not have a name for it, I'd say
> we'll list it as "git.el".
>
Ok, waiting for Alexandre's answer.
This week I foreseen to be quite busy, so perhaps the patch will be
delayed a little bit.
Marco
^ permalink raw reply
* Re: [PATCH 4/4] Read author names and emails from a file
From: Junio C Hamano @ 2006-02-27 5:51 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Karl Hasselström
In-Reply-To: <440195D4.7080905@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Karl Hasselström wrote:
>> Read a file with lines on the form
>> username User's Full Name <email@addres.org>
>> and use "User's Full Name <email@addres.org>" as the GIT author and
>> committer for Subversion commits made by "username". If encountering a
>> commit made by a user not in the list, abort.
>
> This is a good thing, but wouldn't it be better to use the same format
> as that of cvsimport's -A flag?
If both CVS and SVN have their own native format to express
things like this, and if the format they use are different, then
that is a valid reason for git-{cvs,svn}import to use different
file format.
But if that is not the case, I tend to agree that it might be
easier for users if we had just one format. I do not think,
however, any single project is likely to have to deal with both
CVS and SVN upstream, importing into the same git repository, so
reusing the mapping file would not be an issue, but having to
learn how to write the mapping just once is a good thing.
I do not offhand recall if SVN has its own native format; if it
has, it may be better to use that, instead of matching what
git-cvsimport does, since I do not think of a reason why the
version with an equal sign is preferrable over the version with
a space. If the version with '=' were the CVS native format
then that might be a reason to prefer it, but if I recall
correctly that is not the case. so...
^ permalink raw reply
* Re: [PATCH] First cut at libifying revlist generation
From: Linus Torvalds @ 2006-02-27 5:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vy7zx1j6u.fsf@assigned-by-dhcp.cox.net>
On Sun, 26 Feb 2006, Junio C Hamano wrote:
>
> Not really, because the second invocation of add_one_commit()
> says "I've seen that *commit*", which is correct. And the story
> is obviously the same if you used longhand "^v1.0.0^0 v1.0.0".
Ok.
I suspect that the simplest fix is to just move "limited" into the "revs"
structure, the way I did pretty much everything else. That way nothing
really changes: we'll have the exact same logic, the flag just moved
around.
Linus
^ permalink raw reply
* Re: [PATCH] First cut at libifying revlist generation
From: Junio C Hamano @ 2006-02-27 5:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602261914270.22647@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 26 Feb 2006, Junio C Hamano wrote:
>>
>> I am clueless about the "limited = (list && list->next)" part,
>> but there is only one commit involved hence the test is false
>> with my testcase "git-rev-list --objects v1.0.0^0..v1.0.0"; I
>> think the old code said dotdot is a limited case.
>
> dotdot should insert _two_ commits onto the list - the positive and
> the negative one. Doesn't it?
Not really, because the second invocation of add_one_commit()
says "I've seen that *commit*", which is correct. And the story
is obviously the same if you used longhand "^v1.0.0^0 v1.0.0".
As a symbolic notation v1.0.0^0..v1.0.0 may not make much sense,
but the point is "the other end says he has that commit object,
but now he wants the tag we later attached to that commit
object; let's list the objects we need to send him". This is
what upload-pack does.
A bad consequence of not limiting is that:
git-rev-list ^v1.0.0^0 v1.0.0 | tail -n 1
gives this commit ;-):
e83c5163316f89bfbde7d9ab23ca2e25604af290
Argh.
^ permalink raw reply
* Re: [PATCH] First cut at libifying revlist generation
From: Linus Torvalds @ 2006-02-27 3:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vpsl93395.fsf@assigned-by-dhcp.cox.net>
On Sun, 26 Feb 2006, Junio C Hamano wrote:
>
> I am clueless about the "limited = (list && list->next)" part,
> but there is only one commit involved hence the test is false
> with my testcase "git-rev-list --objects v1.0.0^0..v1.0.0"; I
> think the old code said dotdot is a limited case.
dotdot should insert _two_ commits onto the list - the positive and
the negative one. Doesn't it?
So the
if (list && list->next)
check should be correct. If we have just one entry, there's no reason to
do everything up-front, we can just run with it (and get the nice
streaming behaviour).
> -static struct object_list *pending_objects = NULL;
> -
> - for (pending = pending_objects; pending; pending = pending->next) {
> + for (pending = revs.pending_objects; pending; pending = pending->next) {
But this part is obviously correct. I already sent out the same patch a
minute ago ;)
> - if (revs.max_age || revs.min_age)
> + if (revs.max_age != -1 || revs.min_age != -1)
As is this. I for a while had zero meaning "no age", and I actually think
it probably should be that way, but then we'd have to switch the
date-related functions around, which is why I decided not to do it after
all (but missed this one that I had already written for that case).
Linus
^ permalink raw reply
* Re: [PATCH] First cut at libifying revlist generation
From: Junio C Hamano @ 2006-02-27 3:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602251608160.22647@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Comments? I think this is safe to apply, because I've done a diff of the
> old non-split rev-list.c against both the new rev-list.c and revision.c,
> and all the changes _look_ like just moving things around and taking the
> new "struct rev_info" into account.
I think you would need something the attached patch, at least.
I have a suspicion that this was your easter egg to see how
careful I am reading what I apply -- and I failed. Johannes
gets a test-pilot star for this. This also means we need a bit
better set of tests.
The diff between old rev-list.c and new split files would not
have caught the static variable gotcha.
I am clueless about the "limited = (list && list->next)" part,
but there is only one commit involved hence the test is false
with my testcase "git-rev-list --objects v1.0.0^0..v1.0.0"; I
think the old code said dotdot is a limited case.
---
diff --git a/rev-list.c b/rev-list.c
index d1c52a6..630626e 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -214,8 +214,6 @@ static struct object_list **process_tree
return p;
}
-static struct object_list *pending_objects = NULL;
-
static void show_commit_list(struct commit_list *list)
{
struct object_list *objects = NULL, **p = &objects, *pending;
@@ -226,7 +224,7 @@ static void show_commit_list(struct comm
if (process_commit(commit) == STOP)
break;
}
- for (pending = pending_objects; pending; pending = pending->next) {
+ for (pending = revs.pending_objects; pending; pending = pending->next) {
struct object *obj = pending->item;
const char *name = pending->name;
if (obj->flags & (UNINTERESTING | SEEN))
@@ -675,7 +673,7 @@ int main(int argc, const char **argv)
}
list = revs.commits;
- if (list && list->next)
+ if (list)
limited = 1;
if (revs.topo_order)
@@ -689,7 +687,7 @@ int main(int argc, const char **argv)
limited = 1;
diff_tree_setup_paths(revs.paths);
}
- if (revs.max_age || revs.min_age)
+ if (revs.max_age != -1 || revs.min_age != -1)
limited = 1;
save_commit_buffer = verbose_header;
^ permalink raw reply related
* Re: [PATCH] First cut at libifying revlist generation
From: Linus Torvalds @ 2006-02-27 3:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0602270257110.4147@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, 27 Feb 2006, Johannes Schindelin wrote:
>
> beware of that patch. It breaks at least one thing: cloning a repository
> with a tag pointing to a tag object (the tag is cloned, but not the tag
> object).
>
> Sorry to not fix it right away, but I am just too tired.
Ahh. I know what it is.
I'm pretty sure this trivial and stupid patch on top of the patch I sent
out should fix it.
Duh. I moved "pending_objects" into the "revs" structure, but didn't
remove the stale one, along with its use.
Linus
---
diff --git a/rev-list.c b/rev-list.c
index d1c52a6..e9e371c 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -214,8 +214,6 @@ static struct object_list **process_tree
return p;
}
-static struct object_list *pending_objects = NULL;
-
static void show_commit_list(struct commit_list *list)
{
struct object_list *objects = NULL, **p = &objects, *pending;
@@ -226,7 +224,7 @@ static void show_commit_list(struct comm
if (process_commit(commit) == STOP)
break;
}
- for (pending = pending_objects; pending; pending = pending->next) {
+ for (pending = revs.pending_objects; pending; pending = pending->next) {
struct object *obj = pending->item;
const char *name = pending->name;
if (obj->flags & (UNINTERESTING | SEEN))
^ permalink raw reply related
* Re: the war on trailing whitespace
From: MIke Galbraith @ 2006-02-27 2:50 UTC (permalink / raw)
To: Dave Jones; +Cc: Linus Torvalds, Andrew Morton, junkio, git
In-Reply-To: <20060226202617.GH7851@redhat.com>
On Sun, 2006-02-26 at 15:26 -0500, Dave Jones wrote:
> I think I have the same anal-retentive problem Andrew has, because I have ..
>
> highlight RedundantSpaces term=standout ctermbg=red guibg=red
> match RedundantSpaces /\s\+$\| \+\ze\t/
>
> in my .vimrc, which highlights this (and other trailing whitespace) as
> a big red blob. I do this in part for the same reason Andrew does,
> so that when someone sends me a diff with a zillion spaces at the EOL,
> it screams at me, I spot them, and chop them out.
Dang, I'm _not_ perfect after all ;-). I just tried this on a patch of
mine, and up popped a few angry red blobs even though I try to be
careful. Perhaps someone should add more pet peeve thingies to it and
post it to lkml, or put it some place people can be pointed at.
-Mike
^ permalink raw reply
* [PATCH] apply --whitespace fixes and enhancements.
From: Junio C Hamano @ 2006-02-27 2:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vr75p4ojt.fsf@assigned-by-dhcp.cox.net>
In addition to fixing obvious command line parsing bugs in the
previous round, this changes the following:
* Adds "--whitespace=strip". This applies after stripping the
new trailing whitespaces introduced to the patch.
* The output error message format is changed to say
"patch-filename:linenumber:contents of the line". This makes
it similar to typical compiler error message format, and
helps C-x ` (next-error) in Emacs compilation buffer.
* --whitespace=error and --whitespace=warn do not stop at the
first error. We might want to limit the output to say first
20 such lines to prevent cluttering, but on the other hand if
you are willing to hand-fix after inspecting them, getting
everything with a single run might be easier to work with.
After all, somebody has to do the clean-up work somewhere.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Junio C Hamano <junkio@cox.net> writes:
> Regarding git-apply change, I suspect warn_on_whitespace should
> not squelch itself after the first one, and error_on_whitespace
> should not die instantly. The sample pre-applypatch hook (it
> was missing code to figure out where GIT_DIR was so it never
> worked as shipped; corrected in "master") shows line numbers of
> suspicious lines from the files being patched. They can be
> manually fixed up, and then "git am --resolved", if the
> integrator is in a better mood.
>
> The error messages from pre-commit/pre-applypatch hook mimic the
> way compiler errors are spit out, so that it works well in Emacs
> compilation buffer -- doing C-x ` (next-error) takes you the
> line the error appears and lets you edit it.
apply.c | 77 ++++++++++++++++++++++++++++++++++++++++++++-------------------
1 files changed, 54 insertions(+), 23 deletions(-)
e0af70a72d4115c32a1f9b91f1cf4556bbd014b6
diff --git a/apply.c b/apply.c
index e7b3dca..7dbbeb4 100644
--- a/apply.c
+++ b/apply.c
@@ -37,8 +37,11 @@ static const char apply_usage[] =
static enum whitespace_eol {
nowarn,
warn_on_whitespace,
- error_on_whitespace
+ error_on_whitespace,
+ strip_and_apply,
} new_whitespace = nowarn;
+static int whitespace_error = 0;
+static const char *patch_input_file = NULL;
/*
* For "diff-stat" like behaviour, we keep track of the biggest change
@@ -823,19 +826,17 @@ static int parse_fragment(char *line, un
case '+':
/*
* We know len is at least two, since we have a '+' and
- * we checked that the last character was a '\n' above
+ * we checked that the last character was a '\n' above.
+ * That is, an addition of an empty line would check
+ * the '+' here. Sneaky...
*/
- if (isspace(line[len-2])) {
- switch (new_whitespace) {
- case nowarn:
- break;
- case warn_on_whitespace:
- new_whitespace = nowarn; /* Just once */
- error("Added whitespace at end of line at line %d", linenr);
- break;
- case error_on_whitespace:
- die("Added whitespace at end of line at line %d", linenr);
- }
+ if ((new_whitespace != nowarn) &&
+ isspace(line[len-2])) {
+ fprintf(stderr, "Added whitespace\n");
+ fprintf(stderr, "%s:%d:%.*s\n",
+ patch_input_file,
+ linenr, len-2, line+1);
+ whitespace_error = 1;
}
added++;
newlines--;
@@ -1114,6 +1115,27 @@ struct buffer_desc {
unsigned long alloc;
};
+static int apply_line(char *output, const char *patch, int plen)
+{
+ /* plen is number of bytes to be copied from patch,
+ * starting at patch+1 (patch[0] is '+'). Typically
+ * patch[plen] is '\n'.
+ */
+ int add_nl_to_tail = 0;
+ if ((new_whitespace == strip_and_apply) &&
+ 1 < plen && isspace(patch[plen-1])) {
+ if (patch[plen] == '\n')
+ add_nl_to_tail = 1;
+ plen--;
+ while (0 < plen && isspace(patch[plen]))
+ plen--;
+ }
+ memcpy(output, patch + 1, plen);
+ if (add_nl_to_tail)
+ output[plen++] = '\n';
+ return plen;
+}
+
static int apply_one_fragment(struct buffer_desc *desc, struct fragment *frag)
{
char *buf = desc->buffer;
@@ -1149,10 +1171,9 @@ static int apply_one_fragment(struct buf
break;
/* Fall-through for ' ' */
case '+':
- if (*patch != '+' || !no_add) {
- memcpy(new + newsize, patch + 1, plen);
- newsize += plen;
- }
+ if (*patch != '+' || !no_add)
+ newsize += apply_line(new + newsize, patch,
+ plen);
break;
case '@': case '\\':
/* Ignore it, we already handled it */
@@ -1721,7 +1742,7 @@ static int use_patch(struct patch *p)
return 1;
}
-static int apply_patch(int fd)
+static int apply_patch(int fd, const char *filename)
{
int newfd;
unsigned long offset, size;
@@ -1729,6 +1750,7 @@ static int apply_patch(int fd)
struct patch *list = NULL, **listp = &list;
int skipped_patch = 0;
+ patch_input_file = filename;
if (!buffer)
return -1;
offset = 0;
@@ -1755,6 +1777,9 @@ static int apply_patch(int fd)
}
newfd = -1;
+ if (whitespace_error && (new_whitespace == error_on_whitespace))
+ apply = 0;
+
write_index = check_index && apply;
if (write_index)
newfd = hold_index_file_for_update(&cache_file, get_index_file());
@@ -1801,7 +1826,7 @@ int main(int argc, char **argv)
int fd;
if (!strcmp(arg, "-")) {
- apply_patch(0);
+ apply_patch(0, "<stdin>");
read_stdin = 0;
continue;
}
@@ -1862,14 +1887,18 @@ int main(int argc, char **argv)
continue;
}
if (!strncmp(arg, "--whitespace=", 13)) {
- if (strcmp(arg+13, "warn")) {
+ if (!strcmp(arg+13, "warn")) {
new_whitespace = warn_on_whitespace;
continue;
}
- if (strcmp(arg+13, "error")) {
+ if (!strcmp(arg+13, "error")) {
new_whitespace = error_on_whitespace;
continue;
}
+ if (!strcmp(arg+13, "strip")) {
+ new_whitespace = strip_and_apply;
+ continue;
+ }
die("unrecognixed whitespace option '%s'", arg+13);
}
@@ -1885,10 +1914,12 @@ int main(int argc, char **argv)
if (fd < 0)
usage(apply_usage);
read_stdin = 0;
- apply_patch(fd);
+ apply_patch(fd, arg);
close(fd);
}
if (read_stdin)
- apply_patch(0);
+ apply_patch(0, "<stdin>");
+ if (whitespace_error && new_whitespace == error_on_whitespace)
+ return 1;
return 0;
}
--
1.2.3.gac5f
^ permalink raw reply related
* Re: [PATCH] First cut at libifying revlist generation
From: Johannes Schindelin @ 2006-02-27 1:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602251608160.22647@g5.osdl.org>
Hi,
beware of that patch. It breaks at least one thing: cloning a repository
with a tag pointing to a tag object (the tag is cloned, but not the tag
object).
Sorry to not fix it right away, but I am just too tired.
By way of figuring this out, I just found a (warning: irony) "cute
feature" of git-bisect. I needed to apply a certain patch to trigger a
certain bug. So I always applied that patch after bisect chose the next
rev, and of course committed it so that bisect could continue.
(In hindsight, I probably should've applied the patch,
git-update-index'ed the file, and hoped that the merge mechanism take care
of it.)
Now, short of finding the correct commit, bisect would loop endlessly,
giving me the same rev to test over and over again (saying "2 revs to go
after this"), because I would label the current rev (which was the applied
patch, not the bad rev) as bad.
So, in a very real sense, it might not be such a phantastic idea as was
suggested earlier on this list, that you are able to commit on top of a
bisected rev.
Good night and good luck,
Dscho
^ permalink raw reply
* Re: Recoding of {git,cg}-log output
From: Petr Baudis @ 2006-02-27 1:26 UTC (permalink / raw)
To: Krzysiek Pawlik; +Cc: Git Mailing List
In-Reply-To: <44024384.4060406@people.pl>
Dear diary, on Mon, Feb 27, 2006 at 01:10:44AM CET, I got a letter
where Krzysiek Pawlik <krzysiek.pawlik@people.pl> said that...
>
> First: a little "why": having /usr/bin/vim as PAGER allows to enter
> UTF-8 commit messages quite easily, the problem is when git-log (or
> cg-log) is run in terminal that's not UTF-8. In my case: terminal is
> ISO-8859-2 and:
>
> nelchael@nelchael ~$ cat ~/.vimrc | grep gitci
> au BufRead /tmp/gitci* setlocal textwidth=75 fileencoding=utf-8
> encoding=utf-8 fileencodings=utf-8,default
Wouldn't it be enough to also set termencoding?
> So... having {git,cg}-log recode the log entires when displaying is
> quite useful. Two patches attached:
>
> a. git-log-recode.patch - uses iconv to recode the log output to
> GIT_LOG_RECODE encoding
> b. cg-log-recode.patch - the same, but for cogito
>
> With this patches it's possible to write UTF-8 commit messages and see
> them ok in non-UTF-8 terminal in log by having GIT_LOG_RECODE=iso-8859-2.
>
> Comments?
Not opposed in principle. But it would be much more sensible to have
something like $GIT_META_ENCODING (defaulting probably to utf8), recode
to whatever is your current locale, have the appropriate setting in the
configfile, ...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: NT directory traversal speed on 25K files on Cygwin
From: Christopher Faylor @ 2006-02-27 1:18 UTC (permalink / raw)
To: git
In-Reply-To: <20060226231701.GA11961@nospam.com>
On Mon, Feb 27, 2006 at 12:17:01AM +0100, Rutger Nijlunsing wrote:
>On Sun, Feb 26, 2006 at 02:55:52PM -0500, Christopher Faylor wrote:
>>On Thu, Feb 23, 2006 at 03:07:07PM +0100, Alex Riesen wrote:
>>>filesystem is slow and locked down, and exec-attribute is NOT really
>>>useful even on NTFS (it is somehow related to execute permission and
>>>open files. I still cannot figure out how exactly are they related).
>>
>>Again, it's not clear if you're talking about Windows or Cygwin but
>>under Cygwin, in the default configuration, the exec attribute means
>>the same thing to cygwin as it does to linux.
>
>I don't know about native Windows speed, but comparing NutCracker with
>Cygwin on a simple 'find . | wc -l' already gives a clue that looking
>at Cygwin to benchmark NT file inspection IO will give a skewed
>picture:
>
>##### NutCracker $ time find . | wc -l
>
>real 0m 1.44s
>user 0m 0.45s
>sys 0m 0.98s
>25794
>
>##### Cygwin $ time c:\\cygwin\\bin\\find . | wc -l
>
>real 0m 6.72s
>user 0m 1.09s
>sys 0m 5.59s
>25794
>
>##### CMD.EXE + DIR /S C:\PROJECT> c:\cygwin\bin\time cmd /c dir /s
>>NUL 0.01user 0.01system 0:05.70elapsed 0%CPU (0avgtext+0avgdata
>6320maxresident)k 0inputs+0outputs (395major+0minor)pagefaults 0swaps
>
>##### Cygwin 'find -ls' (NutCracker doesn't have a '-ls') C:\PROJECT>
>c:\cygwin\bin\time c:\cygwin\bin\find -ls | wc -l 2.79user 7.81system
>0:10.60elapsed 100%CPU (0avgtext+0avgdata 14480maxresident)k 25794
I'm lost. What does this have to do with the exec attribute?
Or, were you just climbing aboard the "Cygwin sure is slow" bandwagon?
cgf
^ permalink raw reply
* [ANNOUNCE] Cogito-0.17
From: Petr Baudis @ 2006-02-27 1:16 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The last winter snow
leaves but Cogito comes in
its place, snow-white 0.17
(*)
After some random bugfixes I got no more bugreports so this feels
stable enough for a release. The rest of this mail will mostly be
a rehash of the 0.17rc1 announcement; the rc2-to-0.17 bugfixes were
rather dull.
Huge amount of new features and cool stuff. The highlight is cg-switch
for switching between local branches and massive cg-patch improvements,
but there is plenty of other stuff as well. Read on for more details.
The notable new stuff includes:
* cg-switch - Cogito finally gives you the full convenience of
multiple local branches in a single repository ;)
* cg-patch -c, -C, -d - Cogito now supports cherrypicking, easy commit
reverts and automatic committing of applied patches
* Resumable cg-clone - if cg-clone fails in the middle of the initial
fetch, the directory is not deleted and you do not have to start all
over again - just cd inside and run cg-fetch and it will DTRT
* Support for tracking rebasing branches; as long as you use cg-update
(NOT cg-fetch + cg-merge) and won't commit local changes, Cogito
will correctly update the branch even if it got rebased in the
meanwhile
* Quoting fixes - this means that Cogito should be now theoretically
100% resilient to whitespaces and metacharacters in filenames etc.
Note that filenames containing newlines still aren't supported and
aren't likely to ever be. You are a loonie. Go away.
* Radically improved cg-fetch progressbar; it still doesn't quite work
with rsync (use cg-fetch -v -v), but I don't think that can be
helped. The main advantage is that it will show HTTP fetch progress
even when fetching large files (especially packs).
* Much more sensible behaviour for cg-clean wrt. untracked directories
(do not erase their content).
* Significant merges speedup (but still quite some potential for
improvement)
* cg-* --help now by default shows only short help; use --long-help
to see the full manual
* cg-commit --signoff
* cg-commit --review to review and even modify the patch you are
committing
* cg-commit -M to take the commit message from a file
* bash commandline autocompletion files in contrib/
* cg-fetch -v, cg-fetch -v -v, cg-merge -v, cg-update -v
* cg-push -r to push a different branch (or even a specific commit)
instead of your current branch
* cg-rm -r for recursive directories removal
* cg-mv trivial wrapper for git-mv
* cg-push over HTTP
* cg-patch -u for applying non-git patches while autoadding/removing
files, cg-patch -pN with obvious meaning
* cg-object-id -d for short human-readable commit string id
(just wraps git-describe)
* Too many minor new features to list here
* Incompatible change - cg-log -d renamed to cg-log -D
* Incompatible change - the post-commit hook won't be ran for all the
merged commits anymore when you commit a merge; you can reenable
that in .git/config, see the cg-commit documentation for details
P.S.: See us at #git @ FreeNode!
P.P.S.: (*) That means bug-free, if it wasn't obvious!
P.P.P.S.: Yes, it just occurred to me that I've forgot about the
pre-built documentation, but it's too late in the night by now. Sorry,
the next time.
Happy hacking,
--
Petr "Pasky the lousy poet" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: Recoding of {git,cg}-log output
From: Krzysiek Pawlik @ 2006-02-27 0:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0602270133330.5275@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]
Johannes Schindelin wrote:
> Of course, you could always set up a script doing the recoding and
> the paging, like
No.
> The advantage of this approach compared to adjusting git is that
> other programs use PAGER, too.
Passing code (web pages, etc) throught iconv is not a good idea -
{git,cg}-diff should show the file content as it is, not altered by iconv.
Changing PAGER is a bit... ugly and messy way of doing it. Assume that I
work on some files and want to look at some unversioned files outside
the tree (like docs, man pages, whatever) and the $PAGER passes the
legitimate ISO8859-2 files through iconv, what gives us garbage. And we
end up changing pager very often - Bad Idea (TM).
--
Krzysiek Pawlik (Nelchael)
RLU #322999 GPG Key ID: 0xBC555551
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: the war on trailing whitespace
From: Junio C Hamano @ 2006-02-27 0:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, junkio, git
In-Reply-To: <Pine.LNX.4.64.0602261213340.22647@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Personally, I don't mind whitespace that much. In particular, I _suspect_
> I often have empty lines like
>
> int i;
>
> i = 10;
>
> where the "empty" line actually has the same indentation as the lines
> around it. Is that wrong? Perhaps.
Yes, you do, and I hand-fixed one a couple of minutes ago ;-).
Regarding git-apply change, I suspect warn_on_whitespace should
not squelch itself after the first one, and error_on_whitespace
should not die instantly. The sample pre-applypatch hook (it
was missing code to figure out where GIT_DIR was so it never
worked as shipped; corrected in "master") shows line numbers of
suspicious lines from the files being patched. They can be
manually fixed up, and then "git am --resolved", if the
integrator is in a better mood.
The error messages from pre-commit/pre-applypatch hook mimic the
way compiler errors are spit out, so that it works well in Emacs
compilation buffer -- doing C-x ` (next-error) takes you the
line the error appears and lets you edit it.
^ permalink raw reply
* Re: Recoding of {git,cg}-log output
From: Johannes Schindelin @ 2006-02-27 0:36 UTC (permalink / raw)
To: Krzysiek Pawlik; +Cc: Git Mailing List
In-Reply-To: <44024384.4060406@people.pl>
Hi,
On Mon, 27 Feb 2006, Krzysiek Pawlik wrote:
> First: a little "why": having /usr/bin/vim as PAGER allows to enter
> UTF-8 commit messages quite easily, the problem is when git-log (or
> cg-log) is run in terminal that's not UTF-8.
Of course, you could always set up a script doing the recoding and the
paging, like
-- snip --
#!/bin/sh
iconv -f UTF-8 -t ISO-8859-2 "$@" | vim
-- snap --
and point your PAGER to that script (which is untested BTW). The advantage
of this approach compared to adjusting git is that other programs use
PAGER, too.
Hth,
Dscho
^ permalink raw reply
* Re: Make git diff-generation use a simpler spawn-like interface
From: Junio C Hamano @ 2006-02-27 0:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602261547440.22647@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> This actually ends up simplifying the code, and should make it much
> easier to make it efficient under broken operating systems (read: Windows).
>
> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
> ---
>
> Now, somebody else might disagree with my contention that this also makes
> things simpler, but I like how we separate out the "run an external
> program" phase from the actual setup and header printing phase.
I agree this is going in the right direction.
A note that is offtopic to this particular patch but is related
to Andrew's point. I had a wrong version of pre-applypatch hook
in the sample shipped as "templates", and after I rebuilt my
private development repository I've been running with the
version without a fix I personally had. I've pushed out the fix
in the master branch.
I'll look at your patch to git-apply next.
^ permalink raw reply
* [PATCH] contrib/git-svn: add show-ignore command
From: Eric Wong @ 2006-02-27 0:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060226234601.GA28732@localdomain>
Recursively finds and lists the svn:ignore property on
directories. The output is suitable for appending to the
$GIT_DIR/info/exclude file.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Note: Whitespace cleaned
contrib/git-svn/git-svn.perl | 25 +++++++++++++++++++++++++
contrib/git-svn/git-svn.txt | 7 +++++++
2 files changed, 32 insertions(+), 0 deletions(-)
63b497ce5f0762cdfef3ef30ec658b8c98e1a144
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index a32ce15..3d855f1 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -49,6 +49,7 @@ my %cmd = (
fetch => [ \&fetch, "Download new revisions from SVN" ],
init => [ \&init, "Initialize and fetch (import)"],
commit => [ \&commit, "Commit git revisions to SVN" ],
+ 'show-ignore' => [ \&show_ignore, "Show svn:ignore listings" ],
rebuild => [ \&rebuild, "Rebuild git-svn metadata (after git clone)" ],
help => [ \&usage, "Show help" ],
);
@@ -258,6 +259,30 @@ sub commit {
}
+sub show_ignore {
+ require File::Find or die $!;
+ my $exclude_file = "$GIT_DIR/info/exclude";
+ open my $fh, '<', $exclude_file or croak $!;
+ chomp(my @excludes = (<$fh>));
+ close $fh or croak $!;
+
+ $SVN_URL ||= file_to_s("$GIT_DIR/$GIT_SVN/info/url");
+ chdir $SVN_WC or croak $!;
+ my %ign;
+ File::Find::find({wanted=>sub{if(lstat $_ && -d _ && -d "$_/.svn"){
+ s#^\./##;
+ @{$ign{$_}} = safe_qx(qw(svn propget svn:ignore),$_);
+ }}, no_chdir=>1},'.');
+
+ print "\n# /\n";
+ foreach (@{$ign{'.'}}) { print '/',$_ if /\S/ }
+ delete $ign{'.'};
+ foreach my $i (sort keys %ign) {
+ print "\n# ",$i,"\n";
+ foreach (@{$ign{$i}}) { print '/',$i,'/',$_ if /\S/ }
+ }
+}
+
########################### utility functions #########################
sub setup_git_svn {
diff --git a/contrib/git-svn/git-svn.txt b/contrib/git-svn/git-svn.txt
index cf098d7..b4b7789 100644
--- a/contrib/git-svn/git-svn.txt
+++ b/contrib/git-svn/git-svn.txt
@@ -61,6 +61,11 @@ rebuild::
the directory/repository you're tracking has moved or changed
protocols.
+show-ignore::
+ Recursively finds and lists the svn:ignore property on
+ directories. The output is suitable for appending to
+ the $GIT_DIR/info/exclude file.
+
OPTIONS
-------
-r <ARG>::
@@ -152,6 +157,8 @@ Tracking and contributing to an Subversi
git commit git-svn-HEAD..my-branch
# Something is committed to SVN, pull the latest into your branch::
git-svn fetch && git pull . git-svn-HEAD
+# Append svn:ignore settings to the default git exclude file:
+ git-svn show-ignore >> .git/info/exclude
DESIGN PHILOSOPHY
-----------------
--
1.2.2.ga559
^ permalink raw reply related
* Recoding of {git,cg}-log output
From: Krzysiek Pawlik @ 2006-02-27 0:10 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 873 bytes --]
First: a little "why": having /usr/bin/vim as PAGER allows to enter
UTF-8 commit messages quite easily, the problem is when git-log (or
cg-log) is run in terminal that's not UTF-8. In my case: terminal is
ISO-8859-2 and:
nelchael@nelchael ~$ cat ~/.vimrc | grep gitci
au BufRead /tmp/gitci* setlocal textwidth=75 fileencoding=utf-8
encoding=utf-8 fileencodings=utf-8,default
So... having {git,cg}-log recode the log entires when displaying is
quite useful. Two patches attached:
a. git-log-recode.patch - uses iconv to recode the log output to
GIT_LOG_RECODE encoding
b. cg-log-recode.patch - the same, but for cogito
With this patches it's possible to write UTF-8 commit messages and see
them ok in non-UTF-8 terminal in log by having GIT_LOG_RECODE=iso-8859-2.
Comments?
--
Krzysiek Pawlik (Nelchael)
RLU #322999 GPG Key ID: 0xBC555551
[-- Attachment #1.2: cg-log-recode.patch --]
[-- Type: text/plain, Size: 889 bytes --]
--- /usr/bin/cg-log 2006-01-19 17:22:22.000000000 +0100
+++ bin/cg-log 2006-02-27 00:59:07.000000000 +0100
@@ -348,13 +348,21 @@
if [ "$shortlog" ]; then
# Special care here.
- $revls $sep "${ARGS[@]}" | git-shortlog | pager
+ if [ -n "${GIT_LOG_RECODE}" ]; then
+ $revls $sep "${ARGS[@]}" | git-shortlog | iconv --from-code=UTF-8 --to-code="${GIT_LOG_RECODE}" | pager
+ else
+ $revls $sep "${ARGS[@]}" | git-shortlog | pager
+ fi
exit
fi
# LESS="S" will prevent less to wrap too long titles to multiple lines;
# you can scroll horizontally.
-$revls $sep "${ARGS[@]}" | print_commit_log | _local_CG_LESS="S" pager
+if [ -n "${GIT_LOG_RECODE}" ]; then
+ $revls $sep "${ARGS[@]}" | print_commit_log | iconv --from-code=UTF-8 --to-code="${GIT_LOG_RECODE}" | _local_CG_LESS="S" pager
+else
+ $revls $sep "${ARGS[@]}" | print_commit_log | _local_CG_LESS="S" pager
+fi
exit 0
[-- Attachment #1.3: git-log-recode.patch --]
[-- Type: text/plain, Size: 544 bytes --]
--- /usr/bin/git-log 2006-02-23 18:31:32.000000000 +0100
+++ bin/git-log 2006-02-27 00:47:34.000000000 +0100
@@ -11,5 +11,11 @@
[ "$revs" ] || {
die "No HEAD ref"
}
-git-rev-list --pretty $(git-rev-parse --default HEAD "$@") |
-LESS=-S ${PAGER:-less}
+if [ -n "${GIT_LOG_RECODE}" ]; then
+ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \
+ iconv --from-code=UTF-8 --to-code="${GIT_LOG_RECODE}" | \
+ LESS=-S ${PAGER:-less}
+else
+ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \
+ LESS=-S ${PAGER:-less}
+fi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: git-svn and working with tags
From: Eric Wong @ 2006-02-27 0:07 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <4401933B.2070109@iaglans.de>
Nicolas Vilz 'niv' <niv@iaglans.de> wrote:
> Hi guys,
>
> I am about to use a git/svn construct for a project next week to track
> my work and the work of my co-workers.
>
> Reason for this is, that all the others are working on windows-boxes and
> I am the lonesome gunman, who wants to work with git on a linux box
> contributing the others on svn side.
>
> There is still a lot of work todo, preparing both backends, git and svn,
> for serving almost the same content structure.
>
> I think, i can do a little scripting to switch my git-SVN-HEAD to
> another branch. But how am i intended to export tags to svn?
>
> tags should simply go to <repos>/tags/<tagname>
> branches go to <repos>/branches/<branchname>
> master goes to <repos>/trunk
>
> A svn-import should be no problem then. The re-exporting back to one
> branch or svn_path is described in git-svn howto. but how about tags?
>
> do i have to consider the tags on svn-side manually?
You'll need to do tags on the svn-side manually. git-svn (by-design)
has hardly any notion of SVN tags (they're really just branches
designated as read-only). git-svn also fails to track directory copies
[1], so using git-svn to track a higher-level directory and performing a
copy in git and doing git-svn commit may not work so well.
You can make something that parses a git commit that was imported in
git-svn-HEAD. These imported commits have a 'git-svn-id:' line at the
end that can be parsed for URL and revision number, so you could make it
frontend 'svn cp' pretty easily.
[1]: git-diff-* doesn't notice copied/renamed directories. I'm
actually very thankful for this as it's very prone to bugs in my
experience.
--
Eric Wong
^ permalink raw reply
* Make git diff-generation use a simpler spawn-like interface
From: Linus Torvalds @ 2006-02-26 23:51 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Instead of depending of fork() and execve() and doing things in between
the two, make the git diff functions do everything up front, and then do
a single "spawn_prog()" invocation to run the actual external diff
program (if any is even needed).
This actually ends up simplifying the code, and should make it much
easier to make it efficient under broken operating systems (read: Windows).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
Now, somebody else might disagree with my contention that this also makes
things simpler, but I like how we separate out the "run an external
program" phase from the actual setup and header printing phase.
Of course, it still uses fork/execvp here, but now it should be _trivial_
to just have a windows-optimized version of "spawn_prog()" that does that
Windows thang.
Linus
diff --git a/diff.c b/diff.c
index 804c08c..32da5d7 100644
--- a/diff.c
+++ b/diff.c
@@ -178,11 +178,12 @@ static void emit_rewrite_diff(const char
copy_file('+', temp[1].name);
}
-static void builtin_diff(const char *name_a,
+static const char *builtin_diff(const char *name_a,
const char *name_b,
struct diff_tempfile *temp,
const char *xfrm_msg,
- int complete_rewrite)
+ int complete_rewrite,
+ const char **args)
{
int i, next_at, cmd_size;
const char *const diff_cmd = "diff -L%s -L%s";
@@ -242,19 +243,24 @@ static void builtin_diff(const char *nam
}
if (xfrm_msg && xfrm_msg[0])
puts(xfrm_msg);
+ /*
+ * we do not run diff between different kind
+ * of objects.
+ */
if (strncmp(temp[0].mode, temp[1].mode, 3))
- /* we do not run diff between different kind
- * of objects.
- */
- exit(0);
+ return NULL;
if (complete_rewrite) {
- fflush(NULL);
emit_rewrite_diff(name_a, name_b, temp);
- exit(0);
+ return NULL;
}
}
- fflush(NULL);
- execlp("/bin/sh","sh", "-c", cmd, NULL);
+
+ /* This is disgusting */
+ *args++ = "sh";
+ *args++ = "-c";
+ *args++ = cmd;
+ *args = NULL;
+ return "/bin/sh";
}
struct diff_filespec *alloc_filespec(const char *path)
@@ -559,6 +565,40 @@ static void remove_tempfile_on_signal(in
raise(signo);
}
+static int spawn_prog(const char *pgm, const char **arg)
+{
+ pid_t pid;
+ int status;
+
+ fflush(NULL);
+ pid = fork();
+ if (pid < 0)
+ die("unable to fork");
+ if (!pid) {
+ execvp(pgm, (char *const*) arg);
+ exit(255);
+ }
+
+ while (waitpid(pid, &status, 0) < 0) {
+ if (errno == EINTR)
+ continue;
+ return -1;
+ }
+
+ /* Earlier we did not check the exit status because
+ * diff exits non-zero if files are different, and
+ * we are not interested in knowing that. It was a
+ * mistake which made it harder to quit a diff-*
+ * session that uses the git-apply-patch-script as
+ * the GIT_EXTERNAL_DIFF. A custom GIT_EXTERNAL_DIFF
+ * should also exit non-zero only when it wants to
+ * abort the entire diff-* session.
+ */
+ if (WIFEXITED(status) && !WEXITSTATUS(status))
+ return 0;
+ return -1;
+}
+
/* An external diff command takes:
*
* diff-cmd name infile1 infile1-sha1 infile1-mode \
@@ -573,9 +613,9 @@ static void run_external_diff(const char
const char *xfrm_msg,
int complete_rewrite)
{
+ const char *spawn_arg[10];
struct diff_tempfile *temp = diff_temp;
- pid_t pid;
- int status;
+ int retval;
static int atexit_asked = 0;
const char *othername;
@@ -592,59 +632,41 @@ static void run_external_diff(const char
signal(SIGINT, remove_tempfile_on_signal);
}
- fflush(NULL);
- pid = fork();
- if (pid < 0)
- die("unable to fork");
- if (!pid) {
- if (pgm) {
- if (one && two) {
- const char *exec_arg[10];
- const char **arg = &exec_arg[0];
- *arg++ = pgm;
- *arg++ = name;
- *arg++ = temp[0].name;
- *arg++ = temp[0].hex;
- *arg++ = temp[0].mode;
- *arg++ = temp[1].name;
- *arg++ = temp[1].hex;
- *arg++ = temp[1].mode;
- if (other) {
- *arg++ = other;
- *arg++ = xfrm_msg;
- }
- *arg = NULL;
- execvp(pgm, (char *const*) exec_arg);
+ if (pgm) {
+ const char **arg = &spawn_arg[0];
+ if (one && two) {
+ *arg++ = pgm;
+ *arg++ = name;
+ *arg++ = temp[0].name;
+ *arg++ = temp[0].hex;
+ *arg++ = temp[0].mode;
+ *arg++ = temp[1].name;
+ *arg++ = temp[1].hex;
+ *arg++ = temp[1].mode;
+ if (other) {
+ *arg++ = other;
+ *arg++ = xfrm_msg;
}
- else
- execlp(pgm, pgm, name, NULL);
+ } else {
+ *arg++ = pgm;
+ *arg++ = name;
}
- /*
- * otherwise we use the built-in one.
- */
- if (one && two)
- builtin_diff(name, othername, temp, xfrm_msg,
- complete_rewrite);
- else
+ *arg = NULL;
+ } else {
+ if (one && two) {
+ pgm = builtin_diff(name, othername, temp, xfrm_msg, complete_rewrite, spawn_arg);
+ } else
printf("* Unmerged path %s\n", name);
- exit(0);
}
- if (waitpid(pid, &status, 0) < 0 ||
- !WIFEXITED(status) || WEXITSTATUS(status)) {
- /* Earlier we did not check the exit status because
- * diff exits non-zero if files are different, and
- * we are not interested in knowing that. It was a
- * mistake which made it harder to quit a diff-*
- * session that uses the git-apply-patch-script as
- * the GIT_EXTERNAL_DIFF. A custom GIT_EXTERNAL_DIFF
- * should also exit non-zero only when it wants to
- * abort the entire diff-* session.
- */
- remove_tempfile();
+
+ retval = 0;
+ if (pgm)
+ retval = spawn_prog(pgm, spawn_arg);
+ remove_tempfile();
+ if (retval) {
fprintf(stderr, "external diff died, stopping at %s.\n", name);
exit(1);
}
- remove_tempfile();
}
static void diff_fill_sha1_info(struct diff_filespec *one)
^ 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