* Re: [PATCH 1/3] make index-pâck able to complete thin packs
From: Nicolas Pitre @ 2006-10-28 0:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz7hcs0o.fsf@assigned-by-dhcp.cox.net>
On Fri, 27 Oct 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > +static void fix_unresolved_deltas(int nr_unresolved)
> > +{
[...]
> > + if (objects[d->obj_no].real_type != OBJ_REF_DELTA)
> > + continue;
>
> Just for the sake of my own sanity checking,...
>
> Is it because base objects of OFS_DELTA _must_ exist in the same
> pack (even when --thin) that we do not have to worry about them
> in this function?
Indeed. Otherwise it would be impossible to determine the offset to the
base object if that base object is not in the pack.
That doesn't mean there isn't any OFS_DELTA left to resolve though.
But this function is only about adding missing objects to the pack and
the deltas that need them must be REF_DELTA objects.
Once a REF_DELTA has been resolved with an external object, it then
constitute a possible new base for remaining OFS_DELTA or
REF_DELTA objects, and that is found recursively in resolve_delta().
^ permalink raw reply
* [PATCH] Fixes "stg goto `stg top`" to no-op & test
From: Ilpo Järvinen @ 2006-10-27 23:15 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2014 bytes --]
StGIT tried to access index that is not valid when goto'ing to
the current patch. Adds also a test for it.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
stgit/commands/common.py | 17 ++++++++++-------
t/t1600-goto-top.sh | 32 ++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+), 7 deletions(-)
diff --git a/stgit/commands/common.py b/stgit/commands/common.py
index 1ea6025..88b1b94 100644
--- a/stgit/commands/common.py
+++ b/stgit/commands/common.py
@@ -200,16 +200,19 @@ def pop_patches(patches, keep = False):
"""Pop the patches in the list from the stack. It is assumed that
the patches are listed in the stack reverse order.
"""
- p = patches[-1]
- if len(patches) == 1:
- print 'Popping patch "%s"...' % p,
+ if len(patches) == 0:
+ print 'nothing to push/pop'
else:
- print 'Popping "%s" - "%s" patches...' % (patches[0], p),
- sys.stdout.flush()
+ p = patches[-1]
+ if len(patches) == 1:
+ print 'Popping patch "%s"...' % p,
+ else:
+ print 'Popping "%s" - "%s" patches...' % (patches[0], p),
+ sys.stdout.flush()
- crt_series.pop_patch(p, keep)
+ crt_series.pop_patch(p, keep)
- print 'done'
+ print 'done'
def parse_patches(patch_args, patch_list):
"""Parse patch_args list for patch names in patch_list and return
diff --git a/t/t1600-goto-top.sh b/t/t1600-goto-top.sh
new file mode 100755
index 0000000..94a88cf
--- /dev/null
+++ b/t/t1600-goto-top.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Catalin Marinas
+#
+
+test_description='Test the uncommit command.
+
+'
+
+. ./test-lib.sh
+
+test_expect_success \
+ 'Initialize the StGIT repository' \
+ 'stg init
+'
+
+test_expect_success \
+ 'Create the first patch' \
+ '
+ stg new foo -m "Foo Patch" &&
+ echo foo > test &&
+ stg add test &&
+ stg refresh
+ '
+
+test_expect_success \
+ 'Goto current patch' \
+ '
+ stg goto `stg top`
+ '
+
+test_done
--
1.4.2
^ permalink raw reply related
* Re: [PATCH 1/3] make index-pâck able to complete thin packs
From: Junio C Hamano @ 2006-10-27 22:28 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610252323100.12418@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> +static void fix_unresolved_deltas(int nr_unresolved)
> +{
> + struct delta_entry **sorted_by_pos;
> + int i, n = 0;
> +
> + /*
> + * Since many unresolved deltas may well be themselves base objects
> + * for more unresolved deltas, we really want to include the
> + * smallest number of base objects that would cover as much delta
> + * as possible by picking the
> + * trunc deltas first, allowing for other deltas to resolve without
> + * additional base objects. Since most base objects are to be found
> + * before deltas depending on them, a good heuristic is to start
> + * resolving deltas in the same order as their position in the pack.
> + */
> + sorted_by_pos = xmalloc(nr_unresolved * sizeof(*sorted_by_pos));
> for (i = 0; i < nr_deltas; i++) {
> - if (deltas[i].obj->real_type == OBJ_REF_DELTA ||
> - deltas[i].obj->real_type == OBJ_OFS_DELTA)
> - die("pack has unresolved deltas");
> + if (objects[deltas[i].obj_no].real_type != OBJ_REF_DELTA)
> + continue;
> + sorted_by_pos[n++] = &deltas[i];
> }
>
> + qsort(sorted_by_pos, n, sizeof(*sorted_by_pos), delta_pos_compare);
> +
> + for (i = 0; i < n; i++) {
> + struct delta_entry *d = sorted_by_pos[i];
> + void *data;
> + unsigned long size;
> + char type[10];
> + enum object_type obj_type;
> + int j, first, last;
> +
> + if (objects[d->obj_no].real_type != OBJ_REF_DELTA)
> + continue;
Just for the sake of my own sanity checking,...
Is it because base objects of OFS_DELTA _must_ exist in the same
pack (even when --thin) that we do not have to worry about them
in this function?
^ permalink raw reply
* Re: prune/prune-packed
From: Junio C Hamano @ 2006-10-27 21:55 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <1161983997.2426.422.camel@cashmere.sps.mot.com>
Jon Loeliger <jdl@freescale.com> writes:
> On Sun, 2006-10-22 at 22:27, Junio C Hamano wrote:
>
>> Sorry, but you are right and Linus is more right. How about
>> doing FRSX.
>>
>> diff --git a/pager.c b/pager.c
>> index 8bd33a1..4587fbb 100644
>> --- a/pager.c
>> +++ b/pager.c
>> @@ -50,7 +50,7 @@ void setup_pager(void)
>> close(fd[0]);
>> close(fd[1]);
>>
>> - setenv("LESS", "FRS", 0);
>> + setenv("LESS", "FRSX", 0);
>> run_pager(pager);
>> die("unable to execute pager '%s'", pager);
>> exit(255);
>
> I'm a little confused by all this because I
> set the LESS environment variable by myself
> already. And I use the value that I like.
> Why change it or override the user's settings
> like this? Or did I miss something?
This is about "if user does not set it, use this default".
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Junio C Hamano @ 2006-10-27 21:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610271310450.3849@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> We really should _never_ create a pack in-place with the final name.
The "fattening" index-pack Nico did does not have this problem
as far as I can see. Under --stdin, it creates a temporary pack
file "$GIT_OBJECT_DIRECTORY/pack_XXXXXX"; after the received
pack is fattened by adding missing delta-base objects and fixing
up the pack header, final() moves the {pack,idx} pair to the
final location.
The race is about this sequence:
- git-receive-pack is spawned from remove git-send-pack;
it lets "index-pack --stdin --fatten" to keep the pack.
- index-pack does its magic and moves the pack and idx
to their final location;
- "repack -a -d" is started by somebody else; it first
remembers all the existing packs; it does the usual
repacking-into-one.
- git-receive-pack that invoked the index-pack waits for
index-pack to finish, and then updates the refs;
- "repack -a -d" is done repacking; removes the packs
that existed when it checked earlier.
Two instances of receive-pack running simultaneously is safe (in
the sense that it does not corrupt the repository; one instance
can fail after noticing the other updated the ref it wanted to
update) and there is no reason to exclude each other. But
"repack -a -d" and receive-pack are not.
Can we perhaps have reader-writer lock on the filesystem to
pretect the repository? "prune" can also be made into a writer
for that lock and "fetch-pack --keep" would be a reader for the
lock. That reader-writer lock would solve the issue rather
nicely.
> That said, I think some of the "git repack -d" logic is also unnecessarily
> fragile.
Noted; will fix.
^ permalink raw reply
* Re: Generating docu in 1.4.3.3.g01929
From: Junio C Hamano @ 2006-10-27 21:34 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git
In-Reply-To: <200610271726.k9RHQr0F024712@laptop13.inf.utfsm.cl>
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> I'm getting lots of these after today's pull:
>
> asciidoc -b docbook -d manpage -f asciidoc.conf git-daemon.txt
> xmlto -m callouts.xsl man git-daemon.xml
> error : unterminated entity reference
> error : unterminated entity reference
> error : unterminated entity reference ...
> error : unterminated entity reference
> error : unterminated entity reference
> Writing git-daemon.1 for refentry
Is it only with git-daemon.txt (as opposed to other files like
git-cat-file.txt), is it only with generating git-daemon.1 (as
opposed to generating git-daemon.html), and is it only with
today's pull (as opposed to 1.4.3.3)?
The point I am getting at is if it is only for you and if so
we might want to pinpoint where the breakage is.
I do not see it with my xmlto and asciidoc combination, either
on FC6 nor on Debian testing.
^ permalink raw reply
* Re: prune/prune-packed
From: Jon Loeliger @ 2006-10-27 21:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: gitzilla, J. Bruce Fields, Git List
In-Reply-To: <7vvembzp6y.fsf@assigned-by-dhcp.cox.net>
On Sun, 2006-10-22 at 22:27, Junio C Hamano wrote:
> Sorry, but you are right and Linus is more right. How about
> doing FRSX.
>
> diff --git a/pager.c b/pager.c
> index 8bd33a1..4587fbb 100644
> --- a/pager.c
> +++ b/pager.c
> @@ -50,7 +50,7 @@ void setup_pager(void)
> close(fd[0]);
> close(fd[1]);
>
> - setenv("LESS", "FRS", 0);
> + setenv("LESS", "FRSX", 0);
> run_pager(pager);
> die("unable to execute pager '%s'", pager);
> exit(255);
I'm a little confused by all this because I
set the LESS environment variable by myself
already. And I use the value that I like.
Why change it or override the user's settings
like this? Or did I miss something?
Thanks,
jdl
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Linus Torvalds @ 2006-10-27 20:22 UTC (permalink / raw)
To: Eran Tromer; +Cc: git, Junio C Hamano
In-Reply-To: <4540CA0C.6030300@tromer.org>
On Thu, 26 Oct 2006, Eran Tromer wrote:
>
> This creates a race condition w.r.t. "git repack -a -d", similar to the
> existing race condition between "git fetch --keep" and
> "git repack -a -d". There's a point in time where the new pack is stored
> but not yet referenced, and if "git repack -a -d" runs at that point it
> will eradicate the pack. When the heads are finally updated, you get a
> corrupted repository.
(I note that there's a whole thread on this, but I was off doing other
things, so I probably missed part of it)
We really should _never_ create a pack in-place with the final name.
The way to fix the race is to simply not create the patch as
.git/objects/packed/pack-xyz.{pack|idx}
in the first place, but simply "mv" them into place later. If you do that
after you've written the temporary pointer to it, there is no race (the
temporary pointer may not be usable, of course, but that's a separate
issue).
That said, I think some of the "git repack -d" logic is also unnecessarily
fragile. In particular, it shouldn't just do
existing=$(find . -type f \( -name '*.pack' -o -name '*.idx' \))
like it does to generate the "existing" list, it should probably only ever
remove a pack-file and index file _pair_, ie it should do something like
existing=$(find . -type f -name '*.pack')
and then do
for pack in $existing
do
index="$(basename $pack).idx"
if [ -f $index ] && [ "$pack"!= "$newpack" ]
then
rm -f "$pack" "$index"
fi
done
etc, exactly so that it would never remove anything that is getting
indexed or is otherwise half-way done, regardless of any other issues.
Hmm?
^ permalink raw reply
* [PATCH] index-pack: minor fixes to comment and function name
From: Nicolas Pitre @ 2006-10-27 20:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Use proper english. Be more exact in one comment.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/index-pack.c b/index-pack.c
index 5c747a6..3a389c1 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -324,8 +324,8 @@ static int find_delta(const union delta_
return -first-1;
}
-static int find_delta_childs(const union delta_base *base,
- int *first_index, int *last_index)
+static int find_delta_children(const union delta_base *base,
+ int *first_index, int *last_index)
{
int first = find_delta(base);
int last = first;
@@ -389,7 +389,7 @@ static void resolve_delta(struct object_
nr_resolved_deltas++;
hashcpy(delta_base.sha1, delta_obj->sha1);
- if (!find_delta_childs(&delta_base, &first, &last)) {
+ if (!find_delta_children(&delta_base, &first, &last)) {
for (j = first; j <= last; j++) {
struct object_entry *child = objects + deltas[j].obj_no;
if (child->real_type == OBJ_REF_DELTA)
@@ -399,7 +399,7 @@ static void resolve_delta(struct object_
memset(&delta_base, 0, sizeof(delta_base));
delta_base.offset = delta_obj->offset;
- if (!find_delta_childs(&delta_base, &first, &last)) {
+ if (!find_delta_children(&delta_base, &first, &last)) {
for (j = first; j <= last; j++) {
struct object_entry *child = objects + deltas[j].obj_no;
if (child->real_type == OBJ_OFS_DELTA)
@@ -429,7 +429,7 @@ static void parse_pack_objects(unsigned
* First pass:
* - find locations of all objects;
* - calculate SHA1 of all non-delta objects;
- * - remember base SHA1 for all deltas.
+ * - remember base (SHA1 or offset) for all deltas.
*/
if (verbose)
fprintf(stderr, "Indexing %d objects.\n", nr_objects);
@@ -489,10 +489,10 @@ static void parse_pack_objects(unsigned
if (obj->type == OBJ_REF_DELTA || obj->type == OBJ_OFS_DELTA)
continue;
hashcpy(base.sha1, obj->sha1);
- ref = !find_delta_childs(&base, &ref_first, &ref_last);
+ ref = !find_delta_children(&base, &ref_first, &ref_last);
memset(&base, 0, sizeof(base));
base.offset = obj->offset;
- ofs = !find_delta_childs(&base, &ofs_first, &ofs_last);
+ ofs = !find_delta_children(&base, &ofs_first, &ofs_last);
if (!ref && !ofs)
continue;
data = get_data_from_pack(obj);
@@ -615,7 +615,7 @@ static void fix_unresolved_deltas(int nr
else die("base object %s is of type '%s'",
sha1_to_hex(d->base.sha1), type);
- find_delta_childs(&d->base, &first, &last);
+ find_delta_children(&d->base, &first, &last);
for (j = first; j <= last; j++) {
struct object_entry *child = objects + deltas[j].obj_no;
^ permalink raw reply related
* Re: Generating docu in 1.4.3.3.g01929
From: Sean @ 2006-10-27 19:44 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git
In-Reply-To: <200610271726.k9RHQr0F024712@laptop13.inf.utfsm.cl>
On Fri, 27 Oct 2006 14:26:53 -0300
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> wrote:
> I'm getting lots of these after today's pull:
>
> asciidoc -b docbook -d manpage -f asciidoc.conf git-daemon.txt
> xmlto -m callouts.xsl man git-daemon.xml
> error : unterminated entity reference
> error : unterminated entity reference
> error : unterminated entity reference ...
> error : unterminated entity reference
> error : unterminated entity reference
> Writing git-daemon.1 for refentry
Can't reproduce this here on master or on next with:
asciidoc-7.1.2-0 and xmlto-0.0.18-13.1
Maybe this is an Asciidoc 8 issue, are you using it?
^ permalink raw reply
* [PATCH] enhance clone and fetch -k experience
From: Nicolas Pitre @ 2006-10-27 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Now that index-pack can be streamed with a pack, it is probably a good
idea to use it directly instead of creating a temporary file and running
index-pack afterwards. This way index-pack can abort early whenever a
corruption is encountered even if the pack has not been fully
downloaded, it can display a progress percentage as it knows how much to
expects, and it is a bit faster since the pack indexing is partially
done as data is received. Using fetch -k doesn't need to disable thin
pack generation on the remote end either.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/fetch-clone.c b/fetch-clone.c
index 76b99af..96cdab4 100644
--- a/fetch-clone.c
+++ b/fetch-clone.c
@@ -3,97 +3,6 @@
#include "pkt-line.h"
#include "sideband.h"
#include <sys/wait.h>
-#include <sys/time.h>
-
-static int finish_pack(const char *pack_tmp_name, const char *me)
-{
- int pipe_fd[2];
- pid_t pid;
- char idx[PATH_MAX];
- char final[PATH_MAX];
- char hash[41];
- unsigned char sha1[20];
- char *cp;
- int err = 0;
-
- if (pipe(pipe_fd) < 0)
- die("%s: unable to set up pipe", me);
-
- strcpy(idx, pack_tmp_name); /* ".git/objects/pack-XXXXXX" */
- cp = strrchr(idx, '/');
- memcpy(cp, "/pidx", 5);
-
- pid = fork();
- if (pid < 0)
- die("%s: unable to fork off git-index-pack", me);
- if (!pid) {
- close(0);
- dup2(pipe_fd[1], 1);
- close(pipe_fd[0]);
- close(pipe_fd[1]);
- execl_git_cmd("index-pack", "-o", idx, pack_tmp_name, NULL);
- error("cannot exec git-index-pack <%s> <%s>",
- idx, pack_tmp_name);
- exit(1);
- }
- close(pipe_fd[1]);
- if (read(pipe_fd[0], hash, 40) != 40) {
- error("%s: unable to read from git-index-pack", me);
- err = 1;
- }
- close(pipe_fd[0]);
-
- for (;;) {
- int status, code;
-
- if (waitpid(pid, &status, 0) < 0) {
- if (errno == EINTR)
- continue;
- error("waitpid failed (%s)", strerror(errno));
- goto error_die;
- }
- if (WIFSIGNALED(status)) {
- int sig = WTERMSIG(status);
- error("git-index-pack died of signal %d", sig);
- goto error_die;
- }
- if (!WIFEXITED(status)) {
- error("git-index-pack died of unnatural causes %d",
- status);
- goto error_die;
- }
- code = WEXITSTATUS(status);
- if (code) {
- error("git-index-pack died with error code %d", code);
- goto error_die;
- }
- if (err)
- goto error_die;
- break;
- }
- hash[40] = 0;
- if (get_sha1_hex(hash, sha1)) {
- error("git-index-pack reported nonsense '%s'", hash);
- goto error_die;
- }
- /* Now we have pack in pack_tmp_name[], and
- * idx in idx[]; rename them to their final names.
- */
- snprintf(final, sizeof(final),
- "%s/pack/pack-%s.pack", get_object_directory(), hash);
- move_temp_to_file(pack_tmp_name, final);
- chmod(final, 0444);
- snprintf(final, sizeof(final),
- "%s/pack/pack-%s.idx", get_object_directory(), hash);
- move_temp_to_file(idx, final);
- chmod(final, 0444);
- return 0;
-
- error_die:
- unlink(idx);
- unlink(pack_tmp_name);
- exit(1);
-}
static pid_t setup_sideband(int sideband, const char *me, int fd[2], int xd[2])
{
@@ -128,7 +37,7 @@ static pid_t setup_sideband(int sideband
return side_pid;
}
-int receive_unpack_pack(int xd[2], const char *me, int quiet, int sideband)
+static int get_pack(int xd[2], const char *me, int sideband, const char **argv)
{
int status;
pid_t pid, side_pid;
@@ -142,135 +51,37 @@ int receive_unpack_pack(int xd[2], const
dup2(fd[0], 0);
close(fd[0]);
close(fd[1]);
- execl_git_cmd("unpack-objects", quiet ? "-q" : NULL, NULL);
- die("git-unpack-objects exec failed");
+ execv_git_cmd(argv);
+ die("%s exec failed", argv[0]);
}
close(fd[0]);
close(fd[1]);
while (waitpid(pid, &status, 0) < 0) {
if (errno != EINTR)
- die("waiting for git-unpack-objects: %s",
- strerror(errno));
+ die("waiting for %s: %s", argv[0], strerror(errno));
}
if (WIFEXITED(status)) {
int code = WEXITSTATUS(status);
if (code)
- die("git-unpack-objects died with error code %d",
- code);
+ die("%s died with error code %d", argv[0], code);
return 0;
}
if (WIFSIGNALED(status)) {
int sig = WTERMSIG(status);
- die("git-unpack-objects died of signal %d", sig);
+ die("%s died of signal %d", argv[0], sig);
}
- die("git-unpack-objects died of unnatural causes %d", status);
+ die("%s died of unnatural causes %d", argv[0], status);
}
-/*
- * We average out the download speed over this many "events", where
- * an event is a minimum of about half a second. That way, we get
- * a reasonably stable number.
- */
-#define NR_AVERAGE (4)
-
-/*
- * A "binary msec" is a power-of-two-msec, aka 1/1024th of a second.
- * Keeping the time in that format means that "bytes / msecs" means
- * the same as kB/s (modulo rounding).
- *
- * 1000512 is a magic number (usecs in a second, rounded up by half
- * of 1024, to make "rounding" come out right ;)
- */
-#define usec_to_binarymsec(x) ((int)(x) / (1000512 >> 10))
+int receive_unpack_pack(int xd[2], const char *me, int quiet, int sideband)
+{
+ const char *argv[3] = { "unpack-objects", quiet ? "-q" : NULL, NULL };
+ return get_pack(xd, me, sideband, argv);
+}
int receive_keep_pack(int xd[2], const char *me, int quiet, int sideband)
{
- char tmpfile[PATH_MAX];
- int ofd, ifd, fd[2];
- unsigned long total;
- static struct timeval prev_tv;
- struct average {
- unsigned long bytes;
- unsigned long time;
- } download[NR_AVERAGE] = { {0, 0}, };
- unsigned long avg_bytes, avg_time;
- int idx = 0;
-
- setup_sideband(sideband, me, fd, xd);
-
- ifd = fd[0];
- snprintf(tmpfile, sizeof(tmpfile),
- "%s/pack/tmp-XXXXXX", get_object_directory());
- ofd = mkstemp(tmpfile);
- if (ofd < 0)
- return error("unable to create temporary file %s", tmpfile);
-
- gettimeofday(&prev_tv, NULL);
- total = 0;
- avg_bytes = 0;
- avg_time = 0;
- while (1) {
- char buf[8192];
- ssize_t sz, wsz, pos;
- sz = read(ifd, buf, sizeof(buf));
- if (sz == 0)
- break;
- if (sz < 0) {
- if (errno != EINTR && errno != EAGAIN) {
- error("error reading pack (%s)", strerror(errno));
- close(ofd);
- unlink(tmpfile);
- return -1;
- }
- sz = 0;
- }
- pos = 0;
- while (pos < sz) {
- wsz = write(ofd, buf + pos, sz - pos);
- if (wsz < 0) {
- error("error writing pack (%s)",
- strerror(errno));
- close(ofd);
- unlink(tmpfile);
- return -1;
- }
- pos += wsz;
- }
- total += sz;
- if (!quiet) {
- static unsigned long last;
- struct timeval tv;
- unsigned long diff = total - last;
- /* not really "msecs", but a power-of-two millisec (1/1024th of a sec) */
- unsigned long msecs;
-
- gettimeofday(&tv, NULL);
- msecs = tv.tv_sec - prev_tv.tv_sec;
- msecs <<= 10;
- msecs += usec_to_binarymsec(tv.tv_usec - prev_tv.tv_usec);
-
- if (msecs > 500) {
- prev_tv = tv;
- last = total;
-
- /* Update averages ..*/
- avg_bytes += diff;
- avg_time += msecs;
- avg_bytes -= download[idx].bytes;
- avg_time -= download[idx].time;
- download[idx].bytes = diff;
- download[idx].time = msecs;
- idx++;
- if (idx >= NR_AVERAGE)
- idx = 0;
-
- fprintf(stderr, "%4lu.%03luMB (%lu kB/s) \r",
- total >> 20,
- 1000*((total >> 10) & 1023)>>10,
- avg_bytes / avg_time );
- }
- }
- }
- close(ofd);
- return finish_pack(tmpfile, me);
+ const char *argv[5] = { "index-pack", "--stdin", "--fix-thin",
+ quiet ? NULL : "-v", NULL };
+ return get_pack(xd, me, sideband, argv);
}
diff --git a/fetch-pack.c b/fetch-pack.c
index 90b7940..36ea092 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -518,8 +518,6 @@ int main(int argc, char **argv)
}
if (!dest)
usage(fetch_pack_usage);
- if (keep_pack)
- use_thin_pack = 0;
pid = git_connect(fd, dest, exec);
if (pid < 0)
^ permalink raw reply related
* Re: Question on multi-level git repository heiarchy.
From: linux @ 2006-10-27 19:26 UTC (permalink / raw)
To: greearb; +Cc: git
The thing to learn is that the operation you are trying to perform
is called "fetch", not "pull". Pull = fetch + merge.
In fact, the "fetch" part of "git pull" is optional, so it's
best to think of "git pull" as the fundamental *merge* operation.
("git merge" is a helper that you probably don't want to use directly.)
There's a valid argument that this is not good terminology (especially
because "push" is the opposite of "fetch"!), but without getting
into that discussion, there are two ways to do a merge:
- The small-steps way.
git fetch remote
git pull . remoteorigin
- The bold, all-at-once way
git pull remote remoteorigin
The former acutally gives a local name to the remote branch,
then merges it in in a second step.
The latter is what folks like Linus do who aren't carefully following
remote development, but just want to merge it in. It's better for
one-off access to remote development, because it doesn't clutter your
reporistory with a remote branch name that you're not going to use again.
Generally, I always do the former, and I recommend you do too, until
you're comfortable with making such big leaps.
Just remember:
1) "git fetch" copies from the remote repository to the local one.
This doesn't change anything locally except for branch heads that
it's supposed to. And even there, it's careful.
In particular, "git fetch" will refuse to modify the current HEAD.
2) "git pull" actually does a merge. This *does* change the current
HEAD. It creates a new commit on the HEAD branch unless:
- HEAD is already up to date, or
- HEAD can be fast-forwarded, or
- The merge fails.
^ permalink raw reply
* Re: StGit-enabled bash-prompt
From: Robin Rosenberg @ 2006-10-27 18:54 UTC (permalink / raw)
To: Ben Clifford; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610270957020.9123@dildano.hawaga.org.uk>
fredag 27 oktober 2006 12:01 skrev Ben Clifford:
> On Thu, 26 Oct 2006, Robin Rosenberg wrote:
> > Of course you will read and understand this code. I don't know how good
> > an idea it is to use the DEBUG trap this way.
>
> I set my prompt without using it, with something approximating this
> being defined in my .bash_profile. I think the use of ' instead of "
> causes evaluation of __prompt_githead be delayed until the prompt is
> displayed.
Ahh, ofcourse. Thanks.
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Junio C Hamano @ 2006-10-27 18:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: Shawn Pearce, Eran Tromer, git
In-Reply-To: <20061027143854.GC20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Fri, Oct 27, 2006 at 04:27:05PM CEST, I got a letter
> where Nicolas Pitre <nico@cam.org> said that...
>> On Thu, 26 Oct 2006, Shawn Pearce wrote:
>> > OK so the repository won't get corrupted but the repack would be
>> > forced to abort.
>>
>> Maybe this is the best way out? Abort git-repack with "a fetch is in
>> progress -- retry later". No one will really suffer if the repack has
>> to wait for the next scheduled cron job, especially if the fetch doesn't
>> explode packs into loose objects anymore.
>
> I don't really like this that much. Big projects can have 10 commits per
> hour on average, and they also take potentially long time to repack, so
> you might get to never really repack them.
One question about that statistics is if the frequency of 10
commits per hour is 10 pushes into the central repository per
hour or 10 commits distributed all over the world in dozens of
developers' repositories.
Even if the number is 10 pushes into the central repository per
hour, I do not see it as a big problem in practice from the
workflow point of view. Even people sticking to their CVS
workflow to have a central repository model are gaining big time
from being able to keep working disconnected by switching to git
using the shared repository mode, and it should not be a big
deal if the central repository master shuts down pushes into the
repository for N minutes a day for scheduled repacking. So it
could be that a more practical way out is to say "'repack -a -d'
and 'prune' are to be run when things are quiescent".
A cron job for the scheduled repack/prune can set a flag
(repository wide lockfile or something) to ask new push/fetch to
wait and come back later, and we could set up a pre-* hooks for
push/fetch to notice it. While push/fetch processes that have
already been started can still interfere, as long as they cause
repack/prune to fail the "deletion" part, eventually outstanding
push/fetch will die out and the cron job will have that
quiescent window.
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Luben Tuikov @ 2006-10-27 17:45 UTC (permalink / raw)
To: Junio C Hamano, Andreas Ericsson; +Cc: git
In-Reply-To: <7vac3igjpd.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
> > Alex Riesen wrote:
> >>>> >Which leads us to the always interesting, fun and exciting:
> >>>> >
> >>>> > git ls-tree -r HEAD | git update-index --index-info
> >>>> >
> >>>> >which will undo everything except 'git add' from the index, as
> >>>> >ls-tree -r is listing everything in the last commit.
> >>>> >
> >>>>
> >>>> ... and also shows The Power of the Pipe, which Daniel@google was
> >>>> missing in recent versions of git. ;-)
> >>>>
> >>>> Btw, this is most definitely not a documented thing and requires a bit
> >>>> of core git knowledge, so perhaps the "shell-scripts were good for
> >>>> hackers to learn what to pipe where" really *is* a very important point.
> >>>
> >>> Agreed.
> >>
> >> Still, it is very impressive, it is supported (and will be
> >> supported, I assume),
> >> and as such - worth mentioning at least in these examples everyone keeps
> >> dreaming about. Until that happened, why not mention that the output
> >> of "git ls-tree" is compatible with --index-info of "update-index"?
> >
> > +1. Me likes, although I would amend the command-line that Shawn sent
> > and describe what it does. Examples > descriptions everywhere else in
> > the git docs, so it would be concise to do so.
>
> I do not like the one that does the whole tree that much. I
> would think "git-read-tree -m HEAD" would be simpler and more
Yep, that's what I use... "git-undo-update-index" is
#!/bin/sh
git-read-tree -m -i HEAD
Luben
> efficient if you are reverting the whole tree.
>
> On the other hand, I designed --index-info to be compatible with
> ls-tree output (it is not an accident, it was designed). In
>
> git ls-tree HEAD frotz | git update-index --index-info
>
> "frotz" part does not have to be the exact path but can be a
> directory name. It means "revert everything in this directory".
>
> This is quite heavy-handed and you would probably want to run
> update-index --refresh afterwards.
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Generating docu in 1.4.3.3.g01929
From: Horst H. von Brand @ 2006-10-27 17:26 UTC (permalink / raw)
To: git
I'm getting lots of these after today's pull:
asciidoc -b docbook -d manpage -f asciidoc.conf git-daemon.txt
xmlto -m callouts.xsl man git-daemon.xml
error : unterminated entity reference
error : unterminated entity reference
error : unterminated entity reference ...
error : unterminated entity reference
error : unterminated entity reference
Writing git-daemon.1 for refentry
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Nicolas Pitre @ 2006-10-27 17:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sean, Shawn Pearce, Eran Tromer, git
In-Reply-To: <7viri6i6uu.fsf@assigned-by-dhcp.cox.net>
On Thu, 26 Oct 2006, Junio C Hamano wrote:
> I'd almost say "heavy repository-wide operations like 'repack -a
> -d' and 'prune' should operate under a single repository lock",
> but historically we've avoided locks and instead tried to do
> things optimistically and used compare-and-swap to detect
> conflicts, so maybe that avenue might be worth pursuing.
>
> How about (I'm thinking aloud and I'm sure there will be
> holes -- I won't think about prune for now)...
>
> * "repack -a -d":
>
> (1) initially run show-ref (or "ls-remote .") and store the
> result in .git/$ref_pack_lock_file;
>
> (2) enumerate existing packs;
>
> (3) do the usual "rev-list --all | pack-objects" thing; this
> may end up including more objects than what are reachable
> from the result of (1) if somebody else updates refs in the
> meantime;
>
> (4) enumerate existing packs; if there is difference from (2)
> other than what (3) created, that means somebody else added
> a pack in the meantime; stop and do not do the "-d" part;
>
> (5) run "ls-remote ." again and compare it with what it got in
> (1); if different, somebody else updated a ref in the
> meantime; stop and do not do the "-d" part;
>
> (6) do the "-d" part as usual by removing packs we saw in (2)
> but do not remove the pack we created in (3);
>
> (7) remove .git/$ref_pack_lock_file.
>
> * "fetch --thin" and "index-pack --stdin":
>
> (1) check the .git/$ref_pack_lock_file, and refuse to operate
> if there is such (this is not strictly needed for
> correctness but only to give an early exit);
I don't think this is a good idea. A fetch should always work
irrespective of any repack taking place. The fetch really should have
priority over a repack since it is directly related to the user
experience. The repack can fail or produce suboptimal results if a race
occurs, but the fetch must not fail for such a reason.
> (2) create a new pack under a temporary name, and when
> complete, make the pack/index pair .pack and .idx;
Actually this is what already happens if you don't specify a name to
git-index-pack --stdin.
> (3) update the refs.
So the actual race is the really small interval between the time the new
pack+index are moved to .git/objects/pack/ and the moment the refs are
updated. In practice this is probably less than a second. All that is
needed here is to somehow go back to (2) if that interval occurs between
(2) and (3).
^ permalink raw reply
* Re: Creating new repos
From: Horst H. von Brand @ 2006-10-27 17:08 UTC (permalink / raw)
To: Petr Baudis; +Cc: Horst H. von Brand, git
In-Reply-To: <20061027123918.GB20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Fri, Oct 27, 2006 at 02:29:10PM CEST, I got a letter
> where "Horst H. von Brand" <vonbrand@inf.utfsm.cl> said that...
> > I'm trying to set up git repos for remote access here. I set up git-daemon
> > and got it working (some older repositories do work fine), but now:
> >
> > $ mkdir /var/scm/user/SomeRepo.git
> > $ cd /var/scm/user/SomeRepo.git
> > $ git --bare init-db
> > $ touch git-daemon-export-ok
> >
> > All OK, but then, from a remote machine:
> >
> > $ git clone git://git-server/user/SomeRepo.git
> > fatal: no matching remote head
> > fetch-pack from 'git://git-server/user/Test.git' failed.
> > The empty repo created by init-db should be cloneable, so as to get the
> > ball rolling easily.
> Well there's really nothing to clone, so it's tough. :-) What would such
> a clone be supposed to do? It has no branches to record as belonging to
> origin, and note that Git's git-clone is long-term broken in the sense
> that it won't pick new branches as they appear in the remote
> repository. So a clone of an empty repository would be useless anyway.
As useless as the empty set? ;-)
> > You can't push into such an empty repository either.
>
> This is supposed to work. What error do you get?
Pilot error. Sorry for the noise.
> > Any suggestion of how to set up a server into which users can create their
> > own repos /without/ giving out full shell accounts?
>
> Sure:
>
> http://repo.or.cz/w/repo.git
Cloning...
"error: Can't lock ref" (?)
OK, got it; the repo is at git://repo.or.cz/repo.git. Better not calling it
*.git
> But it may be quite an overkill for you. ;-)
Will see.
> If you want them to be able to do it over ssh, you would need to provide
> a trusted tool which would manage the repository setup, that means not
> only doing init-db, but also managing the export-ok files, description
> file, you'd likely want to enable the post-update hook (but probably not
> any other hook or let the user edit it since at that point you've given
> him full shell access), etc. And the tool would have to be carefully
> reviewed since it's security-critical.
I was fearing something along these lines...
> > Also, the behaviour of git-daemon is different when using git or ssh+git,
> > you need to give the full path for the later but not the former (given
> > --base-path=/var/scm):
> >
> > git://git-server/user/Test.git
> > ssh+git://git-server/var/scm/user/Test.git
> >
> > Is this intentional?
>
> git+ssh has nothing to do with git-daemon, it's executing other git
> commands remotely.
OK. But from an UI POW it is confusing.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: J. Bruce Fields @ 2006-10-27 16:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: Nicolas Pitre, Shawn Pearce, Eran Tromer, Junio C Hamano, git
In-Reply-To: <20061027160450.GA3670@fieldses.org>
On Fri, Oct 27, 2006 at 12:04:50PM -0400, bfields wrote:
> I think if you expect x commits per hour, and need y hours to prune,
> then you should be able to get a worst-case estimate of hours between
> y-hour gaps from
>
> octave -q --eval "1/poisscdf(0,x/y)"
Uh, sorry, that should be x*y, not x/y....
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: J. Bruce Fields @ 2006-10-27 16:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Nicolas Pitre, Shawn Pearce, Eran Tromer, Junio C Hamano, git
In-Reply-To: <20061027150334.GD20017@pasky.or.cz>
On Fri, Oct 27, 2006 at 05:03:34PM +0200, Petr Baudis wrote:
> Dear diary, on Fri, Oct 27, 2006 at 04:48:39PM CEST, I got a letter
> where "J. Bruce Fields" <bfields@fieldses.org> said that...
Ya know, it'd be cool if that fit on one line....
> > On Fri, Oct 27, 2006 at 04:38:54PM +0200, Petr Baudis wrote:
> > > I don't really like this that much. Big projects can have 10 commits per
> > > hour on average, and they also take potentially long time to repack, so
> > > you might get to never really repack them.
> >
> > An average of 10 per minute doesn't mean there aren't frequent long idle
> > times. That commit traffic is probably extremely bursty, right?
>
> 10 per _hour_. :-)
Whoops, right.
> E.g. GNOME is 7 commits per hour average, and it does tend to be pretty
> spread out:
>
> http://cia.navi.cx/stats/project/gnome
>
> (Unfortunately I can't figure out how to squeeze more commits from the
> web interface. KDE gets even more commits than GNOME and Gentoo tops
> all the CIA-tracked projects.)
That's not enough to tell how long on average you'd have to wait for a
gap of a certain length.
I think if you expect x commits per hour, and need y hours to prune,
then you should be able to get a worst-case estimate of hours between
y-hour gaps from
octave -q --eval "1/poisscdf(0,x/y)"
but my statistics isn't great, so maybe that's not quite right.
And in any case the commit arrival times are probably very far from
independent, which probably makes gaps more likely.
^ permalink raw reply
* Re: Question on multi-level git repository heiarchy.
From: Andy Parkins @ 2006-10-27 15:31 UTC (permalink / raw)
To: git
In-Reply-To: <4542120E.1050903@candelatech.com>
On Friday 2006 October 27 15:05, Ben Greear wrote:
> I want to synchronize the entire git repo, including all branches. How
> would I go
> about doing that?
That happens anyway. "git pull" is actually a fetch + a merge. Personally I
recommend never doing a "git pull" without arguments. Instead:
First, update every "Pull:" line from .git/remotes/origin
$ git fetch
Now manually merge one of the (now locally stored) upstream trees into your
working tree.
$ git pull . upstream-tree
> Is there any way to recover my currently mangled tree on the
> workstation, or do I need
> to start fresh there? If I start fresh, do I re-clone, or is there some
> better way to get
I'm relatively new to git; my experience is that there is very little that
can't be undone. Exactly what sort of mangling has happened to your tree?
If you've got yourself in a real state, I suggest editing .git/remotes/origin
to pull the upstream trees to some newly named branches (maybe just
add "new/" to the front of them). Treat those as read-only (i.e. don't check
them out), and start comparing branches. "gitk --all" is incredibly useful
for this.
Make yourself a new branch for your own work based off a new/upstream branch
(git checkout -b fixthings new/upstream), then use git-cherry-pick to pull
your patches out of your mangled tree to build up a branch with your changes
on it.
Now, you can delete all the branches that you think are mangled and (if you
really want to), rename all the new/ refs back to whatever they started as.
> the synchronization that I want?
I am going to guess that you've fallen for the same thing I did at first:
confusing "git pull" with "git fetch"; "git pull" can get you in
trouble, "git fetch" probably won't.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Petr Baudis @ 2006-10-27 15:03 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Nicolas Pitre, Shawn Pearce, Eran Tromer, Junio C Hamano, git
In-Reply-To: <20061027144839.GB32451@fieldses.org>
Dear diary, on Fri, Oct 27, 2006 at 04:48:39PM CEST, I got a letter
where "J. Bruce Fields" <bfields@fieldses.org> said that...
> On Fri, Oct 27, 2006 at 04:38:54PM +0200, Petr Baudis wrote:
> > I don't really like this that much. Big projects can have 10 commits per
> > hour on average, and they also take potentially long time to repack, so
> > you might get to never really repack them.
>
> An average of 10 per minute doesn't mean there aren't frequent long idle
> times. That commit traffic is probably extremely bursty, right?
10 per _hour_. :-)
E.g. GNOME is 7 commits per hour average, and it does tend to be pretty
spread out:
http://cia.navi.cx/stats/project/gnome
(Unfortunately I can't figure out how to squeeze more commits from the
web interface. KDE gets even more commits than GNOME and Gentoo tops
all the CIA-tracked projects.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: J. Bruce Fields @ 2006-10-27 14:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: Nicolas Pitre, Shawn Pearce, Eran Tromer, Junio C Hamano, git
In-Reply-To: <20061027143854.GC20017@pasky.or.cz>
On Fri, Oct 27, 2006 at 04:38:54PM +0200, Petr Baudis wrote:
> I don't really like this that much. Big projects can have 10 commits per
> hour on average, and they also take potentially long time to repack, so
> you might get to never really repack them.
An average of 10 per minute doesn't mean there aren't frequent long idle
times. That commit traffic is probably extremely bursty, right?
^ permalink raw reply
* Re: VCS comparison table
From: J. Bruce Fields @ 2006-10-27 14:46 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Horst H. von Brand, Jakub Narebski, git, bazaar-ng
In-Reply-To: <4541D291.5020205@op5.se>
On Fri, Oct 27, 2006 at 11:34:09AM +0200, Andreas Ericsson wrote:
> Horst H. von Brand wrote:
> >Jakub Narebski <jnareb@gmail.com> wrote:
> >>19. Ease of Use. Hmmm... I don't know for Git. I personally find it very
> >>easy to use, but I have not much experiences with other SCM. I wonder why
> >>Bazaar has "No" there...
> >
> >Extremely subjective. Easy to learn doesn't cut it either.
>
> This one just needs to go.
It's certainly a hard question to answer, and will never be answered
completely, but unfortunately it's also a really *important* question.
The best SCM in the world isn't much use if I can't convince my
coworkers to learn the thing.
So I think it's helpful to attempt to find out whether we have a problem
here or not, even if the problem is more one of perception than reality.
Though obviously it would be more helpful to have something more
detailed than just a yes or no answer to "is git easy to use?"
> Could possibly be replaced with "Has tutorial/documentation online" or
> some such. No SCM is really intuitive to users that haven't
> experienced any of them before, so the only thing that really matters
> is how much documentation one can find online and how up-to-date it
> is.
Documentation helps, though sometimes extensive documentation is a sign
of a problem--it takes a lot more documentation to explain how to manage
a branch in CVS than it does in any sensible system....
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Petr Baudis @ 2006-10-27 14:38 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn Pearce, Eran Tromer, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610271022240.11384@xanadu.home>
Dear diary, on Fri, Oct 27, 2006 at 04:27:05PM CEST, I got a letter
where Nicolas Pitre <nico@cam.org> said that...
> On Thu, 26 Oct 2006, Shawn Pearce wrote:
> > OK so the repository won't get corrupted but the repack would be
> > forced to abort.
>
> Maybe this is the best way out? Abort git-repack with "a fetch is in
> progress -- retry later". No one will really suffer if the repack has
> to wait for the next scheduled cron job, especially if the fetch doesn't
> explode packs into loose objects anymore.
I don't really like this that much. Big projects can have 10 commits per
hour on average, and they also take potentially long time to repack, so
you might get to never really repack them.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ 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