* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Shawn Pearce @ 2006-12-20 1:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Theodore Tso, Nicolas Pitre, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612190855300.3479@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> On Tue, 19 Dec 2006, Theodore Tso wrote:
> >
> > So the main reason to use mamp, as Linus puts it, is if the management
> > overhead of needing to read lots of small bits of the file makes the
> > use of malloc/read to be a pain in the *ss, then go for it.
>
> An example of this in git is the regular pack-file accesses. We're MUCH
> better off just mmap'ing the whole pack-file (or at least big chunks of
> it) and not having to maintain difficult structures of "this is where I
> read that part of the file into memory", or read _big_ chunks when
> quite often we just use a few kB of it.
>
> So mmap for pack-files does make sense, but probably only when you can
> mmap big chunks, and are going to access much smaller (random) parts of
> it.
Yes, exactly.
git-fast-import mmaps the pack file for this very reason. It every
so often needs to go back and reread a tree object which has expired
from its own in-memory LRU cache. This usually doesn't happen
very often, but when it does we don't know where we are going to
jump to get data from. mmaping a huge segment of the pack file
(or the whole thing if its reasonably small) works for this case as
the OS buffer cache can just take care of it for us. But as Linus
pointed out mmap and write() aren't safe on some systems. Arrrgh.
However git-fast-import would probably work just as well (or maybe
slightly better) with pread(). I really should port that code
forward to current Git, use pread() instead, and submit the patch
to Junio. But nobody really showed a lot of interest.
My sliding window pack-file access implementation (that I'm currently
rewriting on top of current Git) tries to work in very large chunks,
by default its 32 MiB per chunk, but its user/repository configurable
so kernel hackers may just set it to 256 MiB and continue to get
one large mmap for quite some time to come. Of course I would
also like to get that to autoselect the window size rather than
just hardcode it. :-)
The implementation would prefer a very small number (<8) of very
large chunks (>32 MiB), but is designed to more gracefully degrade
on huge packs on limited address space systems (e.g. Windows 32 bit)
then the current code does.
--
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Shawn Pearce @ 2006-12-20 1:58 UTC (permalink / raw)
To: Theodore Tso; +Cc: Nicolas Pitre, Linus Torvalds, Randal L. Schwartz, git
In-Reply-To: <20061219161919.GA16980@thunk.org>
Theodore Tso <tytso@mit.edu> wrote:
> On Tue, Dec 19, 2006 at 01:39:30AM -0500, Shawn Pearce wrote:
> > This is why git-fast-import mmaps 128 MiB blocks from the file at
> > a time. The mmap region is usually much larger than the file itself;
> > the application appends to the file via write() then goes back
> > and rereads data when necessary via the already established mmap.
> > Its rare for the application to need to unmap/remap a different block
> > so there really isn't very much page table manipulation overhead.
>
> Yes, but unless you are using the (non-portable, Linux specific)
> MAP_POPULATE flag to mmap, each time you touch a new page, you end up
> taking a page fault; and so malloc/read/free might *still* be faster.
> I'd encourage you to make the change and benchmark it; the results may
> be surprising. I played with this with dcraw, the Canon Raw File
> converter a while back (before MAP_POPULATE was added), where I found
> that with a linear access pattern, if you are reading the entire file,
> it's stil marginally faster to use read() over mmap(), because with
> dcraw taking a page fault every 4k of raw file, the system time was
> significantly higher.
Interesting. Lots of good reasons to probably just use pread()
in there instead of mmap. For one thing git-fast-import doesn't
go back and hit the already written pack data very often. Its own
in memory caches usually perform very well.
--
^ permalink raw reply
* Re: git-merge-recursive segmentation error
From: Luben Tuikov @ 2006-12-20 2:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612191709320.6766@woody.osdl.org>
--- Linus Torvalds <torvalds@osdl.org> wrote:
> Can you run that by hand under gdb and get a backtrace?
Linus,
Auto-merging init/Kconfig
Auto-merging init/version.c
Program received signal SIGSEGV, Segmentation fault.
xdl_merge (orig=Variable "orig" is not available.
) at xdiff/xmerge.c:200
200 t2.ptr = (char *)xe2->xdf2.recs[m->i2]->ptr;
(gdb) bt
#0 xdl_merge (orig=Variable "orig" is not available.
) at xdiff/xmerge.c:200
#1 0x000000000040322c in merge_file (o=0x7fffd4f762f0, a=0x7fffd4f76270, b=0x7fffd4f762b0,
branch1=0x7fffd4f77976 "HEAD",
branch2=0x7fffd4f7797b "cc016448b0bf0764928275d034e367753bde8162") at merge-recursive.c:667
#2 0x0000000000404e87 in merge_trees (head=0x12e4a00, merge=0x555328, common=0x555350,
branch1=Variable "branch1" is not available.
) at merge-recursive.c:1074
#3 0x0000000000405376 in merge (h1=0x5452f0, h2=0x545370, branch1=0x7fffd4f77976 "HEAD",
branch2=0x7fffd4f7797b "cc016448b0bf0764928275d034e367753bde8162", call_depth=0,
ancestor=0x5453f0, result=0x7fffd4f764e0) at merge-recursive.c:1245
#4 0x00000000004056a5 in main (argc=Variable "argc" is not available.
) at merge-recursive.c:1312
I also ran git-bisect twice over two well known but overlapping
good-bad regions and I get the same commit as being the culprit.
It seems to be commit 1510fea781cb0517eeba8c378964f7bc4f9577ab.
Luben
^ permalink raw reply
* Re: git-merge-recursive segmentation error
From: Luben Tuikov @ 2006-12-20 2:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612200217300.19693@wbgn013.biozentrum.uni-wuerzburg.de>
--- Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 19 Dec 2006, Luben Tuikov wrote:
>
> > Auto-merging init/version.c
> > /home/luben/bin/git-merge: line 394: 12030
> > Segmentation fault git-merge-$strategy $common -- "$head_arg" "$@"
>
> Do you have any pointers how to get the two branches you try to merge? I'd
> be most grateful to have the sha1's of both heads, too...
The source tree is Linus' "master" tree. The destination tree
is my own "dev" tree, which I use as an intermediate tree, before
merging into my own kernel trees.
Hopefully with the backtrace I posted and with the big-bisect
results pointing to the culprit commit, someone can get a patch out
to fix this.
Luben
^ permalink raw reply
* Re: git-merge-recursive segmentation error
From: Junio C Hamano @ 2006-12-20 2:25 UTC (permalink / raw)
To: ltuikov; +Cc: git, Linus Torvalds
In-Reply-To: <929899.78332.qm@web31809.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> I also ran git-bisect twice over two well known but overlapping
> good-bad regions and I get the same commit as being the culprit.
> It seems to be commit 1510fea781cb0517eeba8c378964f7bc4f9577ab.
>
> Luben
Ooooooops.
^ permalink raw reply
* Re: git-merge-recursive segmentation error
From: Junio C Hamano @ 2006-12-20 2:30 UTC (permalink / raw)
To: ltuikov; +Cc: git, Linus Torvalds
In-Reply-To: <7vtzzrmhhd.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
>> I also ran git-bisect twice over two well known but overlapping
>> good-bad regions and I get the same commit as being the culprit.
>> It seems to be commit 1510fea781cb0517eeba8c378964f7bc4f9577ab.
>>
>> Luben
>
> Ooooooops.
1510fe is buggy and it is my fault.
For now, this _should_ get you keep going.
However, if this fixes it for you, that means we would still
have the problem on Cygwin X-<.
-- >8 --
[PATCH] fix populate-filespec
I hand munged the original patch when committing 1510fea78.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index 9974435..6e6f2a7 100644
--- a/diff.c
+++ b/diff.c
@@ -1223,7 +1223,7 @@ static int reuse_worktree_file(const char *name, const unsigned char *sha1, int
* objects however would tend to be slower as they need
* to be individually opened and inflated.
*/
- if (FAST_WORKING_DIRECTORY && !want_file && has_sha1_pack(sha1, NULL))
+ if (!FAST_WORKING_DIRECTORY && !want_file && has_sha1_pack(sha1, NULL))
return 0;
len = strlen(name);
--
1.4.4.2.g205bf
^ permalink raw reply related
* Re: git-merge-recursive segmentation error
From: Johannes Schindelin @ 2006-12-20 2:31 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <427701.7195.qm@web31811.mail.mud.yahoo.com>
Hi,
On Tue, 19 Dec 2006, Luben Tuikov wrote:
> --- Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Tue, 19 Dec 2006, Luben Tuikov wrote:
> >
> > > Auto-merging init/version.c
> > > /home/luben/bin/git-merge: line 394: 12030
> > > Segmentation fault git-merge-$strategy $common -- "$head_arg" "$@"
> >
> > Do you have any pointers how to get the two branches you try to merge? I'd
> > be most grateful to have the sha1's of both heads, too...
>
> The source tree is Linus' "master" tree. The destination tree
> is my own "dev" tree, which I use as an intermediate tree, before
> merging into my own kernel trees.
>
> Hopefully with the backtrace I posted and with the big-bisect
> results pointing to the culprit commit, someone can get a patch out
> to fix this.
Given that you have an optimized git (it even optimized orig out!), and
that the commit you bisected says "Avoid accessing a slow working copy
during diffcore operations." which has nothing to do at all with
merge-recursive, I give up. I don't have enough information. Really.
Ciao,
Dscho
^ permalink raw reply
* Re: git-merge-recursive segmentation error
From: Shawn Pearce @ 2006-12-20 2:32 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Linus Torvalds, git
In-Reply-To: <929899.78332.qm@web31809.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> wrote:
> --- Linus Torvalds <torvalds@osdl.org> wrote:
> > Can you run that by hand under gdb and get a backtrace?
>
> Linus,
>
> Auto-merging init/Kconfig
> Auto-merging init/version.c
>
> Program received signal SIGSEGV, Segmentation fault.
> xdl_merge (orig=Variable "orig" is not available.
> ) at xdiff/xmerge.c:200
> 200 t2.ptr = (char *)xe2->xdf2.recs[m->i2]->ptr;
> (gdb) bt
> #0 xdl_merge (orig=Variable "orig" is not available.
> ) at xdiff/xmerge.c:200
> #1 0x000000000040322c in merge_file (o=0x7fffd4f762f0, a=0x7fffd4f76270, b=0x7fffd4f762b0,
> branch1=0x7fffd4f77976 "HEAD",
> branch2=0x7fffd4f7797b "cc016448b0bf0764928275d034e367753bde8162") at merge-recursive.c:667
> #2 0x0000000000404e87 in merge_trees (head=0x12e4a00, merge=0x555328, common=0x555350,
> branch1=Variable "branch1" is not available.
> ) at merge-recursive.c:1074
> #3 0x0000000000405376 in merge (h1=0x5452f0, h2=0x545370, branch1=0x7fffd4f77976 "HEAD",
> branch2=0x7fffd4f7797b "cc016448b0bf0764928275d034e367753bde8162", call_depth=0,
> ancestor=0x5453f0, result=0x7fffd4f764e0) at merge-recursive.c:1245
> #4 0x00000000004056a5 in main (argc=Variable "argc" is not available.
> ) at merge-recursive.c:1312
>
> I also ran git-bisect twice over two well known but overlapping
> good-bad regions and I get the same commit as being the culprit.
> It seems to be commit 1510fea781cb0517eeba8c378964f7bc4f9577ab.
Oww, the finger points at me! :-)
Hmm. 1510fe does not look right to me. That return 0 should only
be activating when FAST_WORKING_DIRECTORY == 0, so you really want
this patch below. Normally NO_FAST_WORKING_DIRECTORY is _not_
defined, which means FAST_WORKING_DIRECTORY == 1, and in that case
the if should always be false and the compiler should be stripping
the code out entirely.
What's odd is that the xdl_merge routine is crashing out because
this code activated. It really should not have, so more work is
still required...
diff --git a/diff.c b/diff.c
index 77ba641..1c1de11 100644
--- a/diff.c
+++ b/diff.c
@@ -1194,7 +1194,7 @@ static int reuse_worktree_file(const char *name, const unsigned char *sha1, int
* objects however would tend to be slower as they need
* to be individually opened and inflated.
*/
- if (FAST_WORKING_DIRECTORY && !want_file && has_sha1_pack(sha1, NULL))
+ if (!FAST_WORKING_DIRECTORY && !want_file && has_sha1_pack(sha1, NULL))
return 0;
^ permalink raw reply related
* Re: git-merge-recursive segmentation error
From: Johannes Schindelin @ 2006-12-20 2:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: ltuikov, git, Linus Torvalds
In-Reply-To: <7vpsafmh89.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 19 Dec 2006, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Luben Tuikov <ltuikov@yahoo.com> writes:
> >
> >> I also ran git-bisect twice over two well known but overlapping
> >> good-bad regions and I get the same commit as being the culprit.
> >> It seems to be commit 1510fea781cb0517eeba8c378964f7bc4f9577ab.
> >>
> >> Luben
> >
> > Ooooooops.
>
> 1510fe is buggy and it is my fault.
You hand munging should not have led to any segmentation fault. It would
be sooo nice to have the test case.
Ciao,
^ permalink raw reply
* t1300-repo-config.sh failed on CYGWIN
From: SungHyun Nam @ 2006-12-20 2:37 UTC (permalink / raw)
To: git
If I run it on CYGWIN, there's an error msg:
* FAIL 39: rename section
git-repo-config --rename-section branch.eins branch.zwei
* FAIL 40: rename succeeded
diff -u expect .git/config
...
I run some commands...
$ cd t/trash
$ rm -f .git/config.lock
$ ../../git-repo-config.exe --rename-section branch.eins branch.zwei
error: Cannot commit config file!
Thanks,
namsh
^ permalink raw reply
* Re: git-merge-recursive segmentation error
From: Luben Tuikov @ 2006-12-20 2:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vpsafmh89.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Luben Tuikov <ltuikov@yahoo.com> writes:
> >
> >> I also ran git-bisect twice over two well known but overlapping
> >> good-bad regions and I get the same commit as being the culprit.
> >> It seems to be commit 1510fea781cb0517eeba8c378964f7bc4f9577ab.
> >>
> >> Luben
> >
> > Ooooooops.
>
> 1510fe is buggy and it is my fault.
>
> For now, this _should_ get you keep going.
>
> However, if this fixes it for you, that means we would still
> have the problem on Cygwin X-<.
Yep -- that fixed it.
Thanks,
Luben
>
> -- >8 --
> [PATCH] fix populate-filespec
>
> I hand munged the original patch when committing 1510fea78.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
> diff.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/diff.c b/diff.c
> index 9974435..6e6f2a7 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1223,7 +1223,7 @@ static int reuse_worktree_file(const char *name, const unsigned char
> *sha1, int
> * objects however would tend to be slower as they need
> * to be individually opened and inflated.
> */
> - if (FAST_WORKING_DIRECTORY && !want_file && has_sha1_pack(sha1, NULL))
> + if (!FAST_WORKING_DIRECTORY && !want_file && has_sha1_pack(sha1, NULL))
> return 0;
>
> len = strlen(name);
> --
> 1.4.4.2.g205bf
>
>
>
^ permalink raw reply
* Re: git-merge-recursive segmentation error
From: Luben Tuikov @ 2006-12-20 2:39 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Linus Torvalds, git
In-Reply-To: <20061220023223.GC27638@spearce.org>
--- Shawn Pearce <spearce@spearce.org> wrote:
> Luben Tuikov <ltuikov@yahoo.com> wrote:
> > --- Linus Torvalds <torvalds@osdl.org> wrote:
> > > Can you run that by hand under gdb and get a backtrace?
> >
> > Linus,
> >
> > Auto-merging init/Kconfig
> > Auto-merging init/version.c
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > xdl_merge (orig=Variable "orig" is not available.
> > ) at xdiff/xmerge.c:200
> > 200 t2.ptr = (char *)xe2->xdf2.recs[m->i2]->ptr;
> > (gdb) bt
> > #0 xdl_merge (orig=Variable "orig" is not available.
> > ) at xdiff/xmerge.c:200
> > #1 0x000000000040322c in merge_file (o=0x7fffd4f762f0, a=0x7fffd4f76270, b=0x7fffd4f762b0,
> > branch1=0x7fffd4f77976 "HEAD",
> > branch2=0x7fffd4f7797b "cc016448b0bf0764928275d034e367753bde8162") at
> merge-recursive.c:667
> > #2 0x0000000000404e87 in merge_trees (head=0x12e4a00, merge=0x555328, common=0x555350,
> > branch1=Variable "branch1" is not available.
> > ) at merge-recursive.c:1074
> > #3 0x0000000000405376 in merge (h1=0x5452f0, h2=0x545370, branch1=0x7fffd4f77976 "HEAD",
> > branch2=0x7fffd4f7797b "cc016448b0bf0764928275d034e367753bde8162", call_depth=0,
> > ancestor=0x5453f0, result=0x7fffd4f764e0) at merge-recursive.c:1245
> > #4 0x00000000004056a5 in main (argc=Variable "argc" is not available.
> > ) at merge-recursive.c:1312
> >
> > I also ran git-bisect twice over two well known but overlapping
> > good-bad regions and I get the same commit as being the culprit.
> > It seems to be commit 1510fea781cb0517eeba8c378964f7bc4f9577ab.
>
> Oww, the finger points at me! :-)
>
> Hmm. 1510fe does not look right to me. That return 0 should only
> be activating when FAST_WORKING_DIRECTORY == 0, so you really want
> this patch below. Normally NO_FAST_WORKING_DIRECTORY is _not_
> defined, which means FAST_WORKING_DIRECTORY == 1, and in that case
> the if should always be false and the compiler should be stripping
> the code out entirely.
>
> What's odd is that the xdl_merge routine is crashing out because
> this code activated. It really should not have, so more work is
> still required...
Thanks. It is good to see that the solution patches are identical.
That fixes the problem.
Luben
>
> diff --git a/diff.c b/diff.c
> index 77ba641..1c1de11 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1194,7 +1194,7 @@ static int reuse_worktree_file(const char *name, const unsigned char
> *sha1, int
> * objects however would tend to be slower as they need
> * to be individually opened and inflated.
> */
> - if (FAST_WORKING_DIRECTORY && !want_file && has_sha1_pack(sha1, NULL))
> + if (!FAST_WORKING_DIRECTORY && !want_file && has_sha1_pack(sha1, NULL))
> return 0;
>
> len = strlen(name);
>
^ permalink raw reply
* Re: git-merge-recursive segmentation error
From: Shawn Pearce @ 2006-12-20 2:43 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Junio C Hamano, git, Linus Torvalds, Johannes Schindelin
In-Reply-To: <655753.13323.qm@web31812.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> wrote:
> > Junio C Hamano <junkio@cox.net> writes:
> > 1510fe is buggy and it is my fault.
> >
> > For now, this _should_ get you keep going.
> >
> > However, if this fixes it for you, that means we would still
> > have the problem on Cygwin X-<.
>
> Yep -- that fixed it.
It might be a problem on Cygwin. :-)
I completely fail to see how this patch would cause a segfault
downstream in xdl_merge. All this controls is do we mmap data from
the working directory or decompress it from the ODB. Either way we
should have loaded the file size or content into the diff_filespec.
My other related change (7da41f48c) in this area has a better chance
of causing a problem as it may be bypassing loading the file content
into the diff_filespec where before we were always loading it.
However none of my testing ever showed that would cause a problem.
--
^ permalink raw reply
* Re: Change in git-svn dcommit semantics?
From: Seth Falcon @ 2006-12-20 3:05 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061219220900.GA3148@localdomain>
Eric Wong <normalperson@yhbt.net> writes:
> Huh? safe_qx should've croaked or died, causing git-svn to exit before
> it could do any damage (via git-reset or git-rebase). dcommit is not
> called inside any eval blocks, either...
*shrug* weird. Looking at the code, I don't see how I could have seen
what I think I did. Reproducing the error in a sandbox doesn't show
the git-reset behavior. So unless I can reproduce it, I must have
done something else funny. Sorry for the noise.
> Before, the 'remotes/git-svn..HEAD' argument meant absolutely nothing to
> dcommit (it silently ignored it). Nowadays, you only need 'HEAD~2', the
> 'remotes/git-svn..' is already implied.
>
> git-svn dcommit HEAD~2
That's convenient in that it requires less typing. I will try to
retrain my fingers. I'm in the habit of reviewing the commits not in
svn with:
git log remotes/git-svn..HEAD
And then editing the command like to be 'svn dcommit' instead of log.
Cheers,
+ seth
^ permalink raw reply
* Re: Change in git-svn dcommit semantics?
From: Seth Falcon @ 2006-12-20 3:07 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <94FF72E0-F8BD-4773-803E-F179754BF0ED@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> On Dec 19, 2006, at 4:12 PM, Seth Falcon wrote:
>
>> git version 1.4.4.2.gee60-dirty
>> (the dirty is a hand edit to Makefile for prefix)
>
> Just FYI: You can save Makefile variables in a "config.mak" file
> instead of having to dirty your working tree (and dealing with
> conflicts, etc). For example:
Hey, thanks, that's much nicer :-)
^ permalink raw reply
* [PATCH] Remove COLLISION_CHECK from Makefile since it's not used.
From: Brian Gernhardt @ 2006-12-20 3:25 UTC (permalink / raw)
To: git
It's rather misleading to have configuration options that don't do
anything. If someone adds collision checking they might also want to
restore this option.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
Subject: Re: Change in git-svn dcommit semantics?
On Dec 19, 2006, at 7:38 PM, Brian Gernhardt wrote:
> On Dec 19, 2006, at 6:57 PM, Johannes Schindelin wrote:
>
>>> Mine also has a few variables like "COLLISION_CHECK=paranoid" and my own
>>> prefix.
>>
>> Just to wake sleeping tigers: have you done a "grep COLLISION_CHECK *"
>> recently (where recently means any date after May 3rd, 2005)?
>
> Oh, well, that's cute. It's a configuration option that doesn't touch any
> code at all...
Makefile | 4 ----
configure.ac | 4 ----
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/Makefile b/Makefile
index 8919dab..7651104 100644
--- a/Makefile
+++ b/Makefile
@@ -82,10 +82,6 @@ all:
# Define NO_ACCURATE_DIFF if your diff program at least sometimes misses
# a missing newline at the end of the file.
#
-# Define COLLISION_CHECK below if you believe that SHA1's
-# 1461501637330902918203684832716283019655932542976 hashes do not give you
-# sufficient guarantee that no collisions between objects will ever happen.
-#
# Define USE_NSEC below if you want git to care about sub-second file mtimes
# and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and
# it will BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely
diff --git a/configure.ac b/configure.ac
index 34e3478..e153d53 100644
--- a/configure.ac
+++ b/configure.ac
@@ -316,10 +316,6 @@ GIT_PARSE_WITH(iconv))
## --enable-FEATURE[=ARG] and --disable-FEATURE
#
-# Define COLLISION_CHECK below if you believe that SHA1's
-# 1461501637330902918203684832716283019655932542976 hashes do not give you
-# sufficient guarantee that no collisions between objects will ever happen.
-#
# Define USE_NSEC below if you want git to care about sub-second file mtimes
# and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and
# it will BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely
--
1.4.4.1.GIT
^ permalink raw reply related
* Patch (Re: t1300-repo-config.sh failed on CYGWIN)
From: SungHyun Nam @ 2006-12-20 3:22 UTC (permalink / raw)
To: git
In-Reply-To: <4588A1EC.7040301@gmail.com>
SungHyun Nam wrote:
> If I run it on CYGWIN, there's an error msg:
>
> * FAIL 39: rename section
> git-repo-config --rename-section branch.eins branch.zwei
> * FAIL 40: rename succeeded
> diff -u expect .git/config
With a patch below, the problem gone.
BTW, there's a leak for 'config_filename' in
git_config_rename_section().
Thanks,
namsh
diff --git a/config.c b/config.c
index 663993f..a23ac47 100644
--- a/config.c
+++ b/config.c
@@ -806,6 +806,7 @@ int git_config_rename_section(const char *old_name,
const char *new_name)
}
write(out_fd, buf, strlen(buf));
}
+ fclose(config_file);
if (close(out_fd) || commit_lock_file(lock) < 0)
return error("Cannot commit config file!");
return ret;
^ permalink raw reply related
* Re: git-merge-recursive segmentation error
From: Junio C Hamano @ 2006-12-20 3:45 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, Luben Tuikov
In-Reply-To: <20061220024317.GA27918@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> I completely fail to see how this patch would cause a segfault
> downstream in xdl_merge. All this controls is do we mmap data from
> the working directory or decompress it from the ODB. Either way we
> should have loaded the file size or content into the diff_filespec.
Me neither. Quite puzzled...
^ permalink raw reply
* [PATCH] add log.fulldiff config option
From: Jeff King @ 2006-12-20 6:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This continues to default to 'off'.
Signed-off-by: Jeff King <peff@peff.net>
---
On Tue, Dec 19, 2006 at 05:17:17PM -0800, Junio C Hamano wrote:
> I typically do:
>
> git log --full-diff -p -SCOLLISION
>
> The --full-diff option helps because it shows the diff for other
> files (that do not have different number of substring COLLISION
> in the pre and postimage) in the same commit as well.
I use --full-diff all the time, so this should save some typing. I can't
think of a time when I wouldn't want it on, but if there is, we probably
need a --no-full-diff.
Also, should this instead be diff.fulldiff?
Also also, I was going to submit a patch to document --full-diff,
but I had a few questions. Should it go in diff-options? That makes some
sense to me, but the parsing actually happens in setup_revisions.
Furthermore, it seems to do the same thing as --pickaxe-all. Should we
try to combine these?
Documentation/config.txt | 6 ++++++
builtin-log.c | 6 ++++++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 22482d6..8be1fa6 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -248,6 +248,12 @@ i18n.commitEncoding::
browser (and possibly at other places in the future or in other
porcelains). See e.g. gitlink:git-mailinfo[1]. Defaults to 'utf-8'.
+log.fulldiff::
+ If true, log entries which have been selected through path-limiting
+ or pickaxe will show the diff for all files changed in that commit
+ instead of only the files matching the specified path or pickaxe
+ string.
+
log.showroot::
If true, the initial commit will be shown as a big creation event.
This is equivalent to a diff against an empty tree.
diff --git a/builtin-log.c b/builtin-log.c
index 17014f7..57edd12 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -15,6 +15,7 @@
#include <sys/time.h>
static int default_show_root = 1;
+static int default_full_diff = 0;
/* this is in builtin-diff.c */
void add_head(struct rev_info *revs);
@@ -26,6 +27,7 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
rev->commit_format = CMIT_FMT_DEFAULT;
rev->verbose_header = 1;
rev->show_root_diff = default_show_root;
+ rev->full_diff = default_full_diff;
argc = setup_revisions(argc, argv, rev, "HEAD");
if (rev->diffopt.pickaxe || rev->diffopt.filter)
rev->always_show_header = 0;
@@ -54,6 +56,10 @@ static int git_log_config(const char *var, const char *value)
default_show_root = git_config_bool(var, value);
return 0;
}
+ if (!strcmp(var, "log.fulldiff")) {
+ default_full_diff = git_config_bool(var, value);
+ return 0;
+ }
return git_diff_ui_config(var, value);
}
--
^ permalink raw reply related
* Re: [PATCH] add log.fulldiff config option
From: Junio C Hamano @ 2006-12-20 8:14 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20061220060102.GA540@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I use --full-diff all the time, so this should save some typing. I can't
> think of a time when I wouldn't want it on, but if there is, we probably
> need a --no-full-diff.
Absolutely.
> Also, should this instead be diff.fulldiff?
Probably not.
> Also also, I was going to submit a patch to document --full-diff,
> but I had a few questions. Should it go in diff-options? That makes some
> sense to me, but the parsing actually happens in setup_revisions.
Not at all.
> Furthermore, it seems to do the same thing as --pickaxe-all. Should we
> try to combine these?
No.
Try this with various combinations of with and without
the two flags.
$ git log -1 -Sstate --full-diff --pickaxe-all b3d9899 -- git-fetch.sh
Your understanding needs to be clarified on how paths are
filtered, and how log family and diff interacts, and probably
these need to be better documented.
First, lets forget about 'log', but talk about diff (any of
diff-tree, diff-index --cached, diff-index, and diff-files).
They take paths as arguments. The arguments limit the input
side of the diff.
Side note: that is why "diff -C arch/x86_64" would not
care about renames or copies from arch/i386 to
arch/x86_64. The diff machinery does not even see files
under arch/i386 with that command line.
The pickaxe (-S) is defined at the 'diff' layer, and works as
the output filter from the 'diff' machinery. It omits the
filepair (pair of preimage and postimage) whose both sides have
the same number of specified string in them ("pickaxe
criteria").
$ git-diff-tree --name-status b3d9899
will show three paths, git-fetch.sh, git-ls-remote.sh, and
pkt-line.c. But only git-fetch.sh matches the pickaxe criteria.
That's why:
$ git-diff-tree -p -Sstate b3d9899
shows only git-fetch.sh and omits the other two paths.
The option --pickaxe-all changes this paths filtering to
all-or-none. If any of the incoming paths matches the pickaxe
criteria, all changed paths, even the ones that do not match the
criteria, are included in the output. Thus,
$ git-diff-tree -p -Sstate --pickaxe-all b3d9899
gives three paths, although the other two paths do not change
the number of string "state".
With me so far?
Now, when you give paths to commands of the log family, they are
used to filter commits considered for the output by the revision
traversal machinery. The revision machinery feeds only commits
whose tree is different from its parents at the specified paths
to the commands in the log family. b3d9899 is eligible for
output in the first example because it changes "git-fetch.sh".
Then the commit is fed to the tree-diff machinery, with the same
paths limiter given to the log command. If the diff machinery
says there is no interesting diff, the commit is not even
output.
Side note: that is why
$ git log -p -1 -Snosuchstring b3d9899 -- git-fetch.sh
does not say anything. Pickaxe says git-fetch.sh does not
change "nosuchstring" and nothing comes out of the diff
machinery.
What --full-diff does is to dissociate the paths limiter from
the diff machinery. Before talking about pickaxe interaction,
let's try one without it.
Compare:
$ git log -p -1 b3d9899 -- git-fetch.sh
$ git log -p -1 --full-diff b3d9899 -- git-fetch.sh
In both, git-fetch.sh is first used by the revision traversal to
determine that b3d9899 is worth considering (the commit changes
that path). Then the former uses the same paths limiter to
compute the diff for the commit. Hence you will see only
git-fetch.sh. The latter, however, does not use git-fetch.sh as
the paths limiter to generate diff because of --full-diff; it
feeds the full trees and that is why you can see three files.
Finally.
How do all of the above interact with the pickaxe?
$ git log -p -1 -Sstate b3d9899 -- git-fetch.sh
Because git-fetch.sh is changed by b3d9899, revision traversal
makes the commit eligible. It feeds that single path to diff
machinery and pickaxe says it changes "state". Then it outputs
that path.
How about this one?
$ git log -p -1 -Sstate --full-diff b3d9899 -- git-fetch.sh
git-fetch.sh makes b3d9899 eligible, --full-diff makes all three
paths touched by the commit (ignoring the paths you gave from
the command line) to be fed to the diff machinery, and pickaxe
picks git-fetch.sh because that is the only one that changes
"state". For the same reason, you would see git-fetch.sh out of
this one:
$ git log -p -1 -Sstate --full-diff b3d9899 -- pkt-line.c
Truly finally.
If you add --pickaxe-all to the last one:
$ git log -p -1 -Sstate --pickaxe-all --full-diff b3d9899 -- pkt-line.c
pkt-line.c makes b3d9899 eligible, --full-diff feeds three
changed paths to diff machinery, pickaxe notices that one of
them (git-fetch.sh which is different from what you gave from
the command line) changes "state", --pickaxe-all causes all
three incoming paths to be output.
^ permalink raw reply
* [PATCH] revision: add --no-full-diff command line option
From: Jeff King @ 2006-12-20 8:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xh3j86h.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Jeff King <peff@peff.net>
---
On Wed, Dec 20, 2006 at 12:14:14AM -0800, Junio C Hamano wrote:
> > I use --full-diff all the time, so this should save some typing. I can't
> > think of a time when I wouldn't want it on, but if there is, we probably
> > need a --no-full-diff.
>
> Absolutely.
I took this to mean "absolutely we need --no-full-diff." :)
I note that --full-diff sets rev->diff = 1. The log.fulldiff config
option does not, and nor does --no-full-diff unset it. However, I'm not
sure it makes sense to set it. Doing "git-log --full-diff" outputs an
extra line (separating the diff from the commit log) but since we
haven't told it any type of diff to output, the diff is blank. And if we
had told it a type, then that would have turned on rev->diff. So I don't
see a point in setting it.
revision.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/revision.c b/revision.c
index 56819f8..ac4dbf2 100644
--- a/revision.c
+++ b/revision.c
@@ -955,6 +955,10 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
revs->full_diff = 1;
continue;
}
+ if (!strcmp(arg, "--no-full-diff")) {
+ revs->full_diff = 0;
+ continue;
+ }
if (!strcmp(arg, "--full-history")) {
revs->simplify_history = 0;
continue;
--
1.4.4.2.gee7ba-dirty
^ permalink raw reply related
* Re: [PATCH] add log.fulldiff config option
From: Jeff King @ 2006-12-20 8:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xh3j86h.fsf@assigned-by-dhcp.cox.net>
On Wed, Dec 20, 2006 at 12:14:14AM -0800, Junio C Hamano wrote:
> > Also, should this instead be diff.fulldiff?
>
> Probably not.
Based on your explanation, I think that makes sense.
> > Also also, I was going to submit a patch to document --full-diff,
> > but I had a few questions. Should it go in diff-options? That makes some
> > sense to me, but the parsing actually happens in setup_revisions.
>
> Not at all.
Then where should it go? whatchanged and log have a great deal of
overlap in terms of parsing, but they don't seem to share any
documentation (or note the fact that git-whatchanged is basically just
git-log -p).
> > Furthermore, it seems to do the same thing as --pickaxe-all. Should we
> > try to combine these?
>
> No.
Thanks for the thorough explanation. I think this makes my config option
description a little bit off, then, since it doesn't actually show all
of the changed files for a commit in the case of pickaxe.
What has me confused, then, is that you said this:
> I typically do:
>
> git log --full-diff -p -SCOLLISION
>
> The --full-diff option helps because it shows the diff for other
> files (that do not have different number of substring COLLISION
> in the pre and postimage) in the same commit as well.
But that isn't the case, AFAIK (e.g., the command line you mention shows
only changes to sha1_file.c in commit aac17941, but cache.h was also
changed). Did you mean --pickaxe-all?
> Your understanding needs to be clarified on how paths are
> filtered, and how log family and diff interacts, and probably
> these need to be better documented.
To be honest, I'm not sure when one would really _want_ the flexibility
this provides. It might be more intuitive to git-{log,whatchanged} users
to have a single option (config and command line) to set --full-diff and
--pickaxe-all together. At the very least, I think I now want a
diff.pickaxeall config option.
^ permalink raw reply
* [RFC/PATCH] Implement poor-man's submodule support in pre-commit hook
From: Andy Parkins @ 2006-12-20 9:01 UTC (permalink / raw)
To: git
Make a file called .gitmodules. In it, list the paths containing a
submodule. Add that file to the index.
This addition to the pre-commit hook finds that file and pulls the HEAD
hash out of each of the listed submodule repositories. That hash is
then listed to the .gitmodules file along with the submodule name and
.gitmodules is added back to the repository.
You've now got poor-man's submodule support. Any commits to the
submodule will change the hash and hence the .gitmodules file will be
different and therefore will show up as "modified" to git.
It's not got any nice UI for checking out (obviously) or merging; but it
does at least record the state of a project with a bit of manual work to
check out the right commit in the submodule.
Problems:
- git-prune in the submodule could destroy supermodule-referenced
commits
- no checkout support
- no merge support (other than what git provides for the .gitmodule
file)
- no check for dirty submodule before commit
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
templates/hooks--pre-commit | 31 ++++++++++++++++++++++++++++++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
index 723a9ef..7a71d81 100644
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit
@@ -67,5 +67,34 @@ perl -e '
}
}
exit($found_bad);
-'
+' || exit 1
+
+# Enable poor-man's submodule support when .gitmodules is present
+# Simply create a .gitmodules file listing the paths in your repository
+# that contain other git repositories; each line will be replaced with the
+# path followed by the hash of the current HEAD of the submodule.
+# When the submodule changes hash this file will be different from the
+# version in the repository and a change will be noted - voila, submodules.
+# Of course there is no checkout support, but at least the current state
+# will be accurately recorded
+if [ -f .gitmodules ]; then
+ cat .gitmodules |
+ while read subdir hash
+ do
+ # XXX: check if the line is a comment
+
+ # XXX: really need a check here and quit if the submodule is
+ # dirty
+
+ echo "$subdir $(GIT_DIR=$subdir/.git git-rev-parse HEAD)"
+ done > .gitmodules
+
+ # This relies on the .gitmodules file having already been added to
+ # the repository - perhaps this should be automated?
+ git-update-index .gitmodules ||
+ (
+ echo "Submodule tracker file is not tracked by this repository." >&2
+ exit 1
+ )
+fi
--
1.4.4.2.g95ee-dirty
^ permalink raw reply related
* Re: Bug: git-svn fails on Mediawiki SVN repo r2992
From: Thomas Bleher @ 2006-12-20 9:37 UTC (permalink / raw)
To: git
In-Reply-To: <20061220013634.GA3901@localdomain>
* Eric Wong <normalperson@yhbt.net> [2006-12-20 02:36]:
> Thomas Bleher <bleher@informatik.uni-muenchen.de> wrote:
> > There is some problem between git-svn (v1.4.4.1.gad0c3) and MediaWiki
> > SVN when cloning their repo.
> >
> > I just did
> > $ git-svn init http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3
> > $ git-svn fetch -r 2991:3122
> > and git-svn went into an endless loop, repeatedly downloading and adding
> > the same files from r2992 over and over again.
>
> I'm not sure that it was 'endless', just unnecesarily repeating itself.
> commit 6173c197c9a23fa8594f18fd2c856407d4af31c1 (included in 1.4.4.2)
> should have fixed your problem...
It fetched every file at least three times, and I had to kill it after
that, it had been running for over an hour already.
I just retried with current next, and it's _much_ faster, under one
minute now for this particular revision.
So consider this problem solved, and thanks a lot!
> > The bad revision can be viewed here:
> > http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=2992
> > It adds ~1000 files (mostly small images).
> > I can check out this revision just fine using the svn command line
> > client.
>
> The latest git-svn in git.git now bundles all the changed files into a
> delta on the server side; and is significantly faster over most network
> connections as a result.
Yeah, this is a huge gain.
> > I found this problem while cloning this repo a while ago, using a
> > slightly older version of git (probably 1.4.3, don't remember exactly).
> > In this repo, some directories appeared in the latest revisions which
> > were deleted a long time ago.
> >
> > You can temporarily browse this repo here:
> > http://misc.j-crew.de/cgi-bin/gitweb.cgi?p=mediawiki.git
> > HEAD contains the dir Smarty-2.6.2, which was removed in SVN r3122.
> > Strangely, my repo misses all commits between r2991 and r3822.
> > You can see the gap at
> > http://misc.j-crew.de/cgi-bin/gitweb.cgi?p=mediawiki.git;a=shortlog;h=49e761ba51ee0d0a698999451134acbf2e078c03
> >
> > I didn't notice any strange errors while cloning, but I had to abort and
> > restart git-svn a few times, so maybe there was some error there?
>
> Hmm, it looks like you ran something like:
>
> git-svn fetch -r0:2991
>
> and then something along the lines of:
>
> git-svn fetch -r3822:HEAD
>
> Is that what happened?
Nope. I just ran "git-svn fetch" repeatedly, and stopped it a few times
with ^C (the import was running for several days, and I had to turn off
the computer inbetween). Maybe something broke there?
Anyway, it's working now, so I think we can consider this problem
solved.
Thanks,
Thomas
^ permalink raw reply
* Re: [PATCH] add log.fulldiff config option
From: Junio C Hamano @ 2006-12-20 10:01 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <7v8xh3j86h.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Your understanding needs to be clarified on how paths are
> filtered, and how log family and diff interacts, and probably
> these need to be better documented.
Having said that, I realized that I was making the same mistake
that our existing documentation was criticized for.
Let me first digress to address the documentation criticism.
The description on plumbing were (and still are) far more
thorough than porcelain-ish, and the conjecture by the person
who criticized them was because developers were keen documenting
the real work (plumbing) soon after they finished coding than
the frill (porcelain-ish).
I think the real reason for this is somewhat different. At
least to me, git.git was about the plumbing, and I did not want
to be in the Porcelain business at all [*1*]. Instead, I wanted
to encourage healthy competition among Porcelains. What was
shipped with git.git was meant to be "barely usable examples".
But this vision has not materialized fully yet, fortunately
because we did not end up splitting the userbase too early on.
But this was unfortunate for two reasons. One of them is that
different Porcelains would have brought completely different
ways of thinking and workflows into the picture.
Because git.git was primarily about the plumbing, the main focus
of the interface the plumbing offers was not about integration
and uniformity but modularity. Designing them as independent
building blocks as much as practical, and describing them fully,
were part of completing the plumbing. And the "barely usable
examples" started their lives as a set of trivial pipelines,
whose meaning was quite obvious and straightforward when you
understand the plumbing parts used in them. It also had UI
warts. "barely usable examples" cheated their command line
parsing, and the flags used by the plumbing showed through its
thin veneer to the UI used by the end users.
But that was a long time ago. Now we are in the v1.5.0 process,
whose theme is "usability and teachability".
Now, viewing in that light, what I described in the previous
message may have been a precise description of how things happen
to work currently, but it was not about the reason how and why
they were designed to be (because there was little design at the
UI level). We should instead (or at least "in addition") be
talking more about how things ought to be.
I described why --full-diff and --pickaxe-all are different
options, you can give 4 combinations of them, and how the
combinations work differently and why. That does not justify
that all of these four combinations make sense. In fact, I do
not think they do.
When pickaxe is used and --full-diff is given to 'log', I think
it does not make any sense not to use --pickaxe-all. So, I
think at the level of log family commands, unifying these two
flags make a lot of sense (although I earlier said "no").
Although --diff-filter does not have a corresponding option that
makes it behave all-or-none (i.e. an equivalent to --pickaxe-all),
it is conceivable that you might want to say:
$ git log --diff-filter=A --full-diff --diff-filter-all
to view commits that add new files with full diffs (not just
added paths). If we were to add that, I think it makes sense to
internally have a flag separate from pickaxe-all to express it
but when 'log' uses --full-diff, it does not make any sense not
to enable it. In other words,
$ git log -M --diff-filter=R -Sstring --full-diff
should internally enable pickaxe-all and diff-filter-all and
show all of diff that has renames in the paths that change
"string" [*2*].
[Footnote]
*1* I once wanted to do a Porcelain of my own, after finding it
distasteful that Cogito tried to hide the index back when it did
not even use the index properly for merges. But things have
been improved quite a lot in Cogito land and I do not have
anything against it anymore. And as you all know, I like StGIT
very much.
*2* This is actually in line with what we did in 582af688. As a
member of 'log' family, 'git log' were originally meant to show
commit messages for all commits that revision traversal gave it,
regardless of the diff output (and without the diffcore
transformation, when revision traversal said a commit is
interesting, the commit always has some diff or a merge). When
used in conjunction with --pickaxe and --diff-filter, however,
this layering made the command much less useful. We fixed the
problem by violating the layering and made the log command aware
of the underlying diff machinery's output filter. I think the
same would apply to the issue we are currently discussing.
^ 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