* Re: Performance impact of a large number of commits
From: david @ 2008-10-24 20:11 UTC (permalink / raw)
To: Samuel Abels; +Cc: git
In-Reply-To: <1224878202.7566.25.camel@localhost>
On Fri, 24 Oct 2008, Samuel Abels wrote:
> On Fri, 2008-10-24 at 12:43 -0700, david@lang.hm wrote:
>> 100,000 commits per day??
>>
>> that's 1.5 commits/second. what is updating files that quickly?
>
> This is an automated process taking snapshots of rapidly changing files
> containing statistical data. Unfortunately, our needs go beyond what a
> versioning file system has to offer, and the data is an unstructured
> text file (in other words, using a relational database is not a good
> option).
>
>> I suspect that you will have some issues here, but it's going to depend on
>> how many files get updated each 3/4 of a second.
>
> That would be 5 to 10 changed files per commit, and those are passed to
> git commit explicitly (i.e., walking the tree to stat files for finding
> changes is not necessary).
I suspect that your limits would be filesystem/OS limits more than git
limits
at 5-10 files/commit you are going to be creating .5-1m files/day, even
spread across 256 directories this is going to be a _lot_ of files.
packing this may help (depending on how much the files change), but with
this many files the work of doing the packing would be expensive.
David Lang
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 20:13 UTC (permalink / raw)
To: david; +Cc: Junio C Hamano, Jakub Narebski, Jean-Luc Herren, git
In-Reply-To: <alpine.DEB.1.10.0810241254330.27333@asgard.lang.hm>
On Fri, Oct 24, 2008 at 9:54 PM, <david@lang.hm> wrote:
> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
>> Zit does
>> echo "*" > $GIT_DIR/info/exclude
>> and yes it sucks to use a whole block for a file that only contains
>> one character. Suggestions welcome.
>
> can this be configured in the config file?
Yes, the file pointed at by the config key core.excludesfile is read
too, so we could have it point at $GIT_DIR/zitexclude, which would
allow us to spare a block. The most space saving would be achieved by
a core.excludepattern or similar key, which would allow us to get rid
of the exclude file altogether.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Jakub Narebski @ 2008-10-24 20:30 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: David Lang, Junio C Hamano, Jean-Luc Herren, git
In-Reply-To: <cb7bb73a0810241313o341febccgbea1cd59b25b9cc4@mail.gmail.com>
On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
> On Fri, Oct 24, 2008 at 9:54 PM, <david@lang.hm> wrote:
>> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
>>> Zit does
>>> echo "*" > $GIT_DIR/info/exclude
>>> and yes it sucks to use a whole block for a file that only contains
>>> one character. Suggestions welcome.
>>
>> can this be configured in the config file?
>
> Yes, the file pointed at by the config key core.excludesfile is read
> too, so we could have it point at $GIT_DIR/zitexclude, which would
> allow us to spare a block. The most space saving would be achieved by
> a core.excludepattern or similar key, which would allow us to get rid
> of the exclude file altogether.
Well, with all zit repositories in '.zit/' directory (similar to RCS/)
you could have point core.excludesfile to _common_ '.zit/excludes';
the pattern doesn't change from zit repository to zit repository?
You could even use per-user ~/.zitignore (I'm not sure if git expands
'~' in paths; there was some patch for it, but was it accepted?) or
system-wide /usr/lib/zitignore or /usr/libexec/zitignore file.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-daemon and hook output
From: Miklos Vajna @ 2008-10-24 20:39 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20081024050713.GA21548@kodama.kitenet.net>
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
On Fri, Oct 24, 2008 at 01:07:13AM -0400, Joey Hess <joey@kitenet.net> wrote:
> I ran into this in a real-world application -- I'm implementing
> anonymous pushes into ikiwiki, which are checked pre-receive to limit
> them to changes that could be done via the web interface. So all my nice
> error messages about why a commit is refused are not available, which is
> a pity.
I think the recommended protocol even for anonymous push is ssh, at
least that's what repo.or.cz uses for the 'mob' user, which is
equivalent to anonymous, AFAIK.
(The source is available under repo.git, I did not have a look how one
can set up an account - using git-shell - that can be used without a
password.)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-daemon and hook output
From: Shawn O. Pearce @ 2008-10-24 20:42 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Joey Hess, git
In-Reply-To: <20081024203943.GV26961@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Fri, Oct 24, 2008 at 01:07:13AM -0400, Joey Hess <joey@kitenet.net> wrote:
> > I ran into this in a real-world application -- I'm implementing
> > anonymous pushes into ikiwiki, which are checked pre-receive to limit
> > them to changes that could be done via the web interface. So all my nice
> > error messages about why a commit is refused are not available, which is
> > a pity.
>
> I think the recommended protocol even for anonymous push is ssh, at
> least that's what repo.or.cz uses for the 'mob' user, which is
> equivalent to anonymous, AFAIK.
Nah. git:// supports anonymous push. For some applications its
just what people want. I say the original change is worthwhile;
expose the remote address and let a hook do logging and/or denials
based on its own logic.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/5] refactor userdiff textconv code
From: Junio C Hamano @ 2008-10-24 21:12 UTC (permalink / raw)
To: Jeff King; +Cc: git, Johannes Sixt, Matthieu Moy
In-Reply-To: <20081024025330.GC2831@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think this is much cleaner. I have a nagging worry that a
> text-converted filespec might live longer than I expect. Maybe it would
> make sense to free the filespec data after the diff has been generated
> (and then further populate_filespec calls would just restore the
> original data).
Either that or drop data_is_textconv and have two sets of <ptr,size> pair
in filespec, one for real data and another purely for diff text
generation.
But I have a very naïve question.
Why isn't this just primarily a patch to diff.c::builtin_diff() function?
That is, you let fill_mmfile() to fill the real data in mf1 and mf2 as
before, ask one/two if they have textconv, and if so, convert mf1 and mf2
in place, and let xdl work on it, like...
if (fill_mmfile(&mf1, one) < 0 || fill_mmfile(&mf2, two) < 0)
die("unable to read files to diff");
+ if (has_textconv(one))
+ apply_textconv(one, &mf1);
+ if (has_textconv(two))
+ apply_textconv(two, &mf2);
if (!DIFF_OPT_TST(o, TEXT) &&
- (diff_filespec_is_binary(one) || diff_filespec_is_binary(two))) {
+ ( (diff_filespec_is_binary(one) && !has_textconv(one)) ||
+ (diff_filespec_is_binary(two) && !has_textconv(two)) )) {
/* Quite common confusing case */
...
}
else {
/* Crazy xdl interfaces.. */
const char *diffopts = getenv("GIT_DIFF_OPTS");
...
^ permalink raw reply
* RE: git history and file moves
From: Moore, Robert @ 2008-10-24 21:30 UTC (permalink / raw)
To: Michael J Gruber, Lin, Ming M; +Cc: Alex Riesen, git@vger.kernel.org
In-Reply-To: <48FF1EDB.8010503@drmicha.warpmail.net>
Here's what we have:
/var/www/cgi-bin/gitweb.acpica/gitweb.conf
Containts this : GITWEB_CSS = "/icons/gitweb.css";
What should we add to automatically get all file history?
Thanks,
Bob
>-----Original Message-----
>From: Michael J Gruber [mailto:git@drmicha.warpmail.net]
>Sent: Wednesday, October 22, 2008 5:39 AM
>To: Lin, Ming M
>Cc: Alex Riesen; git@vger.kernel.org; Moore, Robert
>Subject: Re: git history and file moves
>
>Alex Riesen venit, vidit, dixit 10/22/08 13:19:
>> 2008/10/22 Lin Ming <ming.m.lin@intel.com>:
>>> I'm looking for a way to move files to a new directory and have the
>>> full history follow the file automatically. Is this possible?
>>>
>>> I know about --follow, but I want the history to just follow the file
>>> transparently. ...
>>
>> Of all Git tools, what does not do this "transparently" or
>"automatically"?
>> How more transparent do you imagine this?
>> What do you think should follow what?
>>
>> I ask, because it is hard to understand what exactly is it you're
>missing:
>> merge support (which we have), git log listing the files as
>copied/renamed
>> (which is what --follow is for, and the suggestion for you is to make an
>> alias or something), git blame (ever looked at git gui blame?) or gitk
>> (which follows renames in default configuration)
>>
>>> Also, we have a git web interface and we want the full
>>> history for the moved files to be available.
>>
>> It is available. Whether it is shown is another question. git-web can
>> be improved (or just configured?)
>
>By default, gitweb uses "-M" for diff. You can specify all options (-C,
>-CC, -B) using "@diff_opts" in the config file for gitweb.cgi - if that
>is what you are using. Is it?
>
>Anyways, using default configs for git log and gitweb.cgi both of them
>show the full history (renames, history before and after) for me here,
>using current git (1.6.0.3.514.g2f91b). What is your setup?
>
>Michael
^ permalink raw reply
* Re: git history and file moves
From: Alex Riesen @ 2008-10-24 21:43 UTC (permalink / raw)
To: Moore, Robert; +Cc: Michael J Gruber, Lin, Ming M, git@vger.kernel.org
In-Reply-To: <4911F71203A09E4D9981D27F9D8308580AA7FFFB@orsmsx503.amr.corp.intel.com>
2008/10/24 Moore, Robert <robert.moore@intel.com>:
> Here's what we have:
>
> /var/www/cgi-bin/gitweb.acpica/gitweb.conf
>
> Containts this : GITWEB_CSS = "/icons/gitweb.css";
>
> What should we add to automatically get all file history?
>
Nothing. It is the default. You can change the variable Michael
mentioned to use "-M -M -C -C" but it is very-very slow on any
kind of history worth its commits.
And you almost never talk about _file_ history in Git. It is all
_project_ history, filtered for commits which touch the file you're
interested in at the moment of looking.
^ permalink raw reply
* [PATCH] add -p: warn if only binary changes present
From: Thomas Rast @ 2008-10-24 21:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Current 'git add -p' will say "No changes." if there are no changes to
text files, which can be confusing if there _are_ changes to binary
files. Add some code to distinguish the two cases, and give a
different message in the latter one.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
git-add--interactive.perl | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index da768ee..a560133 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -811,11 +811,16 @@ EOF
}
sub patch_update_cmd {
- my @mods = grep { !($_->{BINARY}) } list_modified('file-only');
+ my @all_mods = list_modified('file-only');
+ my @mods = grep { !($_->{BINARY}) } @all_mods;
my @them;
if (!@mods) {
- print STDERR "No changes.\n";
+ if (@all_mods) {
+ print STDERR "No changes except to binary files.\n";
+ } else {
+ print STDERR "No changes.\n";
+ }
return 0;
}
if ($patch_mode) {
--
tg: (759ad19..) t/add-p-binary-warn (depends on: origin/master)
^ permalink raw reply related
* Re* ext3: fix ext3_dx_readdir hash collision handling - Regression
From: Junio C Hamano @ 2008-10-24 22:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0810240853310.3287@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> The "git buglet" looks liek this:
>
> - build a kernel
>
> - do "git clean -dqfx". This fails with
>
> warning: failed to remove 'include/config/'
>
> - do "git clean -dqfx" again. And now it works - apparently because the
> first invocation deleted enough of the big directory.
>
> Doing an 'strace' to see what is going on, I see:
>
> ..
> getdents(3, /* 132 entries */, 4096) = 3888
> lstat("include/config/sgi", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> open("include/config/sgi", O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 4
> fstat(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> getdents(4, /* 3 entries */, 4096) = 80
> lstat("include/config/sgi/partition.h", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> unlink("include/config/sgi/partition.h") = 0
> getdents(4, /* 0 entries */, 4096) = 0
> close(4) = 0
> rmdir("include/config/sgi") = 0
> lstat("include/config/sgi", 0x7fffdc4d2110) = -1 ENOENT (No such file or directory)
> close(3) = 0
> write(2, "warning: failed to remove \'include/config/\'\n", 44) = 44
> ..
>
> and notice how it does that
>
> lstat("include/config/sgi", ..
>
> _twice_. That, in turn (knowing the git implementation), implies that it
> was returned twice from that first "getdents(3, ...)" call.
>
> So what git clean does is to scan over the readdir() return values, see if
> it's a file it knows about, try to remove it if not, lstat() every entry,
> recurse into them if they are directories, and then remove it. If the
> lstat() fails, "git clean" will fail.
Hmm, interesting.
-- >8 --
Subject: allow readdir(3) to return the same entry twice
When removing a large directory recursively, repeatedly running unlink(2)
on what we read from readdir(3) can cause readdir(3) (or underlying
getdents(2)) to return the same entry twice. If we have already removed
it, running lstat() on the entry would fail with ENOENT, but there is no
harm if we ignore such an error.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
dir.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git i/dir.c w/dir.c
index 0131983..293df4e 100644
--- i/dir.c
+++ w/dir.c
@@ -800,8 +800,11 @@ int remove_dir_recursively(struct strbuf *path, int only_empty)
strbuf_setlen(path, len);
strbuf_addstr(path, e->d_name);
- if (lstat(path->buf, &st))
- ; /* fall thru */
+ if (lstat(path->buf, &st)) {
+ if (errno == ENOENT)
+ continue;
+ /* otherwise fall thru */
+ }
else if (S_ISDIR(st.st_mode)) {
if (!remove_dir_recursively(path, only_empty))
continue; /* happy */
^ permalink raw reply related
* RE: git history and file moves
From: Moore, Robert @ 2008-10-24 22:01 UTC (permalink / raw)
To: Alex Riesen; +Cc: Michael J Gruber, Lin, Ming M, git@vger.kernel.org
In-Reply-To: <81b0412b0810241443t75e2022fg984df400585cb254@mail.gmail.com>
What we are seeing is an issue after we do a file move to a new directory. Once moved, the previous history of the file is not readily available. One needs to know to use --follow on the command line, and worse, gitweb does not show the full history at all.
We have almost a decade of history on the project, from several different source control systems. We often find it useful to go back and find out when something changed, so we want to keep it and have it easily available.
>-----Original Message-----
>From: Alex Riesen [mailto:raa.lkml@gmail.com]
>Sent: Friday, October 24, 2008 2:43 PM
>To: Moore, Robert
>Cc: Michael J Gruber; Lin, Ming M; git@vger.kernel.org
>Subject: Re: git history and file moves
>
>2008/10/24 Moore, Robert <robert.moore@intel.com>:
>> Here's what we have:
>>
>> /var/www/cgi-bin/gitweb.acpica/gitweb.conf
>>
>> Containts this : GITWEB_CSS = "/icons/gitweb.css";
>>
>> What should we add to automatically get all file history?
>>
>
>Nothing. It is the default. You can change the variable Michael
>mentioned to use "-M -M -C -C" but it is very-very slow on any
>kind of history worth its commits.
>
>And you almost never talk about _file_ history in Git. It is all
>_project_ history, filtered for commits which touch the file you're
>interested in at the moment of looking.
^ permalink raw reply
* Re: git history and file moves
From: Jakub Narebski @ 2008-10-24 22:13 UTC (permalink / raw)
To: Moore, Robert
Cc: Michael J Gruber, Lin, Ming M, Alex Riesen, git@vger.kernel.org
In-Reply-To: <4911F71203A09E4D9981D27F9D8308580AA7FFFB@orsmsx503.amr.corp.intel.com>
"Moore, Robert" <robert.moore@intel.com> writes:
>
> Thanks,
> Bob
>
> >-----Original Message-----
>Michael J Gruber wrote:
>>Alex Riesen venit, vidit, dixit 10/22/08 13:19:
>>> 2008/10/22 Lin Ming <ming.m.lin@intel.com>:
>>>> I'm looking for a way to move files to a new directory and have the
>>>> full history follow the file automatically. Is this possible?
>>>>
>>>> I know about --follow, but I want the history to just follow the file
>>>> transparently. ...
>>>
>>> Of all Git tools, what does not do this "transparently" or "automatically"?
[...]
>>>> Also, we have a git web interface and we want the full
>>>> history for the moved files to be available.
>>>
>>> It is available. Whether it is shown is another question. git-web can
>>> be improved (or just configured?)
>>
>> By default, gitweb uses "-M" for diff. You can specify all options (-C,
>> -CC, -B) using "@diff_opts" in the config file for gitweb.cgi - if that
>> is what you are using. Is it?
>>
>> Anyways, using default configs for git log and gitweb.cgi both of them
>> show the full history (renames, history before and after) for me here,
>> using current git (1.6.0.3.514.g2f91b). What is your setup?
>
> Here's what we have:
>
> /var/www/cgi-bin/gitweb.acpica/gitweb.conf
>
> Containts this : GITWEB_CSS = "/icons/gitweb.css";
This fragment has nothing to do with rename (file movement) detection.
>
> What should we add to automatically get all file history?
While the 'commitdiff' view would, in default gitweb configuration,
contain information about file renames, currently 'history' view does
not support '--follow' option to git-log. It wouldn't be too hard to
add it, but it just wasn't done (well, add to this the fact that
--follow works only for simple cases).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2008, #05; Wed, 22)
From: Junio C Hamano @ 2008-10-24 22:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <gdsjb1$eob$1@ger.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> * gb/gitweb-pathinfo (Tue Oct 21 21:34:54 2008 +0200) 5 commits
>> - gitweb: generate parent..current URLs
>> - gitweb: parse parent..current syntax from PATH_INFO
>> - gitweb: use_pathinfo filenames start with /
>> - gitweb: generate project/action/hash URLs
>> - gitweb: parse project/action/hash_base:filename PATH_INFO
>>
>> Seventh iteration; hopefully the usual gitweb gangs will give quick
>> comments and ack to push this out to 'next' soon.
>
> If I remember correctly v7 is mainly cosmetic changes, and I have
> acked all or almost all of the equivalent patches from v6.
I take it to mean you reviewed v7 and we have your Ack on them;
thanks.
^ permalink raw reply
* Re: [PATCH] Fixed git archive for bare repos
From: René Scharfe @ 2008-10-24 22:19 UTC (permalink / raw)
To: Charles Bailey; +Cc: git, Deskin Miller, kenneth johansson, gitster
In-Reply-To: <1224712023-5280-1-git-send-email-charles@hashpling.org>
Charles Bailey schrieb:
> This moves the call to git config to a place where it doesn't break
> the logic for using git archive in a bare repository but retains the
> fix to make git archive respect core.autocrlf.
If one combines your patch, Deskin's commit message and test and extends
on the latter a bit then I think we have a winner. :)
Here are a few more tests which create a ZIP file in addition to a tar
archive and compare them to their non-bare counterparts.
Care to resend?
Thanks,
René
t/t5000-tar-tree.sh | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index e395ff4..bf5fa25 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -58,6 +58,11 @@ test_expect_success \
git commit-tree $treeid </dev/null)'
test_expect_success \
+ 'create bare clone' \
+ 'git clone --bare . bare.git &&
+ cp .gitattributes bare.git/info/attributes'
+
+test_expect_success \
'remove ignored file' \
'rm a/ignored'
@@ -74,6 +79,14 @@ test_expect_success \
'diff b.tar b2.tar'
test_expect_success \
+ 'git archive in a bare repo' \
+ '(cd bare.git && git archive HEAD) >b3.tar'
+
+test_expect_success \
+ 'git archive vs. the same in a bare repo' \
+ 'test_cmp b.tar b3.tar'
+
+test_expect_success \
'validate file modification time' \
'mkdir extract &&
"$TAR" xf b.tar -C extract a/a &&
@@ -151,6 +164,14 @@ test_expect_success \
'git archive --format=zip' \
'git archive --format=zip HEAD >d.zip'
+test_expect_success \
+ 'git archive --format=zip in a bare repo' \
+ '(cd bare.git && git archive --format=zip HEAD) >d1.zip'
+
+test_expect_success \
+ 'git archive --format=zip vs. the same in a bare repo' \
+ 'test_cmp d.zip d1.zip'
+
$UNZIP -v >/dev/null 2>&1
if [ $? -eq 127 ]; then
echo "Skipping ZIP tests, because unzip was not found"
^ permalink raw reply related
* Re: Re* ext3: fix ext3_dx_readdir hash collision handling - Regression
From: Linus Torvalds @ 2008-10-24 22:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsfx1wnb.fsf_-_@gitster.siamese.dyndns.org>
On Fri, 24 Oct 2008, Junio C Hamano wrote:
>
> Subject: allow readdir(3) to return the same entry twice
The thing is, this really is a kernel bug. We have even bisected it (and
it hasn't hit any released kernel). The original reporter showed it with a
simple "rm -r".
So it really isn't a git bug, even though I initially thought it might be,
before I looked closer.
That said, the git patch may be worth it just because two *concurrent*
invocations of "git clean" could then cause one (or both) to fail this
way.
Linus
^ permalink raw reply
* Re: [PATCH 2/3] Add -n/--no-prompt option to mergetool
From: William Pursell @ 2008-10-24 22:32 UTC (permalink / raw)
To: Charles Bailey
Cc: Junio C Hamano, git, Jeff King, Andreas Ericsson,
Theodore Ts'o
In-Reply-To: <20081023064455.GA10675@hashpling.org>
Charles Bailey wrote:
>
> After more thoughts, I'm somewhat in favour of dropping the short
> switch altogether. As it just saves a single keypress per merge I
> imagine that most mergetool users, once they discover this new
> feature and decide that they want to use it, will prefer to use a user
> config option to switch it on. The command line option then becomes
> something that you would only need to use to override your normal
> default and something on which to hang the option description in the
> man page.
If the short option is dropped, the config option should
probably associated with mergetool.<tool>.interactive rather
than mergetool.interactive. (s/interactive/whatever)
--
William Pursell
^ permalink raw reply
* Re: Re* ext3: fix ext3_dx_readdir hash collision handling - Regression
From: Junio C Hamano @ 2008-10-24 22:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0810241524350.3287@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Fri, 24 Oct 2008, Junio C Hamano wrote:
>>
>> Subject: allow readdir(3) to return the same entry twice
>
> The thing is, this really is a kernel bug. We have even bisected it (and
> it hasn't hit any released kernel). The original reporter showed it with a
> simple "rm -r".
>
> So it really isn't a git bug, even though I initially thought it might be,
> before I looked closer.
>
> That said, the git patch may be worth it just because two *concurrent*
> invocations of "git clean" could then cause one (or both) to fail this
> way.
Yeah, or on perhaps a buggy implementation of readdir(3) on somebody
else's system. In either case, I just thought it might be a low impact
belt-and-suspenders fix that is worth considering.
^ permalink raw reply
* Re: [PATCH 3/5] refactor userdiff textconv code
From: Jeff King @ 2008-10-24 22:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt, Matthieu Moy
In-Reply-To: <7v3ail3dfy.fsf@gitster.siamese.dyndns.org>
On Fri, Oct 24, 2008 at 02:12:17PM -0700, Junio C Hamano wrote:
> Either that or drop data_is_textconv and have two sets of <ptr,size> pair
> in filespec, one for real data and another purely for diff text
> generation.
I thought about that. My reasoning against it was two-fold:
1. We don't want to keep two copies in memory unnecessarily. Of
course, we could easily free the original, but just store the
information in a different pointer to make sure they never get
confused. So that is a non-issue.
2. I had some vague notion that it is more convenient in the long run
to do this to the filespec, since we can then transparently pass the
munged filespec around and pretend like the converted text was the
original content.
However, I'm not sure exactly _where_ we would want to do this.
The obvious places are for patch, for diffstat, or for whitespace
checking. But all of those places use mmfile, so we can munge them
in the same way. I haven't looked at using this with blame, but I do
think "git blame --textconv foo.jpg" would be useful.
(Actually not true. I did just look for 30 seconds at using this
with blame, but blame doesn't seem to to use builtin_diff at all).
> That is, you let fill_mmfile() to fill the real data in mf1 and mf2 as
> before, ask one/two if they have textconv, and if so, convert mf1 and mf2
> in place, and let xdl work on it, like...
I think your example would work fine, if there is no other advantage to
having a transparently-munged diff_filespec (as above).
-Peff
^ permalink raw reply
* Re: [PATCH 2/3] Add -n/--no-prompt option to mergetool
From: Charles Bailey @ 2008-10-24 22:55 UTC (permalink / raw)
To: William Pursell
Cc: Junio C Hamano, git, Jeff King, Andreas Ericsson,
Theodore Ts'o
In-Reply-To: <49024CF1.5040406@gmail.com>
On Fri, Oct 24, 2008 at 11:32:17PM +0100, William Pursell wrote:
>
> If the short option is dropped, the config option should
> probably associated with mergetool.<tool>.interactive rather
> than mergetool.interactive. (s/interactive/whatever)
I'm not sure I understand your reasoning. The no-prompt/interactive
option affects the behaviour of the mergetool script independent of
which particular merge tool is being used. Why should the presence or
absence of a short option affect whether the config option is global
or per tool?
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: [PATCH 3/5] refactor userdiff textconv code
From: Jeff King @ 2008-10-24 22:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt, Matthieu Moy
In-Reply-To: <20081024225001.GA13978@coredump.intra.peff.net>
On Fri, Oct 24, 2008 at 06:50:01PM -0400, Jeff King wrote:
> However, I'm not sure exactly _where_ we would want to do this.
> The obvious places are for patch, for diffstat, or for whitespace
> checking. But all of those places use mmfile, so we can munge them
> in the same way. I haven't looked at using this with blame, but I do
> think "git blame --textconv foo.jpg" would be useful.
>
> (Actually not true. I did just look for 30 seconds at using this
> with blame, but blame doesn't seem to to use builtin_diff at all).
Ah, I see. It looks like we would have to munge fill_blob_sha1 in
builtin-blame.c. In which case totally splitting this out from
diff_filespec is even better, since we don't have one there.
So let me try to re-roll my series based on your suggestion, and then
I'll see if I can add "blame --textconv" on top.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2008, #05; Wed, 22)
From: Jakub Narebski @ 2008-10-24 23:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprlp1w1u.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Junio C Hamano wrote:
>>
>>> * gb/gitweb-pathinfo (Tue Oct 21 21:34:54 2008 +0200) 5 commits
>>> - gitweb: generate parent..current URLs
>>> - gitweb: parse parent..current syntax from PATH_INFO
>>> - gitweb: use_pathinfo filenames start with /
>>> - gitweb: generate project/action/hash URLs
>>> - gitweb: parse project/action/hash_base:filename PATH_INFO
>>>
>>> Seventh iteration; hopefully the usual gitweb gangs will give quick
>>> comments and ack to push this out to 'next' soon.
>>
>> If I remember correctly v7 is mainly cosmetic changes, and I have
>> acked all or almost all of the equivalent patches from v6.
All of v6 patches were acked.
> I take it to mean you reviewed v7 and we have your Ack on them;
> thanks.
Yes.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git performance
From: Pete Harlan @ 2008-10-24 23:10 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <49017F8F.3000908@pcharlan.com>
Pete Harlan wrote:
> Edward Ned Harvey wrote:
>>> Yes, it does stat all the files. How many files are you talking about,
>>> and what platform? From a warm cache on Linux, the 23,000 files kernel
>>> repo takes about a tenth of a second to stat all files for me (and this
>> I'm talking about 40-50,000 files, on multi-user production linux,
>> which means the cache is never warm, except when I'm benchmarking.
>> Specifically RHEL 4 with the files on NFS mount. Cold cache "svn
>> st" takes ~10 mins. Warm cache 20-30 sec. Surprisingly to me,
>
> I did some tests with a repo with ~32k files, and git was slightly
> slower than svn with a cold cache (10.2s vs 8.4s), and around twice as
> fast with a warm cache (.5s vs 1s).
>
> Git 1.6.0.2, svn 1.4.6. Cache made cold with
> "echo 1 >/proc/sys/vm/drop_caches". Timings best of 5 runs.
After redoing this test with "echo 3 >/proc/sys/vm/drop_caches" (which
also discards metadata, as pointed out by Linus), the cold-cache
timings are:
svn 12.65 seconds
git 10.3 seconds
So no Earth-shattering difference, but now git is somewhat quicker
than Subversion at everything I tested.
--Pete
^ permalink raw reply
* Re: [PATCH] Implement git remote rename
From: Junio C Hamano @ 2008-10-24 23:33 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <1224766597-16034-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> +static int mv(int argc, const char **argv)
> +{
> + struct option options[] = {
> + OPT_END()
> + };
> + struct remote *oldremote, *newremote;
> + struct strbuf buf = STRBUF_INIT, buf2 = STRBUF_INIT;
> + struct string_list remote_branches = { NULL, 0, 0, 0 };
> + struct rename_info rename;
> + int i;
> +
> + if (argc != 3)
> + usage_with_options(builtin_remote_usage, options);
> +
> + rename.old = argv[1];
> + rename.new = argv[2];
> + rename.remote_branches = &remote_branches;
> +
> + oldremote = remote_get(rename.old);
> + if (!oldremote)
> + die("No such remote: %s", rename.old);
> +
> + newremote = remote_get(rename.new);
> + if (newremote && (newremote->url_nr > 1 || newremote->fetch_refspec_nr))
> + die("remote %s already exists.", rename.new);
> +
> + strbuf_addf(&buf, "refs/heads/test:refs/remotes/%s/test", rename.new);
> + if (!valid_fetch_refspec(buf.buf))
> + die("'%s' is not a valid remote name", rename.new);
> +
> + strbuf_reset(&buf);
> + strbuf_addf(&buf, "remote.%s", rename.old);
> + strbuf_addf(&buf2, "remote.%s", rename.new);
> + if (git_config_rename_section(buf.buf, buf2.buf) < 1)
> + return error("Could not rename config section '%s' to '%s'",
> + buf.buf, buf2.buf);
Hmm, remote_get() can read from all three supported places that you can
define remotes. Could you explain what happens if the old remote is read
from say $GIT_DIR/remotes/origin and you are renaming it to "upstream"
with "git remote rename origin upstream"?
I suspect that if you record where you read the configuration from in
"struct remote" and add necessary code to remove the original when
rename.old is *not* coming from in-config definition, you would make it
possible for repositories initialized with older git that has either
$GIT_DIR/branches/origin or $GIT_DIR/remotes/origin to be migrated to the
in-config format using "git remote rename origin origin".
^ permalink raw reply
* Re: [PATCH 3/5] refactor userdiff textconv code
From: Jeff King @ 2008-10-25 0:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt, Matthieu Moy
In-Reply-To: <20081024225605.GA16774@coredump.intra.peff.net>
On Fri, Oct 24, 2008 at 06:56:05PM -0400, Jeff King wrote:
> Ah, I see. It looks like we would have to munge fill_blob_sha1 in
> builtin-blame.c. In which case totally splitting this out from
> diff_filespec is even better, since we don't have one there.
>
> So let me try to re-roll my series based on your suggestion, and then
> I'll see if I can add "blame --textconv" on top.
Actually, the blame thing is a little trickier than that. The textconv
stuff is still tied to a diff_filespec because it uses the diff
prepare_temp_file interface. So I will have to work around that if I
want to add blame support.
However, I re-did the existing patches according to your suggestions,
and I think the result is pretty reasonable. Six patches to follow.
-Peff
^ permalink raw reply
* [PATCH 1/7] diff: add missing static declaration
From: Jeff King @ 2008-10-25 0:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Matthieu Moy, git
In-Reply-To: <20081025004815.GA23851@coredump.intra.peff.net>
This function isn't used outside of diff.c; the 'static' was
simply overlooked in the original writing.
Signed-off-by: Jeff King <peff@peff.net>
---
Oops, it is actually 7 patches. This one is the same as before.
diff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index e368fef..d1fd594 100644
--- a/diff.c
+++ b/diff.c
@@ -1282,7 +1282,7 @@ static void emit_binary_diff(FILE *file, mmfile_t *one, mmfile_t *two)
emit_binary_diff_body(file, two, one);
}
-void diff_filespec_load_driver(struct diff_filespec *one)
+static void diff_filespec_load_driver(struct diff_filespec *one)
{
if (!one->driver)
one->driver = userdiff_find_by_path(one->path);
--
1.6.0.3.523.g38597.dirty
^ 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