* Re: GIT_OBJECT_DIRECTORY
From: Jörn Engel @ 2006-04-18 14:16 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060418141050.7941.qmail@science.horizon.com>
On Tue, 18 April 2006 10:10:50 -0400, linux@horizon.com wrote:
>
> Just to cover the obvious "is it plugged in?" questions, did you
> also "export GIT_OBJECT_DIRECTORY"? That is, what does
> env | grep GIT_OBJECT_DIRECTORY
> produce?
$ env | grep GIT_OBJECT_DIRECTORY
GIT_OBJECT_DIRECTORY=/home/joern/.git
And maybe for the record, I just the debian unstable package:
$ git --version
git version 1.2.1
Jörn
--
Anything that can go wrong, will.
-- Finagle's Law
^ permalink raw reply
* Re: [PATCH] git-rev-list: fix --header
From: Johannes Schindelin @ 2006-04-18 14:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd4rlw0m.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 17 Apr 2006, Junio C Hamano wrote:
> Still undecided. As you say it is an easy change, so I'd rather
> leave the behaviour as before for now.
Okay, I'd say go with the shorter (your) solution.
Ciao,
Dscho
^ permalink raw reply
* Re: GIT_OBJECT_DIRECTORY
From: Linus Torvalds @ 2006-04-18 15:25 UTC (permalink / raw)
To: Jörn Engel; +Cc: git
In-Reply-To: <20060418133847.GC4720@wohnheim.fh-wedel.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 805 bytes --]
On Tue, 18 Apr 2006, Jörn Engel wrote:
>
> $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git foo
> [ stored >200M of data under foo/.git/objects ]
>
> The above looks as if new objects are not stored under
> /home/joern/.git, as specified by GIT_OBJECT_DIRECTORY.
The "rsync" protocol really doesn't honor git rules. It's basically just a
big recursive copy, and it will copy things from the place they were
before.
I suspect that if you had used a real git-aware protocol instead, you'd
have been fine, ie
git clone git://git.kernel.org/... foo/
would probably work. (I say "probably", because very few people likely use
GIT_OBJECT_DIRECTORY, and it makes a lot less sense with pack-files than
it did originally, so it's not getting any testing).
Linus
^ permalink raw reply
* Re: Log message printout cleanups
From: Linus Torvalds @ 2006-04-18 15:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5ffig70.fsf@assigned-by-dhcp.cox.net>
On Mon, 17 Apr 2006, Junio C Hamano wrote:
>
> I think this does what both of us want. One thing I noticed is
> that log-tree-diff-flush does "---\n" under --patch-with-stat
> but not under --stat; I matched that here.
Looks very nice now. Thanks.
My only slight complaint is that I think it should be possible to do
git log --cc --stat
to get both patches and stat, but that doesn't work. You have to write
git log --cc --patch-with-stat
to get both ;/
But that's just a small (and unimportant) detail.
Here's another really small detail: with merges, there's two newlines
between the diffstat and the diff. That bug doesn't show up with regular
commits.
But this all looks very nice. I agree that "git log --stat" is a very nice
way to look at the log, much better than "git-whatchanged". And the thing
that has really fallen out of this all is how you can do
git log --stat --full-diff drivers/pci/
which git-whatchanged historically didn't support (of course, now it
does, but you're right, the new "git log" is so nice that I'm starting to
teach myself not to use "git whatchanged" any more).
Linus
^ permalink raw reply
* Re: Log message printout cleanups
From: Linus Torvalds @ 2006-04-18 16:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604180827040.3701@g5.osdl.org>
On Tue, 18 Apr 2006, Linus Torvalds wrote:
>
> But this all looks very nice. I agree that "git log --stat" is a very nice
> way to look at the log, much better than "git-whatchanged". And the thing
> that has really fallen out of this all is how you can do
>
> git log --stat --full-diff drivers/pci/
>
> which git-whatchanged historically didn't support (of course, now it
> does, but you're right, the new "git log" is so nice that I'm starting to
> teach myself not to use "git whatchanged" any more).
Junio, I just tested the "master" branch, and "git log --stat" doesn't
work there. You may _think_ it works because you've tested it on the git
tree, were it looks like it is working, but it's missing setting
"recursive", so it won't actually go into any subdirectories (so it mostly
works for git itself which has most stuff in the top-level directory, but
it almost completely doesn't work for linux)
"git log -r --stat" works, so it's really just a missing that.
Something like this (this is master, not "next").
"next" actually has the same bug, but there it is hidden because "git log"
sets recursive automatically. Which may or may not be appropriate. It
might be worthwhile to fix it properly in "next" too (there the same
if (...output_format == DIFF_FORMAT_PATCH)
...recursive = 1;
is in revision.c: setup_revisions()).
Linus
----
diff --git a/git.c b/git.c
index 140ed18..f98c9ba 100644
--- a/git.c
+++ b/git.c
@@ -344,7 +344,8 @@ static int cmd_log(int argc, const char
opt.ignore_merges = 0;
if (opt.dense_combined_merges)
opt.diffopt.output_format = DIFF_FORMAT_PATCH;
- if (opt.diffopt.output_format == DIFF_FORMAT_PATCH)
+ if (opt.diffopt.output_format == DIFF_FORMAT_PATCH ||
+ opt.diffopt.output_format == DIFF_FORMAT_DIFFSTAT)
opt.diffopt.recursive = 1;
if (!full_diff && rev.prune_data)
diff_tree_setup_paths(rev.prune_data, &opt.diffopt);
^ permalink raw reply related
* Re: Log message printout cleanups
From: Junio C Hamano @ 2006-04-18 16:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604180854550.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Junio, I just tested the "master" branch, and "git log --stat" doesn't
> work there.
Ahhhh.
> opt.diffopt.output_format = DIFF_FORMAT_PATCH;
> - if (opt.diffopt.output_format == DIFF_FORMAT_PATCH)
> + if (opt.diffopt.output_format == DIFF_FORMAT_PATCH ||
> + opt.diffopt.output_format == DIFF_FORMAT_DIFFSTAT)
> opt.diffopt.recursive = 1;
When pointed out in a patch from, it looks so obvious. *BLUSH*
Thanks.
^ permalink raw reply
* Re: GIT_OBJECT_DIRECTORY
From: Jörn Engel @ 2006-04-18 17:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604180822470.3701@g5.osdl.org>
On Tue, 18 April 2006 08:25:47 -0700, Linus Torvalds wrote:
> On Tue, 18 Apr 2006, Jörn Engel wrote:
> >
> > $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git foo
> > [ stored >200M of data under foo/.git/objects ]
> >
> > The above looks as if new objects are not stored under
> > /home/joern/.git, as specified by GIT_OBJECT_DIRECTORY.
>
> The "rsync" protocol really doesn't honor git rules. It's basically just a
> big recursive copy, and it will copy things from the place they were
> before.
>
> I suspect that if you had used a real git-aware protocol instead, you'd
> have been fine, ie
>
> git clone git://git.kernel.org/... foo/
Is it possible for non-owners of a kernel.org account to do this?
> would probably work. (I say "probably", because very few people likely use
> GIT_OBJECT_DIRECTORY, and it makes a lot less sense with pack-files than
> it did originally, so it's not getting any testing).
Well, .git/objects for your kernel still consumes 121M. It's not
gigabytes but I still wouldn't want too many copies of that lying
around. Right now, I already feel slightly motivated to move the
whole content-addressable idea into the kernel. It has disadvantages,
but the effect on disk- and pagecache-footprint for people like me
would come in handy.
Jörn
--
The cheapest, fastest and most reliable components of a computer
system are those that aren't there.
-- Gordon Bell, DEC labratories
^ permalink raw reply
* [RESEND] [PATCH] fix gitk with lots of tags
From: Jim Radford @ 2006-04-18 18:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, Git Mailing List
In-Reply-To: <20060406203637.GA15009@blackbean.org>
Hi Junio,
I've gotten no reposnse from Paul on this patch[1]. If it seems ok to
you, would you mind putting it in your queue for him? I hate to see
gitk die with "argument list too long" messages. They're so 640k.
Thanks,
-Jim
[1] Maybe he judges people by the color of their IP address?
Then again, he could just be busy.
---
This fix allow gitk to be used on repositories with lots of tags. It
bypasses git-rev-parse and passes its arguments to git-rev-list
directly to avoid tcl's argument list length restrictions.
Signed-Off-By: Jim Radford <radford@blackbean.org>
diff --git a/gitk b/gitk
index 26fa79a..40672fb 100755
--- a/gitk
+++ b/gitk
@@ -17,19 +17,11 @@ proc gitdir {} {
}
proc parse_args {rargs} {
- global parsed_args
-
- if {[catch {
- set parse_args [concat --default HEAD $rargs]
- set parsed_args [split [eval exec git-rev-parse $parse_args] "\n"]
- }]} {
- # if git-rev-parse failed for some reason...
- if {$rargs == {}} {
- set rargs HEAD
- }
- set parsed_args $rargs
+ if {$rargs == {}} {
+ return HEAD
+ } else {
+ return $rargs
}
- return $parsed_args
}
proc start_rev_list {rlargs} {
^ permalink raw reply related
* Re: GIT_OBJECT_DIRECTORY
From: Sam Ravnborg @ 2006-04-18 18:07 UTC (permalink / raw)
To: J?rn Engel; +Cc: Linus Torvalds, git
In-Reply-To: <20060418175853.GA25688@wohnheim.fh-wedel.de>
On Tue, Apr 18, 2006 at 07:58:53PM +0200, J?rn Engel wrote:
>
> > git clone git://git.kernel.org/... foo/
>
> Is it possible for non-owners of a kernel.org account to do this?
Yes - everyone can do so.
I never use rsync myself anymore.
Sam
^ permalink raw reply
* Confused about tracking git master
From: Seth Falcon @ 2006-04-18 18:08 UTC (permalink / raw)
To: git
Hi,
I'm tracking git and somehow getting confused about how to get
updates.
To start, I did: git clone git://git.kernel.org/pub/scm/git/git.git
To get updates, I _think_ all I have to do is 'git pull'. Doing so I
get:
Unpacking 157 objects
100% (157/157) done
* refs/heads/todo: same as branch 'todo' of git://git.kernel.org/pub/scm/git/git
* refs/heads/maint: same as branch 'maint' of git://git.kernel.org/pub/scm/git/git
* refs/heads/origin: same as branch 'master' of git://git.kernel.org/pub/scm/git/git
* refs/heads/pu: does not fast forward to branch 'pu' of git://git.kernel.org/pub/scm/git/git;
not updating.
Then when I do git whatchanged, the last change is on Saturday the
15th. I'm figuring there has probably been at least one commit since
then? So I tried 'git checkout origin' and then repeated the
whatchanged call and see:
diff-tree 2855d58... (from bb99661...)
Author: Junio C Hamano <junkio@cox.net>
Date: Mon Apr 17 17:46:07 2006 -0700
Is there a step I'm missing? Or am I just misunderstanding what to
expect? Clarification on either of those would be appreciated.
Thanks,
+ seth
^ permalink raw reply
* Re: GIT_OBJECT_DIRECTORY
From: Linus Torvalds @ 2006-04-18 18:08 UTC (permalink / raw)
To: Jörn Engel; +Cc: git
In-Reply-To: <20060418175853.GA25688@wohnheim.fh-wedel.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1200 bytes --]
On Tue, 18 Apr 2006, Jörn Engel wrote:
> >
> > git clone git://git.kernel.org/... foo/
>
> Is it possible for non-owners of a kernel.org account to do this?
Yes, kernel.org runs the git daemon.
If a repo isn't packed enough, the git protocol can be pretty CPU
intensive, but I'm hoping that everybody keeps their repos mostly packed,
at which point the git protocol should actually be a lot faster than
rsync.
> > GIT_OBJECT_DIRECTORY, and it makes a lot less sense with pack-files than
> > it did originally, so it's not getting any testing).
>
> Well, .git/objects for your kernel still consumes 121M. It's not
> gigabytes but I still wouldn't want too many copies of that lying
> around.
Right. However, these days we have better approaches than
GIT_OBJECT_DIRECTORY for that.
In particular, if you create local clones, use "git clone -l -s", which
shares its base objects with the thing you clone from. It makes the clone
incredibly fast too (the only real cost is the check-out, which can
obviously be pretty expensive), and you can then use
git repack -a -d -l
on all the to repack just the _local_ objects to avoid having packs
duplicate objects unnecessarily.
Linus
^ permalink raw reply
* Re: GIT_OBJECT_DIRECTORY
From: Junio C Hamano @ 2006-04-18 18:20 UTC (permalink / raw)
To: Jörn Engel; +Cc: git
In-Reply-To: <20060418175853.GA25688@wohnheim.fh-wedel.de>
Jörn Engel <joern@wohnheim.fh-wedel.de> writes:
> Well, .git/objects for your kernel still consumes 121M. It's not
> gigabytes but I still wouldn't want too many copies of that lying
> around.
That is what "git clone -l -s" is for.
The alternates pointer mechanism used with the above largely
makes GIT_OBJECT_DIRECTORY unnecessary for end users these days.
It is a fine mechanism as an implementation detail of the
lowlevel and Porcelains, and that is the reason the
documentation still mentions the environment.
^ permalink raw reply
* Re: GIT_OBJECT_DIRECTORY
From: Jörn Engel @ 2006-04-18 18:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604181104420.3701@g5.osdl.org>
On Tue, 18 April 2006 11:08:40 -0700, Linus Torvalds wrote:
> On Tue, 18 Apr 2006, Jörn Engel wrote:
> > >
> > > git clone git://git.kernel.org/... foo/
> >
> > Is it possible for non-owners of a kernel.org account to do this?
>
> Yes, kernel.org runs the git daemon.
Excellent! I have a faint memory of hpa recently saying that the git
daemon would be too resource-hungry. One of the cases where being
wrong is a Good Thing.
> >
> > Well, .git/objects for your kernel still consumes 121M. It's not
> > gigabytes but I still wouldn't want too many copies of that lying
> > around.
>
> Right. However, these days we have better approaches than
> GIT_OBJECT_DIRECTORY for that.
>
> In particular, if you create local clones, use "git clone -l -s", which
> shares its base objects with the thing you clone from. It makes the clone
> incredibly fast too (the only real cost is the check-out, which can
> obviously be pretty expensive), and you can then use
>
> git repack -a -d -l
>
> on all the to repack just the _local_ objects to avoid having packs
> duplicate objects unnecessarily.
This still isn't good enough for me. Before git, all my trees were
hard-linked (cowlinked, actually) and another copy barely consumed any
space. "git clone -l -s" creates a copy of the currently 311M of
kernel source, quite a bit more expensive.
But it appears as if I could "cp -lr" the git tree and work with that.
The nice thing of having cowlinks is that I don't have to rely on git
breaking the hard links - which it probably won't. But since the
estimated user base of cowlinks is 1, that won't help too many people.
Jörn
--
Good warriors cause others to come to them and do not go to others.
-- Sun Tzu
^ permalink raw reply
* [PATCH] diff --stat: make sure to set recursive.
From: Junio C Hamano @ 2006-04-18 18:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604180854550.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Junio, I just tested the "master" branch, and "git log --stat" doesn't
> work there. You may _think_ it works because you've tested it on the git
> tree, were it looks like it is working, but it's missing setting
> "recursive", so it won't actually go into any subdirectories (so it mostly
> works for git itself which has most stuff in the top-level directory, but
> it almost completely doesn't work for linux)
True. It shows that I usually install and use "next" version
exclusively, which is fine during the normal development phase,
but it was a wrong thing to keep doing just before the release.
I think diff-tree --stat has the same problem in "master", so
I'd do it slightly differently.
-- >8 --
Just like "patch" format always needs recursive, "diffstat"
format does not make sense without setting recursive.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff-tree.c | 3 ---
diff.c | 10 ++++++++++
git.c | 2 --
3 files changed, 10 insertions(+), 5 deletions(-)
f56ef54174598d5362d0446c5a560cb5892537c2
diff --git a/diff-tree.c b/diff-tree.c
index 7015b06..d1c61c8 100644
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -117,9 +117,6 @@ int main(int argc, const char **argv)
if (opt->dense_combined_merges)
opt->diffopt.output_format = DIFF_FORMAT_PATCH;
- if (opt->diffopt.output_format == DIFF_FORMAT_PATCH)
- opt->diffopt.recursive = 1;
-
diff_tree_setup_paths(get_pathspec(prefix, argv), &opt->diffopt);
diff_setup_done(&opt->diffopt);
diff --git a/diff.c b/diff.c
index b54bbfa..3a1e6ce 100644
--- a/diff.c
+++ b/diff.c
@@ -1029,6 +1029,16 @@ int diff_setup_done(struct diff_options
options->detect_rename != DIFF_DETECT_COPY) ||
(0 <= options->rename_limit && !options->detect_rename))
return -1;
+
+ /*
+ * These cases always need recursive; we do not drop caller-supplied
+ * recursive bits for other formats here.
+ */
+ if ((options->output_format == DIFF_FORMAT_PATCH) ||
+ (options->output_format == DIFF_FORMAT_DIFFSTAT) ||
+ (options->with_stat))
+ options->recursive = 1;
+
if (options->detect_rename && options->rename_limit < 0)
options->rename_limit = diff_rename_limit_default;
if (options->setup & DIFF_SETUP_USE_CACHE) {
diff --git a/git.c b/git.c
index 140ed18..5209b04 100644
--- a/git.c
+++ b/git.c
@@ -344,8 +344,6 @@ static int cmd_log(int argc, const char
opt.ignore_merges = 0;
if (opt.dense_combined_merges)
opt.diffopt.output_format = DIFF_FORMAT_PATCH;
- if (opt.diffopt.output_format == DIFF_FORMAT_PATCH)
- opt.diffopt.recursive = 1;
if (!full_diff && rev.prune_data)
diff_tree_setup_paths(rev.prune_data, &opt.diffopt);
diff_setup_done(&opt.diffopt);
--
1.3.0.rc4.g8060
^ permalink raw reply related
* Re: [RESEND] [PATCH] fix gitk with lots of tags
From: Linus Torvalds @ 2006-04-18 18:38 UTC (permalink / raw)
To: Jim Radford; +Cc: Junio C Hamano, Paul Mackerras, Git Mailing List
In-Reply-To: <20060418180614.GA31543@blackbean.org>
On Tue, 18 Apr 2006, Jim Radford wrote:
>
> I've gotten no reposnse from Paul on this patch[1]. If it seems ok to
> you, would you mind putting it in your queue for him? I hate to see
> gitk die with "argument list too long" messages. They're so 640k.
Don't do this patch. It's wrong.
However, this simpler patch might be ok.
It just depends on the fact that git-rev-list can parse everything that
git-rev-parse used to do these days, and thus the git-rev-parse call
really isn't needed any more (and if that isn't true for some odd
argument, we should make it true).
So the only thing we need to do is to add the "--default HEAD" thing to
the front of the argument list.
Linus
---
diff --git a/gitk b/gitk
index 87e7162..5d95779 100755
--- a/gitk
+++ b/gitk
@@ -19,16 +19,7 @@ proc gitdir {} {
proc parse_args {rargs} {
global parsed_args
- if {[catch {
- set parse_args [concat --default HEAD $rargs]
- set parsed_args [split [eval exec git-rev-parse $parse_args] "\n"]
- }]} {
- # if git-rev-parse failed for some reason...
- if {$rargs == {}} {
- set rargs HEAD
- }
- set parsed_args $rargs
- }
+ set parsed_args [concat --default HEAD $rargs]
return $parsed_args
}
^ permalink raw reply related
* Re: GIT_OBJECT_DIRECTORY
From: Jörn Engel @ 2006-04-18 18:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfykag2yd.fsf@assigned-by-dhcp.cox.net>
On Tue, 18 April 2006 11:20:58 -0700, Junio C Hamano wrote:
> Jörn Engel <joern@wohnheim.fh-wedel.de> writes:
>
> > Well, .git/objects for your kernel still consumes 121M. It's not
> > gigabytes but I still wouldn't want too many copies of that lying
> > around.
>
> That is what "git clone -l -s" is for.
See my response to Linus. .git/objects is currently the smaller
problem. The larger problem is 311M of raw kernel source - without
any SCM overhead of any flavour. Like many others, I solved the
larger problem with hardlink trees. "git clone -l -s" is imo nearly
unethical, as it solved the smaller problem and leaves the larger one
unaffected. It reeks of hypocricy.
Hardlink trees still aren't perfect. If I take one tree, "cp -lr" it
twice and apply the same patches to both copies, the changed files
exist twice for both copies. That sucks, but it is a fairly small
problem and there is no simple solution to it.
If git was able to deal with hardlink trees and properly break the
links when working in one copy, "cp -lr" would be a lot smarter than
"git clone -l -s". It just happens that I have written some kernel
patches that automatically break hardlinks, even if applications don't
know how to do it. So for my personal use, git has this ability.
Now, going one step further, GIT_OBJECT_DIRECTORY could solve another
problem. Just like source files, git object can be pulled twice into
two copies of a tree. But for git objects, there appeared to be an
easy solution: the central object storage. So we're back where this
thread started.
Except that I get the idea of GIT_OBJECT_DIRECTORY not being a simple
solution to a small problem, so maybe I should just forget about it.
Jörn
--
To my face you have the audacity to advise me to become a thief - the worst
kind of thief that is conceivable, a thief of spiritual things, a thief of
ideas! It is insufferable, intolerable!
-- M. Binet in Scarabouche
^ permalink raw reply
* Re: GIT_OBJECT_DIRECTORY
From: Linus Torvalds @ 2006-04-18 18:47 UTC (permalink / raw)
To: Jörn Engel; +Cc: git
In-Reply-To: <20060418182650.GB25688@wohnheim.fh-wedel.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 923 bytes --]
On Tue, 18 Apr 2006, Jörn Engel wrote:
>
> But it appears as if I could "cp -lr" the git tree and work with that.
That should work. I just personally fear cowlinks, because some things
will edit the files in place, and then you're screwed.
I _think_ it should be ok for the .git subdirectory, but quite frankly,
I'm not going to guarantee it. Also, you will break the cow-linking when
you ever re-pack either the source or the destination, so you'd actually
be _better_ off with something that does
# clone the git directories by hand, no checkout (-n).
git clone -l -s -n src dst
# cow-link the checked-out state
(cd src ; git ls-files | cpio -pudml dst)
# make sure to refresh the index
git update-index --refresh
or something like that.
TOTALLY UNTESTED!! (And you need to have made "dst" be an absolute path,
of course, since we want it to work even after we've done the "cd src"
thing).
Linus
^ permalink raw reply
* Re: GIT_OBJECT_DIRECTORY
From: Jörn Engel @ 2006-04-18 18:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604181139150.3701@g5.osdl.org>
On Tue, 18 April 2006 11:47:53 -0700, Linus Torvalds wrote:
> On Tue, 18 Apr 2006, Jörn Engel wrote:
> >
> > But it appears as if I could "cp -lr" the git tree and work with that.
>
> That should work. I just personally fear cowlinks, because some things
> will edit the files in place, and then you're screwed.
s/cowlinks/hardlinks/ ?
The reason for me to write the cowlink patches was exactly the fear
you are talking about. With those patches, links are broken whenever
such a thing happens.
> I _think_ it should be ok for the .git subdirectory, but quite frankly,
> I'm not going to guarantee it. Also, you will break the cow-linking when
> you ever re-pack either the source or the destination, so you'd actually
In that case, cowlinks should still turn a blatant bug into some
wasted space - which is a hell of a lot better.
> # cow-link the checked-out state
And this happens to be a problem. Creating the links when the copy is
created is simple. Detecting identical files and linking them after
the fact is racy, complicated, racy and, well, racy. I wouldn't want
to touch it with a ten foot pole. Not without kernel support.
Jörn
--
Linux is more the core point of a concept that surrounds "open source"
which, in turn, is based on a false concept. This concept is that
people actually want to look at source code.
-- Rob Enderle
^ permalink raw reply
* Re: Confused about tracking git master
From: Nicolas Vilz @ 2006-04-18 18:59 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m2wtdmg3in.fsf@ziti.fhcrc.org>
On Tue, Apr 18, 2006 at 11:08:48AM -0700, Seth Falcon wrote:
> To get updates, I _think_ all I have to do is 'git pull'. Doing so I
> get:
>
> Unpacking 157 objects
> 100% (157/157) done
> * refs/heads/todo: same as branch 'todo' of git://git.kernel.org/pub/scm/git/git
> * refs/heads/maint: same as branch 'maint' of git://git.kernel.org/pub/scm/git/git
> * refs/heads/origin: same as branch 'master' of git://git.kernel.org/pub/scm/git/git
> * refs/heads/pu: does not fast forward to branch 'pu' of git://git.kernel.org/pub/scm/git/git;
> not updating.
>
[..]
>
> Is there a step I'm missing? Or am I just misunderstanding what to
> expect? Clarification on either of those would be appreciated.
You are trapped with the pu branch imho, like many others before *G* ...
simply do a
Pull: +refs/heads/pu:refs/heads/pu
in your .git/remotes/origin file or remove that pu line...
Greetings
Nicolas
^ permalink raw reply
* Re: [PATCH 1/7] cleanups: Fix resource leak and buffer overrun in daemon.c
From: Junio C Hamano @ 2006-04-18 19:32 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: git
In-Reply-To: <20060418131106.GD7562@sergelap.austin.ibm.com>
"Serge E. Hallyn" <serue@us.ibm.com> writes:
> Argh, I had to pull out a sheet of paper, but you are right. I
> misread, and the warning must be about the case where the
> snprint "[%ld] " prints out 1023 characters.
If snprintf(buf, sizeof(buf), "[%ld] ", (long) getpid()) is
judged to possibly overrun the buffer by your static analysis
tool, I think the tool is broken. It at least should know how
big a printed long can be. It would earn bonus points if it can
warn me when sizeof(buf) is sufficiently small, say 40 bytes,
with a message like "on future architectures with 128-bit long
this code might break" ;-).
^ permalink raw reply
* Re: Confused about tracking git master
From: Seth Falcon @ 2006-04-18 19:47 UTC (permalink / raw)
To: git
In-Reply-To: <20060418185937.GD13672@vsectoor.geht-ab-wie-schnitzel.de>
Nicolas Vilz <niv@iaglans.de> writes:
> You are trapped with the pu branch imho, like many others before *G* ...
> simply do a
>
> Pull: +refs/heads/pu:refs/heads/pu
>
> in your .git/remotes/origin file or remove that pu line...
Thank you! That seems to get me going again. But, isn't this going
to trip up other newbies? I just tried a fresh git clone and the pu
branch comes in...
It would improve one's first impressions to not have to edit
.git/remotes/origin (although it is instructional) just to stay up to
date with git.
Cheers,
+ seth
^ permalink raw reply
* Next problem: empty ident <joern@limerick.(none)> not allowed
From: Jörn Engel @ 2006-04-18 20:25 UTC (permalink / raw)
To: git
After successfully using a central object store with git://... instead
of rsync://... (thanks to Sam and Linus), I've run into the next
problem:
$ env | grep GIT
GIT_AUTHOR_NAME=Joern Engel
GIT_OBJECT_DIRECTORY=/home/joern/.git
GIT_AUTHOR_EMAIL=joern@wh.fh-wedel.de
$ git pull git://git.infradead.org/mtd-2.6.git
Unpacking 74 objects
100% (74/74) done
Trying really trivial in-index merge...
Wonderful.
fatal: empty ident <joern@limerick.(none)> not allowed
Adding this to .git/config solved the problem:
[user]
name = "Joern Engel"
email = "joern@foo.bar"
And now I have some questions:
1. Why didn't the environment variables work?
2. Why is there a check for commit information when I pull from some
tree?
Jörn
--
I've never met a human being who would want to read 17,000 pages of
documentation, and if there was, I'd kill him to get him out of the
gene pool.
-- Joseph Costello
^ permalink raw reply
* Re: Next problem: empty ident <joern@limerick.(none)> not allowed
From: Junio C Hamano @ 2006-04-18 20:37 UTC (permalink / raw)
To: Jörn Engel; +Cc: git
In-Reply-To: <20060418202525.GD25688@wohnheim.fh-wedel.de>
Jörn Engel <joern@wohnheim.fh-wedel.de> writes:
> And now I have some questions:
> 1. Why didn't the environment variables work?
> 2. Why is there a check for commit information when I pull from some
> tree?
Because "pull" means "fetch and merge the local modifications if
any". When you merge (and you _did_ merge), you create a new
commit of your own, and the commit records who committed it.
You need GIT_COMMITTER_EMAIL.
Now, the normal "git log" does not verbosely show committer and
author,
^ permalink raw reply
* Re: Next problem: empty ident <joern@limerick.(none)> not allowed
From: Junio C Hamano @ 2006-04-18 20:37 UTC (permalink / raw)
To: Jörn Engel; +Cc: git
In-Reply-To: <20060418202525.GD25688@wohnheim.fh-wedel.de>
Jörn Engel <joern@wohnheim.fh-wedel.de> writes:
> And now I have some questions:
> 1. Why didn't the environment variables work?
> 2. Why is there a check for commit information when I pull from some
> tree?
Because "pull" means "fetch and merge the local modifications if
any". When you merge (and you _did_ merge), you create a new
commit of your own, and the commit records who committed it.
You need GIT_COMMITTER_EMAIL.
^ permalink raw reply
* Re: Next problem: empty ident <joern@limerick.(none)> not allowed
From: Jörn Engel @ 2006-04-18 20:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu08qei2o.fsf@assigned-by-dhcp.cox.net>
On Tue, 18 April 2006 13:37:19 -0700, Junio C Hamano wrote:
> Jörn Engel <joern@wohnheim.fh-wedel.de> writes:
>
> > And now I have some questions:
> > 1. Why didn't the environment variables work?
> > 2. Why is there a check for commit information when I pull from some
> > tree?
>
> Because "pull" means "fetch and merge the local modifications if
> any". When you merge (and you _did_ merge), you create a new
> commit of your own, and the commit records who committed it.
>
> You need GIT_COMMITTER_EMAIL.
Ok. I was stupid in two accounts. Thanks!
Jörn
--
Time? What's that? Time is only worth what you do with it.
-- Theo de Raadt
^ 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