* 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: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: [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
* [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: 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
* 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: 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
* 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: 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
* [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: 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
* 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: 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: 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: 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: [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: 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: GIT_OBJECT_DIRECTORY
From: linux @ 2006-04-18 14:10 UTC (permalink / raw)
To: joern; +Cc: git
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?
^ permalink raw reply
* GIT_OBJECT_DIRECTORY
From: Jörn Engel @ 2006-04-18 13:38 UTC (permalink / raw)
To: git
Hi!
I recently noticed GIT_OBJECT_DIRECTORY in the git manpage and wanted
to play with it. But it looks as if it doesn't work, the
documentation is wrong/insufficient or I can't properly read the
documentation. So let me figure out, which one it is.
$ set | grep GIT_OBJECT_DIRECTORY
GIT_OBJECT_DIRECTORY=/home/joern/.git
$ ls -l /home/joern/.git
total 288
drwxrwxr-x 2 joern joern 4096 Apr 16 01:22 0f
[...]
$ 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 manpage
tells me:
GIT_OBJECT_DIRECTORY
If the object storage directory is specified via this environ-
ment variable then the sha1 directories are created underneath -
otherwise the default $GIT_DIR/objects directory is used.
And I would interpret this as "store all new objects under
/home/joern/.git". So far, things don't seem to imply me being too
stupid. What went wrong?
Jörn
--
Why do musicians compose symphonies and poets write poems?
They do it because life wouldn't have any meaning for them if they didn't.
That's why I draw cartoons. It's my life.
-- Charles Shultz
^ permalink raw reply
* Re: [PATCH 1/7] cleanups: Fix resource leak and buffer overrun in daemon.c
From: Serge E. Hallyn @ 2006-04-18 13:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu08rkhey.fsf@assigned-by-dhcp.cox.net>
Quoting Junio C Hamano (junkio@cox.net):
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
>
> > Address two reports from an automatic code analyzer:
> >
> > 1. In logreport, it is possible to write \0 one
> > character past the end of buf[].
>
> I am perhaps slower than I usually am today, but it seems to me
> that the code caps msglen to (maxlen-1) and then adds that to
> buflen.
>
> Now, maxlen is (sizeof(buf)-buflen-1), so that means after
> the "buflen += msglen" happens, buflen is at most:
>
> buflen + (sizeof(buf)-buflen-1) - 1
> = sizeof(buf) - 2
>
> And then "buf[buflen++] = '\n'; buf[buflen] = '\0'" happens.
> '\n' is written at sizeof(buf)-2 (or lower index than that) and
> '\0' is written at sizeof(buf)-1 (or lower). I am unsure how it
> steps beyond the end...
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.
> > 2. In socksetup, socklist can be leaked when returning
> > if set_reuse_addr(). Note: dunno why this case returns...
>
> I am not sure why this part returns either. It appears to me
> that it should just keep going just like the cases where
> bind/listen fails.
Then perhaps the following is more appropriate.
thanks,
-serge
From: Serge E. Hallyn <serue@us.ibm.com>
Subject: [PATCH] socksetup: don't return on set_reuse_addr() error
The set_reuse_addr() error case was the only error case in
socklist() where we returned rather than continued. Not sure
why. Either we must free the socklist, or continue. This patch
continues on error.
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
---
daemon.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
b589029e3187eed51c3fe6a2715f51bea2159786
diff --git a/daemon.c b/daemon.c
index a1ccda3..776749e 100644
--- a/daemon.c
+++ b/daemon.c
@@ -535,7 +535,7 @@ static int socksetup(int port, int **soc
if (set_reuse_addr(sockfd)) {
close(sockfd);
- return 0; /* not fatal */
+ continue;
}
if (bind(sockfd, ai->ai_addr, ai->ai_addrlen) < 0) {
--
1.2.5
^ permalink raw reply related
* Re: [PATCH] Handle branch names with slashes
From: Karl Hasselström @ 2006-04-18 11:07 UTC (permalink / raw)
To: Yann Dirson; +Cc: Catalin Marinas, git
In-Reply-To: <20060412191655.GD27397@nowhere.earth>
On 2006-04-12 21:16:55 +0200, Yann Dirson wrote:
> Is this still being worked on?
I haven't worked any more on the slashes-in-branch-names patch, but I
have been using it myself, and it works for me. Getting that fancy new
test suite to excercise it would be a really good next step . . .
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [BUG] gitk draws a wrong line
From: Uwe Zeisberger @ 2006-04-18 10:40 UTC (permalink / raw)
To: git
Hallo,
I'm using 1.3.0.rc4.g2855d in Linus Linux tree. When doing
$ gitk v2.6.16..v2.6.17-rc1
and then going to commit 10c2df65060e1ab57b2f75e0749de0ee9b8f4810,
I see a small superfluous line between the two commits under 10c2df.
But still worse, if I select the line going down from 10c2df and then
select it's parent (i.e c76b6b) I get a big line ending in the commit
descriptions and four lines ending in midair.
See screenshots at
http://www.informatik.uni-freiburg.de/~zeisberg/bug-gitk/
Best regards
Uwe
--
Uwe Zeisberger
cat /*dev/null; echo 'Hello World!';
cat > /dev/null <<*/
() { } int main() { printf("Hello World!\n");}
/* */
^ permalink raw reply
* Re: [PATCH] git-svnimport symlink support
From: smurf @ 2006-04-18 9:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Karl Hasselström, Martin Langhoff, Herbert Valerio Riedel,
git
In-Reply-To: <7v3bgcngqc.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 154 bytes --]
Hi,
Junio C Hamano:
> Karl, Martin, Smurf, Comments?
OK with me.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-04-18 8:44 UTC (permalink / raw)
To: git
In-Reply-To: <7vodz4tx4s.fsf@assigned-by-dhcp.cox.net>
* The 'master' branch has these since the last announcement.
- Update xdiff (Davide Libenzi)
- Add diff --stat and --patch-with-stat (Johannes Schindelin)
- Miscellaneous fixes (A Large Angry SCM, Linus, Serge
E. Hallyn, Yann Dirson, me)
- Fix rev-list --boundary (me)
- Update gitk (Paul Mackerras)
* The 'next' branch, in addition, has these.
- Common option parsing for "git log --diff" and friends (Linus)
- Log message printout cleanups (Linus)
- Log/show/whatchanged commands are now built-in (Linus and me)
- Similarity fingerprint (Geert Bosch)
- Define "log --stat" to be "stat with first parent" (Linus and me)
The commits on the lt/logopt branch (part of "next" branch) are
proving to be more stable and safe enough to use. It cleans up
the code quote a lot,
I'm really resisting the temptation to merge these before 1.3.0.
There is a slight output format change from diff-tree --pretty;
while I would not expect no Porcelains is affected in practice,
technically this is a backward incompatible change, so...
Anyway, they will be merged immediately after the big release.
^ permalink raw reply
* Re: Log message printout cleanups
From: Junio C Hamano @ 2006-04-18 5:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604171751540.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> There's actually something _wrong_ with "git log --stat".
>
> What happens is that "git log" will enable "rev.combine_merges" by
> default, and that means that together with "--stat" ignoring merges by
> default, it will _instead_ generate a "--cc" diff for that merge.
>
> I'll leave that up to you, I'm getting pretty fed up with "git log" right
> now ;)
The primary problem is that the code in "next" was before the
"fancy diffstat for combined" work by Johannes; it punts and
always shows the patch output even when stat is asked for.
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.
-- >8 --
combine-diff: show diffstat with the first parent.
Even under combine-diff, asking for stat (either with --stat or
--patch-with-stat) gives you diffstat for the first parent.
While the combined patch is useful to highlight the complexity
and interaction of the parts touched by all branches when
reviewing a merge commit, diffstat is a tool to assess the
extent of damage the merge brings in, and showing stat with the
first parent is more sensible than clever per-parent diffstat.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
combine-diff.c | 24 +++++++++++++++++++-----
1 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index aef9006..27f6f57 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -831,10 +831,11 @@ void show_combined_diff(struct combine_d
case DIFF_FORMAT_NAME:
show_raw_diff(p, num_parent, rev);
return;
-
- default:
case DIFF_FORMAT_PATCH:
show_patch_diff(p, num_parent, dense, rev);
+ return;
+ default:
+ return;
}
}
@@ -847,10 +848,13 @@ void diff_tree_combined_merge(const unsi
struct commit_list *parents;
struct combine_diff_path *p, *paths = NULL;
int num_parent, i, num_paths;
+ int do_diffstat;
+ do_diffstat = (opt->output_format == DIFF_FORMAT_DIFFSTAT ||
+ opt->with_stat);
diffopts = *opt;
- diffopts.output_format = DIFF_FORMAT_NO_OUTPUT;
diffopts.with_raw = 0;
+ diffopts.with_stat = 0;
diffopts.recursive = 1;
/* count parents */
@@ -864,14 +868,24 @@ void diff_tree_combined_merge(const unsi
parents;
parents = parents->next, i++) {
struct commit *parent = parents->item;
+ /* show stat against the first parent even
+ * when doing combined diff.
+ */
+ if (i == 0 && do_diffstat)
+ diffopts.output_format = DIFF_FORMAT_DIFFSTAT;
+ else
+ diffopts.output_format = DIFF_FORMAT_NO_OUTPUT;
diff_tree_sha1(parent->object.sha1, commit->object.sha1, "",
&diffopts);
diffcore_std(&diffopts);
paths = intersect_paths(paths, i, num_parent);
- if (diffopts.with_stat && rev->loginfo)
- show_log(rev, rev->loginfo, "---\n");
+ if (do_diffstat && rev->loginfo)
+ show_log(rev, rev->loginfo,
+ opt->with_stat ? "---\n" : "\n");
diff_flush(&diffopts);
+ if (opt->with_stat)
+ putchar('\n');
}
/* find out surviving paths */
^ 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