* Re: SIGSEGV in merge recursive
From: Luben Tuikov @ 2006-12-29 20:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7iwampi4.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > This time it happens when merging one of my git trees into another:
> > ...
> > And here is the backtrace:
> >
> > $gdb ~/bin/git-merge-recursive
> > GNU gdb 6.5
> > Copyright (C) 2006 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB. Type "show warranty" for details.
> > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library
> > "/lib/libthread_db.so.1".
> >
> > (gdb) run 777f68432f1db967573e5722bf0fd08af05e748f -- HEAD
> > d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7
> > Starting program: /home/luben/bin/git-merge-recursive 777f68432f1db967573e5722bf0fd08af05e748f
> --
> > HEAD d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7
> > Failed to read a valid object file image from memory.
>
> Who says this?
>
> > Merging HEAD with d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7
> > Merging:
> > 52d5052 Merge branch 'git-upstream' into git-lt-work
> > d985fda Merge branch 'next' into git-upstream
> > found 1 common ancestor(s):
> > 777f684 Merge branch 'next' into git-upstream
> > Auto-merging .gitignore
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x08070469 in xdl_merge (orig=0xbff3aae0, mf1=0xbff3aad8,
> > name1=0x80f5208 "HEAD:.gitignore", mf2=0xbff3aad0,
> > name2=0x80f59a8 "d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7:.gitignore",
> > xpp=0xbff3aae8, level=2, result=0xbff3aac8) at xdiff/xmerge.c:200
> > warning: Source file is more recent than executable.
> > 200 */
>
> What local mods are you running with?
Not much -- the one-offs you've sent to git and me to fix various
problems I've complained about, some scripts of mine which have nothing
to do with merging. The log of the commits diff between next and
git-lt-work doesn't show anything in the merge area -- only things
I've been active in like gitweb, etc.
Luben
^ permalink raw reply
* Re: [PATCH/RFH] send-pack: fix pipeline.
From: Junio C Hamano @ 2006-12-29 20:13 UTC (permalink / raw)
To: git; +Cc: Andy Whitcroft, Linus Torvalds
In-Reply-To: <7v1wmjoumq.fsf@assigned-by-dhcp.cox.net>
I really need a sanity checking on this one. I think I got the
botched pipeline fixed with the patch I am replying to, but I do
not understand the waitpid() business. Care to enlighten me?
-- >8 --
Documentation/technical/send-pack-pipeline.txt | 112 ++++++++++++++++++++++++
1 files changed, 112 insertions(+), 0 deletions(-)
create mode 100644 Documentation/technical/send-pack-pipeline.txt
diff --git a/Documentation/technical/send-pack-pipeline.txt b/Documentation/technical/send-pack-pipeline.txt
new file mode 100644
index 0000000..bd32aff
--- /dev/null
+++ b/Documentation/technical/send-pack-pipeline.txt
@@ -0,0 +1,112 @@
+git-send-pack
+=============
+
+Overall operation
+-----------------
+
+. Connects to the remote side and invokes git-receive-pack.
+
+. Learns what refs the remote has and what commit they point at.
+ Matches them to the refspecs we are pushing.
+
+. Checks if there are non-fast-forwards. Unlike fetch-pack,
+ the repository send-pack runs in is supposed to be a superset
+ of the recipient in fast-forward cases, so there is no need
+ for want/have exchanges, and fast-forward check can be done
+ locally. Tell the result to the other end.
+
+. Calls pack_objects() which generates a packfile and sends it
+ over to the other end.
+
+. If the remote side is new enough (v1.1.0 or later), wait for
+ the unpack and hook status from the other end.
+
+. Exit with appropriate error codes.
+
+
+Pack_objects pipeline
+---------------------
+
+This function gets one file descriptor (`out`) which is either a
+socket (over the network) or a pipe (local). What's written to
+this fd goes to git-receive-pack to be unpacked.
+
+ send-pack ---> fd ---> receive-pack
+
+It somehow forks once, but does not wait for it. I am not sure
+why.
+
+The forked child calls rev_list_generate() with that file
+descriptor (while the parent closes `out` -- the child will be
+the one that writes the packfile to the other end).
+
+ send-pack
+ |
+ rev-list-generate ---> fd ---> receive-pack
+
+
+Then rev-list-generate forks after creates a pipe; the child
+will become a pipeline "rev-list --stdin | pack-objects", which
+is the rev_list() function, while the parent feeds that pipeline
+the list of refs.
+
+ send-pack
+ |
+ rev-list-generate ---> fd ---> receive-pack
+ | ^ (pipe)
+ v |
+ rev-list
+
+The child process, before calling rev-list, rearranges the file
+descriptors:
+
+. what it reads from rev-list-generate via pipe becomes the
+ stdin; this is to feed the upstream of the pipeline which will
+ be git-rev-list process.
+
+. what it writes to its stdout goes to the fd connected to
+ receive-pack.
+
+On the other hand, the parent process, before starting to feed
+the child pipeline, closes the reading side of the pipe and fd
+to receive-pack.
+
+ send-pack
+ |
+ rev-list-generate
+ |
+ v [0]
+ rev-list [1] ---> receive-pack
+
+The parent then writes to the pipe and later closes it. There
+is a commented out waitpid to wait for the rev-list side before
+it exits, I again do not understand why.
+
+The rev-list function further sets up a pipe and forks to run
+git-rev-list piped to git-pack-objects. The child side, before
+exec'ing git-pack-objects, rearranges the file descriptors:
+
+. what it reads from the pipe becomes the stdin; this gets the
+ list of objects from the git-rev-list process.
+
+. its stdout is already connected to receive-pack, so what it
+ generates goes there.
+
+The parent process arranges its file descriptors before exec'ing
+git-rev-list:
+
+. its stdout is sent to the pipe to feed git-pack-objects.
+
+. its stdin is already connected to rev-list-generate and will
+ read the set of refs from it.
+
+
+ send-pack
+ |
+ rev-list-generate
+ |
+ v [0]
+ git-rev-list [1] ---> [0] git-pack-objects [1] ---> receive-pack
+
+
+
^ permalink raw reply related
* Re: SIGSEGV in merge recursive
From: Junio C Hamano @ 2006-12-29 20:11 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <699806.13055.qm@web31803.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> This time it happens when merging one of my git trees into another:
> ...
> And here is the backtrace:
>
> $gdb ~/bin/git-merge-recursive
> GNU gdb 6.5
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library
> "/lib/libthread_db.so.1".
>
> (gdb) run 777f68432f1db967573e5722bf0fd08af05e748f -- HEAD
> d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7
> Starting program: /home/luben/bin/git-merge-recursive 777f68432f1db967573e5722bf0fd08af05e748f --
> HEAD d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7
> Failed to read a valid object file image from memory.
Who says this?
> Merging HEAD with d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7
> Merging:
> 52d5052 Merge branch 'git-upstream' into git-lt-work
> d985fda Merge branch 'next' into git-upstream
> found 1 common ancestor(s):
> 777f684 Merge branch 'next' into git-upstream
> Auto-merging .gitignore
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x08070469 in xdl_merge (orig=0xbff3aae0, mf1=0xbff3aad8,
> name1=0x80f5208 "HEAD:.gitignore", mf2=0xbff3aad0,
> name2=0x80f59a8 "d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7:.gitignore",
> xpp=0xbff3aae8, level=2, result=0xbff3aac8) at xdiff/xmerge.c:200
> warning: Source file is more recent than executable.
> 200 */
What local mods are you running with?
^ permalink raw reply
* SIGSEGV in merge recursive
From: Luben Tuikov @ 2006-12-29 19:49 UTC (permalink / raw)
To: git
This time it happens when merging one of my git trees into another:
$git-pull . git-upstream
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
git-merge-recursive 777f68432f1db967573e5722bf0fd08af05e748f -- HEAD
d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7
Merging HEAD with d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7
Merging:
52d5052 Merge branch 'git-upstream' into git-lt-work
d985fda Merge branch 'next' into git-upstream
found 1 common ancestor(s):
777f684 Merge branch 'next' into git-upstream
Auto-merging .gitignore
/home/luben/bin/git-merge: line 441: 2889 Segmentation fault git-merge-$strategy $common --
"$head_arg" "$@"
Merge with strategy recursive failed.
(git-upstream has already had "next" merged into it without a problem.)
And here is the backtrace:
$gdb ~/bin/git-merge-recursive
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library
"/lib/libthread_db.so.1".
(gdb) run 777f68432f1db967573e5722bf0fd08af05e748f -- HEAD
d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7
Starting program: /home/luben/bin/git-merge-recursive 777f68432f1db967573e5722bf0fd08af05e748f --
HEAD d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7
Failed to read a valid object file image from memory.
Merging HEAD with d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7
Merging:
52d5052 Merge branch 'git-upstream' into git-lt-work
d985fda Merge branch 'next' into git-upstream
found 1 common ancestor(s):
777f684 Merge branch 'next' into git-upstream
Auto-merging .gitignore
Program received signal SIGSEGV, Segmentation fault.
0x08070469 in xdl_merge (orig=0xbff3aae0, mf1=0xbff3aad8,
name1=0x80f5208 "HEAD:.gitignore", mf2=0xbff3aad0,
name2=0x80f59a8 "d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7:.gitignore",
xpp=0xbff3aae8, level=2, result=0xbff3aac8) at xdiff/xmerge.c:200
warning: Source file is more recent than executable.
200 */
(gdb) bt
#0 0x08070469 in xdl_merge (orig=0xbff3aae0, mf1=0xbff3aad8,
name1=0x80f5208 "HEAD:.gitignore", mf2=0xbff3aad0,
name2=0x80f59a8 "d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7:.gitignore",
xpp=0xbff3aae8, level=2, result=0xbff3aac8) at xdiff/xmerge.c:200
#1 0x0804a6c2 in merge_file (o=0xbff3accc, a=0xbff3ac74, b=0xbff3aca0,
branch1=0xbff3c928 "HEAD",
branch2=0xbff3c92d "d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7")
at merge-recursive.c:660
#2 0x0804c296 in merge_trees (head=0x80924c8, merge=0x80924e8,
common=0x8092508, branch1=<value optimized out>,
branch2=<value optimized out>, result=0xbff3add0) at merge-recursive.c:1067
#3 0x0804c9cd in merge (h1=0x80874c0, h2=0x8087544,
branch1=0xbff3c928 "HEAD",
branch2=0xbff3c92d "d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7",
call_depth=0, ancestor=0x8087518, result=0xbff3ae24)
at merge-recursive.c:1238
#4 0x0804cc78 in main (argc=3, argv=0xbff3aea4) at merge-recursive.c:1320
Luben
^ permalink raw reply
* Re: read-for-fill and caching in gitweb (Re: kernel.org mirroring)
From: Robert Fitzsimons @ 2006-12-29 19:31 UTC (permalink / raw)
To: Jakub Narebski
Cc: Robert Fitzsimons, Martin Langhoff, Linus Torvalds, Jeff Garzik,
H. Peter Anvin, Rogan Dawes, Kernel Org Admin, Git Mailing List
In-Reply-To: <200612291140.46909.jnareb@gmail.com>
> > project_list summary shortlog log
> > v267 173 1.6 1141 8.8 795 5.0 919 1.9
> > 1.4.4.3 220 2.3 397 2.4 930 4.2 1113 56.9
> > 1.5.0.rc0.g4a4d 226 1.9 292 1.7 352 4.0 491 6.7
> > 1.5.0.rc0.g4a4d 60 1.0 131 0.7 195 1.2 347 3.7
> > (mod_perl)
> It is simply the case that new features cost more. Namely in earlier
> versions of gitweb Last Change time was taken from HEAD (from current
> branch), in newer we check all branches (using git-for-each-ref).
> For published public repository it migh make sense to pack also heads
> (make them packed refs).
>
> I was thinking about making this a gitweb %feature, allowing gitweb
> administrator to chose if Last Change is taken from all branches
> (as it is now), from HEAD (as it was before), or from given branch
> (for example master).
I've sent a separate email with a patch to add this feature.
("[PATCH] gitweb: New feature last_modified_ref."
<20061229185805.GF6558@localhost>).
Here are the new numbers. Notes: I've only got 3 projects in my project
list and I did a 'git gc' on them since yesterday.
project_list summary shortlog log
v267 174 1.1 286 2.1 794 3.4 921 3.2
1.4.4.3 207 1.7 383 2.0 921 5.2 1082 3.8
g04509 + patch 213 1.6 297 68.9 341 3.9 484 5.0
g04509 + patch 71 69.9 117 2.5 190 2.1 341 2.7
(mod_perl)
g04509 + patch 209 1.0 276 1.5 342 3.3 483 6.3
(HEAD)
g04509 + patch 66 70.1 117 2.6 189 3.4 341 3.8
(HEAD, mod_perl)
The v267 summary time is wrong, that version of gitweb is not
packed-refs aware.
I think I need a more consistent test setup I'm seeing some weird
deviations.
Robert
^ permalink raw reply
* Re: [PATCH] gitweb: New feature last_modified_ref.
From: Junio C Hamano @ 2006-12-29 19:12 UTC (permalink / raw)
To: Robert Fitzsimons; +Cc: Jakub Narebski, Martin Langhoff, git
In-Reply-To: <20061229185805.GF6558@localhost>
I somehow suspect this is solving the problem with a wrong
tradeoff.
This change only affects the project list page, which I think is
simpler to deal with more aggressive caching (say, no more than
once every 10 minutes even if some project pushed a new head in
the meantime).
Not a firm refusal, but something to think about.
^ permalink raw reply
* [PATCH] gitweb: New feature last_modified_ref.
From: Robert Fitzsimons @ 2006-12-29 18:58 UTC (permalink / raw)
To: Git Mailing List; +Cc: Jakub Narebski, Martin Langhoff
Added a new feature which allows the gitweb administrator to set a
symbolic ref name that will be used to work out the Last Change value
for the project_list action. This was suggested by Jakub Narebski in
<200612291140.46909.jnareb@gmail.com>.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
---
gitweb/gitweb.perl | 52 +++++++++++++++++++++++++++++++++++++++++++---------
1 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d845e91..9fb5208 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -185,6 +185,21 @@ our %feature = (
'forks' => {
'override' => 0,
'default' => [0]},
+
+ # Set a symbolic ref name that will be used to working out the Last
+ # Change value for the project_list action. If the ref name does not
+ # exist for a project or the ref name is undefined, the code will fall
+ # back on doing a 'for-each-ref refs/heads'.
+ #
+ # To enable system wide have in $GITWEB_CONFIG
+ # $feature{'last_activity_ref'}{'default'} = ['HEAD'];
+ # or
+ # $feature{'last_activity_ref'}{'default'} = ['refs/heads/master'];
+ # etc.
+ # Project specific override is not supported.
+ 'last_activity_ref' => {
+ 'override' => 0,
+ 'default' => [undef]},
);
sub gitweb_check_feature {
@@ -1147,17 +1162,35 @@ sub git_get_project_owner {
}
sub git_get_last_activity {
- my ($path) = @_;
+ my ($path, $ref) = @_;
my $fd;
+ my $most_recent = undef;
$git_dir = "$projectroot/$path";
- open($fd, "-|", git_cmd(), 'for-each-ref',
- '--format=%(committer)',
- '--sort=-committerdate',
- '--count=1',
- 'refs/heads') or return;
- my $most_recent = <$fd>;
- close $fd or return;
+
+ if (defined $ref) {
+ open($fd, "-|", git_cmd(), "cat-file",
+ "commit",
+ $ref) or return;
+ while (my $line = <$fd>) {
+ last if $line eq "\n";
+ if ($line =~ m/^committer /) {
+ $most_recent = $line;
+ last;
+ }
+ }
+ close $fd;
+ }
+ if (!defined $most_recent) {
+ open($fd, "-|", git_cmd(), 'for-each-ref',
+ '--format=%(committer)',
+ '--sort=-committerdate',
+ '--count=1',
+ 'refs/heads') or return;
+ $most_recent = <$fd>;
+ close $fd or return;
+ }
+
if ($most_recent =~ / (\d+) [-+][01]\d\d\d$/) {
my $timestamp = $1;
my $age = time - $timestamp;
@@ -2561,10 +2594,11 @@ sub git_project_list_body {
my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
my ($check_forks) = gitweb_check_feature('forks');
+ my ($last_activity_ref) = gitweb_check_feature('last_activity_ref');
my @projects;
foreach my $pr (@$projlist) {
- my (@aa) = git_get_last_activity($pr->{'path'});
+ my (@aa) = git_get_last_activity($pr->{'path'}, $last_activity_ref);
unless (@aa) {
next;
}
--
1.5.0.rc0.g5b5f
^ permalink raw reply related
* [PATCH] Fix 'git add' with .gitignore (Re: git-add ignores .gitignore)
From: Junio C Hamano @ 2006-12-29 18:57 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <033682AF-B324-4049-B331-8A8AF2335E4D@silverinsanity.com>
Thanks for noticing.
The commit 4888c534 tried to mark the path it returns so that
the caller can tell if it is ignored or not, but botched the
case where a directory is ignored. It should have marked the
contents as ignored if higher level directory was.
But I think the approach that change makes is more expensive
than the original code and is not necessary. How about this
patch, after you revert that commit?
-- >8 --
[PATCH] Fix 'git add' with .gitignore
When '*.ig' is ignored, and you have two files f.ig and d.ig/foo
in the working tree,
$ git add .
correctly ignored f.ig but failed to ignore d.ig/foo. This was
caused by a thinko in an earlier commit 4888c534, when we tried
to allow adding otherwise ignored files.
After reverting that commit, this takes a much simpler approach.
When we have an unmatched pathspec that talks about an existing
pathname, we know it is an ignored path the user tried to add,
so we include it in the set of paths directory walker returned.
This does not let you say "git add -f D" on an ignored directory
D and add everything under D. People can submit a patch to
further allow it if they want to, but I think it is a saner
behaviour to require explicit paths to be spelled out in such a
case.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-add.c | 52 +++++++++++++++++++++++++++-------------------------
dir.c | 8 +++++---
dir.h | 5 ++++-
t/t3700-add.sh | 33 +++++++++++++++++++++++++++++++++
4 files changed, 69 insertions(+), 29 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 8ed4a6a..e7a1b4d 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -26,18 +26,9 @@ static void prune_directory(struct dir_struct *dir, const char **pathspec, int p
i = dir->nr;
while (--i >= 0) {
struct dir_entry *entry = *src++;
- int how = match_pathspec(pathspec, entry->name, entry->len,
- prefix, seen);
- /*
- * ignored entries can be added with exact match,
- * but not with glob nor recursive.
- */
- if (!how ||
- (entry->ignored_entry && how != MATCHED_EXACTLY)) {
- free(entry);
- continue;
- }
- *dst++ = entry;
+ if (match_pathspec(pathspec, entry->name, entry->len,
+ prefix, seen))
+ *dst++ = entry;
}
dir->nr = dst - dir->entries;
@@ -47,10 +38,20 @@ static void prune_directory(struct dir_struct *dir, const char **pathspec, int p
if (seen[i])
continue;
- /* Existing file? We must have ignored it */
match = pathspec[i];
- if (!match[0] || !lstat(match, &st))
+ if (!match[0])
continue;
+
+ /* Existing file? We must have ignored it */
+ if (!lstat(match, &st)) {
+ struct dir_entry *ent;
+
+ ent = dir_add_name(dir, match, strlen(match));
+ ent->ignored = 1;
+ if (S_ISDIR(st.st_mode))
+ ent->ignored_dir = 1;
+ continue;
+ }
die("pathspec '%s' did not match any files", match);
}
}
@@ -62,8 +63,6 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec)
/* Set up the default git porcelain excludes */
memset(dir, 0, sizeof(*dir));
- if (pathspec)
- dir->show_both = 1;
dir->exclude_per_dir = ".gitignore";
path = git_path("info/exclude");
if (!access(path, R_OK))
@@ -154,7 +153,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
if (show_only) {
const char *sep = "", *eof = "";
for (i = 0; i < dir.nr; i++) {
- if (!ignored_too && dir.entries[i]->ignored_entry)
+ if (!ignored_too && dir.entries[i]->ignored)
continue;
printf("%s%s", sep, dir.entries[i]->name);
sep = " ";
@@ -168,16 +167,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)
die("index file corrupt");
if (!ignored_too) {
- int has_ignored = -1;
- for (i = 0; has_ignored < 0 && i < dir.nr; i++)
- if (dir.entries[i]->ignored_entry)
- has_ignored = i;
- if (0 <= has_ignored) {
+ int has_ignored = 0;
+ for (i = 0; i < dir.nr; i++)
+ if (dir.entries[i]->ignored)
+ has_ignored = 1;
+ if (has_ignored) {
fprintf(stderr, ignore_warning);
- for (i = has_ignored; i < dir.nr; i++) {
- if (!dir.entries[i]->ignored_entry)
+ for (i = 0; i < dir.nr; i++) {
+ if (!dir.entries[i]->ignored)
continue;
- fprintf(stderr, "%s\n", dir.entries[i]->name);
+ fprintf(stderr, "%s", dir.entries[i]->name);
+ if (dir.entries[i]->ignored_dir)
+ fprintf(stderr, " (directory)");
+ fputc('\n', stderr);
}
fprintf(stderr,
"Use -f if you really want to add them.\n");
diff --git a/dir.c b/dir.c
index 8477472..0338d6c 100644
--- a/dir.c
+++ b/dir.c
@@ -260,12 +260,12 @@ int excluded(struct dir_struct *dir, const char *pathname)
return 0;
}
-static void add_name(struct dir_struct *dir, const char *pathname, int len)
+struct dir_entry *dir_add_name(struct dir_struct *dir, const char *pathname, int len)
{
struct dir_entry *ent;
if (cache_name_pos(pathname, len) >= 0)
- return;
+ return NULL;
if (dir->nr == dir->alloc) {
int alloc = alloc_nr(dir->alloc);
@@ -273,10 +273,12 @@ static void add_name(struct dir_struct *dir, const char *pathname, int len)
dir->entries = xrealloc(dir->entries, alloc*sizeof(ent));
}
ent = xmalloc(sizeof(*ent) + len + 1);
+ ent->ignored = ent->ignored_dir = 0;
ent->len = len;
memcpy(ent->name, pathname, len);
ent->name[len] = 0;
dir->entries[dir->nr++] = ent;
+ return ent;
}
static int dir_exists(const char *dirname, int len)
@@ -364,7 +366,7 @@ static int read_directory_recursive(struct dir_struct *dir, const char *path, co
if (check_only)
goto exit_early;
else
- add_name(dir, fullname, baselen + len);
+ dir_add_name(dir, fullname, baselen + len);
}
exit_early:
closedir(fdir);
diff --git a/dir.h b/dir.h
index c919727..7233d65 100644
--- a/dir.h
+++ b/dir.h
@@ -13,7 +13,9 @@
struct dir_entry {
- int len;
+ unsigned int ignored : 1;
+ unsigned int ignored_dir : 1;
+ unsigned int len : 30;
char name[FLEX_ARRAY]; /* more */
};
@@ -55,5 +57,6 @@ extern void add_excludes_from_file(struct dir_struct *, const char *fname);
extern void add_exclude(const char *string, const char *base,
int baselen, struct exclude_list *which);
extern int file_exists(const char *);
+extern struct dir_entry *dir_add_name(struct dir_struct *dir, const char *pathname, int len);
#endif
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index c09c53f..e98786d 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -51,4 +51,37 @@ test_expect_success \
*) echo fail; git-ls-files --stage xfoo3; (exit 1);;
esac'
+test_expect_success '.gitignore test setup' '
+ echo "*.ig" >.gitignore &&
+ mkdir c.if d.ig &&
+ >a.ig && >b.if &&
+ >c.if/c.if && >c.if/c.ig &&
+ >d.ig/d.if && >d.ig/d.ig
+'
+
+test_expect_success '.gitignore is honored' '
+ git-add . &&
+ ! git-ls-files | grep "\\.ig"
+'
+
+test_expect_success 'error out when attempting to add ignored ones without -f' '
+ ! git-add a.?? &&
+ ! git-ls-files | grep "\\.ig"
+'
+
+test_expect_success 'error out when attempting to add ignored ones without -f' '
+ ! git-add d.?? &&
+ ! git-ls-files | grep "\\.ig"
+'
+
+test_expect_success 'add ignored ones with -f' '
+ git-add -f a.?? &&
+ git-ls-files --error-unmatch a.ig
+'
+
+test_expect_success 'add ignored ones with -f' '
+ git-add -f d.??/* &&
+ git-ls-files --error-unmatch d.ig/d.if d.ig/d.ig
+'
+
test_done
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2006-12-29 18:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612291853210.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 28 Dec 2006, Junio C Hamano wrote:
>
>> * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
>> + git-merge: preserve and merge local changes when doing fast
>> forward
>
> I'd like this, but behind a command line switch. And in addition to saying
> "cannot merge, blabla needs update", git could spit out "if you want to
> risk a 3way merge, go ahead and add the --preserve-local flag to
> git-merge".
>
> Comments?
I think what you propose is in line is what I originally wanted
to do, but I backburnered it exactly because I did not like the
"if you want to risk a 3-way" phrase. It's not the wording, but
the fact that I have to say "risk" bothers me. No matter how
you cut it, it _is_ risky, and indicates to me that we are
somehow doing this in a wrong way. I have a nagging suspicion
that there may be a better approach, but I haven't found one.
But you are welcome to take a crack at it.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2006-12-29 18:06 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612291853210.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 28 Dec 2006, Junio C Hamano wrote:
>
>> * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
>> + git-merge: preserve and merge local changes when doing fast
>> forward
>
> I'd like this, but behind a command line switch. And in addition to saying
> "cannot merge, blabla needs update", git could spit out "if you want to
> risk a 3way merge, go ahead and add the --preserve-local flag to
> git-merge".
>
> Comments?
Good idea.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2006-12-29 17:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzzfp86x.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 28 Dec 2006, Junio C Hamano wrote:
> * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
> + git-merge: preserve and merge local changes when doing fast
> forward
I'd like this, but behind a command line switch. And in addition to saying
"cannot merge, blabla needs update", git could spit out "if you want to
risk a 3way merge, go ahead and add the --preserve-local flag to
git-merge".
Comments?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/11] Misc. pull/merge/am improvements
From: Junio C Hamano @ 2006-12-29 17:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612291845070.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 28 Dec 2006, Junio C Hamano wrote:
>
>> Although I do find the detached HEAD attractive [...]
>
> You do mean "git fetch --depth 0", don't you? (Totally untested, of
> course.)
No, what I meant was
$ git checkout v1.5.0
Checking out a tag -- you are not on any branch now...
$ ls -l .git/HEAD
-rw-rw-r-- 1 junio junio 41 2006-12-29 09:51 .git/HEAD
$ git branch
master
$ git commit -m 'fix' -a; echo $?
You cannot commit without the current branch.
0
$ git checkout -b maint-1.5.0
$ git commit -m 'fix' -a
^ permalink raw reply
* Re: [PATCH 0/11] Misc. pull/merge/am improvements
From: Johannes Schindelin @ 2006-12-29 17:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7vmz58whnx.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 28 Dec 2006, Junio C Hamano wrote:
> Although I do find the detached HEAD attractive [...]
You do mean "git fetch --depth 0", don't you? (Totally untested, of
course.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 11/11] Improve merge performance by avoiding in-index merges.
From: Johannes Schindelin @ 2006-12-29 17:44 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061228082441.GB18029@spearce.org>
Hi,
On Thu, 28 Dec 2006, Shawn Pearce wrote:
> From what I can tell, merge-recursive and read-tree -m are running
> exactly the same code.
That was the idea of tags/v1.4.3~333^2 "read-tree: move merge functions
to the library" and v1.4.3~236^2~10 "merge-recur: use the unpack_trees()
interface instead of exec()ing read-tree".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] Allow non-fast-forward of remote tracking branches in default clone
From: Johannes Schindelin @ 2006-12-29 16:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk60btucu.fsf_-_@assigned-by-dhcp.cox.net>
Hi,
On Thu, 28 Dec 2006, Junio C Hamano wrote:
> git-repo-config remote."$origin".fetch \
> - "refs/heads/*:$remote_top/*" '^$' &&
> + "+refs/heads/*:$remote_top/*" '^$' &&
Minor nit: these days, it is cleaner (and clearer) to use "git-repo-config
--add" instead of using the "^$" construct yourself. However, I don't
think this patch has to be changed.
Ciao,
Dscho
^ permalink raw reply
* git-add ignores .gitignore
From: Brian Gernhardt @ 2006-12-29 15:51 UTC (permalink / raw)
To: git
I just ran "git add ." and got a very surprising result. Test case:
$ mkdir tmp
$ git init-db
$ mkdir a
$ touch a/b c
$ cat > .gitignore << EOF
a
EOF
$ git status
# On branch refs/heads/master
#
# Initial commit
#
# Untracked files:
# (use "git add file1 file2" to include for commit)
#
# .gitignore
# c
nothing to commit (use "git add file1 file2" to include for commit)
$ git add .
$ git status
# On branch refs/heads/master
#
# Initial commit
#
# Added but not yet committed:
# (will commit)
#
# new file: .gitignore
# new file: a/b
# new file: c
#
$ git --version
git version 1.5.0.rc0.g04509
Huh? I'm deep into my own code so can't diagnose it myself right
now, but thought maybe someone on list could. I really hope that's
not the expected behavior. Same thing happens with "git add *"
~~ Brian
^ permalink raw reply
* [PATCH] Add info about new test families (8 and 9) to t/README
From: Jakub Narebski @ 2006-12-29 13:39 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
t/README | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/t/README b/t/README
index c5db580..7abab1d 100644
--- a/t/README
+++ b/t/README
@@ -74,6 +74,8 @@ First digit tells the family:
5 - the pull and exporting commands
6 - the revision tree commands (even e.g. merge-base)
7 - the porcelainish commands concerning the working tree
+ 8 - the porcelainish commands concerning forensics
+ 9 - the git tools
Second digit tells the particular command we are testing.
--
1.4.4.3
^ permalink raw reply related
* Re: read-for-fill and caching in gitweb (Re: kernel.org mirroring)
From: Jakub Narebski @ 2006-12-29 12:47 UTC (permalink / raw)
To: Martin Langhoff
Cc: Robert Fitzsimons, Linus Torvalds, Jeff Garzik, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin, Git Mailing List
In-Reply-To: <46a038f90612290346n35386e14g922465d66beaf5ab@mail.gmail.com>
Martin Langhoff wrote:
> On 12/29/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> It is simply the case that new features cost more. Namely in earlier
>> versions of gitweb Last Change time was taken from HEAD (from current
>> branch), in newer we check all branches (using git-for-each-ref).
>> For published public repository it migh make sense to pack also heads
>> (make them packed refs).
>
> I haven't been using packed refs at all, but it sounds like it's a
> single file. So we can stat just that file rather than ask questions
> about the heads themselves. That makes checking for if-modified-since
> cheap as well.
That I think would work _only_ for the working repository. For
publishing bare repository you push into (or which is a mirror of some
other repository) I think stat $GIT_DIR/packed-refs would return date
of last push (last mirror), not when repository was last committed to...
>> I was thinking about making this a gitweb %feature, allowing gitweb
>> administrator to chose if Last Change is taken from all branches
>> (as it is now), from HEAD (as it was before), or from given branch
>> (for example master).
>
> I think the natural thing is to check all heads (doing it on the cheap
> on packed-refs repos) and provide tuning tips. in this case "use
> packed refs" which I guess will become the default eventually.
...but this could be included in above %feature.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH/RFT] Work around http-fetch built with cURL 7.16.0
From: Horst H. von Brand @ 2006-12-29 12:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyazttzm.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> It appears that curl_easy_duphandle() from libcurl 7.16.0
> returns a curl session handle which fails GOOD_MULTI_HANDLE()
> check in curl_multi_add_handle(). This causes fetch_ref() to
> fail because start_active_slot() cannot start the request.
>
> For now, check for 7.16.0 to work this issue around.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
>
> * I think people who were having trouble with cURL 7.16.0 want
> to have the issue resolved before v1.5.0-rc1. Please test
> and report, or else ;-).
Checked it out. Now clone and pull both work here.
Thanks!
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: David Kågedal @ 2006-12-29 11:56 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0612272041421.18171@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Wed, 27 Dec 2006, Junio C Hamano wrote:
>
>> Junio C Hamano <junkio@cox.net> writes:
>>
>> > "Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
>> > ...
>> >> And what happens to the people who can't/won't display UTF-8? This is a
>> >> both a project wide configuration (how does stuff get saved) + a user/local
>> >> configuration (how to display stuff).
>> > ...
>> > Maybe i18n.displayencoding set to latin1 is what you are after?
>> > I think it might make sense...
>>
>> I've done this and will be pushing the result out in 'next'
>> shortly, with a new test. I find the result mostly sensible.
>
> Shouldn't the LANG environment variable be used for this purpose
> instead?
You mean LC_CTYPE, no?
--
David Kågedal
^ permalink raw reply
* Re: read-for-fill and caching in gitweb (Re: kernel.org mirroring)
From: Martin Langhoff @ 2006-12-29 11:46 UTC (permalink / raw)
To: Jakub Narebski
Cc: Robert Fitzsimons, Linus Torvalds, Jeff Garzik, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin, Git Mailing List
In-Reply-To: <200612291140.46909.jnareb@gmail.com>
On 12/29/06, Jakub Narebski <jnareb@gmail.com> wrote:
> It is simply the case that new features cost more. Namely in earlier
> versions of gitweb Last Change time was taken from HEAD (from current
> branch), in newer we check all branches (using git-for-each-ref).
> For published public repository it migh make sense to pack also heads
> (make them packed refs).
I haven't been using packed refs at all, but it sounds like it's a
single file. So we can stat just that file rather than ask questions
about the heads themselves. That makes checking for if-modified-since
cheap as well.
> I was thinking about making this a gitweb %feature, allowing gitweb
> administrator to chose if Last Change is taken from all branches
> (as it is now), from HEAD (as it was before), or from given branch
> (for example master).
I think the natural thing is to check all heads (doing it on the cheap
on packed-refs repos) and provide tuning tips. in this case "use
packed refs" which I guess will become the default eventually.
cheers,
martin
^ permalink raw reply
* Re: read-for-fill and caching in gitweb (Re: kernel.org mirroring)
From: Jakub Narebski @ 2006-12-29 10:40 UTC (permalink / raw)
To: Robert Fitzsimons
Cc: Martin Langhoff, Linus Torvalds, Jeff Garzik, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin, Git Mailing List
In-Reply-To: <20061229032126.GE6558@localhost>
Robert Fitzsimons wrote:
> Here are the mean (and standard deviation) in milliseconds for those
> pages using a few different versions of gitweb.
>
> project_list summary shortlog log
> v267 173 1.6 1141 8.8 795 5.0 919 1.9
> 1.4.4.3 220 2.3 397 2.4 930 4.2 1113 56.9
> 1.5.0.rc0.g4a4d 226 1.9 292 1.7 352 4.0 491 6.7
> 1.5.0.rc0.g4a4d 60 1.0 131 0.7 195 1.2 347 3.7
> (mod_perl)
> I'll look into the increase in time for the project_list in more recent
> versions of gitweb, tomorrow.
It is simply the case that new features cost more. Namely in earlier
versions of gitweb Last Change time was taken from HEAD (from current
branch), in newer we check all branches (using git-for-each-ref).
For published public repository it migh make sense to pack also heads
(make them packed refs).
I was thinking about making this a gitweb %feature, allowing gitweb
administrator to chose if Last Change is taken from all branches
(as it is now), from HEAD (as it was before), or from given branch
(for example master).
Another thing that might made small increase in time is checking
if project is to be visible to gitweb ($export_ok and $strict_export).
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH/RFH] send-pack: fix pipeline.
From: Junio C Hamano @ 2006-12-29 10:37 UTC (permalink / raw)
To: git; +Cc: Andy Whitcroft
send-pack builds a pipeline that runs "rev-list | pack-objects"
and sends the output from pack-objects to the other side, while
feeding the input side of that pipe from itself. However, the
file descriptor that is given to this pipeline (so that it can
be dup2(2)'ed into file descriptor 1 of pack-objects) is closed
by the caller before the complex fork+exec dance! Worse yet,
the caller already dup2's it to 1, so the child process did not
even have to.
I do not understand how this code could possibly have been
working, but it somehow was working by accident.
Merging the sliding mmap() code reveals this problem, presumably
because it keeps one extra file descriptor open for a packfile
and changes the way file descriptors are allocated. I am too
tired to diagnose the problem now, but this seems to be a
sensible fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* With this patch (and another one I sent out a fix already),
it appears that the send-pack problem I was having with
sp/mmap topic seems to have disappeared. But that is no way
a proof that everything is peachy now.
Somebody less tired than myself should really audit the
pipeline built by send-pack.
send-pack.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index cc884f3..54de96e 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -58,7 +58,7 @@ static void exec_rev_list(struct ref *refs)
/*
* Run "rev-list --stdin | pack-objects" pipe.
*/
-static void rev_list(int fd, struct ref *refs)
+static void rev_list(struct ref *refs)
{
int pipe_fd[2];
pid_t pack_objects_pid;
@@ -71,10 +71,8 @@ static void rev_list(int fd, struct ref *refs)
* and writes to the original fd
*/
dup2(pipe_fd[0], 0);
- dup2(fd, 1);
close(pipe_fd[0]);
close(pipe_fd[1]);
- close(fd);
exec_pack_objects();
die("pack-objects setup failed");
}
@@ -85,7 +83,6 @@ static void rev_list(int fd, struct ref *refs)
dup2(pipe_fd[1], 1);
close(pipe_fd[0]);
close(pipe_fd[1]);
- close(fd);
exec_rev_list(refs);
}
@@ -111,7 +108,7 @@ static void rev_list_generate(int fd, struct ref *refs)
close(pipe_fd[0]);
close(pipe_fd[1]);
close(fd);
- rev_list(fd, refs);
+ rev_list(refs);
die("rev-list setup failed");
}
if (rev_list_generate_pid < 0)
^ permalink raw reply related
* Re: [PATCH 0/11] Misc. pull/merge/am improvements
From: Junio C Hamano @ 2006-12-29 6:14 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061229045327.GD12072@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> While I was looking at the problem, I noticed something a bit
>> easier to reproduce and should be lot easier to diagnose. At
>> http://userweb.kernel.org/~junio/broken.tar, I have a tarball of
>> git.git repository.
>
> Thanks. I downloaded that tar but I can't debug it right now.
> I'm feeling under the weather and already had a long day; I'm too
> fried to seriously look at this pack code. I'll do it tomorrow
> evening.
I think there is a thinko in the OFS_DELTA arm of that switch
statement. You are resetting buf to (in-pack-offset + used), so
you should fetch the variably encoded length starting from buf[0].
This seems to fix that particular repacking for me.
---
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index e9a1804..42dd8c8 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1003,6 +1003,7 @@ static void check_object(struct object_entry *entry)
if (!no_reuse_delta) {
unsigned char c, *base_name;
unsigned long ofs;
+ unsigned long used_0;
/* there is at least 20 bytes left in the pack */
switch (entry->in_pack_type) {
case OBJ_REF_DELTA:
@@ -1013,14 +1014,15 @@ static void check_object(struct object_entry *entry)
case OBJ_OFS_DELTA:
buf = use_pack(p, &w_curs,
entry->in_pack_offset + used, NULL);
- c = buf[used++];
+ used_0 = 0;
+ c = buf[used_0++];
ofs = c & 127;
while (c & 128) {
ofs += 1;
if (!ofs || ofs & ~(~0UL >> 7))
die("delta base offset overflow in pack for %s",
sha1_to_hex(entry->sha1));
- c = buf[used++];
+ c = buf[used_0++];
ofs = (ofs << 7) + (c & 127);
}
if (ofs >= entry->in_pack_offset)
@@ -1028,6 +1030,7 @@ static void check_object(struct object_entry *entry)
sha1_to_hex(entry->sha1));
ofs = entry->in_pack_offset - ofs;
base_name = find_packed_object_name(p, ofs);
+ used += used_0;
break;
default:
base_name = NULL;
^ permalink raw reply related
* Re: How to build manpages on OS X
From: Randal L. Schwartz @ 2006-12-29 6:02 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <459453F8.1010200@midwinter.com>
>>>>> "Steven" == Steven Grimm <koreth@midwinter.com> writes:
Steven> Didn't see this documented anywhere, so...
Steven> If you want to do a full build of git on OS X including the manpages, you need
Steven> the asciidoc and xmlto packages. Both of them are available from macports.org
Steven> (formerly known as DarwinPorts) but out of the box, they don't work quite
Steven> right.
I'm using the ones out of fink, and it seems to work just fine.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ 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