* Re: [PATCH] git-repack question
From: Linus Torvalds @ 2006-02-17 22:20 UTC (permalink / raw)
To: linux; +Cc: git, junkio
In-Reply-To: <20060217213824.5848.qmail@science.horizon.com>
On Fri, 17 Feb 2006, linux@horizon.com wrote:
>
> I'm trying to imagine when you'd want to run git-repack without the -d
> option, or without running git-prune-packed afterwards.
> (Isn't the idea behind packs to save space?)
Normally you'd always run git-prune-packed.
The reason it doesn't do that is simply being anally careful, and because
conceptually the pruning phase is totally independent.
For example, in an environment that mirrors out git repositories by rsync,
it can make sense to wait with pruning until the mirror cycle has
finished, so that all mirrors always have all the objects.
(I don't do it for the kernel, because (a) I'm a lazy bastard, (b) I'm so
confused that I sometimes forget my own name, much less to prune things a
day after I've repacked them and (c) I don't care that much about rsync
anyway, since you can't avoid some of the _other_ races).
As to whether you'd normally run "-d" - usually you'd run it whenever you
pair it up with "-a". When you do an incremental re-pack, "-d" won't do
anything anyway.
Again, it might make sense to not delete the old packs when repacking
everything in a rsync'ing environment - or even in a shared repository,
where removing a pack-file could race with somebody else working on it.
Basically, the default ends up being to never remove any objects at all,
simply because that's the _safe_ thing to do.
In practice, I personally always do
git repack -a -d
git prune-packed
together, because the full repack isn't _that_ expensive for me (I tend to
have lots of cpu power), and because I can't be bothered to worry too much
about rsync and there are never any other users working on my git trees.
Linus
^ permalink raw reply
* Re: [PATCH 1/5] Fixes for ancient versions of GNU make
From: Johannes Schindelin @ 2006-02-17 23:29 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <11491.1140196527@lotus.CS.Berkeley.EDU>
Hi,
On Fri, 17 Feb 2006, Jason Riedy wrote:
> And Johannes Schindelin writes:
> -
> - Some version of GNU make do not understand $(call), and have
> - problems to interpret rules like this:
>
> Is building a newer version of GNU make impossible on Irix?
No. But it is annoying to be forced to upgrade every second package. If
there'd be some real benefit, then okay, I'd do it. But there is really no
point in not supporting the old version.
Besides, in some environments you are just not allowed to go wild
installing programs. And in some environments, you just don't have the
quota.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 0/5] Support ancient systems
From: Johannes Schindelin @ 2006-02-18 0:14 UTC (permalink / raw)
To: Tim O'Callaghan; +Cc: git
In-Reply-To: <20060217170345.GB3468@ELSAMSW37164>
Hi,
On Fri, 17 Feb 2006, Tim O'Callaghan wrote:
> On Fri, Feb 17, 2006 at 04:18:35PM +0100, Adrien Beau wrote:
> > On 2/17/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > I just got git to work on an Irix box. These are the changes I needed
> > > to apply. Maybe some of them are of use for other ancient systems... You
> > > know, I like ancient systems. And if I could get my hands on a VMS, I
> > > would try to get git to work on it, too ;-)
> >
> > You can get free VMS accounts at the Deathrow Cluster:
> > http://deathrow.vistech.net/
> >
> > If you're serious about using your account, you'll find that the admin
> > team is pretty supportive and friendly.
>
> You should check out polarhome.com if you want a variety of platforms
> to muck about on, including IRIX, Plan 9, OpenVMS Vax, OpenVMS Alpha
> etc.
>
> I work on VMS systems at the moment and i thought of attempting to
> port git for the hell of it. I decided not to bother for a variety of
> reasons, but mostly because it looked like too much work :)
Well, I did not remember that VMS does not have a proper fork() call. So
maybe it would be easier to port git to MinGW32 first...
BTW, my remark about VMS was more tongue-in-cheek than not...
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Prevent git-upload-pack segfault if object cannot be found
From: Carl Worth @ 2006-02-18 0:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]
Signed-off-by: Carl Worth <cworth@cworth.org>
---
It's probably a just-don't-do-that situation, but I did-it by moving a
directory that had already been cached in objects/info/alternates by
clone -l -s. Here's a fix for the segfault that that turned up.
Probably trivial enough to not bother the list with, but I'm still
learning about formatting patches and mails and things, so I'm open to
any feedback if I'm getting anything wrong.
sha1_file.c | 4 +++-
upload-pack.c | 3 +++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/sha1_file.c b/sha1_file.c
index 64cf245..1d799f7 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -551,8 +551,10 @@ static void prepare_packed_git_one(char
sprintf(path, "%s/pack", objdir);
len = strlen(path);
dir = opendir(path);
- if (!dir)
+ if (!dir) {
+ fprintf(stderr, "unable to open object pack directory: %s: %s\n", path, strerror(errno));
return;
+ }
path[len++] = '/';
while ((de = readdir(dir)) != NULL) {
int namelen = strlen(de->d_name);
diff --git a/upload-pack.c b/upload-pack.c
index d198055..3606529 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -216,6 +216,9 @@ static int send_ref(const char *refname,
static char *capabilities = "multi_ack";
struct object *o = parse_object(sha1);
+ if (!o)
+ die("git-upload-pack: cannot find object %s:", sha1_to_hex(sha1));
+
if (capabilities)
packet_write(1, "%s %s%c%s\n", sha1_to_hex(sha1), refname,
0, capabilities);
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: diffstat wierdness with 'git format-patch' output
From: Greg KH @ 2006-02-18 0:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd72v2jp.fsf@assigned-by-dhcp.cox.net>
On Mon, Feb 13, 2006 at 11:10:18PM -0800, Junio C Hamano wrote:
> Greg KH <greg@kroah.com> writes:
>
> > Hm, git-send-email doesn't see this, so it doesn't get sent out if you
> > use that tool.
>
> And people are very likely to remove it by hand.
>
> Another possibility would be to use "git apply --numstat" and
> add numbers up in your script, but that would not give you a
> nice graph output either X-<.
>
> I'd say if you really care we should just remove those two
> lines, and remember I am _very_ receptive from such suggestion
> from prominent kernel people.
Hm, in thinking about this some more, I realized that it only requires
me to change my script to generate the emails for Linus to pull from a
tiny bit, making this whole thing not a bit deal at all.
Thanks a lot for being so receptive, if I have further problems with it,
I'll let you know.
greg k-h
^ permalink raw reply
* [PATCH] git-rev-parse: Fix --short= option parsing
From: Jonas Fonseca @ 2006-02-18 1:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
commit 16e2efc524d181cf46dcb252532139a0aff4a28f
tree c57ea8bf09b25fb643aadd224e7e73673187cc60
parent b867c7c23a42fbe9f261153a9814a5efbc071a29
author Jonas Fonseca <fonseca@diku.dk> Sat, 18 Feb 2006 02:04:26 +0100
committer Jonas Fonseca <fonseca@antimatter.localdomain> Sat, 18 Feb 2006 02:04:26 +0100
rev-parse.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/rev-parse.c b/rev-parse.c
index b82f294..70a8271 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -225,12 +225,12 @@ int main(int argc, char **argv)
continue;
}
if (!strcmp(arg, "--short") ||
- !strncmp(arg, "--short=", 9)) {
+ !strncmp(arg, "--short=", 8)) {
filter &= ~(DO_FLAGS|DO_NOREV);
verify = 1;
abbrev = DEFAULT_ABBREV;
- if (arg[8] == '=')
- abbrev = strtoul(arg + 9, NULL, 10);
+ if (arg[7] == '=')
+ abbrev = strtoul(arg + 8, NULL, 10);
if (abbrev < MINIMUM_ABBREV)
abbrev = MINIMUM_ABBREV;
else if (40 <= abbrev)
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] Document --short and --git-dir in git-rev-parse(1)
From: Jonas Fonseca @ 2006-02-18 1:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
commit 013b99654ee464856d266a72f0203d0fee2b0d11
tree 3c961d6ebb8b9805ee3950ec081679de15f5a9ba
parent 16e2efc524d181cf46dcb252532139a0aff4a28f
author Jonas Fonseca <fonseca@diku.dk> Sat, 18 Feb 2006 02:05:11 +0100
committer Jonas Fonseca <fonseca@antimatter.localdomain> Sat, 18 Feb 2006 02:05:11 +0100
Documentation/git-rev-parse.txt | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index d638bfc..1662e06 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -77,6 +77,14 @@ OPTIONS
path of the top-level directory relative to the current
directory (typically a sequence of "../", or an empty string).
+--git-dir::
+ Show `$GIT_DIR` if defined else show the path to the .git directory.
+
+--short, short=number::
+ Instead of outputting the full SHA1 values of object names try to
+ abbriviate them to a shorter unique name. When no length is specified
+ 7 is used. The minimum length is 4.
+
--since=datestring, --after=datestring::
Parses the date string, and outputs corresponding
--max-age= parameter for git-rev-list command.
--
Jonas Fonseca
^ permalink raw reply related
* Re: stGIT: commit vs export vs mail
From: Jesse Brandeburg @ 2006-02-18 2:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Jesse Brandeburg, git
In-Reply-To: <43F64A51.10607@gmail.com>
On Fri, 17 Feb 2006, Catalin Marinas wrote:
> Jesse Brandeburg wrote:
>> So I am using stgit .8 right now, and I'm having a hard time figuring
>> out what the correct workflow should be for using stg and then
>> committing a change
>>
>> Here is what I've been doing:
>> stg new test
>> enter my short description on first line
>> enter my long description on next lines.
>> vi file
>> stg refresh
>> stg mail <blah blah blah>
>> or
>> stg commit
>
> There is no "or" above but only "and maybe". The 'commit' command is
> only used to permanently store a set of patches into the repository.
> After that, you should not be able to change them anymore (well, someone
> just sent me a patch for an uncommit command). I only use this command
> when I work in the "maintainer" mode on StGIT. For contributing patches,
> you shouldn't need it since the base of the stack should usually be
> identical to the HEAD of the remote repository.
I'm trying to commit changes to a local repository so that the maintainer
can do a "pull" off of my repository.
>> Problem that I'm having right now is that the templates do the right
>> thing for mail, but, the commit only puts in the "enter my..." text.
>
> I don't fully understand this. Where does commit put the "enter my..." text?
so I used stgit to commit this change. It puts it in the git log of
checkins for the repository.
[jbrandeb@lindenhurst-2 e1000]$ git log | head -n 20
commit fb16b7111dae51b9a928aa7706d1cc022df8741d
Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date: Fri Feb 17 11:29:19 2006 -0800
e1000: update readme
Update the e1000 text to the latest version
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
>> Is there a template based way to automatically append the author in the
>> Signed-off-by: line when i do stg commit?
>
> This can only be done when creating a patch. Commit doesn't modify the
> patches. I think you slightly misunderstood the commit command.
the stgit command stg commit freezes patches that I've made into my
repository. I think I get that, but I've been wrong before. Its just
that I can template the Signed-off-by: line for emails, but when I do a
stg commit I want the thing to have the Signed-off-by: line in the commit
text (like above where I added it by hand)
I guess I'll just change my templates to not auto add the Signed-off-by
line and then things will work okay, as I'll just add the line during stg
new ...
Thanks for your reply, and the cool tool!
Jesse
^ permalink raw reply
* Junio, you are a genius.
From: Johannes Schindelin @ 2006-02-18 2:12 UTC (permalink / raw)
To: git
Hi,
Earlier, I avoided to repack too often, since "repack -a -d" was too
expensive, and small incremental packs were inefficient.
Now, with the reusing delta patch, "repack -a -d" is marginally less
efficient than incremental packs. No longer worry about when to repack:
Just do it! No need for incremental packs!
Hero!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/5] Support ancient systems
From: Andreas Ericsson @ 2006-02-18 2:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tim O'Callaghan, git
In-Reply-To: <Pine.LNX.4.63.0602180109480.525@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Fri, 17 Feb 2006, Tim O'Callaghan wrote:
>
>
>>On Fri, Feb 17, 2006 at 04:18:35PM +0100, Adrien Beau wrote:
>>
>>>On 2/17/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>
>>>>I just got git to work on an Irix box. These are the changes I needed
>>>>to apply. Maybe some of them are of use for other ancient systems... You
>>>>know, I like ancient systems. And if I could get my hands on a VMS, I
>>>>would try to get git to work on it, too ;-)
>>>
>>>You can get free VMS accounts at the Deathrow Cluster:
>>>http://deathrow.vistech.net/
>>>
>>>If you're serious about using your account, you'll find that the admin
>>>team is pretty supportive and friendly.
>>
>>You should check out polarhome.com if you want a variety of platforms
>>to muck about on, including IRIX, Plan 9, OpenVMS Vax, OpenVMS Alpha
>>etc.
>>
>>I work on VMS systems at the moment and i thought of attempting to
>>port git for the hell of it. I decided not to bother for a variety of
>>reasons, but mostly because it looked like too much work :)
>
>
> Well, I did not remember that VMS does not have a proper fork() call.
It doesn't. It's got vfork() though.
> BTW, my remark about VMS was more tongue-in-cheek than not...
>
Thanks anyway. I would never have gotten that link to polarhome if you'd
kept your tongue straight.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.2.1
From: Michael Fischer @ 2006-02-18 4:31 UTC (permalink / raw)
To: git
In-Reply-To: <7vzmkrizuw.fsf@assigned-by-dhcp.cox.net>
*sigh*
I got confused about git pull origin and git pull master.
Tutorial seems to tell me I should have said git pull origin
and left well enough alone.
Now I get:
fatal: you need to resolve your current index first
How do I do that?
TIA.
Michael
--
Michael Fischer Happiness is a config option.
michael@visv.net Recompile and be happy.
^ permalink raw reply
* [PATCH] git-svn: remove files from the index before adding/updating
From: Eric Wong @ 2006-02-18 5:04 UTC (permalink / raw)
To: git; +Cc: Eric Wong
This fixes a bug when importing where a directory gets removed/renamed
but is immediately replaced by a file of the same name in the same
revision.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
c142c70866ab8ce1765e4b88506aa79b5c5c1427
diff --git a/contrib/git-svn/git-svn b/contrib/git-svn/git-svn
index 2caf057..71a8b3b 100755
--- a/contrib/git-svn/git-svn
+++ b/contrib/git-svn/git-svn
@@ -580,13 +580,12 @@ sub svn_info {
sub sys { system(@_) == 0 or croak $? }
sub git_addremove {
- system( "git-ls-files -z --others ".
+ system( "git-diff-files --name-only -z ".
+ " | git-update-index --remove -z --stdin; ".
+ "git-ls-files -z --others ".
"'--exclude-from=$GIT_DIR/$GIT_SVN/info/exclude'".
- "| git-update-index --add -z --stdin; ".
- "git-ls-files -z --deleted ".
- "| git-update-index --remove -z --stdin; ".
- "git-ls-files -z --modified".
- "| git-update-index -z --stdin") == 0 or croak $?
+ " | git-update-index --add -z --stdin; "
+ ) == 0 or croak $?
}
sub s_to_file {
--
1.2.0.g4d1a-dirty
^ permalink raw reply related
* Re: What's in git.git
From: Junio C Hamano @ 2006-02-18 6:49 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060217142836.13137.qmail@science.horizon.com>
linux@horizon.com writes:
> Er... what does this do, again? I couldn't find the list
> discussion, and I can get this exact effect in vanilla 1.2.1
> with "git rebase master~1 topic".
>...
> OTOH, I can imagine wanting
>...
> A B---C topic
> / /
> D---E---F---G master
Yup. The example was a bad one, but the above, and in general
X---A'--B'--C' topic
D---E---F---G master
on an arbitrary X was what I wanted to do.
^ permalink raw reply
* Re: contrib/ area
From: Junio C Hamano @ 2006-02-18 6:49 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <873biikx6k.fsf@wine.dyndns.org>
Alexandre Julliard <julliard@winehq.org> writes:
> Is there interest in an emacs interface for git? I posted a first
> version (http://marc.theaimsgroup.com/?l=git&m=113313040724346&w=2)
> some time ago, I'd be happy to send you a patch with my latest version
> if you want to include it.
Martin already said he wants it, and I would second that. VC
backend is one of the things I kept in the TODO list for quite a
while (I think since early September 2005)...
^ permalink raw reply
* Re: contrib/ area
From: Junio C Hamano @ 2006-02-18 6:50 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: git
In-Reply-To: <cc723f590602170436l5b33ae6s1780c3c8d6383627@mail.gmail.com>
Aneesh Kumar <aneesh.kumar@gmail.com> writes:
> Attaching below the same in the form of patch generated by git format-patch
I'll let it pass this time, but you forgot a sign-off and
perhaps forgot to read Documentation/SubmittingPatches ;-).
^ permalink raw reply
* Re: [PATCH] git-repack question
From: Junio C Hamano @ 2006-02-18 6:50 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060217213824.5848.qmail@science.horizon.com>
linux@horizon.com writes:
> (Legalese: Patch placed in the public domain; copyright abandoned.)
The rest of the patch looks good, but I'd rather prefer a patch
with a proper sign-off, strongly prefereable with a real name so
that we can attach blame on later when another SCO happens ;-).
^ permalink raw reply
* Re: [PATCH] Prevent git-upload-pack segfault if object cannot be found
From: Junio C Hamano @ 2006-02-18 6:50 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87hd6x34lf.wl%cworth@cworth.org>
Thanks, this is the last remaining call that did not check its
return value from opendir().
I queued this one and three clone things from you. They will
appear in "next" first, but also be in 1.2.2.
^ permalink raw reply
* Re: [PATCH] git-rev-parse: Fix --short= option parsing
From: Junio C Hamano @ 2006-02-18 6:50 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20060218011053.GB2562@diku.dk>
Thanks. I queued the two fixes from you.
They will first appear in "next" and also in 1.2.2.
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
>
> ---
> commit 013b99654ee464856d266a72f0203d0fee2b0d11
> tree 3c961d6ebb8b9805ee3950ec081679de15f5a9ba
> parent 16e2efc524d181cf46dcb252532139a0aff4a28f
> author Jonas Fonseca <fonseca@diku.dk> Sat, 18 Feb 2006 02:05:11 +0100
> committer Jonas Fonseca <fonseca@antimatter.localdomain> Sat, 18 Feb 2006 02:05:11 +0100
BTW, what git-based tool do you use to spit out this ugly format?
Full object name of the parent commit is useful only if the
recipient has that object, and it is not one of mine, so it is
unlikely nobody but you would have it. Name of the tree is what
you would get _after_ applying this patch, so it also is not
very useful for e-mail communication.
^ permalink raw reply
* Re: [PATCH 1/5] Fixes for ancient versions of GNU make
From: Junio C Hamano @ 2006-02-18 6:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0602171522020.24274@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> diff --git a/Makefile b/Makefile
> index d7d79de..b3401ac 100644
> --- a/Makefile
> +++ b/Makefile
> ...
> +# These will be used inside ''
> +SHELL_PATH_QUOTED = $(subst ','\'',$(SHELL_PATH))
> ...
> diff --git a/t/Makefile b/t/Makefile
> index 5c5a620..d78404f 100644
> --- a/t/Makefile
> +++ b/t/Makefile
> @@ -8,17 +8,14 @@ SHELL_PATH ?= $(SHELL)
> TAR ?= $(TAR)
>
> # Shell quote;
> -# Result of this needs to be placed inside ''
> -shq = $(subst ','\'',$(1))
> -# This has surrounding ''
> -shellquote = '$(call shq,$(1))'
> +SHELL_PATH_QUOTED = '$(subst ','\'',$(SHELL_PATH))'
I am not opposed to avoiding $(call), but subst everywhere look
ugly ;-).
You inherited this problem, but these two symbols in different
Makefiles with the same name mean two completely different
things, which confused me quite badly.
So if we were to do this portability fix, how about consistently
defining it without surrounding sq pair? Most of the places in
the main Makefile you use the symbol with other string, with the
whole thing quoted inside a sq pair, so that would make things
easier to read.
Then the one that uses it in the t/Makefile in 5/5 becomes:
$(T):
@echo "*** $@ ***"; '$(SHELL_PATH_QUOTED)' $@ $(GIT_TEST_OPTS)
^ permalink raw reply
* Re: [PATCH 5/5] Optionally work without python
From: Junio C Hamano @ 2006-02-18 6:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0602171523510.24274@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> In some setups (notably server setups) you do not need that dependency.
> Gracefully handle the absence of python when NO_PYTHON is defined.
> +ifdef NO_PYTHON
> + TEST_DEFS += NO_PYTHON=YesPlease
> +endif
I wonder if there is a better way to do this. All future
NO_BLAH that may affect tests need to have something like this
otherwise.
> -default_strategies='recursive'
> +if test -z "@@NO_PYTHON@@"; then
> + default_strategies='recursive'
> +else
> + default_strategies='resolve'
> +fi
Somebody commented on this part to make it shorter...
I'll take 2, 3, and 4 from this series for now. They will
appear in "next". Thanks.
^ permalink raw reply
* [PATCH] pack-objects: avoid delta chains that are too long.
From: Junio C Hamano @ 2006-02-18 6:50 UTC (permalink / raw)
To: git
In-Reply-To: <7vlkwa6zk6.fsf@assigned-by-dhcp.cox.net>
This tries to rework the solution for the excess delta chain
problem. An earlier commit worked it around ``cheaply'', but
repeated repacking risks unbound growth of delta chains.
This version counts the length of delta chain we are reusing
from the existing pack, and makes sure a base object that has
sufficiently long delta chain does not get deltified.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This solves the problem by doing exactly what the previous
commit log suggested. We limit the chain depth correctly, to
save the user of the resulting pack from suffering runtime
overhead.
Will be in "next" tonight.
pack-objects.c | 43 +++++++++++++++++++++++++++++++++++--------
1 files changed, 35 insertions(+), 8 deletions(-)
e4c9327a77bd59e85d4b17a612e78977d68773ee
diff --git a/pack-objects.c b/pack-objects.c
index 38e1c99..0c9f4c9 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -10,16 +10,22 @@ static const char pack_usage[] = "git-pa
struct object_entry {
unsigned char sha1[20];
unsigned long size; /* uncompressed size */
- unsigned long offset; /* offset into the final pack file (nonzero if already written) */
+ unsigned long offset; /* offset into the final pack file;
+ * nonzero if already written.
+ */
unsigned int depth; /* delta depth */
+ unsigned int delta_limit; /* base adjustment for in-pack delta */
unsigned int hash; /* name hint hash */
enum object_type type;
- unsigned char edge; /* reused delta chain points at this entry. */
enum object_type in_pack_type; /* could be delta */
unsigned long delta_size; /* delta data size (uncompressed) */
struct object_entry *delta; /* delta base object */
struct packed_git *in_pack; /* already in pack */
unsigned int in_pack_offset;
+ struct object_entry *delta_child; /* delitified objects who bases me */
+ struct object_entry *delta_sibling; /* other deltified objects who
+ * uses the same base as me
+ */
};
/*
@@ -470,7 +476,8 @@ static void check_object(struct object_e
entry->delta = base_entry;
entry->type = OBJ_DELTA;
- base_entry->edge = 1;
+ entry->delta_sibling = base_entry->delta_child;
+ base_entry->delta_child = entry;
return;
}
@@ -513,15 +520,32 @@ static void hash_objects(void)
}
}
+static unsigned int check_delta_limit(struct object_entry *me, unsigned int n)
+{
+ struct object_entry *child = me->delta_child;
+ unsigned int m = n;
+ while (child) {
+ unsigned int c = check_delta_limit(child, n + 1);
+ if (m < c)
+ m = c;
+ child = child->delta_sibling;
+ }
+ return m;
+}
+
static void get_object_details(void)
{
int i;
- struct object_entry *entry = objects;
+ struct object_entry *entry;
hash_objects();
prepare_pack_ix();
- for (i = 0; i < nr_objects; i++)
- check_object(entry++);
+ for (i = 0, entry = objects; i < nr_objects; i++, entry++)
+ check_object(entry);
+ for (i = 0, entry = objects; i < nr_objects; i++, entry++)
+ if (!entry->delta && entry->delta_child)
+ entry->delta_limit =
+ check_delta_limit(entry, 1);
}
typedef int (*entry_sort_t)(const struct object_entry *, const struct object_entry *);
@@ -598,8 +622,11 @@ static int try_delta(struct unpacked *cu
* that depend on the current object into account -- otherwise
* they would become too deep.
*/
- if (cur_entry->edge)
- max_depth /= 4;
+ if (cur_entry->delta_child) {
+ if (max_depth <= cur_entry->delta_limit)
+ return 0;
+ max_depth -= cur_entry->delta_limit;
+ }
size = cur_entry->size;
if (size < 50)
--
1.2.1.g9b132
^ permalink raw reply related
* empty ident error on pull
From: carbonated beverage @ 2006-02-18 7:05 UTC (permalink / raw)
To: git
I'm tracking the Linux kernel repo via git, and got the following:
barbeque/zarathustra:linux-2.6: git pull
Unpacking 885 objects
100% (885/885) done
* refs/heads/origin: fast forward to branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Auto-following refs/tags/v2.6.16-rc4
Unpacking 1 objects
100% (1/1) done
* refs/tags/v2.6.16-rc4: storing tag 'v2.6.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Trying really trivial in-index merge...
Wonderful.
fatal: empty ident <barbeque@zarathustra.internal.psychosnugglebunnies.net.> not allowed
Then I tried the following:
barbeque/zarathustra:linux-2.6: git-fsck-objects
dangling tree 47678b69f7dcc6d5fcae007d1e4fe511fd260e5b
barbeque/zarathustra:linux-2.6: git prune
barbeque/zarathustra:linux-2.6: git-fsck-objects
barbeque/zarathustra:linux-2.6: git pull
* refs/heads/origin: same as branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Trying really trivial in-index merge...
Wonderful.
fatal: empty ident <barbeque@zarathustra.internal.psychosnugglebunnies.net.> not allowed
Okay... so... what now? I'm still a bit clueless when it comes to git. Using
it for some of my personal projects has gotten me a bit more comfortable with
it, but my usage is still along the lines of "CVS without warts", for now.
(And yes, it's the concept of the index file that's still throwing me for
a loop :-)
I was tracking the repo with "current" versions of git until I got the above
error message the first time. Went to a 1.1.6 tarball of git, pulled the
repro from scratch, all seemed well. Upgraded to 1.2.1, tried a pull today,
and got the above.
The system above is a Debian/sarge amd64 system, using gcc 3.3.5.
-- DN
Daniel
^ permalink raw reply
* Re: git-cvs-import retries
From: Junio C Hamano @ 2006-02-18 7:27 UTC (permalink / raw)
To: Martin Mares; +Cc: git
In-Reply-To: <mj+md-20060217.193146.10308.albireo@ucw.cz>
Martin Mares <mj@ucw.cz> writes:
> Hello!
>...
> This patch extends the retry check and makes the symptoms go away.
> However, take it with a grain of salt as I don't understand yet why the
> connection is aborted.
>
> Have a nice fortnight
> --
> Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
> Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
> A jury consists of 12 persons chosen to decide who has the better lawyer.
>
>
> Signed-Off-By: Martin Mares <mj@ucw.cz>
>
> --- old/git-cvsimport 2006-02-17 13:02:24.000000000 +0100
First, one technicality. You can see what's wrong with the
above, right? Remember, the top part of your message goes into
the commit log, so we do not want "Hello!" nor signature.
> +++ new/git-cvsimport 2006-02-17 18:13:06.000000000 +0100
> @@ -371,7 +371,7 @@
>
> $self->_file($fn,$rev) and $res = $self->_line($fh);
>
> - if (!defined $res) {
> + if (!defined $res || $res eq '') {
> # retry
> $self->conn();
> $self->_file($fn,$rev)
I read _line() three times but its return value is the lexical
variable $res which is initialized to 0 and then either reset to
0 by assignment or updated with $res += somethingelse. So I do
not see how you can get a defined but empty string in there.
Even when _file() returns false, the $res variable in file()
(the function you are modifying) is not initialized, so it would
stay undefined.
Maybe I am missing something very obvious, but I cannot see how
this can make any difference. Please enlighten.
^ permalink raw reply
* Re: Why can't git-rebase back up?
From: Junio C Hamano @ 2006-02-18 7:39 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: linux, git
In-Reply-To: <43F5FA10.5020605@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> The order of precedence works as such:
> .git/<anchor-name>
> .git/refs/<anchor-name>
> .git/refs/tags/<tag-name>
> .git/refs/heads/<branch-name>
> sha1, with git magic to allow abbreviations
>
> This is why you can't sanely have a branch named HEAD.
Actually, you should be able to sanely have a branch named HEAD.
When git barebone Porcelain tools _expect_ branch name from the
user (not just a random committish), they _ought_ to prefix
"refs/heads" in front of it, exactly in order to help
disambiguate things.
Otherwise you have spotted a bug, so please send in a fix.
It is however a different story if you can keep your sanity if
you created a branch called HEAD. You have to remember to
explicitly say refs/heads/HEAD, where a command wants any
committish or treeish.
^ permalink raw reply
* Re: Why can't git-rebase back up?
From: Junio C Hamano @ 2006-02-18 7:39 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060217135938.7412.qmail@science.horizon.com>
linux@horizon.com writes:
> But suppose discover a nasty bug in -rc3 and want to move my build branch
> back to -rc2. "git-rebase v2.6.16-rc2" does nothing. After a bit
> of thought, I realize why, but sometime I do want to back up.
>
> What's the best way to do that? Should git-rebase take an optional
> third argument which is the branch head we are moving away from?
> E.g. what I want to do would be
>
> git-rebase v2.6.16-rc2 build v2.6.16-rc3
The one in "next" has a topic branch change which lets you say:
$ git rebase --onto v2.6.16-rc2 v2.6.16-rc3 build
which is a shorthand for
$ git checkout build
$ git rebase --onto v2.6.16-rc2 v2.6.16-rc3
That is, tear out my changes that forked from the development
trail that led to v2.6.16-rc3, and graft them on top of
v2.6.16-rc2.
^ 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