* [PATCH 09/22] Add run_command_v_opt_cd: chdir into a directory before exec
From: skimo @ 2007-05-23 22:22 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Martin Waitz, Alex Riesen
In-Reply-To: <11799589913153-git-send-email-skimo@liacs.nl>
From: Alex Riesen <raa.lkml@gmail.com>
It can make code simplier (no need to preserve cwd) and safer
(no chance the cwd of the current process is accidentally forgotten).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
run-command.c | 27 ++++++++++++++++++++++-----
run-command.h | 2 ++
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/run-command.c b/run-command.c
index eff523e..043b570 100644
--- a/run-command.c
+++ b/run-command.c
@@ -73,6 +73,9 @@ int start_command(struct child_process *cmd)
close(cmd->out);
}
+ if (cmd->dir && chdir(cmd->dir))
+ die("exec %s: cd to %s failed (%s)", cmd->argv[0],
+ cmd->dir, strerror(errno));
if (cmd->git_cmd) {
execv_git_cmd(cmd->argv);
} else {
@@ -133,13 +136,27 @@ int run_command(struct child_process *cmd)
return finish_command(cmd);
}
+static void prepare_run_command_v_opt(struct child_process *cmd,
+ const char **argv, int opt)
+{
+ memset(cmd, 0, sizeof(*cmd));
+ cmd->argv = argv;
+ cmd->no_stdin = opt & RUN_COMMAND_NO_STDIN ? 1 : 0;
+ cmd->git_cmd = opt & RUN_GIT_CMD ? 1 : 0;
+ cmd->stdout_to_stderr = opt & RUN_COMMAND_STDOUT_TO_STDERR ? 1 : 0;
+}
+
int run_command_v_opt(const char **argv, int opt)
{
struct child_process cmd;
- memset(&cmd, 0, sizeof(cmd));
- cmd.argv = argv;
- cmd.no_stdin = opt & RUN_COMMAND_NO_STDIN ? 1 : 0;
- cmd.git_cmd = opt & RUN_GIT_CMD ? 1 : 0;
- cmd.stdout_to_stderr = opt & RUN_COMMAND_STDOUT_TO_STDERR ? 1 : 0;
+ prepare_run_command_v_opt(&cmd, argv, opt);
+ return run_command(&cmd);
+}
+
+int run_command_v_opt_cd(const char **argv, int opt, const char *dir)
+{
+ struct child_process cmd;
+ prepare_run_command_v_opt(&cmd, argv, opt);
+ cmd.dir = dir;
return run_command(&cmd);
}
diff --git a/run-command.h b/run-command.h
index 3680ef9..cbd7484 100644
--- a/run-command.h
+++ b/run-command.h
@@ -16,6 +16,7 @@ struct child_process {
pid_t pid;
int in;
int out;
+ const char *dir;
unsigned close_in:1;
unsigned close_out:1;
unsigned no_stdin:1;
@@ -32,5 +33,6 @@ int run_command(struct child_process *);
#define RUN_GIT_CMD 2 /*If this is to be git sub-command */
#define RUN_COMMAND_STDOUT_TO_STDERR 4
int run_command_v_opt(const char **argv, int opt);
+int run_command_v_opt_cd(const char **argv, int opt, const char *dir);
#endif
--
1.5.2.784.g5532e
^ permalink raw reply related
* [PATCH 17/22] entry.c: optionally checkout newly cloned submodules
From: skimo @ 2007-05-23 22:23 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Martin Waitz, Alex Riesen
In-Reply-To: <11799589913153-git-send-email-skimo@liacs.nl>
From: Sven Verdoolaege <skimo@kotnet.org>
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
entry.c | 23 ++++++++++++++++++++---
submodules.c | 43 +++++++++++++++++++++++++++++++++++++++++++
submodules.h | 1 +
3 files changed, 64 insertions(+), 3 deletions(-)
diff --git a/entry.c b/entry.c
index 7ba2241..f3e0c59 100644
--- a/entry.c
+++ b/entry.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "blob.h"
#include "run-command.h"
+#include "submodules.h"
static void create_directories(const char *path, const struct checkout *state)
{
@@ -82,7 +83,7 @@ static int checkout_submodule(struct cache_entry *ce, const char *path, const st
int argc;
int err;
- if (!state->submodules)
+ if (!state->submodules && !is_checkedout_submodule(ce->name))
return 0;
argc = 0;
@@ -101,10 +102,25 @@ static int checkout_submodule(struct cache_entry *ce, const char *path, const st
return 0;
}
+static int write_submodule(struct cache_entry *ce, char *path, const struct checkout *state)
+{
+ if (mkdir(path, 0777) < 0)
+ return error("git-checkout-index: cannot create subproject directory %s", path);
+
+ if (!state->submodules)
+ return 0;
+
+ if (attach_submodule(ce->name))
+ return -1;
+
+ return checkout_submodule(ce, path, state);
+}
+
static int write_entry(struct cache_entry *ce, char *path, const struct checkout *state, int to_tempfile)
{
int fd;
long wrote;
+ int err;
switch (ntohl(ce->ce_mode) & S_IFMT) {
char *buf, *new;
@@ -174,8 +190,9 @@ static int write_entry(struct cache_entry *ce, char *path, const struct checkout
case S_IFGITLINK:
if (to_tempfile)
return error("git-checkout-index: cannot create temporary subproject %s", path);
- if (mkdir(path, 0777) < 0)
- return error("git-checkout-index: cannot create subproject directory %s", path);
+ err = write_submodule(ce, path, state);
+ if (err)
+ return err;
break;
default:
return error("git-checkout-index: unknown file mode for %s", path);
diff --git a/submodules.c b/submodules.c
index 44c0f2c..325de33 100644
--- a/submodules.c
+++ b/submodules.c
@@ -209,3 +209,46 @@ int clone_submodule(const char *submodule)
return 0;
}
+
+static const char *relativize_path(const char *path, const char *dest)
+{
+ static char relative_path[PATH_MAX];
+ int slashes;
+ const char *cp;
+ char *rp;
+
+ if (path[0] == '/')
+ return path;
+
+ for (slashes = 0, cp = strchr(dest, '/'); cp; cp = strchr(cp, '/')) {
+ ++slashes;
+ while (*cp == '/')
+ ++cp;
+ }
+ if (3 * slashes + strlen(path) + 1 > sizeof(relative_path))
+ die("path too long");
+
+ rp = relative_path;
+ while (slashes--) {
+ memcpy(rp, "../", 3);
+ rp += 3;
+ }
+ strcpy(rp, path);
+
+ return relative_path;
+}
+
+int attach_submodule(const char *submodule)
+{
+ struct stat st;
+ const char *submodule_dir, *dest;
+
+ submodule_dir = git_path("submodules/%s/.git", submodule);
+ if (lstat(submodule_dir, &st))
+ return error("submodule '%s' unavailable", submodule);
+
+ dest = mkpath("%s/.git", submodule);
+ submodule_dir = relativize_path(submodule_dir, dest);
+
+ return symlink(submodule_dir, dest);
+}
diff --git a/submodules.h b/submodules.h
index bf3f118..57432bb 100644
--- a/submodules.h
+++ b/submodules.h
@@ -3,5 +3,6 @@
int is_checkedout_submodule(const char *path);
int clone_submodule(const char *submodule);
+int attach_submodule(const char *submodule);
#endif
--
1.5.2.784.g5532e
^ permalink raw reply related
* [PATCH 19/22] test for simple submodule checkout support
From: skimo @ 2007-05-23 22:23 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Martin Waitz, Alex Riesen
In-Reply-To: <11799589913153-git-send-email-skimo@liacs.nl>
From: Martin Waitz <tali@admingilde.org>
Signed-off-by: Martin Waitz <tali@admingilde.org>
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
t/t3041-subprojects-checkout.sh | 39 +++++++++++++++++++++++++++++++++++++++
1 files changed, 39 insertions(+), 0 deletions(-)
create mode 100755 t/t3041-subprojects-checkout.sh
diff --git a/t/t3041-subprojects-checkout.sh b/t/t3041-subprojects-checkout.sh
new file mode 100755
index 0000000..4b3cea9
--- /dev/null
+++ b/t/t3041-subprojects-checkout.sh
@@ -0,0 +1,39 @@
+#!/bin/sh
+
+test_description='submodule checkout'
+. ./test-lib.sh
+
+test_expect_success 'submodule creation' \
+ '(mkdir A && cd A &&
+ git init &&
+ echo 1 > a &&
+ git add a &&
+ git commit -m "create submodule" || exit $? )'
+
+test_expect_success 'Super module creation' \
+ 'git add A &&
+ git commit -m "supermodule creation" &&
+ git branch one'
+
+test_expect_success 'submodule change' \
+ '(cd A &&
+ echo 2 > a &&
+ git add a &&
+ git commit -m "create submodule" || exit $? )'
+
+test_expect_success 'supermodule change' \
+ 'git add A &&
+ git commit -m "supermodule creation"'
+
+test_expect_success 'supermodule switching branch' \
+ 'git checkout one &&
+ echo 1 > expected &&
+ git diff expected A/a'
+
+test_expect_success 'supermodule reset' \
+ 'git reset --hard master &&
+ echo 2 > expected &&
+ git diff expected A/a'
+
+
+test_done
--
1.5.2.784.g5532e
^ permalink raw reply related
* Re: [PATCH] Add another verbosity level to git-fetch
From: Alex Riesen @ 2007-05-23 22:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael S. Tsirkin
In-Reply-To: <7viraj1a2e.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Wed, May 23, 2007 23:53:13 +0200:
> > Use "-v -v" to run git-fetch-pack in verbose mode.
> >
> > Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> > ---
> >
> > Otherwise there is no way to show connect messages for git-fetch
>
> How about just a single -v to do so?
>
Dunno, it looks too verbose for a single -v. Try it
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-23 23:40 UTC (permalink / raw)
To: skimo; +Cc: git, Junio C Hamano, Martin Waitz, Alex Riesen
In-Reply-To: <11799589913153-git-send-email-skimo@liacs.nl>
Hi,
On Thu, 24 May 2007, skimo@liacs.nl wrote:
> This patch series implements a mechanism for cloning submodules.
> Each submodule is specified by a 'submodule.<submodule>.url'
> configuration option, e.g.,
>
> bash-3.00$ ./git-config --remote=http://www.liacs.nl/~sverdool/isa.git --get-regexp 'submodule\..*\.url'
> submodule.cloog.url /home/sverdool/public_html/cloog.git
> submodule.cloog.url http://www.liacs.nl/~sverdool/cloog.git
I am sorry to complain so late in the game, but I am not really interested
in submodules. However, what you say here is not a task for git-config
IMHO, but rather for git-remote.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Prevent megablobs from gunking up git packs
From: Dana How @ 2007-05-23 23:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, danahow
In-Reply-To: <7v7iqz19d2.fsf@assigned-by-dhcp.cox.net>
On 5/23/07, Junio C Hamano <junkio@cox.net> wrote:
> Dana How <danahow@gmail.com> writes:
> > This patch implements the following:
> > 1. git pack-objects takes a new --max-blob-size=N flag,
> > with the effect that only blobs less than N KB are written
> > to the packfiles(s). If a blob was in a pack but violates
> > this limit (perhaps the packs were created by fast-import
> > or max-blob-size was reduced), then a new loose object
> > is written out if needed so the data is not lost.
>
> Why?
>
> I really do not like that "write a new loose object" part
> without proper justification. From your description, I thought
> the most natural way to do this is to pretend you did not hear
> about large objects at all, by rejecting them early, perhaps
> inside add_object_entry() or inside get_object_details() --
> either case you would do sha1_object_info() early instead of
> doing it in check_object().
>
> By the way, is there fundamental reason that this needs to be
> "blob size" limit? Wouldn't "max-object-size" be more clean in
> theory, and work the same way in practice?
I agree with your sentiments. Some nasty details pushed
me to implement it this way. Let me explain them and perhaps
you can come up with a different combination of solutions.
Each object to be packed can be in one of 4 states:
{loose or packed} X {small or too big}.
Regardless of the {loose or packed} selection,
a "small" object can always be placed in the pack.
A loose object which is too big does not require
any special action either -- if we drop it from the pack,
we don't lose anything since it already exists in objects/xx .
The packed X too big combination is the problem. As the
commit message says, this could happen if the packs
came from fast-import, or if the max-blob-size were reduced.
We have three options in this case:
(1) Drop the object (do not put it in the new pack(s)).
(2) Pass the object into the new pack(s).
(3) Write out the object as a new loose object.
Option (1) is unacceptable. When you call git-repack -a,
it blindly deletes all the non-kept packs at the end. So
the megablobs would be lost.
Let's suppose we always used Option (2), and Option (3)
were never available. Then once a large object got into
a pack, the only way to get it out would be to explode
the pack using git-unpack-objects -- but hey, that doesn't
work because they all already exist in this repository packed.
So we make a temporary repository to explode the pack,
then copy over the loose objects, then delete the pack,
then repack with the correct/updated max-blob-size specification.
I would claim this is even more ugly, and more importantly,
more error-prone than supporting Option (3) in at least some cases.
The way large objects get into a pack is that you realize after
the fact that you need a max-blob-size, or that you need to
decrease it since your pack files have become unwieldy.
I think I've shown we need Option (3) in at least some cases.
To better address _which_ cases, let's move on to your
second point:: why did I implement --max-blob-size instead
of --max-object-size? I take this to mean that I should use
the blob size if undeltified, and the delta size if previously deltified?
That's actually what I do internally, but the total effect
over many repackings is what one would expect from --max-blob-size.
In normal use on a personal repository starting from scratch,
all blobs are first packed from loose objects. When I am
deciding if I want to include the loose object or not, I want
to use the object's direct size, not its deltified size. If I use
the latter, then I have to deltify all the megablobs to see
if their deltas are small enough. This takes a long time
and is one of the things this patch aims to eliminate.
So I take the list of loose objects, throw out the megablobs,
try to deltify the rest, and write out the pack.
When I repack, any deltas are smaller than the original
objects, so in any sequence of packings from loose
objects and repackings of packs, in which all packs
were created with a max-blob-size limit which stayed the
same or increased over time, there is no difference
between max-blob-size or max-object-size: checking loose
object size or in-pack size gives the same pack contents.
Now let's say you decrease max-blob-size and repack,
or repack from some packs that had no max-blob-size
(e.g. from fast-import). Now there is some difficulty in
a clean definition when you follow Option (3). You might
have a base object B in an old pack, and a deltified object
D based on it, where B is now larger than the newly-decreased
max-blob-size while D's deltified size is still smaller.
So you write out B, but D can no longer be stored deltified
and may become bigger as well.
But in this case you should do the following:
Since you are going to decrease max-blob-size when you decide
your repository packs have become "gunked up" with megablobs,
I would propose git-repack -a -f (git-pack-objects --no-object-reuse)
be used. This means all deltas are recomputed
from the new, smaller universe of blobs, which makes sense,
and since no deltas are reused, all blob-size limits can only
be based on the actual blob size by the arguments 3 paragraphs back.
(Note: I made sure the current patch loses no data if you decrease
max-blob-size and forget to specify -f -- you just get a few large
packed objects resulting from "lost" deltifications.)
In actuality, the object_entry.size field is checked, so objects
_are_ being filtered by delta size if deltified. But I went through
the (suggested) usage scenarios above to show that the *result* is that
you get a pack limited in raw object size. --max-object-size
is what I implemented because it's easier, but in use it acts
like --max-blob-size so I named it that.
Now, concerning Option (2) vs Option (3): I need to write
out loose objects in *some* cases. Right now I always write
out a large object as a loose one. It would be reasonable to
change this so that it only happens with --no-object-reuse
(i.e. git-repack -f). This is what you should specify when you're
decreasing max-blob-size. Shall I change it so that large objects
are passed to the result pack without --no-object-reuse,
and written out as loose objects with --no-object-reuse?
I did not do this because it's a strange interaction --
just look how long it took me to build up to explaining it!
> > 2. git repack inspects repack.maxblobsize . If set, its
> > value is passed to git pack-objects on the command line.
> > The user should change repack.maxblobsize , NOT specify
> > --max-blob-size=N .
> Why not?
Well, indeed. That's why [PATCH *v2*] lets you specify
--max-blob-size to git-repack, and gives an example of
why you might want to do that [I don't].
> > This patch is on top of the earlier max-pack-size patch,
> > because I thought I needed some behavior it supplied,
> > but could be rebased on master if desired.
>
> Your earlier "split according to max-pack-size" will hopefully be
> on master shortly.
Thanks!
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Junio C Hamano @ 2007-05-24 0:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: skimo, git, Martin Waitz, Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0705240039370.4113@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 24 May 2007, skimo@liacs.nl wrote:
>
>> This patch series implements a mechanism for cloning submodules.
>> Each submodule is specified by a 'submodule.<submodule>.url'
>> configuration option, e.g.,
>>
>> bash-3.00$ ./git-config --remote=http://www.liacs.nl/~sverdool/isa.git --get-regexp 'submodule\..*\.url'
>> submodule.cloog.url /home/sverdool/public_html/cloog.git
>> submodule.cloog.url http://www.liacs.nl/~sverdool/cloog.git
>
> I am sorry to complain so late in the game, but I am not really interested
> in submodules. However, what you say here is not a task for git-config
> IMHO, but rather for git-remote.
Honestly speaking, I do not think people have no business
peeking into configuratoin remote repository has, and it would
be preferrable that supermodule Porcelain stuff does not rely on
that.
^ permalink raw reply
* [PATCH] Document branch.autosetupmerge.
From: Paolo Bonzini @ 2007-05-23 5:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wink Saville, Josef Weidendorfer, Steven Grimm, git
In-Reply-To: <7vwsz05qcq.fsf@assigned-by-dhcp.cox.net>
This patch documents the branch.autosetupmerge config option, adding
in commit 0746d19a.
Signed-Off-By: Paolo Bonzini <bonzini@gnu.org>
---
config.txt | 7 +++++++
1 files changed, 7 insertions(+)
> I notice that Paolo did not update Documentation/config.txt
> when he add this feature with 0746d19a; care to send in a patch
> to correct this?
Sure.
Paolo.
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 179cb17..de3c276 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -280,4 +280,11 @@ apply.whitespace::
Tells `git-apply` how to handle whitespaces, in the same way
as the '--whitespace' option. See gitlink:git-apply[1].
+branch.autosetupmerge::
+ Tells `git-branch' and `git-checkout' to setup new branches
+ so that gitlink:git-pull[1] will appropriately merge from that
+ remote branch. Note that even if this option is not set,
+ this behavior can be chosen per-branch using the `--track`
+ and `--no-track` options. This option defaults to false.
+
branch.<name>.remote::
^ permalink raw reply related
* Re: [PATCH] Prevent megablobs from gunking up git packs
From: Junio C Hamano @ 2007-05-24 1:44 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <56b7f5510705231655o589de801w88adc1aa6c18162b@mail.gmail.com>
"Dana How" <danahow@gmail.com> writes:
> The packed X too big combination is the problem. As the
> commit message says, this could happen if the packs
> came from fast-import,...
> We have three options in this case:
> (1) Drop the object (do not put it in the new pack(s)).
> (2) Pass the object into the new pack(s).
> (3) Write out the object as a new loose object.
>
> Option (1) is unacceptable. When you call git-repack -a,
> it blindly deletes all the non-kept packs at the end. So
> the megablobs would be lost.
Ok, I can buy that -- (1) nor (2) are unacceptable and (3) is
the only sane thing to do for a previously packed objects that
exceed the size limit.
Since you have to handle that case _anyway_, I think it makes
sense to always say "Ok, we will write it out if there is no
loose representation already available".
That is, unless somebody smarter than me, like Nico or Shawn,
come up with better ideas to do this ;-).
> ... why did I implement --max-blob-size instead
> of --max-object-size? I take this to mean that I should use
> the blob size if undeltified, and the delta size if previously deltified?
No, I think the only sensible way for the end user to specify
the size is uncompressed size of the object. For a blob, that
is the size of checked-out file. IOW:
$ git cat-file $type $sha | wc -c
Nothing else would make any sense.
^ permalink raw reply
* Re: [PATCH] fast-import: Fix crash when referencing already existing objects
From: Shawn O. Pearce @ 2007-05-24 3:44 UTC (permalink / raw)
To: Simon Hausmann; +Cc: git
In-Reply-To: <200705232301.49667.simon@lst.de>
Simon Hausmann <simon@lst.de> wrote:
> Commit a5c1780a0355a71b9fb70f1f1977ce726ee5b8d8 sets the pack_id of existing
> objects to MAX_PACK_ID. When the same object is referenced later again it is
> found in the local object hash. With such a pack_id fast-import should not try
> to locate that object in the newly created pack(s).
Thanks, that was a _really_ nasty bug. :-(
Turns out there's more cases. Such as if we reload a mark table of
commits (--import-marks) and then try to create a branch from them.
The existing commit will also have a pack_id of MAX_PACK_ID and
we'll go right into the same corruption you saw and fixed here.
I will be pushing your two patches and my additional fixup to
my maint branch tonight.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Documentation: fix git-config.xml generation
From: Jeffrey C. Ollie @ 2007-05-24 4:10 UTC (permalink / raw)
To: git
In-Reply-To: <3f80363f0705231516x7c6fa2daua33a708deaa7a10c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 324 bytes --]
On Wed, 2007-05-23 at 18:16 -0400, James Bowes wrote:
>
> With asciidoc 8.1.0 and xmlto 0.0.18, git-config.xml failed to
> validate. This patch just makes the asciidoc formatting for
> branch.autosetupmerge the same as the other config options.
I can confirm that this patch fixes the validation errors...
Jeff
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: fix git-config.xml generation
From: Junio C Hamano @ 2007-05-24 4:22 UTC (permalink / raw)
To: Jeffrey C. Ollie; +Cc: git
In-Reply-To: <1179979802.3682.12.camel@lt21223.campus.dmacc.edu>
"Jeffrey C. Ollie" <jeff@ocjtech.us> writes:
> On Wed, 2007-05-23 at 18:16 -0400, James Bowes wrote:
>>
>> With asciidoc 8.1.0 and xmlto 0.0.18, git-config.xml failed to
>> validate. This patch just makes the asciidoc formatting for
>> branch.autosetupmerge the same as the other config options.
>
> I can confirm that this patch fixes the validation errors...
Yup, already pushed out about 7 hours ago.
Thanks.
^ permalink raw reply
* Re: [PATCH] Documentation: fix git-config.xml generation
From: Jeffrey C. Ollie @ 2007-05-24 4:43 UTC (permalink / raw)
To: git
In-Reply-To: <7vhcq2zw7y.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
On Wed, 2007-05-23 at 21:22 -0700, Junio C Hamano wrote:
> "Jeffrey C. Ollie" <jeff@ocjtech.us> writes:
>
> > On Wed, 2007-05-23 at 18:16 -0400, James Bowes wrote:
> >>
> >> With asciidoc 8.1.0 and xmlto 0.0.18, git-config.xml failed to
> >> validate. This patch just makes the asciidoc formatting for
> >> branch.autosetupmerge the same as the other config options.
> >
> > I can confirm that this patch fixes the validation errors...
>
> Yup, already pushed out about 7 hours ago.
I do not see it in any of the public git repos. Is there some
synchronization interval I need to wait for?
Jeff
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: fix git-config.xml generation
From: Shawn O. Pearce @ 2007-05-24 4:47 UTC (permalink / raw)
To: Jeffrey C. Ollie; +Cc: git
In-Reply-To: <1179981812.3682.16.camel@lt21223.campus.dmacc.edu>
"Jeffrey C. Ollie" <jeff@ocjtech.us> wrote:
> On Wed, 2007-05-23 at 21:22 -0700, Junio C Hamano wrote:
> > "Jeffrey C. Ollie" <jeff@ocjtech.us> writes:
> >
> > > On Wed, 2007-05-23 at 18:16 -0400, James Bowes wrote:
> > >>
> > >> With asciidoc 8.1.0 and xmlto 0.0.18, git-config.xml failed to
> > >> validate. This patch just makes the asciidoc formatting for
> > >> branch.autosetupmerge the same as the other config options.
> > >
> > > I can confirm that this patch fixes the validation errors...
> >
> > Yup, already pushed out about 7 hours ago.
>
> I do not see it in any of the public git repos. Is there some
> synchronization interval I need to wait for?
kernel.org has mirroring lags. When Junio pushes to kernel.org
he also pushes to repo.or.cz/alt-git.git. That's usually where
I fetch from, as there's no mirroring lag at all.
Note that repo.or.cz also has a git.git, which is a mirror of
kernel.org's mirrors, so its uh, way way behind sometimes. ;-)
--
Shawn.
^ permalink raw reply
* [PATCH] Fix git-svn to handle svn not reporting the md5sum of a file, and test.
From: James Y Knight @ 2007-05-24 4:37 UTC (permalink / raw)
To: git; +Cc: normalperson, James Y Knight
---
git-svn.perl | 2 +-
t/t9112-git-svn-md5less-file.sh | 45 +++++++++++++++++++++++++++++++++++++++
2 files changed, 46 insertions(+), 1 deletions(-)
create mode 100755 t/t9112-git-svn-md5less-file.sh
diff --git a/git-svn.perl b/git-svn.perl
index 3c4f490..b2773dc 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2471,7 +2471,7 @@ sub close_file {
$md5->addfile($fh);
my $got = $md5->hexdigest;
die "Checksum mismatch: $path\n",
- "expected: $exp\n got: $got\n" if ($got ne $exp);
+ "expected: $exp\n got: $got\n" if (defined $exp && $got ne $exp);
sysseek($fh, 0, 0) or croak $!;
if ($fb->{mode_b} == 120000) {
sysread($fh, my $buf, 5) == 5 or croak $!;
diff --git a/t/t9112-git-svn-md5less-file.sh b/t/t9112-git-svn-md5less-file.sh
new file mode 100755
index 0000000..08313bb
--- /dev/null
+++ b/t/t9112-git-svn-md5less-file.sh
@@ -0,0 +1,45 @@
+test_description='test that git handles an svn repository with missing md5sums'
+
+. ./lib-git-svn.sh
+
+# Loading a node from a svn dumpfile without a Text-Content-Length
+# field causes svn to neglect to store or report an md5sum. (it will
+# calculate one if you had put Text-Content-Length: 0). This showed
+# up in a repository creted with cvs2svn.
+
+cat > dumpfile.svn <<EOF
+SVN-fs-dump-format-version: 1
+
+Revision-number: 1
+Prop-content-length: 98
+Content-length: 98
+
+K 7
+svn:log
+V 0
+
+K 10
+svn:author
+V 4
+test
+K 8
+svn:date
+V 27
+2007-05-06T12:37:01.153339Z
+PROPS-END
+
+Node-path: md5less-file
+Node-kind: file
+Node-action: add
+Prop-content-length: 10
+Content-length: 10
+
+PROPS-END
+
+EOF
+
+test_expect_success 'load svn dumpfile' "svnadmin load $rawsvnrepo < dumpfile.svn"
+
+test_expect_success 'initialize git-svn' "git-svn init $svnrepo"
+test_expect_success 'fetch revisions from svn' 'git-svn fetch'
+test_done
--
1.5.2.rc2.1.g7f0b
^ permalink raw reply related
* Re: [PATCH] Documentation: fix git-config.xml generation
From: Jeffrey C. Ollie @ 2007-05-24 4:55 UTC (permalink / raw)
To: git
In-Reply-To: <20070524044736.GH28023@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
On Thu, 2007-05-24 at 00:47 -0400, Shawn O. Pearce wrote:
>
> kernel.org has mirroring lags. When Junio pushes to kernel.org
> he also pushes to repo.or.cz/alt-git.git. That's usually where
> I fetch from, as there's no mirroring lag at all.
>
> Note that repo.or.cz also has a git.git, which is a mirror of
> kernel.org's mirrors, so its uh, way way behind sometimes. ;-)
Yes, I looked at all three, but didn't see it. It's not a big deal, as
I've applied the patch locally.
Jeff
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* fast-import maint fixes
From: Shawn O. Pearce @ 2007-05-24 4:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Simon Hausmann
The following changes since commit 7ca055f75ad7ffd2251d4b607fbb86d7bcfd77c7:
Stephan Springl (1):
Use git-for-each-ref to check whether the origin branch exists.
are available in the git repository at:
repo.or.cz:/srv/git/git/fastimport.git maint
Shawn O. Pearce (2):
Refactor fast-import branch creation from existing commit
Fix possible coredump with fast-import --import-marks
Simon Hausmann (2):
fast-import: Fix uninitialized variable
fast-import: Fix crash when referencing already existing objects
fast-import.c | 67 ++++++++++++++++++++++++++---------------------
t/t9300-fast-import.sh | 29 ++++++++++++++++++++
2 files changed, 66 insertions(+), 30 deletions(-)
These are built on top of Junio's maint, and should be merged there,
as they fix coredumps when documented features are actually used.
:-(
--
Shawn.
^ permalink raw reply
* bash completion updates
From: Shawn O. Pearce @ 2007-05-24 6:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The following changes since commit aba170cdb4874b72dd619e6f7bbc13c33295f831:
Junio C Hamano (1):
GIT 1.5.2
are available in the git repository at:
repo.or.cz:/srv/git/git/fastimport.git master
Jonas Fonseca (1):
Update bash completion to ignore some more plumbing commands
Shawn O. Pearce (7):
Hide the plumbing diff-{files,index,tree} from bash completion
Teach bash completion about git-shortlog
Remove a duplicate --not option in bash completion
Update bash completion header documentation
Teach bash completion about 'git remote update'
Teach bash completion about recent log long options
Update bash completion for git-config options
contrib/completion/git-completion.bash | 81 ++++++++++++++++++++++++++++----
1 files changed, 71 insertions(+), 10 deletions(-)
These are relative to the 1.5.2 tip commit, so they should be able to
go just about anywhere. I consider them all to be new features, but
they should really be suitable for inclusion in a 1.5.2.1 release.
Note that my master branch doesn't contain my maint branch; I'm
expecting you to merge things up on your end. ;-)
--
Shawn.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Shawn O. Pearce @ 2007-05-24 6:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Daniel Barkalow
In-Reply-To: <7vodkb1adr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> * db/remote (Tue May 15 22:50:19 2007 -0400) 4 commits
> + Update local tracking refs when pushing
> + Add handlers for fetch-side configuration of remotes.
> + Move refspec parser from connect.c and cache.h to remote.{c,h}
> + Move remote parsing into a library file out of builtin-push.
>
> Will need to look at this once more; I do not expect too much
> problems with it.
I spent all day today working with this series. Lots of pushing new
branches, deleting existing branches, updating existing branches
across many repositories. Its an *awesome* change. I'm really
happy with it.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 10/22] run-command: optionally clear git environment
From: Alex Riesen @ 2007-05-24 6:57 UTC (permalink / raw)
To: skimo@liacs.nl; +Cc: git, Junio C Hamano, Martin Waitz
In-Reply-To: <11799589923790-git-send-email-skimo@liacs.nl>
On 5/24/07, skimo@liacs.nl <skimo@liacs.nl> wrote:
> + if (cmd->clear_git_env) {
> + unsetenv(ALTERNATE_DB_ENVIRONMENT);
> + unsetenv(DB_ENVIRONMENT);
> + unsetenv(CONFIG_ENVIRONMENT);
> + unsetenv(GIT_DIR_ENVIRONMENT);
> + unsetenv(GRAFT_ENVIRONMENT);
> + unsetenv(INDEX_ENVIRONMENT);
> + }
You might want to try the alternative approach from the recently
proposed patches to do the same, but more generic. Would
be less code, too.
^ permalink raw reply
* Re: [PATCH 11/22] entry.c: optionally checkout submodules
From: Alex Riesen @ 2007-05-24 6:59 UTC (permalink / raw)
To: skimo@liacs.nl; +Cc: git, Junio C Hamano, Martin Waitz
In-Reply-To: <11799589922243-git-send-email-skimo@liacs.nl>
On 5/24/07, skimo@liacs.nl <skimo@liacs.nl> wrote:
> + args[argc++] = "checkout";
> + if (state->force)
> + args[argc++] = "-f";
> + args[argc++] = sha1_to_hex(ce->sha1);
> + args[argc] = NULL;
You should consider passing "-v" if the superprojects read-tree
had it. Some submodules will be annoyingly big
^ permalink raw reply
* Re: [PATCH] Prevent megablobs from gunking up git packs
From: Shawn O. Pearce @ 2007-05-24 7:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dana How, Git Mailing List
In-Reply-To: <7vps4ryp02.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Dana How" <danahow@gmail.com> writes:
>
> > The packed X too big combination is the problem. As the
> > commit message says, this could happen if the packs
> > came from fast-import,...
> > We have three options in this case:
> > (1) Drop the object (do not put it in the new pack(s)).
> > (2) Pass the object into the new pack(s).
> > (3) Write out the object as a new loose object.
> >
> > Option (1) is unacceptable. When you call git-repack -a,
> > it blindly deletes all the non-kept packs at the end. So
> > the megablobs would be lost.
>
> Ok, I can buy that -- (1) nor (2) are unacceptable and (3) is
> the only sane thing to do for a previously packed objects that
> exceed the size limit.
I still don't buy the idea that these megablobs shouldn't be packed.
I understand Dana's pain here (at least a little bit, my problems
aren't as bad as his are), but I also hate to see us run away from
packfiles for these really sick cases just because we have some
issues in our current packfile handling.
Packfiles give us a lot of benefits:
1) less inode usage;
2) transport can write directly to local disk;
3) transport can (quickly) copy from local disk;
4) testing for existance is *much* faster;
5) deltafication is possible;
Now #3 is actually really important here. Don't forget that we
*just* disabled the fancy "new loose object format". It doesn't
exist. We can read the packfile-like loose objects, but we cannot
write them anymore. So lets say we explode a megablob into a loose
object, and its 800 MiB by itself. Now we have to send that object
to a client. Yes, that's right, we must *RECOMPRESS* 800 MiB for
no reason. Not the best choice. Maybe we shouldn't have deleted
that packfile formatted loose object writer...
Now one argument to work around that recompression problem would
be to NFS share out the loose objects directory, and let clients
mount that volume and add it to their .git/objects/info/alternates
list. But this doesn't work in the very general distributed case,
such as me getting huge files from kernel.org. Last I checked,
the kernel.org admins did not offer up NSF mounts. Besides, the
round-trip latency between me and kernel.org is too large for it
to be useful anyway over NFS. :)
So I think this "explode out megablobs" is a bad idea. Its violating
other things that make us fast, like #3's being able to reuse large
parts of an existing packfile during transfer.
Dana pointed out the megablobs make access slower because their
packfile indexes must still be searched to locate a commit; but if
the megablob packfile(s) contain only blobs then there is no value
in looking at those packfiles.
We might be able to fix this by altering the sort_pack function
in sha1_file.c to not only order by mtime, but also by the ratio
of the size of the .pack to the number of objects stored in it.
Any packfile with a high size/object ratio is likely to be what
Dana has been calling a "metadata" pack, holding things like tags,
commits, trees and small blobs. Its these packfiles that we want
to search first, as they are the most likely to be accessed.
By pushing the megablob packs to the end of our packed_git search
list we won't tend to scan their indexes, as most of our objects
will be found earlier in the search list. Hence we will generally
avoid any costs associated with their indexes.
Huge packfiles probably should be scheduled for keeping with a .keep
automatically. We probably should teach pack-objects to generate a
.keep file if the resulting .pack was over a certain size threshold
(say 1.5 GiB by default) and teach git-repack to rename the .keep
file as it also renames the .idx and .pack.
Better that we degrade gracefully when faced with massive inputs
than we do something stupid by default and make the poor user pay
for their mistake of not throughly reading plumbing documentation
before use.
Now I would agree that we should punt on deltification of anything
that is just too large, and let the user decide what too large means,
and default it around 500 or 1024 MiB. But I would still stuff it
into a packfile.
Maybe it still makes sense to have a limit on the maximum size of a
loose object to pack, but I think that's only to avoid the sick case
of a very simple no-argument "git repack" taking a long while because
there's 8 loose objects and 6 of them are 900 MiB image files.
Once in a packfile, I'd keep it there, even if the user decreases
the threshold, as the advantages of it being in the packfile outweigh
the disadvantages of it being in the packfile. And there's like no
advantage to being loose once packed.
All of that is actually a very minor set of changes to the system,
and doesn't create odd corner cases. It should also degrade better
out of the box.
> > ... why did I implement --max-blob-size instead
> > of --max-object-size? I take this to mean that I should use
> > the blob size if undeltified, and the delta size if previously deltified?
>
> No, I think the only sensible way for the end user to specify
> the size is uncompressed size of the object. For a blob, that
> is the size of checked-out file. IOW:
>
> $ git cat-file $type $sha | wc -c
>
> Nothing else would make any sense.
I agree. And when you combine it with what I'm saying above about
only applying this to loose objects, its really quite easy to fetch
that value from the header and perform the test.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 10/22] run-command: optionally clear git environment
From: Shawn O. Pearce @ 2007-05-24 7:15 UTC (permalink / raw)
To: Alex Riesen; +Cc: skimo@liacs.nl, git, Junio C Hamano, Martin Waitz
In-Reply-To: <81b0412b0705232357i535be2adl6570847942ecb9c0@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> wrote:
> On 5/24/07, skimo@liacs.nl <skimo@liacs.nl> wrote:
> >+ if (cmd->clear_git_env) {
> >+ unsetenv(ALTERNATE_DB_ENVIRONMENT);
> >+ unsetenv(DB_ENVIRONMENT);
> >+ unsetenv(CONFIG_ENVIRONMENT);
> >+ unsetenv(GIT_DIR_ENVIRONMENT);
> >+ unsetenv(GRAFT_ENVIRONMENT);
> >+ unsetenv(INDEX_ENVIRONMENT);
> >+ }
>
> You might want to try the alternative approach from the recently
> proposed patches to do the same, but more generic. Would
> be less code, too.
Unfortunately Alex's approach means the caller must know the list of
"special Git envvars" that should be cleared when entering into a
subproject Git repository to execute a command. That's horrible code
duplication in the callers of run_command, and is just asking for
trouble later when/if another magic environment variable is added.
As long as the above unsetenv list is, I'd really rather have a
specific clear_git_env bit in struct child_process, just so that the
callers don't have to be bothered with the precise list of names.
Of course declaring those names in a static const char** and
looping over it before doing Alex's env array thing would probably
be less code and let the two play along together rather nicely.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 11/22] entry.c: optionally checkout submodules
From: Shawn O. Pearce @ 2007-05-24 7:18 UTC (permalink / raw)
To: Alex Riesen; +Cc: skimo@liacs.nl, git, Junio C Hamano, Martin Waitz
In-Reply-To: <81b0412b0705232359g34321bb9hda50c3e29d7d3473@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> wrote:
> On 5/24/07, skimo@liacs.nl <skimo@liacs.nl> wrote:
>
> >+ args[argc++] = "checkout";
> >+ if (state->force)
> >+ args[argc++] = "-f";
> >+ args[argc++] = sha1_to_hex(ce->sha1);
> >+ args[argc] = NULL;
>
> You should consider passing "-v" if the superprojects read-tree
> had it. Some submodules will be annoyingly big
In 1.5.2 that -v shouldn't be necessary. The read-tree should
start a timer, and if it has not reached 50% of its processing
within 2 seconds it starts showing progress. Unless !istty(2),
in which case it just sits there, chugging away at your drive.
I'm actually really unhappy with our !istty(2) means disable
progress thing. git-gui knows how to read and show the progress
meters, but nobody prints them anymore as 2 is a pipe. I have the
same problem with a Java build tool that sometimes starts up an
expensive Git operation (like a clone over SSH of a 60+ MiB project).
I've been considering adding a GIT_ISTTY environment variable to
forcefully override the istty result, just to get the progress
meters turned back on...
--
Shawn.
^ permalink raw reply
* Re: [PATCH 10/22] run-command: optionally clear git environment
From: Alex Riesen @ 2007-05-24 7:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: skimo@liacs.nl, git, Junio C Hamano, Martin Waitz
In-Reply-To: <20070524071527.GM28023@spearce.org>
On 5/24/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Alex Riesen <raa.lkml@gmail.com> wrote:
> > On 5/24/07, skimo@liacs.nl <skimo@liacs.nl> wrote:
> > >+ if (cmd->clear_git_env) {
> > >+ unsetenv(ALTERNATE_DB_ENVIRONMENT);
> > >+ unsetenv(DB_ENVIRONMENT);
> > >+ unsetenv(CONFIG_ENVIRONMENT);
> > >+ unsetenv(GIT_DIR_ENVIRONMENT);
> > >+ unsetenv(GRAFT_ENVIRONMENT);
> > >+ unsetenv(INDEX_ENVIRONMENT);
> > >+ }
> >
> > You might want to try the alternative approach from the recently
> > proposed patches to do the same, but more generic. Would
> > be less code, too.
>
> Unfortunately Alex's approach means the caller must know the list of
> "special Git envvars" that should be cleared when entering into a
> subproject Git repository to execute a command. That's horrible code
> duplication in the callers of run_command, and is just asking for
> trouble later when/if another magic environment variable is added.
#define GIT_ENV_LIST ALTERNATE_DB_ENVIRONMENT, \
...
^ 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