* Re: [Census] So who uses git?
From: Johannes Schindelin @ 2006-02-01 14:43 UTC (permalink / raw)
To: Joel Becker
Cc: Linus Torvalds, Keith Packard, Carl Baldwin, Junio C Hamano,
Martin Langhoff, Git Mailing List
In-Reply-To: <20060131225514.GC2812@ca-server1.us.oracle.com>
Hi,
On Tue, 31 Jan 2006, Joel Becker wrote:
> On Tue, Jan 31, 2006 at 11:21:52AM -0800, Linus Torvalds wrote:
> > Now, I do agree. I don't actually like hiding the index too much.
> > Understanding the index is _invaluable_ whenever you're doing a merge with
> > conflicts, and understanding what tools are available to you to resolve
> > those conflicts.
>
> This is precisely the experience I've had explaining GIT to
> folks moving to it. The simplest workflow (clone; hack one file, commit
> one file) is so similar to CVS/Subversion/Anything that it's immediately
> understood. But when pull, push, merge, and any non-linear history are
> discussed, I have to describe the index and the commit/tree layout.
> Once I do, they get it.
>
> > So I'm actually of the "revel in the index" camp (as could probably be
> > guessed by the original tutorial).
>
> I'm going to second this, from a real-world "explain it to
> others" standpoint.
How about talking about the index a bit at the end of tutorial.txt like
this:
-- snip --
For a number of (mostly technical) reasons, "git diff" does not show the
changes of the current working directory with respect to the latest
commit, but rather to an intermediate stage: the "index".
Think of the index as a staging area just before committing: the commit
object (and the tree and blob objects referenced from it) are assembled
there.
Also, when you checkout, the index is used to disassemble the commit
object just before writing the corresponding files and directories.
-- snap --
May this be worth the work?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] shallow clone
From: Johannes Schindelin @ 2006-02-01 14:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr76oun9o.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 31 Jan 2006, Junio C Hamano wrote:
> This is whacky, but another completely different strategy is to
> introduce remote alternates.
I'd rather go with the original plan. After all, you do not really need
the cut-off commit objects. All needed objects are available on the server
side: it just has to have a way to know which ones to send.
Ciao,
Dscho
^ permalink raw reply
* Re: [Census] So who uses git?
From: Alex Riesen @ 2006-02-01 14:55 UTC (permalink / raw)
To: Martin Langhoff
Cc: Ray Lehtiniemi, Linus Torvalds, Radoslaw Szkodzinski,
Keith Packard, Junio C Hamano, cworth, Git Mailing List
In-Reply-To: <46a038f90601311852ie8cfac0rbe92779edea4da1b@mail.gmail.com>
On 2/1/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> Perhaps a local git/cygwin on NTFS would be more reasonable to benchmark?
$ time git update-index --refresh
real 0m21.500s
user 0m0.358s
sys 0m1.406s
WinNT, NTFS, 13k files, hot cache.
^ permalink raw reply
* Re: [PATCH 4/9] http-fetch: Actually watch the file descriptors of interest.
From: Nick Hengeveld @ 2006-02-01 15:03 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <20060201114433.5042.22737.stgit@metalzone.distorted.org.uk>
On Wed, Feb 01, 2006 at 11:44:33AM +0000, Mark Wooding wrote:
> Presumably this was just some kind of oversight.
I was never able to make this work reliably across multiple versions of
curl.
> Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
> ---
>
> http.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/http.c b/http.c
> index 0a70e1c..521323c 100644
> --- a/http.c
> +++ b/http.c
> @@ -425,6 +425,8 @@ void run_active_slot(struct active_reque
> FD_ZERO(&excfds);
> select_timeout.tv_sec = 0;
> select_timeout.tv_usec = 50000;
> + curl_multi_fdset(curlm, &readfds, &writefds,
> + &excfds, &max_fd);
> select(max_fd, &readfds, &writefds,
> &excfds, &select_timeout);
> }
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [PATCH 0/9] http-fetch fixes
From: Uwe Zeisberger @ 2006-02-01 15:30 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <20060201112822.5042.41256.stgit@metalzone.distorted.org.uk>
Hello Mark,
Mark Wooding wrote:
> This patch series fixes the git-http-fetch bug I reported in
> `git-http-fetch failure/segfault -- alas no patch'. The preliminary
> patch I was working on /did/ actually fix the bug I found, but uncovered
> a bunch more, which I think I've finally got to the bottom of.
>
> The series applies to commit 1506fc34f7585880aeeb12b5fdfe2de4800f9df5.
after reverting c8568e139ed2149fbfb7ef9a8d819d5b6b7c554f it applies to
8233340ce6eb700eb2cd9c0fef4d1705997c499b (=current master), too.
With these patches applied, I get now a Segfault, while cloning u-boot.
walk a7b9fb9110e3c0be644b3e2c8f397f606138a710
got 98dce899a97f7998b11f58e8c7897ba9f7e0b95a
got 0cfa422c45d2e2b6023b74a3784034bb18a7eb73
got 9341e20e95c5ff5c36a8f9506b4039bbc6aefd43
/home/uzeisberger/usr/bin/git-clone: line 42: 24002 Segmentation fault
git-http-fetch -v -a -w "$name" "$name" "$1/"
Actually now I cannot reproduce it anymore. I added some debugging code
s.t. I can give more details if it reoccurs.
Best regards
Uwe
--
Uwe Zeisberger
http://www.google.com/search?q=5+choose+3
^ permalink raw reply
* git-unadd anyone?
From: Radoslaw Szkodzinski @ 2006-02-01 15:31 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 330 bytes --]
Is there an easy way to just unmark files wrongly marked as added?
I'm not thinking about something like git-reset --mixed,
which would discard the index as a whole.
I only want to unmark files I git-add(1)ed.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: git-unadd anyone?
From: Uwe Zeisberger @ 2006-02-01 15:38 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <43E0D469.1030404@gorzow.mm.pl>
Hello Radoslaw,
Radoslaw Szkodzinski wrote:
> Is there an easy way to just unmark files wrongly marked as added?
>
> I'm not thinking about something like git-reset --mixed,
> which would discard the index as a whole.
> I only want to unmark files I git-add(1)ed.
How about
git update-index --force-remove <filename>
Best regards
Uwe
--
Uwe Zeisberger
http://www.google.com/search?q=5+choose+3
^ permalink raw reply
* Re: [PATCH 0/9] http-fetch fixes
From: Mark Wooding @ 2006-02-01 15:47 UTC (permalink / raw)
To: git
In-Reply-To: <20060201153052.GA16461@informatik.uni-freiburg.de>
Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> wrote:
>> The series applies to commit 1506fc34f7585880aeeb12b5fdfe2de4800f9df5.
> after reverting c8568e139ed2149fbfb7ef9a8d819d5b6b7c554f it applies to
> 8233340ce6eb700eb2cd9c0fef4d1705997c499b (=current master), too.
Good-oh. (I did pull the latest tip, and then panicked because Nick's
change had already made it out.)
> With these patches applied, I get now a Segfault, while cloning
> u-boot.
Oh. :-(
> Actually now I cannot reproduce it anymore. I added some debugging code
> s.t. I can give more details if it reoccurs.
Please do. I've just tried, and I can't reproduce the problem either.
The watch-slots patch seems to uncover all manner of brokenness in
http-fetch.c -- or I've violated some unwritten assumptions of a very
deep nature, which is always possible.
Maybe the right thing to do is to go with Nick's separate-status-
structures patch as an actual mainline fix, with my patches for
http-fetch.c's other bugs as a belt-and-braces.
-- [mdw]
^ permalink raw reply
* [PATCH] git-svnimport.perl: fix for 'arg list too long...'
From: Sasha Khapyorsky @ 2006-02-01 15:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthias Urlichs, git
Hello,
This fixes 'arg list too long' problem when passed to git-ls-files.
Sasha.
This fixes 'arg list too long..' problem with git-ls-files.
Note that second arg list separation loop (with 'git-update-index') is
needed since git-ls-files arguments can be directories.
Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com>
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 6e3a44a..b6799d8 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -546,23 +546,30 @@ sub commit {
}
}
- if(@old) {
- open my $F, "-|", "git-ls-files", "-z", @old or die $!;
- @old = ();
+ while(@old) {
+ my @o1;
+ if(@old > 55) {
+ @o1 = splice(@old,0,50);
+ } else {
+ @o1 = @old;
+ @old = ();
+ }
+ open my $F, "-|", "git-ls-files", "-z", @o1 or die $!;
+ @o1 = ();
local $/ = "\0";
while(<$F>) {
chomp;
- push(@old,$_);
+ push(@o1,$_);
}
close($F);
- while(@old) {
+ while(@o1) {
my @o2;
- if(@old > 55) {
- @o2 = splice(@old,0,50);
+ if(@o1 > 55) {
+ @o2 = splice(@o1,0,50);
} else {
- @o2 = @old;
- @old = ();
+ @o2 = @o1;
+ @o1 = ();
}
system("git-update-index","--force-remove","--",@o2);
die "Cannot remove files: $?\n" if $?;
^ permalink raw reply related
* Re: [Census] So who uses git?
From: Linus Torvalds @ 2006-02-01 16:04 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060201070847.2021.qmail@science.horizon.com>
On Tue, 1 Feb 2006, linux@horizon.com wrote:
>
> At the risk of complicating something already very complicated, and
> possibly breaking on Microsoft file systems, that case can be detected
> by reading the directory and noticing that the inode number changed.
>
> Would it be worth validating the inode numbers (which can be retrieved
> in a batch) even if you don't do a full lstat()?
I don't think it's worth it. It's the unusual case anyway, and it doesn't
even really guarantee anything either (the person _could_ just have marked
the inode writable - not understanding what is going on, he could have
just done a "chmod +w" behind git's back).
Together with the fact that it might not work everywhere, and that I could
well imagine that "readdir()" is slow on cygwin too (how does it do
"d_ino"? Maybe it has to do a stat() to emulate unix behaviour?), I'm not
convinced it's worth it.
I think the whole "assume it's valid" is a crutch - but if we do it, we
should make it _really_ fast, because it's also useful for automated
procedures that _know_ which files they touch. So we should make it have
minimal impact.
Linus
^ permalink raw reply
* Re: [Census] So who uses git?
From: Alex Riesen @ 2006-02-01 16:10 UTC (permalink / raw)
To: linux@horizon.com; +Cc: torvalds, git
In-Reply-To: <20060201070847.2021.qmail@science.horizon.com>
On 1 Feb 2006 02:08:47 -0500, linux@horizon.com <linux@horizon.com> wrote:
> > Yes, I think the "assume unchanged" flag goes well together with making
> > sure that the checked-out file is non-writable at the time.
> >
> > Of course, any number of editors and other actions won't care: if you do
> > anything like
> >
> > for i in *.c
> > do
> > sed 's/xyzzy/bas/g' < $i > $i.new
> > mv $i.new $i
> > done
> >
> > you'll never have even noticed that the old file was marked read-only. So
> > it's obviously not in any way any guarantee, but it probably makes sense
> > as a crutch.
>
> At the risk of complicating something already very complicated, and
> possibly breaking on Microsoft file systems, that case can be detected
> by reading the directory and noticing that the inode number changed.
Inodes are either uselessor dangerous in cygwin (hash of an
absolute pathname on FAT). They may not even change after rm+touch.
^ permalink raw reply
* Re: git-unadd anyone?
From: Radoslaw Szkodzinski @ 2006-02-01 16:11 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20060201153823.GB16461@informatik.uni-freiburg.de>
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]
Uwe Zeisberger wrote:
> Hello Radoslaw,
>
> Radoslaw Szkodzinski wrote:
>> Is there an easy way to just unmark files wrongly marked as added?
>>
>> I'm not thinking about something like git-reset --mixed,
>> which would discard the index as a whole.
>> I only want to unmark files I git-add(1)ed.
> How about
>
> git update-index --force-remove <filename>
>
>
> Best regards
> Uwe
>
Thank you, it's exactly what I was looking for.
If I was mad enough, I'd use git-update-index --add instead of git-add.
I'll have to reacquaint with git low-level commands anyway.
It's weird that there's git-add, yet no git-remove.
The only difference is the exclude file handling (not a problem with remove)
and doing global changes when no parameters are given.
Actually, I don't like the second property that much.
I'd prefer an explicit -a for --all. But it's probably for CVS users sake, right?
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [Census] So who uses git?
From: Jason Riedy @ 2006-02-01 16:15 UTC (permalink / raw)
Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601311747360.7301@g5.osdl.org>
And Linus Torvalds writes:
-
- Has anybody used git over NFS? If it's this bad (or even close to), I
- guess the "mark files as up-to-date in the index" approach is a really
- good idea..
My normal use is on NFS (Solaris and Linux) and IBM's GPFS
(AIX and Linux). I haven't noticed any particular problems,
and LAPACK and the reference BLAS make a moderately sized
working set of around 3000 source files. Not kernel sized,
but not tiny.
However, I mostly use git over NFS on a relatively slow
machine. NFS is faster than the local disk...
Jason
^ permalink raw reply
* Re: [Census] So who uses git?
From: Linus Torvalds @ 2006-02-01 16:25 UTC (permalink / raw)
To: Alex Riesen
Cc: Martin Langhoff, Ray Lehtiniemi, Radoslaw Szkodzinski,
Keith Packard, Junio C Hamano, cworth, Git Mailing List
In-Reply-To: <81b0412b0602010655i7b538bdck2baa216203279bce@mail.gmail.com>
On Wed, 1 Feb 2006, Alex Riesen wrote:
>
> $ time git update-index --refresh
>
> real 0m21.500s
> user 0m0.358s
> sys 0m1.406s
>
> WinNT, NTFS, 13k files, hot cache.
That's 25% less files than the Linux kernel, and I can do that operation
in 0m0.062s (0.012s user, 0.048s system).
So WinNT/cygwin is about 2.5 _orders_of_maginitude_ slower here, or 340
times slower.
Now, I'm tempted to say that NT is a piece of sh*t, but the fact is, your
CPU-times seem to indicate that most of it is IO (and the "real" cost is
just 1.7 seconds, much of which is system time, which in turn itself is
probably due to the IO costs too - so even that isn't comparable with
the ).
Which may mean that you simply don't have enough memory to cache the whole
thing. Which may be NT sucking, of course ("we don't like to use more than
10% of memory for caches"), but it might also be a tunable (which is sucky
in itself, of course), but finally, it might just be that you just don't
have a ton of memory. I've got 2GB in my machines, although 1GB is plenty
to cache the kernel.
Linus
^ permalink raw reply
* Re: [Census] So who uses git?
From: Linus Torvalds @ 2006-02-01 17:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q3jlgw2.fsf@assigned-by-dhcp.cox.net>
On Tue, 31 Jan 2006, Junio C Hamano wrote:
>
> Taken together with your "during a partially conflicted merge"
> example, it feels to me that the simplest safety valve would be
> to refuse "git commit paths..." if the index does not exactly
> match HEAD. Not just mentioned paths but anywhere.
But at that point, the existing "git commit" semantics actually are the
ones we'd use, and the only difference ends up being that we error out
if the index doesn't match HEAD.
The problem with that is that it appears that some of the people who don't
like the current "git commit <filename>" thing _do_ actually understand
the index, but they want to commit just that one file.
So at least from my understanding, I think Dscho was arguing for the new
semantics of "git commit <file>" to _work_, but to only commit <file>,
even if he does understand the index perfectly well, and might have done a
"git add" or updated a file for some other reason..
Btw, one thing that _can_ be confusing is that you do
git commit fileA
and then when you edit the commit message, you realize that you don't
actually want to do this at all, so you exit out of the editor without
changes (which aborts the commit). Now "git commit" will not actually have
done the commit, but it _will_ have done the "git-update-index" on that
file.
So next time, when you do
git commit fileB
you'll currently commit _both_ fileA and fileB.
This is, in my opinion, the biggest argument for the suggested _new_
semantics: if you explicitly name a set of files, it should always do a
# Verify current state
parent=$(git-rev-parse --verify HEAD) || exit
# Verify that the current index is ok in the named files
a=$(git-diff-files --name-only --cached $parent "$@") || exit
if [ "$a" ]; then
echo -e >&2 "Files are changed in the index:\n $a"
exit 2
fi
# create the new tree object
export GIT_INDEX_FILE=tmpfile
newtree=$(git-read-tree $parent &&
git-update-index "$@" &&
git-write-tree) || exit
# edit message
... edit message ..
# do commit
newhead=$(git-commit-tree -p $parent < msg)
git-update-ref HEAD $newhead $parent
or similar. That has the advantage that if we _do_ decide to break out of
the commit, we will not have changed the current index (only the temporary
one).
Linus
^ permalink raw reply
* Re: [PATCH 3/9] http-fetch: Abort requests for objects which arrived in packs
From: Nick Hengeveld @ 2006-02-01 17:12 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <20060201114430.5042.5144.stgit@metalzone.distorted.org.uk>
On Wed, Feb 01, 2006 at 11:44:31AM +0000, Mark Wooding wrote:
> +void release_active_slot(struct active_request_slot *slot)
> +{
> + closedown_active_slot(slot);
> + if (slot->curl) {
> + curl_multi_remove_handle(curlm, slot->curl);
> + curl_easy_cleanup(slot->curl);
> + slot->curl = NULL;
> + }
> + fill_active_slots();
> +}
Does it make sense to call curl_easy_cleanup here? This will close
persistent server connections and cause another connection startup if
the slot is reused.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [Census] So who uses git?
From: Nicolas Pitre @ 2006-02-01 17:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v4q3jlgw2.fsf@assigned-by-dhcp.cox.net>
On Tue, 31 Jan 2006, Junio C Hamano wrote:
> This "I thought I was only checking in the two-liner I did as
> the last step but you committed the whole thing, stupid git!"
> confusion feels to be a parallel of "I thought I was only
> checking in the files I specified on the command line but you
> also committed the files I earlier git-add'ed, stupid git!"
> confusion.
>
> Taken together with your "during a partially conflicted merge"
> example, it feels to me that the simplest safety valve would be
> to refuse "git commit paths..." if the index does not exactly
> match HEAD. Not just mentioned paths but anywhere.
>
> People who do not like this can set in their config file some
> flag, say, 'core.index = understood', to get the current
> behaviour.
I'd avoid hidden config options that magically change behaviors and
semantics like that as much as possible. _This_ would pave the way to
even greater confusion and prevent the git user base from converging on
a unified semantics knowledge. Better add a command line option which
has the vertue of being visible, and name it such that it make the
intention explicit whether the previous index state is preserved or not,
something like --current-index or the like.
> The reason I am bringing this up is because of this command
> sequence:
>
> # start from a clean tree, after 'git reset --hard'
> $ create a-new-file
> $ git add a-new-file
> $ edit existing-file
> $ edit another-file
> $ git commit existing-file
>
> There is no question we do not commit "another-file" and we do
> commit changes to the "existing-file" as a whole. What should
> we do to "a-new-file", and how do we explain why we do so to
> novices?
>
> We can argue it either way. We could say we shouldn't because
> "commit" argument does not mention it. We could say we should
> because the user already told that he wants to add that file to
> git. Either makes sort-of sense from what the end user did.
It is much more intuitive to expect that, if you specify path arguments
to commit, then only those paths are considered, and even if you didn't
do a git add on some of them. If nothing is specified then the current
index (the default, including a-new-file) is considered.
> I think a file "cvs add"ed is committed if whole subdirectory
> commit (similar to our "commit -a") is done or the file is
> explicitly specified on the "cvs commit" command line, and that
> may match people's expectations. That's an argument for not
> committing "a-new-file".
Exact.
> But to be consistent with that, this should not commit anything:
>
> # the same clean tree.
> $ create a-new-file
> $ git add a-new-file
> $ git commit
>
> Which is counterintuitive to me by now (because I played too
> long with git).
IMHO this should commit a_new_file simply because you added it to the
index and a commit without any argument should commit the whole
(refreshed) index.
> We could make "git commit" without paths to mean the current
> "-a" behaviour, which would match CVS behaviour more closely.
Exact.
> However, it would make commit after a merge conflict resolution
> in a dirty working tree _very_ dangerous -- it may give more
> familiar feel to CVS people, but it is not an improvement for
> git people at all. I would rather not.
For that case, (assuming that -a would be the default) maybe something
meaning the opposite of -a could be specified on the commit argument
list like I suggested earlier. And maybe it should always be the
default when committing a merge (in which case the -a would override
that and refresh everything and not only the merged files plus those
specified on the command line).
So to resume:
- a non-merge commit without any argument would imply -a.
- a non-merge commit with path arguments implies _only_ those paths,
regardless if they were previously "git add"ed or not.
- a non-merge commit with, say, --no-auto or --current-index or
whatever would preserve the current behavior, with or without
additional paths.
- a merge commit would imply that --no-auto behavior automatically.
- a merge commit could override the --no-auto with an explicit -a.
This might look complicated when presented like that, but I think that
the default behavior of each (non-merge vs merge) commit would more
closely fit most people's expectations. The merge commit create a shift
in semantics of course, but committing a merge is already something a
bit more involved anyway and at that point git users should have gained
a bit more experience with the index concept and the default merge
behavior is probably what most people will expect at that point as well.
Nicolas
^ permalink raw reply
* Re: [PATCH 3/9] http-fetch: Abort requests for objects which arrived in packs
From: Mark Wooding @ 2006-02-01 17:23 UTC (permalink / raw)
To: git
In-Reply-To: <20060201171225.GI3873@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> wrote:
> Does it make sense to call curl_easy_cleanup here? This will close
> persistent server connections and cause another connection startup if
> the slot is reused.
I'm by no means a Curl expert. But I scoured the docs for another way
of interrupting the current fetch and I couldn't find anything. It
really didn't seem like a good idea to leave the handle as it was,
having (possibly) half-fetched a thing we weren't actually interested in
-- that way lies confusion.
Besides, in practice, what's happened is that the object we asked for is
in a pack which we've just collected. Unless the upstream repository
hasn't been git-prune-packed, our fetch is going to fail with a 404
anyway, at which point Curl /will/ close the connection and make another
one next time. So, in real life, it makes no difference.
-- [mdw]
^ permalink raw reply
* Re: [Census] So who uses git?
From: Julian Phillips @ 2006-02-01 19:20 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ray Lehtiniemi, Alex Riesen, Radoslaw Szkodzinski, Keith Packard,
Junio C Hamano, cworth, Martin Langhoff, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601311747360.7301@g5.osdl.org>
On Tue, 31 Jan 2006, Linus Torvalds wrote:
> Sounds like every single stat() will go out the wire. I forget what the
> Linux NFS client does, but I _think_ it has a metadata timeout that avoids
> this. But it might be as bad under NFS.
>
> Has anybody used git over NFS? If it's this bad (or even close to), I
> guess the "mark files as up-to-date in the index" approach is a really
> good idea..
As it happens, yes ... I can't say that I've noticed git being
particularly slow, but then - I've not tried running git with a local
repos ... ;)
using a recentish 2.6 kernel repos, directly on the server I get:
server: linux-2.6>time git update-index --refresh
real 0m0.067s
user 0m0.015s
sys 0m0.052s
then against the same repos over NFS, I get:
client: linux-2.6>time git update-index --refresh
real 0m1.578s
user 0m0.018s
sys 0m0.366s
and if I do it from the client again soon afterward I get:
client: linux-2.6>time git update-index --refresh
real 0m0.145s
user 0m0.012s
sys 0m0.118s
>
> Of course, the whole point of git is that you should keep your repository
> close, but sometimes NFS - or similar - is enforced upon you by other
> issues, like the fact that the powers-that-be want anonymous workstations
> and everybody should work with a home-directory automounted over NFS..
>
--
Julian
---
You know it's going to be a bad day when you want to put on the clothes
you wore home from the party and there aren't any.
^ permalink raw reply
* Re: [Census] So who uses git?
From: H. Peter Anvin @ 2006-02-01 19:30 UTC (permalink / raw)
To: Linus Torvalds
Cc: Martin Langhoff, Ray Lehtiniemi, Alex Riesen,
Radoslaw Szkodzinski, Keith Packard, Junio C Hamano, cworth,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601311943290.7301@g5.osdl.org>
Linus Torvalds wrote:
>
> It's not magic, and it's not all that recent. Linux FS ops have always
> been pretty good, and the dentry cache was introduced in 2.0.x, I think,
> so you'd be hard-pressed to find a Linux system that doesn't have it.
>
2.1.14, I seem to remember -- it was definitely 2.1.1x-ish. I mostly
recall because autofs didn't just break horribly, it took adding several
dcache hooks to make it work again :)
-hpa
^ permalink raw reply
* Re: [Census] So who uses git?
From: Linus Torvalds @ 2006-02-01 19:29 UTC (permalink / raw)
To: Julian Phillips
Cc: Ray Lehtiniemi, Alex Riesen, Radoslaw Szkodzinski, Keith Packard,
Junio C Hamano, cworth, Martin Langhoff, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602011909330.6498@beast.quantumfyre.co.uk>
On Wed, 1 Feb 2006, Julian Phillips wrote:
>
> As it happens, yes ... I can't say that I've noticed git being particularly
> slow, but then - I've not tried running git with a local repos ... ;)
Well, NFS seems to be ok. Which is not that surprising: NFS has gotten a
_lot_ of attention in the caching area (I worked on it myself a couple of
years back when the page cache transition happened during 2.3.x, but
happily we've had very good NFS maintainership since, so I don't get
involved any more).
Your numbers show that NFS is fine (my "benchmark" is that I refuse to see
the kinds of commit times that "cvs commit" does - easily several minutes
for a big project. If it goes over 2 seconds, it's painful, and over ten
seconds is totally unacceptable).
Your numbers seem to say that at least with a good network/server, NFS on
Linux is not a problem at all.
CIFS is likely a very different animal. I suspect the cifs people have
spent a whole lot more effort on strange Windows interaction issues than
on trying to make sure that cached performance is top-notch.
Linus
^ permalink raw reply
* Re: gnu/linux sued for predatory business practices
From: Radoslaw Szkodzinski @ 2006-02-01 19:33 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <drp5vk$njt$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 371 bytes --]
walt wrote:
> Now, when Micro$oft (eventually) takes its (natural)
> place as a loser in the marketplace -- who will the
> lawyers be anxious to sue?
Possible targets include FSF and especially OSDL.
Is there any Linux Corp.? Maybe Linux Australia?
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [Census] So who uses git?
From: H. Peter Anvin @ 2006-02-01 19:32 UTC (permalink / raw)
To: Carl Baldwin
Cc: Junio C Hamano, Keith Packard, Martin Langhoff, Linus Torvalds,
Git Mailing List
In-Reply-To: <20060130185822.GA24487@hpsvcnb.fc.hp.com>
Carl Baldwin wrote:
>
> - Anyone can install and fire it up without license/contract hassles.
>
For something like an SCM this is a big deal, and not just for the Open
Source world. In a company, it means not having to worry about having
enough licenses, and getting budget approval, etc, etc, before a new
person can join a project. Perhaps more importantly, it allows someone
who normally isn't *on* the project to look at it and participate.
-hpa
^ permalink raw reply
* Re: [Census] So who uses git?
From: H. Peter Anvin @ 2006-02-01 19:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Carl Baldwin, Junio C Hamano, Keith Packard,
Martin Langhoff, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601310926330.7301@g5.osdl.org>
Linus Torvalds wrote:
>>
>>For example, I had a hard time explaining to a friend why a git-add'ed
>>file is committed when saying "git commit some_other_file", but not
>>another (modified) file. Very unintuitive.
>
> I really think you should explain it one of two ways:
>
> - ignore it. Never _ever_ use git-update-index directly, and don't tell
> people about use individual filenames to git-commit. Maybe even add
> "-a" by default to the git-commit flags as a special installation
> addition.
>
> - talk about the index, and revel in it as a way to explain the staging
> area. This is what the old tutorial.txt did before it got simplified.
>
> The "ignore the index" approach is the simple one to explain. It's
> strictly less powerful, but hey, what else is new?
>
I think both of these are probably the wrong answer, and it's pretty
much a matter of the git model violating the principle of least
surprise. Perhaps added (or removed?) files need to be handled in a
different way than they currently are.
-hpa
^ permalink raw reply
* Re: [Announce] gitview-0.1
From: Junio C Hamano @ 2006-02-01 20:01 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: Dave Jones, git, junkio
In-Reply-To: <cc723f590602010328w7b4a7befr40a76620e197d00c@mail.gmail.com>
Aneesh Kumar <aneesh.kumar@gmail.com> writes:
> for parent_id in parent_sha1 parent_sha2 parent_sha3 .......
> commit_diff = commit_diff + git diff tree -p parent_id commit_sha1
>
> is this the correct way ?
Are parent_sha$N true parents of commit_sha1? If you want to
get three independent diffs, "git diff-tree -m -p $commit_sha1"
would give that to you in one go.
^ 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