2005-07-04 22:26:53 +02:00
|
|
|
#include "cache.h"
|
|
|
|
|
#include "refs.h"
|
|
|
|
|
#include "pkt-line.h"
|
2006-09-10 12:20:24 +02:00
|
|
|
#include "sideband.h"
|
2005-10-14 03:57:40 +02:00
|
|
|
#include "tag.h"
|
|
|
|
|
#include "object.h"
|
2005-10-28 04:48:32 +02:00
|
|
|
#include "commit.h"
|
2006-01-11 03:12:17 +01:00
|
|
|
#include "exec_cmd.h"
|
2006-10-30 20:08:43 +01:00
|
|
|
#include "diff.h"
|
|
|
|
|
#include "revision.h"
|
|
|
|
|
#include "list-objects.h"
|
2007-10-19 21:47:59 +02:00
|
|
|
#include "run-command.h"
|
2005-07-04 22:26:53 +02:00
|
|
|
|
2010-10-08 19:31:15 +02:00
|
|
|
static const char upload_pack_usage[] = "git upload-pack [--strict] [--timeout=<n>] <dir>";
|
2005-07-04 22:26:53 +02:00
|
|
|
|
2006-07-06 06:28:20 +02:00
|
|
|
/* bits #0..7 in revision.h, #8..10 in commit.c */
|
|
|
|
|
#define THEY_HAVE (1u << 11)
|
|
|
|
|
#define OUR_REF (1u << 12)
|
|
|
|
|
#define WANTED (1u << 13)
|
|
|
|
|
#define COMMON_KNOWN (1u << 14)
|
|
|
|
|
#define REACHABLE (1u << 15)
|
|
|
|
|
|
2006-10-30 20:09:53 +01:00
|
|
|
#define SHALLOW (1u << 16)
|
|
|
|
|
#define NOT_SHALLOW (1u << 17)
|
|
|
|
|
#define CLIENT_SHALLOW (1u << 18)
|
|
|
|
|
|
2006-11-24 11:34:27 +01:00
|
|
|
static unsigned long oldest_have;
|
2006-07-06 06:28:20 +02:00
|
|
|
|
2006-08-15 19:23:48 +02:00
|
|
|
static int multi_ack, nr_our_refs;
|
2011-03-29 21:29:10 +02:00
|
|
|
static int no_done;
|
2008-03-04 04:27:33 +01:00
|
|
|
static int use_thin_pack, use_ofs_delta, use_include_tag;
|
2009-06-16 20:41:16 +02:00
|
|
|
static int no_progress, daemon_mode;
|
2009-06-10 01:50:18 +02:00
|
|
|
static int shallow_nr;
|
2006-07-06 03:00:02 +02:00
|
|
|
static struct object_array have_obj;
|
|
|
|
|
static struct object_array want_obj;
|
2009-09-04 01:08:33 +02:00
|
|
|
static struct object_array extra_edge_obj;
|
2006-08-15 19:23:48 +02:00
|
|
|
static unsigned int timeout;
|
2006-09-11 01:27:08 +02:00
|
|
|
/* 0 for no sideband,
|
|
|
|
|
* otherwise maximum packet size (up to 65520 bytes).
|
|
|
|
|
*/
|
2006-08-15 19:23:48 +02:00
|
|
|
static int use_sideband;
|
2008-03-03 03:35:18 +01:00
|
|
|
static int debug_fd;
|
2009-10-31 01:47:33 +01:00
|
|
|
static int advertise_refs;
|
|
|
|
|
static int stateless_rpc;
|
2005-10-19 23:27:01 +02:00
|
|
|
|
|
|
|
|
static void reset_timeout(void)
|
|
|
|
|
{
|
|
|
|
|
alarm(timeout);
|
|
|
|
|
}
|
2005-07-05 00:29:17 +02:00
|
|
|
|
2005-07-05 01:35:13 +02:00
|
|
|
static int strip(char *line, int len)
|
|
|
|
|
{
|
|
|
|
|
if (len && line[len-1] == '\n')
|
|
|
|
|
line[--len] = 0;
|
|
|
|
|
return len;
|
|
|
|
|
}
|
|
|
|
|
|
2006-06-21 09:30:21 +02:00
|
|
|
static ssize_t send_client_data(int fd, const char *data, ssize_t sz)
|
|
|
|
|
{
|
2006-09-10 12:20:24 +02:00
|
|
|
if (use_sideband)
|
2006-09-11 01:27:08 +02:00
|
|
|
return send_sideband(1, fd, data, sz, use_sideband);
|
2006-09-10 12:20:24 +02:00
|
|
|
if (fd == 3)
|
|
|
|
|
/* emergency quit */
|
|
|
|
|
fd = 2;
|
|
|
|
|
if (fd == 2) {
|
2007-01-08 16:58:23 +01:00
|
|
|
/* XXX: are we happy to lose stuff here? */
|
2006-09-10 12:20:24 +02:00
|
|
|
xwrite(fd, data, sz);
|
|
|
|
|
return sz;
|
2006-06-21 09:30:21 +02:00
|
|
|
}
|
2006-09-10 12:20:24 +02:00
|
|
|
return safe_write(fd, data, sz);
|
2006-06-21 09:30:21 +02:00
|
|
|
}
|
|
|
|
|
|
2007-06-08 11:54:57 +02:00
|
|
|
static FILE *pack_pipe = NULL;
|
2009-04-06 21:28:36 +02:00
|
|
|
static void show_commit(struct commit *commit, void *data)
|
2006-10-30 20:08:43 +01:00
|
|
|
{
|
|
|
|
|
if (commit->object.flags & BOUNDARY)
|
|
|
|
|
fputc('-', pack_pipe);
|
|
|
|
|
if (fputs(sha1_to_hex(commit->object.sha1), pack_pipe) < 0)
|
|
|
|
|
die("broken output pipe");
|
|
|
|
|
fputc('\n', pack_pipe);
|
|
|
|
|
fflush(pack_pipe);
|
|
|
|
|
free(commit->buffer);
|
|
|
|
|
commit->buffer = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
show_object(): push path_name() call further down
In particular, pushing the "path_name()" call _into_ the show() function
would seem to allow
- more clarity into who "owns" the name (ie now when we free the name in
the show_object callback, it's because we generated it ourselves by
calling path_name())
- not calling path_name() at all, either because we don't care about the
name in the first place, or because we are actually happy walking the
linked list of "struct name_path *" and the last component.
Now, I didn't do that latter optimization, because it would require some
more coding, but especially looking at "builtin-pack-objects.c", we really
don't even want the whole pathname, we really would be better off with the
list of path components.
Why? We use that name for two things:
- add_preferred_base_object(), which actually _wants_ to traverse the
path, and now does it by looking for '/' characters!
- for 'name_hash()', which only cares about the last 16 characters of a
name, so again, generating the full name seems to be just unnecessary
work.
Anyway, so I didn't look any closer at those things, but it did convince
me that the "show_object()" calling convention was crazy, and we're
actually better off doing _less_ in list-objects.c, and giving people
access to the internal data structures so that they can decide whether
they want to generate a path-name or not.
This patch does that, and then for people who did use the name (even if
they might do something more clever in the future), it just does the
straightforward "name = path_name(path, component); .. free(name);" thing.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-11 03:15:26 +02:00
|
|
|
static void show_object(struct object *obj, const struct name_path *path, const char *component)
|
2006-10-30 20:08:43 +01:00
|
|
|
{
|
|
|
|
|
/* An object with name "foo\n0000000..." can be used to
|
|
|
|
|
* confuse downstream git-pack-objects very badly.
|
|
|
|
|
*/
|
show_object(): push path_name() call further down
In particular, pushing the "path_name()" call _into_ the show() function
would seem to allow
- more clarity into who "owns" the name (ie now when we free the name in
the show_object callback, it's because we generated it ourselves by
calling path_name())
- not calling path_name() at all, either because we don't care about the
name in the first place, or because we are actually happy walking the
linked list of "struct name_path *" and the last component.
Now, I didn't do that latter optimization, because it would require some
more coding, but especially looking at "builtin-pack-objects.c", we really
don't even want the whole pathname, we really would be better off with the
list of path components.
Why? We use that name for two things:
- add_preferred_base_object(), which actually _wants_ to traverse the
path, and now does it by looking for '/' characters!
- for 'name_hash()', which only cares about the last 16 characters of a
name, so again, generating the full name seems to be just unnecessary
work.
Anyway, so I didn't look any closer at those things, but it did convince
me that the "show_object()" calling convention was crazy, and we're
actually better off doing _less_ in list-objects.c, and giving people
access to the internal data structures so that they can decide whether
they want to generate a path-name or not.
This patch does that, and then for people who did use the name (even if
they might do something more clever in the future), it just does the
straightforward "name = path_name(path, component); .. free(name);" thing.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-11 03:15:26 +02:00
|
|
|
const char *name = path_name(path, component);
|
process_{tree,blob}: show objects without buffering
Here's a less trivial thing, and slightly more dubious one.
I was looking at that "struct object_array objects", and wondering why we
do that. I have honestly totally forgotten. Why not just call the "show()"
function as we encounter the objects? Rather than add the objects to the
object_array, and then at the very end going through the array and doing a
'show' on all, just do things more incrementally.
Now, there are possible downsides to this:
- the "buffer using object_array" _can_ in theory result in at least
better I-cache usage (two tight loops rather than one more spread out
one). I don't think this is a real issue, but in theory..
- this _does_ change the order of the objects printed. Instead of doing a
"process_tree(revs, commit->tree, &objects, NULL, "");" in the loop
over the commits (which puts all the root trees _first_ in the object
list, this patch just adds them to the list of pending objects, and
then we'll traverse them in that order (and thus show each root tree
object together with the objects we discover under it)
I _think_ the new ordering actually makes more sense, but the object
ordering is actually a subtle thing when it comes to packing
efficiency, so any change in order is going to have implications for
packing. Good or bad, I dunno.
- There may be some reason why we did it that odd way with the object
array, that I have simply forgotten.
Anyway, now that we don't buffer up the objects before showing them
that may actually result in lower memory usage during that whole
traverse_commit_list() phase.
This is seriously not very deeply tested. It makes sense to me, it seems
to pass all the tests, it looks ok, but...
Does anybody remember why we did that "object_array" thing? It used to be
an "object_list" a long long time ago, but got changed into the array due
to better memory usage patterns (those linked lists of obejcts are
horrible from a memory allocation standpoint). But I wonder why we didn't
do this back then. Maybe there's a reason for it.
Or maybe there _used_ to be a reason, and no longer is.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-11 02:27:58 +02:00
|
|
|
const char *ep = strchr(name, '\n');
|
2006-10-30 20:08:43 +01:00
|
|
|
if (ep) {
|
process_{tree,blob}: show objects without buffering
Here's a less trivial thing, and slightly more dubious one.
I was looking at that "struct object_array objects", and wondering why we
do that. I have honestly totally forgotten. Why not just call the "show()"
function as we encounter the objects? Rather than add the objects to the
object_array, and then at the very end going through the array and doing a
'show' on all, just do things more incrementally.
Now, there are possible downsides to this:
- the "buffer using object_array" _can_ in theory result in at least
better I-cache usage (two tight loops rather than one more spread out
one). I don't think this is a real issue, but in theory..
- this _does_ change the order of the objects printed. Instead of doing a
"process_tree(revs, commit->tree, &objects, NULL, "");" in the loop
over the commits (which puts all the root trees _first_ in the object
list, this patch just adds them to the list of pending objects, and
then we'll traverse them in that order (and thus show each root tree
object together with the objects we discover under it)
I _think_ the new ordering actually makes more sense, but the object
ordering is actually a subtle thing when it comes to packing
efficiency, so any change in order is going to have implications for
packing. Good or bad, I dunno.
- There may be some reason why we did it that odd way with the object
array, that I have simply forgotten.
Anyway, now that we don't buffer up the objects before showing them
that may actually result in lower memory usage during that whole
traverse_commit_list() phase.
This is seriously not very deeply tested. It makes sense to me, it seems
to pass all the tests, it looks ok, but...
Does anybody remember why we did that "object_array" thing? It used to be
an "object_list" a long long time ago, but got changed into the array due
to better memory usage patterns (those linked lists of obejcts are
horrible from a memory allocation standpoint). But I wonder why we didn't
do this back then. Maybe there's a reason for it.
Or maybe there _used_ to be a reason, and no longer is.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-11 02:27:58 +02:00
|
|
|
fprintf(pack_pipe, "%s %.*s\n", sha1_to_hex(obj->sha1),
|
|
|
|
|
(int) (ep - name),
|
|
|
|
|
name);
|
2006-10-30 20:08:43 +01:00
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
fprintf(pack_pipe, "%s %s\n",
|
process_{tree,blob}: show objects without buffering
Here's a less trivial thing, and slightly more dubious one.
I was looking at that "struct object_array objects", and wondering why we
do that. I have honestly totally forgotten. Why not just call the "show()"
function as we encounter the objects? Rather than add the objects to the
object_array, and then at the very end going through the array and doing a
'show' on all, just do things more incrementally.
Now, there are possible downsides to this:
- the "buffer using object_array" _can_ in theory result in at least
better I-cache usage (two tight loops rather than one more spread out
one). I don't think this is a real issue, but in theory..
- this _does_ change the order of the objects printed. Instead of doing a
"process_tree(revs, commit->tree, &objects, NULL, "");" in the loop
over the commits (which puts all the root trees _first_ in the object
list, this patch just adds them to the list of pending objects, and
then we'll traverse them in that order (and thus show each root tree
object together with the objects we discover under it)
I _think_ the new ordering actually makes more sense, but the object
ordering is actually a subtle thing when it comes to packing
efficiency, so any change in order is going to have implications for
packing. Good or bad, I dunno.
- There may be some reason why we did it that odd way with the object
array, that I have simply forgotten.
Anyway, now that we don't buffer up the objects before showing them
that may actually result in lower memory usage during that whole
traverse_commit_list() phase.
This is seriously not very deeply tested. It makes sense to me, it seems
to pass all the tests, it looks ok, but...
Does anybody remember why we did that "object_array" thing? It used to be
an "object_list" a long long time ago, but got changed into the array due
to better memory usage patterns (those linked lists of obejcts are
horrible from a memory allocation standpoint). But I wonder why we didn't
do this back then. Maybe there's a reason for it.
Or maybe there _used_ to be a reason, and no longer is.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-11 02:27:58 +02:00
|
|
|
sha1_to_hex(obj->sha1), name);
|
show_object(): push path_name() call further down
In particular, pushing the "path_name()" call _into_ the show() function
would seem to allow
- more clarity into who "owns" the name (ie now when we free the name in
the show_object callback, it's because we generated it ourselves by
calling path_name())
- not calling path_name() at all, either because we don't care about the
name in the first place, or because we are actually happy walking the
linked list of "struct name_path *" and the last component.
Now, I didn't do that latter optimization, because it would require some
more coding, but especially looking at "builtin-pack-objects.c", we really
don't even want the whole pathname, we really would be better off with the
list of path components.
Why? We use that name for two things:
- add_preferred_base_object(), which actually _wants_ to traverse the
path, and now does it by looking for '/' characters!
- for 'name_hash()', which only cares about the last 16 characters of a
name, so again, generating the full name seems to be just unnecessary
work.
Anyway, so I didn't look any closer at those things, but it did convince
me that the "show_object()" calling convention was crazy, and we're
actually better off doing _less_ in list-objects.c, and giving people
access to the internal data structures so that they can decide whether
they want to generate a path-name or not.
This patch does that, and then for people who did use the name (even if
they might do something more clever in the future), it just does the
straightforward "name = path_name(path, component); .. free(name);" thing.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-11 03:15:26 +02:00
|
|
|
free((char *)name);
|
2006-10-30 20:08:43 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void show_edge(struct commit *commit)
|
|
|
|
|
{
|
|
|
|
|
fprintf(pack_pipe, "-%s\n", sha1_to_hex(commit->object.sha1));
|
|
|
|
|
}
|
|
|
|
|
|
2010-07-28 11:39:10 +02:00
|
|
|
static int do_rev_list(int in, int out, void *user_data)
|
2007-10-19 21:48:02 +02:00
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
struct rev_info revs;
|
|
|
|
|
|
2010-02-05 21:57:38 +01:00
|
|
|
pack_pipe = xfdopen(out, "w");
|
2007-10-19 21:48:02 +02:00
|
|
|
init_revisions(&revs, NULL);
|
|
|
|
|
revs.tag_objects = 1;
|
|
|
|
|
revs.tree_objects = 1;
|
|
|
|
|
revs.blob_objects = 1;
|
|
|
|
|
if (use_thin_pack)
|
|
|
|
|
revs.edge_hint = 1;
|
|
|
|
|
|
2010-07-28 11:39:10 +02:00
|
|
|
for (i = 0; i < want_obj.nr; i++) {
|
|
|
|
|
struct object *o = want_obj.objects[i].item;
|
|
|
|
|
/* why??? */
|
|
|
|
|
o->flags &= ~UNINTERESTING;
|
|
|
|
|
add_pending_object(&revs, o, NULL);
|
2007-10-19 21:48:02 +02:00
|
|
|
}
|
2010-07-28 11:39:10 +02:00
|
|
|
for (i = 0; i < have_obj.nr; i++) {
|
|
|
|
|
struct object *o = have_obj.objects[i].item;
|
|
|
|
|
o->flags |= UNINTERESTING;
|
|
|
|
|
add_pending_object(&revs, o, NULL);
|
|
|
|
|
}
|
|
|
|
|
setup_revisions(0, NULL, &revs, NULL);
|
2008-02-18 08:31:56 +01:00
|
|
|
if (prepare_revision_walk(&revs))
|
|
|
|
|
die("revision walk setup failed");
|
2007-10-19 21:48:02 +02:00
|
|
|
mark_edges_uninteresting(revs.commits, &revs, show_edge);
|
2009-09-04 01:08:33 +02:00
|
|
|
if (use_thin_pack)
|
|
|
|
|
for (i = 0; i < extra_edge_obj.nr; i++)
|
|
|
|
|
fprintf(pack_pipe, "-%s\n", sha1_to_hex(
|
|
|
|
|
extra_edge_obj.objects[i].item->sha1));
|
2009-04-06 21:28:36 +02:00
|
|
|
traverse_commit_list(&revs, show_commit, show_object, NULL);
|
2007-12-08 22:19:14 +01:00
|
|
|
fflush(pack_pipe);
|
|
|
|
|
fclose(pack_pipe);
|
2007-10-19 21:48:03 +02:00
|
|
|
return 0;
|
2007-10-19 21:48:02 +02:00
|
|
|
}
|
|
|
|
|
|
2005-07-05 00:29:17 +02:00
|
|
|
static void create_pack_file(void)
|
|
|
|
|
{
|
2007-10-19 21:48:03 +02:00
|
|
|
struct async rev_list;
|
2007-10-19 21:47:59 +02:00
|
|
|
struct child_process pack_objects;
|
2006-07-06 03:00:02 +02:00
|
|
|
int create_full_pack = (nr_our_refs == want_obj.nr && !have_obj.nr);
|
2006-06-21 07:48:23 +02:00
|
|
|
char data[8193], progress[128];
|
2006-06-21 09:30:21 +02:00
|
|
|
char abort_msg[] = "aborting due to possible repository "
|
|
|
|
|
"corruption on the remote side.";
|
2006-06-21 03:26:34 +02:00
|
|
|
int buffered = -1;
|
2009-12-10 21:17:11 +01:00
|
|
|
ssize_t sz;
|
2007-10-19 21:47:59 +02:00
|
|
|
const char *argv[10];
|
|
|
|
|
int arg = 0;
|
2005-07-05 01:35:13 +02:00
|
|
|
|
upload-pack: start pack-objects before async rev-list
In a pthread-enabled version of upload-pack, there's a race condition
that can cause a deadlock on the fflush(NULL) we call from run-command.
What happens is this:
1. Upload-pack is informed we are doing a shallow clone.
2. We call start_async() to spawn a thread that will generate rev-list
results to feed to pack-objects. It gets a file descriptor to a
pipe which will eventually hook to pack-objects.
3. The rev-list thread uses fdopen to create a new output stream
around the fd we gave it, called pack_pipe.
4. The thread writes results to pack_pipe. Outside of our control,
libc is doing locking on the stream. We keep writing until the OS
pipe buffer is full, and then we block in write(), still holding
the lock.
5. The main thread now uses start_command to spawn pack-objects.
Before forking, it calls fflush(NULL) to flush every stdio output
buffer. It blocks trying to get the lock on pack_pipe.
And we have a deadlock. The thread will block until somebody starts
reading from the pipe. But nobody will read from the pipe until we
finish flushing to the pipe.
To fix this, we swap the start order: we start the
pack-objects reader first, and then the rev-list writer
after. Thus the problematic fflush(NULL) happens before we
even open the new file descriptor (and even if it didn't,
flushing should no longer block, as the reader at the end of
the pipe is now active).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-06 23:33:33 +02:00
|
|
|
argv[arg++] = "pack-objects";
|
|
|
|
|
if (!shallow_nr) {
|
2009-06-10 01:50:18 +02:00
|
|
|
argv[arg++] = "--revs";
|
|
|
|
|
if (create_full_pack)
|
|
|
|
|
argv[arg++] = "--all";
|
|
|
|
|
else if (use_thin_pack)
|
|
|
|
|
argv[arg++] = "--thin";
|
|
|
|
|
}
|
2005-07-05 01:35:13 +02:00
|
|
|
|
2007-10-19 21:47:59 +02:00
|
|
|
argv[arg++] = "--stdout";
|
|
|
|
|
if (!no_progress)
|
|
|
|
|
argv[arg++] = "--progress";
|
|
|
|
|
if (use_ofs_delta)
|
|
|
|
|
argv[arg++] = "--delta-base-offset";
|
2008-03-04 04:27:33 +01:00
|
|
|
if (use_include_tag)
|
|
|
|
|
argv[arg++] = "--include-tag";
|
2007-10-19 21:47:59 +02:00
|
|
|
argv[arg++] = NULL;
|
|
|
|
|
|
|
|
|
|
memset(&pack_objects, 0, sizeof(pack_objects));
|
upload-pack: start pack-objects before async rev-list
In a pthread-enabled version of upload-pack, there's a race condition
that can cause a deadlock on the fflush(NULL) we call from run-command.
What happens is this:
1. Upload-pack is informed we are doing a shallow clone.
2. We call start_async() to spawn a thread that will generate rev-list
results to feed to pack-objects. It gets a file descriptor to a
pipe which will eventually hook to pack-objects.
3. The rev-list thread uses fdopen to create a new output stream
around the fd we gave it, called pack_pipe.
4. The thread writes results to pack_pipe. Outside of our control,
libc is doing locking on the stream. We keep writing until the OS
pipe buffer is full, and then we block in write(), still holding
the lock.
5. The main thread now uses start_command to spawn pack-objects.
Before forking, it calls fflush(NULL) to flush every stdio output
buffer. It blocks trying to get the lock on pack_pipe.
And we have a deadlock. The thread will block until somebody starts
reading from the pipe. But nobody will read from the pipe until we
finish flushing to the pipe.
To fix this, we swap the start order: we start the
pack-objects reader first, and then the rev-list writer
after. Thus the problematic fflush(NULL) happens before we
even open the new file descriptor (and even if it didn't,
flushing should no longer block, as the reader at the end of
the pipe is now active).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-06 23:33:33 +02:00
|
|
|
pack_objects.in = -1;
|
2007-10-19 21:47:59 +02:00
|
|
|
pack_objects.out = -1;
|
|
|
|
|
pack_objects.err = -1;
|
|
|
|
|
pack_objects.git_cmd = 1;
|
|
|
|
|
pack_objects.argv = argv;
|
2007-10-19 21:48:03 +02:00
|
|
|
|
upload-pack: Use finish_{command,async}() instead of waitpid().
upload-pack spawns two processes, rev-list and pack-objects, and carefully
monitors their status so that it can report failure to the remote end.
This change removes the complicated procedures on the grounds of the
following observations:
- If everything is OK, rev-list closes its output pipe end, upon which
pack-objects (which reads from the pipe) sees EOF and terminates itself,
closing its output (and error) pipes. upload-pack reads from both until
it sees EOF in both. It collects the exit codes of the child processes
(which indicate success) and terminates successfully.
- If rev-list sees an error, it closes its output and terminates with
failure. pack-objects sees EOF in its input and terminates successfully.
Again upload-pack reads its inputs until EOF. When it now collects
the exit codes of its child processes, it notices the failure of rev-list
and signals failure to the remote end.
- If pack-objects sees an error, it terminates with failure. Since this
breaks the pipe to rev-list, rev-list is killed with SIGPIPE.
upload-pack reads its input until EOF, then collects the exit codes of
the child processes, notices their failures, and signals failure to the
remote end.
- If upload-pack itself dies unexpectedly, pack-objects is killed with
SIGPIPE, and subsequently also rev-list.
The upshot of this is that precise monitoring of child processes is not
required because both terminate if either one of them dies unexpectedly.
This allows us to use finish_command() and finish_async() instead of
an explicit waitpid(2) call.
The change is smaller than it looks because most of it only reduces the
indentation of a large part of the inner loop.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04 20:46:48 +01:00
|
|
|
if (start_command(&pack_objects))
|
2008-08-31 18:39:19 +02:00
|
|
|
die("git upload-pack: unable to fork git-pack-objects");
|
2006-06-21 03:26:34 +02:00
|
|
|
|
upload-pack: start pack-objects before async rev-list
In a pthread-enabled version of upload-pack, there's a race condition
that can cause a deadlock on the fflush(NULL) we call from run-command.
What happens is this:
1. Upload-pack is informed we are doing a shallow clone.
2. We call start_async() to spawn a thread that will generate rev-list
results to feed to pack-objects. It gets a file descriptor to a
pipe which will eventually hook to pack-objects.
3. The rev-list thread uses fdopen to create a new output stream
around the fd we gave it, called pack_pipe.
4. The thread writes results to pack_pipe. Outside of our control,
libc is doing locking on the stream. We keep writing until the OS
pipe buffer is full, and then we block in write(), still holding
the lock.
5. The main thread now uses start_command to spawn pack-objects.
Before forking, it calls fflush(NULL) to flush every stdio output
buffer. It blocks trying to get the lock on pack_pipe.
And we have a deadlock. The thread will block until somebody starts
reading from the pipe. But nobody will read from the pipe until we
finish flushing to the pipe.
To fix this, we swap the start order: we start the
pack-objects reader first, and then the rev-list writer
after. Thus the problematic fflush(NULL) happens before we
even open the new file descriptor (and even if it didn't,
flushing should no longer block, as the reader at the end of
the pipe is now active).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-06 23:33:33 +02:00
|
|
|
if (shallow_nr) {
|
|
|
|
|
memset(&rev_list, 0, sizeof(rev_list));
|
|
|
|
|
rev_list.proc = do_rev_list;
|
|
|
|
|
rev_list.out = pack_objects.in;
|
|
|
|
|
if (start_async(&rev_list))
|
|
|
|
|
die("git upload-pack: unable to fork git-rev-list");
|
|
|
|
|
}
|
|
|
|
|
else {
|
2009-09-12 10:43:27 +02:00
|
|
|
FILE *pipe_fd = xfdopen(pack_objects.in, "w");
|
2009-06-10 01:50:18 +02:00
|
|
|
if (!create_full_pack) {
|
|
|
|
|
int i;
|
|
|
|
|
for (i = 0; i < want_obj.nr; i++)
|
|
|
|
|
fprintf(pipe_fd, "%s\n", sha1_to_hex(want_obj.objects[i].item->sha1));
|
|
|
|
|
fprintf(pipe_fd, "--not\n");
|
|
|
|
|
for (i = 0; i < have_obj.nr; i++)
|
|
|
|
|
fprintf(pipe_fd, "%s\n", sha1_to_hex(have_obj.objects[i].item->sha1));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fprintf(pipe_fd, "\n");
|
|
|
|
|
fflush(pipe_fd);
|
|
|
|
|
fclose(pipe_fd);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2007-10-19 21:47:59 +02:00
|
|
|
/* We read from pack_objects.err to capture stderr output for
|
|
|
|
|
* progress bar, and pack_objects.out to capture the pack data.
|
2006-06-21 03:26:34 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
|
struct pollfd pfd[2];
|
2006-06-21 07:48:23 +02:00
|
|
|
int pe, pu, pollsize;
|
2006-06-21 03:26:34 +02:00
|
|
|
|
2006-07-18 19:14:51 +02:00
|
|
|
reset_timeout();
|
|
|
|
|
|
2006-06-21 03:26:34 +02:00
|
|
|
pollsize = 0;
|
2006-06-21 07:48:23 +02:00
|
|
|
pe = pu = -1;
|
2006-06-21 03:26:34 +02:00
|
|
|
|
2007-10-19 21:47:59 +02:00
|
|
|
if (0 <= pack_objects.out) {
|
|
|
|
|
pfd[pollsize].fd = pack_objects.out;
|
2006-06-21 03:26:34 +02:00
|
|
|
pfd[pollsize].events = POLLIN;
|
|
|
|
|
pu = pollsize;
|
|
|
|
|
pollsize++;
|
|
|
|
|
}
|
2007-10-19 21:47:59 +02:00
|
|
|
if (0 <= pack_objects.err) {
|
|
|
|
|
pfd[pollsize].fd = pack_objects.err;
|
2006-06-21 07:48:23 +02:00
|
|
|
pfd[pollsize].events = POLLIN;
|
|
|
|
|
pe = pollsize;
|
|
|
|
|
pollsize++;
|
|
|
|
|
}
|
2006-06-21 03:26:34 +02:00
|
|
|
|
upload-pack: Use finish_{command,async}() instead of waitpid().
upload-pack spawns two processes, rev-list and pack-objects, and carefully
monitors their status so that it can report failure to the remote end.
This change removes the complicated procedures on the grounds of the
following observations:
- If everything is OK, rev-list closes its output pipe end, upon which
pack-objects (which reads from the pipe) sees EOF and terminates itself,
closing its output (and error) pipes. upload-pack reads from both until
it sees EOF in both. It collects the exit codes of the child processes
(which indicate success) and terminates successfully.
- If rev-list sees an error, it closes its output and terminates with
failure. pack-objects sees EOF in its input and terminates successfully.
Again upload-pack reads its inputs until EOF. When it now collects
the exit codes of its child processes, it notices the failure of rev-list
and signals failure to the remote end.
- If pack-objects sees an error, it terminates with failure. Since this
breaks the pipe to rev-list, rev-list is killed with SIGPIPE.
upload-pack reads its input until EOF, then collects the exit codes of
the child processes, notices their failures, and signals failure to the
remote end.
- If upload-pack itself dies unexpectedly, pack-objects is killed with
SIGPIPE, and subsequently also rev-list.
The upshot of this is that precise monitoring of child processes is not
required because both terminate if either one of them dies unexpectedly.
This allows us to use finish_command() and finish_async() instead of
an explicit waitpid(2) call.
The change is smaller than it looks because most of it only reduces the
indentation of a large part of the inner loop.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04 20:46:48 +01:00
|
|
|
if (!pollsize)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
if (poll(pfd, pollsize, -1) < 0) {
|
|
|
|
|
if (errno != EINTR) {
|
|
|
|
|
error("poll failed, resuming: %s",
|
|
|
|
|
strerror(errno));
|
|
|
|
|
sleep(1);
|
2006-06-21 03:26:34 +02:00
|
|
|
}
|
upload-pack: Use finish_{command,async}() instead of waitpid().
upload-pack spawns two processes, rev-list and pack-objects, and carefully
monitors their status so that it can report failure to the remote end.
This change removes the complicated procedures on the grounds of the
following observations:
- If everything is OK, rev-list closes its output pipe end, upon which
pack-objects (which reads from the pipe) sees EOF and terminates itself,
closing its output (and error) pipes. upload-pack reads from both until
it sees EOF in both. It collects the exit codes of the child processes
(which indicate success) and terminates successfully.
- If rev-list sees an error, it closes its output and terminates with
failure. pack-objects sees EOF in its input and terminates successfully.
Again upload-pack reads its inputs until EOF. When it now collects
the exit codes of its child processes, it notices the failure of rev-list
and signals failure to the remote end.
- If pack-objects sees an error, it terminates with failure. Since this
breaks the pipe to rev-list, rev-list is killed with SIGPIPE.
upload-pack reads its input until EOF, then collects the exit codes of
the child processes, notices their failures, and signals failure to the
remote end.
- If upload-pack itself dies unexpectedly, pack-objects is killed with
SIGPIPE, and subsequently also rev-list.
The upshot of this is that precise monitoring of child processes is not
required because both terminate if either one of them dies unexpectedly.
This allows us to use finish_command() and finish_async() instead of
an explicit waitpid(2) call.
The change is smaller than it looks because most of it only reduces the
indentation of a large part of the inner loop.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04 20:46:48 +01:00
|
|
|
continue;
|
|
|
|
|
}
|
2009-11-11 23:24:42 +01:00
|
|
|
if (0 <= pe && (pfd[pe].revents & (POLLIN|POLLHUP))) {
|
|
|
|
|
/* Status ready; we ship that in the side-band
|
|
|
|
|
* or dump to the standard error.
|
|
|
|
|
*/
|
|
|
|
|
sz = xread(pack_objects.err, progress,
|
|
|
|
|
sizeof(progress));
|
|
|
|
|
if (0 < sz)
|
|
|
|
|
send_client_data(2, progress, sz);
|
|
|
|
|
else if (sz == 0) {
|
|
|
|
|
close(pack_objects.err);
|
|
|
|
|
pack_objects.err = -1;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
goto fail;
|
|
|
|
|
/* give priority to status messages */
|
|
|
|
|
continue;
|
|
|
|
|
}
|
upload-pack: Use finish_{command,async}() instead of waitpid().
upload-pack spawns two processes, rev-list and pack-objects, and carefully
monitors their status so that it can report failure to the remote end.
This change removes the complicated procedures on the grounds of the
following observations:
- If everything is OK, rev-list closes its output pipe end, upon which
pack-objects (which reads from the pipe) sees EOF and terminates itself,
closing its output (and error) pipes. upload-pack reads from both until
it sees EOF in both. It collects the exit codes of the child processes
(which indicate success) and terminates successfully.
- If rev-list sees an error, it closes its output and terminates with
failure. pack-objects sees EOF in its input and terminates successfully.
Again upload-pack reads its inputs until EOF. When it now collects
the exit codes of its child processes, it notices the failure of rev-list
and signals failure to the remote end.
- If pack-objects sees an error, it terminates with failure. Since this
breaks the pipe to rev-list, rev-list is killed with SIGPIPE.
upload-pack reads its input until EOF, then collects the exit codes of
the child processes, notices their failures, and signals failure to the
remote end.
- If upload-pack itself dies unexpectedly, pack-objects is killed with
SIGPIPE, and subsequently also rev-list.
The upshot of this is that precise monitoring of child processes is not
required because both terminate if either one of them dies unexpectedly.
This allows us to use finish_command() and finish_async() instead of
an explicit waitpid(2) call.
The change is smaller than it looks because most of it only reduces the
indentation of a large part of the inner loop.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04 20:46:48 +01:00
|
|
|
if (0 <= pu && (pfd[pu].revents & (POLLIN|POLLHUP))) {
|
|
|
|
|
/* Data ready; we keep the last byte to ourselves
|
|
|
|
|
* in case we detect broken rev-list, so that we
|
|
|
|
|
* can leave the stream corrupted. This is
|
|
|
|
|
* unfortunate -- unpack-objects would happily
|
|
|
|
|
* accept a valid packdata with trailing garbage,
|
|
|
|
|
* so appending garbage after we pass all the
|
|
|
|
|
* pack data is not good enough to signal
|
|
|
|
|
* breakage to downstream.
|
|
|
|
|
*/
|
|
|
|
|
char *cp = data;
|
|
|
|
|
ssize_t outsz = 0;
|
|
|
|
|
if (0 <= buffered) {
|
|
|
|
|
*cp++ = buffered;
|
|
|
|
|
outsz++;
|
2006-06-21 03:26:34 +02:00
|
|
|
}
|
upload-pack: Use finish_{command,async}() instead of waitpid().
upload-pack spawns two processes, rev-list and pack-objects, and carefully
monitors their status so that it can report failure to the remote end.
This change removes the complicated procedures on the grounds of the
following observations:
- If everything is OK, rev-list closes its output pipe end, upon which
pack-objects (which reads from the pipe) sees EOF and terminates itself,
closing its output (and error) pipes. upload-pack reads from both until
it sees EOF in both. It collects the exit codes of the child processes
(which indicate success) and terminates successfully.
- If rev-list sees an error, it closes its output and terminates with
failure. pack-objects sees EOF in its input and terminates successfully.
Again upload-pack reads its inputs until EOF. When it now collects
the exit codes of its child processes, it notices the failure of rev-list
and signals failure to the remote end.
- If pack-objects sees an error, it terminates with failure. Since this
breaks the pipe to rev-list, rev-list is killed with SIGPIPE.
upload-pack reads its input until EOF, then collects the exit codes of
the child processes, notices their failures, and signals failure to the
remote end.
- If upload-pack itself dies unexpectedly, pack-objects is killed with
SIGPIPE, and subsequently also rev-list.
The upshot of this is that precise monitoring of child processes is not
required because both terminate if either one of them dies unexpectedly.
This allows us to use finish_command() and finish_async() instead of
an explicit waitpid(2) call.
The change is smaller than it looks because most of it only reduces the
indentation of a large part of the inner loop.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04 20:46:48 +01:00
|
|
|
sz = xread(pack_objects.out, cp,
|
|
|
|
|
sizeof(data) - outsz);
|
|
|
|
|
if (0 < sz)
|
2009-12-10 21:17:11 +01:00
|
|
|
;
|
upload-pack: Use finish_{command,async}() instead of waitpid().
upload-pack spawns two processes, rev-list and pack-objects, and carefully
monitors their status so that it can report failure to the remote end.
This change removes the complicated procedures on the grounds of the
following observations:
- If everything is OK, rev-list closes its output pipe end, upon which
pack-objects (which reads from the pipe) sees EOF and terminates itself,
closing its output (and error) pipes. upload-pack reads from both until
it sees EOF in both. It collects the exit codes of the child processes
(which indicate success) and terminates successfully.
- If rev-list sees an error, it closes its output and terminates with
failure. pack-objects sees EOF in its input and terminates successfully.
Again upload-pack reads its inputs until EOF. When it now collects
the exit codes of its child processes, it notices the failure of rev-list
and signals failure to the remote end.
- If pack-objects sees an error, it terminates with failure. Since this
breaks the pipe to rev-list, rev-list is killed with SIGPIPE.
upload-pack reads its input until EOF, then collects the exit codes of
the child processes, notices their failures, and signals failure to the
remote end.
- If upload-pack itself dies unexpectedly, pack-objects is killed with
SIGPIPE, and subsequently also rev-list.
The upshot of this is that precise monitoring of child processes is not
required because both terminate if either one of them dies unexpectedly.
This allows us to use finish_command() and finish_async() instead of
an explicit waitpid(2) call.
The change is smaller than it looks because most of it only reduces the
indentation of a large part of the inner loop.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04 20:46:48 +01:00
|
|
|
else if (sz == 0) {
|
|
|
|
|
close(pack_objects.out);
|
|
|
|
|
pack_objects.out = -1;
|
2006-06-21 07:48:23 +02:00
|
|
|
}
|
upload-pack: Use finish_{command,async}() instead of waitpid().
upload-pack spawns two processes, rev-list and pack-objects, and carefully
monitors their status so that it can report failure to the remote end.
This change removes the complicated procedures on the grounds of the
following observations:
- If everything is OK, rev-list closes its output pipe end, upon which
pack-objects (which reads from the pipe) sees EOF and terminates itself,
closing its output (and error) pipes. upload-pack reads from both until
it sees EOF in both. It collects the exit codes of the child processes
(which indicate success) and terminates successfully.
- If rev-list sees an error, it closes its output and terminates with
failure. pack-objects sees EOF in its input and terminates successfully.
Again upload-pack reads its inputs until EOF. When it now collects
the exit codes of its child processes, it notices the failure of rev-list
and signals failure to the remote end.
- If pack-objects sees an error, it terminates with failure. Since this
breaks the pipe to rev-list, rev-list is killed with SIGPIPE.
upload-pack reads its input until EOF, then collects the exit codes of
the child processes, notices their failures, and signals failure to the
remote end.
- If upload-pack itself dies unexpectedly, pack-objects is killed with
SIGPIPE, and subsequently also rev-list.
The upshot of this is that precise monitoring of child processes is not
required because both terminate if either one of them dies unexpectedly.
This allows us to use finish_command() and finish_async() instead of
an explicit waitpid(2) call.
The change is smaller than it looks because most of it only reduces the
indentation of a large part of the inner loop.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04 20:46:48 +01:00
|
|
|
else
|
|
|
|
|
goto fail;
|
|
|
|
|
sz += outsz;
|
|
|
|
|
if (1 < sz) {
|
|
|
|
|
buffered = data[sz-1] & 0xFF;
|
|
|
|
|
sz--;
|
2006-06-21 03:26:34 +02:00
|
|
|
}
|
upload-pack: Use finish_{command,async}() instead of waitpid().
upload-pack spawns two processes, rev-list and pack-objects, and carefully
monitors their status so that it can report failure to the remote end.
This change removes the complicated procedures on the grounds of the
following observations:
- If everything is OK, rev-list closes its output pipe end, upon which
pack-objects (which reads from the pipe) sees EOF and terminates itself,
closing its output (and error) pipes. upload-pack reads from both until
it sees EOF in both. It collects the exit codes of the child processes
(which indicate success) and terminates successfully.
- If rev-list sees an error, it closes its output and terminates with
failure. pack-objects sees EOF in its input and terminates successfully.
Again upload-pack reads its inputs until EOF. When it now collects
the exit codes of its child processes, it notices the failure of rev-list
and signals failure to the remote end.
- If pack-objects sees an error, it terminates with failure. Since this
breaks the pipe to rev-list, rev-list is killed with SIGPIPE.
upload-pack reads its input until EOF, then collects the exit codes of
the child processes, notices their failures, and signals failure to the
remote end.
- If upload-pack itself dies unexpectedly, pack-objects is killed with
SIGPIPE, and subsequently also rev-list.
The upshot of this is that precise monitoring of child processes is not
required because both terminate if either one of them dies unexpectedly.
This allows us to use finish_command() and finish_async() instead of
an explicit waitpid(2) call.
The change is smaller than it looks because most of it only reduces the
indentation of a large part of the inner loop.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04 20:46:48 +01:00
|
|
|
else
|
|
|
|
|
buffered = -1;
|
|
|
|
|
sz = send_client_data(1, data, sz);
|
|
|
|
|
if (sz < 0)
|
2006-06-21 03:26:34 +02:00
|
|
|
goto fail;
|
upload-pack: Use finish_{command,async}() instead of waitpid().
upload-pack spawns two processes, rev-list and pack-objects, and carefully
monitors their status so that it can report failure to the remote end.
This change removes the complicated procedures on the grounds of the
following observations:
- If everything is OK, rev-list closes its output pipe end, upon which
pack-objects (which reads from the pipe) sees EOF and terminates itself,
closing its output (and error) pipes. upload-pack reads from both until
it sees EOF in both. It collects the exit codes of the child processes
(which indicate success) and terminates successfully.
- If rev-list sees an error, it closes its output and terminates with
failure. pack-objects sees EOF in its input and terminates successfully.
Again upload-pack reads its inputs until EOF. When it now collects
the exit codes of its child processes, it notices the failure of rev-list
and signals failure to the remote end.
- If pack-objects sees an error, it terminates with failure. Since this
breaks the pipe to rev-list, rev-list is killed with SIGPIPE.
upload-pack reads its input until EOF, then collects the exit codes of
the child processes, notices their failures, and signals failure to the
remote end.
- If upload-pack itself dies unexpectedly, pack-objects is killed with
SIGPIPE, and subsequently also rev-list.
The upshot of this is that precise monitoring of child processes is not
required because both terminate if either one of them dies unexpectedly.
This allows us to use finish_command() and finish_async() instead of
an explicit waitpid(2) call.
The change is smaller than it looks because most of it only reduces the
indentation of a large part of the inner loop.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04 20:46:48 +01:00
|
|
|
}
|
|
|
|
|
}
|
2006-06-21 03:26:34 +02:00
|
|
|
|
upload-pack: Use finish_{command,async}() instead of waitpid().
upload-pack spawns two processes, rev-list and pack-objects, and carefully
monitors their status so that it can report failure to the remote end.
This change removes the complicated procedures on the grounds of the
following observations:
- If everything is OK, rev-list closes its output pipe end, upon which
pack-objects (which reads from the pipe) sees EOF and terminates itself,
closing its output (and error) pipes. upload-pack reads from both until
it sees EOF in both. It collects the exit codes of the child processes
(which indicate success) and terminates successfully.
- If rev-list sees an error, it closes its output and terminates with
failure. pack-objects sees EOF in its input and terminates successfully.
Again upload-pack reads its inputs until EOF. When it now collects
the exit codes of its child processes, it notices the failure of rev-list
and signals failure to the remote end.
- If pack-objects sees an error, it terminates with failure. Since this
breaks the pipe to rev-list, rev-list is killed with SIGPIPE.
upload-pack reads its input until EOF, then collects the exit codes of
the child processes, notices their failures, and signals failure to the
remote end.
- If upload-pack itself dies unexpectedly, pack-objects is killed with
SIGPIPE, and subsequently also rev-list.
The upshot of this is that precise monitoring of child processes is not
required because both terminate if either one of them dies unexpectedly.
This allows us to use finish_command() and finish_async() instead of
an explicit waitpid(2) call.
The change is smaller than it looks because most of it only reduces the
indentation of a large part of the inner loop.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04 20:46:48 +01:00
|
|
|
if (finish_command(&pack_objects)) {
|
2008-08-31 18:39:19 +02:00
|
|
|
error("git upload-pack: git-pack-objects died with error.");
|
upload-pack: Use finish_{command,async}() instead of waitpid().
upload-pack spawns two processes, rev-list and pack-objects, and carefully
monitors their status so that it can report failure to the remote end.
This change removes the complicated procedures on the grounds of the
following observations:
- If everything is OK, rev-list closes its output pipe end, upon which
pack-objects (which reads from the pipe) sees EOF and terminates itself,
closing its output (and error) pipes. upload-pack reads from both until
it sees EOF in both. It collects the exit codes of the child processes
(which indicate success) and terminates successfully.
- If rev-list sees an error, it closes its output and terminates with
failure. pack-objects sees EOF in its input and terminates successfully.
Again upload-pack reads its inputs until EOF. When it now collects
the exit codes of its child processes, it notices the failure of rev-list
and signals failure to the remote end.
- If pack-objects sees an error, it terminates with failure. Since this
breaks the pipe to rev-list, rev-list is killed with SIGPIPE.
upload-pack reads its input until EOF, then collects the exit codes of
the child processes, notices their failures, and signals failure to the
remote end.
- If upload-pack itself dies unexpectedly, pack-objects is killed with
SIGPIPE, and subsequently also rev-list.
The upshot of this is that precise monitoring of child processes is not
required because both terminate if either one of them dies unexpectedly.
This allows us to use finish_command() and finish_async() instead of
an explicit waitpid(2) call.
The change is smaller than it looks because most of it only reduces the
indentation of a large part of the inner loop.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04 20:46:48 +01:00
|
|
|
goto fail;
|
|
|
|
|
}
|
2009-06-10 01:50:18 +02:00
|
|
|
if (shallow_nr && finish_async(&rev_list))
|
upload-pack: Use finish_{command,async}() instead of waitpid().
upload-pack spawns two processes, rev-list and pack-objects, and carefully
monitors their status so that it can report failure to the remote end.
This change removes the complicated procedures on the grounds of the
following observations:
- If everything is OK, rev-list closes its output pipe end, upon which
pack-objects (which reads from the pipe) sees EOF and terminates itself,
closing its output (and error) pipes. upload-pack reads from both until
it sees EOF in both. It collects the exit codes of the child processes
(which indicate success) and terminates successfully.
- If rev-list sees an error, it closes its output and terminates with
failure. pack-objects sees EOF in its input and terminates successfully.
Again upload-pack reads its inputs until EOF. When it now collects
the exit codes of its child processes, it notices the failure of rev-list
and signals failure to the remote end.
- If pack-objects sees an error, it terminates with failure. Since this
breaks the pipe to rev-list, rev-list is killed with SIGPIPE.
upload-pack reads its input until EOF, then collects the exit codes of
the child processes, notices their failures, and signals failure to the
remote end.
- If upload-pack itself dies unexpectedly, pack-objects is killed with
SIGPIPE, and subsequently also rev-list.
The upshot of this is that precise monitoring of child processes is not
required because both terminate if either one of them dies unexpectedly.
This allows us to use finish_command() and finish_async() instead of
an explicit waitpid(2) call.
The change is smaller than it looks because most of it only reduces the
indentation of a large part of the inner loop.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04 20:46:48 +01:00
|
|
|
goto fail; /* error was already reported */
|
2006-06-21 03:26:34 +02:00
|
|
|
|
upload-pack: Use finish_{command,async}() instead of waitpid().
upload-pack spawns two processes, rev-list and pack-objects, and carefully
monitors their status so that it can report failure to the remote end.
This change removes the complicated procedures on the grounds of the
following observations:
- If everything is OK, rev-list closes its output pipe end, upon which
pack-objects (which reads from the pipe) sees EOF and terminates itself,
closing its output (and error) pipes. upload-pack reads from both until
it sees EOF in both. It collects the exit codes of the child processes
(which indicate success) and terminates successfully.
- If rev-list sees an error, it closes its output and terminates with
failure. pack-objects sees EOF in its input and terminates successfully.
Again upload-pack reads its inputs until EOF. When it now collects
the exit codes of its child processes, it notices the failure of rev-list
and signals failure to the remote end.
- If pack-objects sees an error, it terminates with failure. Since this
breaks the pipe to rev-list, rev-list is killed with SIGPIPE.
upload-pack reads its input until EOF, then collects the exit codes of
the child processes, notices their failures, and signals failure to the
remote end.
- If upload-pack itself dies unexpectedly, pack-objects is killed with
SIGPIPE, and subsequently also rev-list.
The upshot of this is that precise monitoring of child processes is not
required because both terminate if either one of them dies unexpectedly.
This allows us to use finish_command() and finish_async() instead of
an explicit waitpid(2) call.
The change is smaller than it looks because most of it only reduces the
indentation of a large part of the inner loop.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04 20:46:48 +01:00
|
|
|
/* flush the data */
|
|
|
|
|
if (0 <= buffered) {
|
|
|
|
|
data[0] = buffered;
|
|
|
|
|
sz = send_client_data(1, data, 1);
|
|
|
|
|
if (sz < 0)
|
|
|
|
|
goto fail;
|
|
|
|
|
fprintf(stderr, "flushed.\n");
|
2006-06-21 03:26:34 +02:00
|
|
|
}
|
upload-pack: Use finish_{command,async}() instead of waitpid().
upload-pack spawns two processes, rev-list and pack-objects, and carefully
monitors their status so that it can report failure to the remote end.
This change removes the complicated procedures on the grounds of the
following observations:
- If everything is OK, rev-list closes its output pipe end, upon which
pack-objects (which reads from the pipe) sees EOF and terminates itself,
closing its output (and error) pipes. upload-pack reads from both until
it sees EOF in both. It collects the exit codes of the child processes
(which indicate success) and terminates successfully.
- If rev-list sees an error, it closes its output and terminates with
failure. pack-objects sees EOF in its input and terminates successfully.
Again upload-pack reads its inputs until EOF. When it now collects
the exit codes of its child processes, it notices the failure of rev-list
and signals failure to the remote end.
- If pack-objects sees an error, it terminates with failure. Since this
breaks the pipe to rev-list, rev-list is killed with SIGPIPE.
upload-pack reads its input until EOF, then collects the exit codes of
the child processes, notices their failures, and signals failure to the
remote end.
- If upload-pack itself dies unexpectedly, pack-objects is killed with
SIGPIPE, and subsequently also rev-list.
The upshot of this is that precise monitoring of child processes is not
required because both terminate if either one of them dies unexpectedly.
This allows us to use finish_command() and finish_async() instead of
an explicit waitpid(2) call.
The change is smaller than it looks because most of it only reduces the
indentation of a large part of the inner loop.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04 20:46:48 +01:00
|
|
|
if (use_sideband)
|
|
|
|
|
packet_flush(1);
|
|
|
|
|
return;
|
|
|
|
|
|
2006-06-21 03:26:34 +02:00
|
|
|
fail:
|
2006-06-21 09:30:21 +02:00
|
|
|
send_client_data(3, abort_msg, sizeof(abort_msg));
|
2008-08-31 18:39:19 +02:00
|
|
|
die("git upload-pack: %s", abort_msg);
|
2005-07-05 00:29:17 +02:00
|
|
|
}
|
|
|
|
|
|
2005-07-04 22:26:53 +02:00
|
|
|
static int got_sha1(char *hex, unsigned char *sha1)
|
|
|
|
|
{
|
2006-07-06 03:00:02 +02:00
|
|
|
struct object *o;
|
2006-07-06 06:28:20 +02:00
|
|
|
int we_knew_they_have = 0;
|
2006-07-06 03:00:02 +02:00
|
|
|
|
2005-07-04 22:26:53 +02:00
|
|
|
if (get_sha1_hex(hex, sha1))
|
2008-08-31 18:39:19 +02:00
|
|
|
die("git upload-pack: expected SHA1 object, got '%s'", hex);
|
2005-07-05 00:29:17 +02:00
|
|
|
if (!has_sha1_file(sha1))
|
2006-07-06 06:28:20 +02:00
|
|
|
return -1;
|
2006-07-06 03:00:02 +02:00
|
|
|
|
|
|
|
|
o = lookup_object(sha1);
|
|
|
|
|
if (!(o && o->parsed))
|
|
|
|
|
o = parse_object(sha1);
|
|
|
|
|
if (!o)
|
|
|
|
|
die("oops (%s)", sha1_to_hex(sha1));
|
2006-08-13 07:16:51 +02:00
|
|
|
if (o->type == OBJ_COMMIT) {
|
2006-07-06 03:00:02 +02:00
|
|
|
struct commit_list *parents;
|
2006-07-06 06:28:20 +02:00
|
|
|
struct commit *commit = (struct commit *)o;
|
2006-07-06 03:00:02 +02:00
|
|
|
if (o->flags & THEY_HAVE)
|
2006-07-06 06:28:20 +02:00
|
|
|
we_knew_they_have = 1;
|
|
|
|
|
else
|
|
|
|
|
o->flags |= THEY_HAVE;
|
|
|
|
|
if (!oldest_have || (commit->date < oldest_have))
|
|
|
|
|
oldest_have = commit->date;
|
|
|
|
|
for (parents = commit->parents;
|
2006-07-06 03:00:02 +02:00
|
|
|
parents;
|
|
|
|
|
parents = parents->next)
|
|
|
|
|
parents->item->object.flags |= THEY_HAVE;
|
2005-07-05 00:29:17 +02:00
|
|
|
}
|
2006-07-06 06:28:20 +02:00
|
|
|
if (!we_knew_they_have) {
|
|
|
|
|
add_object_array(o, NULL, &have_obj);
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int reachable(struct commit *want)
|
|
|
|
|
{
|
|
|
|
|
struct commit_list *work = NULL;
|
|
|
|
|
|
2010-11-27 02:58:14 +01:00
|
|
|
commit_list_insert_by_date(want, &work);
|
2006-07-06 06:28:20 +02:00
|
|
|
while (work) {
|
|
|
|
|
struct commit_list *list = work->next;
|
|
|
|
|
struct commit *commit = work->item;
|
|
|
|
|
free(work);
|
|
|
|
|
work = list;
|
|
|
|
|
|
|
|
|
|
if (commit->object.flags & THEY_HAVE) {
|
|
|
|
|
want->object.flags |= COMMON_KNOWN;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
if (!commit->object.parsed)
|
|
|
|
|
parse_object(commit->object.sha1);
|
|
|
|
|
if (commit->object.flags & REACHABLE)
|
|
|
|
|
continue;
|
|
|
|
|
commit->object.flags |= REACHABLE;
|
|
|
|
|
if (commit->date < oldest_have)
|
|
|
|
|
continue;
|
|
|
|
|
for (list = commit->parents; list; list = list->next) {
|
|
|
|
|
struct commit *parent = list->item;
|
|
|
|
|
if (!(parent->object.flags & REACHABLE))
|
2010-11-27 02:58:14 +01:00
|
|
|
commit_list_insert_by_date(parent, &work);
|
2006-07-06 06:28:20 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
want->object.flags |= REACHABLE;
|
|
|
|
|
clear_commit_marks(want, REACHABLE);
|
|
|
|
|
free_commit_list(work);
|
|
|
|
|
return (want->object.flags & COMMON_KNOWN);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int ok_to_give_up(void)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
if (!have_obj.nr)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < want_obj.nr; i++) {
|
|
|
|
|
struct object *want = want_obj.objects[i].item;
|
|
|
|
|
|
|
|
|
|
if (want->flags & COMMON_KNOWN)
|
|
|
|
|
continue;
|
|
|
|
|
want = deref_tag(want, "a want line", 0);
|
|
|
|
|
if (!want || want->type != OBJ_COMMIT) {
|
|
|
|
|
/* no way to tell if this is reachable by
|
|
|
|
|
* looking at the ancestry chain alone, so
|
|
|
|
|
* leave a note to ourselves not to worry about
|
|
|
|
|
* this object anymore.
|
|
|
|
|
*/
|
|
|
|
|
want_obj.objects[i].item->flags |= COMMON_KNOWN;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
if (!reachable((struct commit *)want))
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2005-07-05 00:29:17 +02:00
|
|
|
return 1;
|
2005-07-04 22:26:53 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int get_common_commits(void)
|
|
|
|
|
{
|
|
|
|
|
static char line[1000];
|
2006-07-06 03:12:12 +02:00
|
|
|
unsigned char sha1[20];
|
2009-10-31 01:47:25 +01:00
|
|
|
char last_hex[41];
|
2011-03-15 00:48:39 +01:00
|
|
|
int got_common = 0;
|
|
|
|
|
int got_other = 0;
|
2011-03-29 21:29:10 +02:00
|
|
|
int sent_ready = 0;
|
2005-07-04 22:26:53 +02:00
|
|
|
|
2005-10-28 04:48:32 +02:00
|
|
|
save_commit_buffer = 0;
|
|
|
|
|
|
2009-09-01 07:35:10 +02:00
|
|
|
for (;;) {
|
2009-03-07 21:02:26 +01:00
|
|
|
int len = packet_read_line(0, line, sizeof(line));
|
2005-10-19 23:27:01 +02:00
|
|
|
reset_timeout();
|
2005-07-04 22:26:53 +02:00
|
|
|
|
|
|
|
|
if (!len) {
|
2011-03-15 00:48:39 +01:00
|
|
|
if (multi_ack == 2 && got_common
|
2011-03-29 21:29:10 +02:00
|
|
|
&& !got_other && ok_to_give_up()) {
|
|
|
|
|
sent_ready = 1;
|
2011-03-15 00:48:39 +01:00
|
|
|
packet_write(1, "ACK %s ready\n", last_hex);
|
2011-03-29 21:29:10 +02:00
|
|
|
}
|
2006-07-06 03:00:02 +02:00
|
|
|
if (have_obj.nr == 0 || multi_ack)
|
2005-10-28 04:49:16 +02:00
|
|
|
packet_write(1, "NAK\n");
|
2011-03-29 21:29:10 +02:00
|
|
|
|
|
|
|
|
if (no_done && sent_ready) {
|
|
|
|
|
packet_write(1, "ACK %s\n", last_hex);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2009-10-31 01:47:33 +01:00
|
|
|
if (stateless_rpc)
|
|
|
|
|
exit(0);
|
2011-03-15 00:48:39 +01:00
|
|
|
got_common = 0;
|
|
|
|
|
got_other = 0;
|
2005-07-04 22:26:53 +02:00
|
|
|
continue;
|
|
|
|
|
}
|
2009-03-07 21:02:26 +01:00
|
|
|
strip(line, len);
|
Mechanical conversion to use prefixcmp()
This mechanically converts strncmp() to use prefixcmp(), but only when
the parameters match specific patterns, so that they can be verified
easily. Leftover from this will be fixed in a separate step, including
idiotic conversions like
if (!strncmp("foo", arg, 3))
=>
if (!(-prefixcmp(arg, "foo")))
This was done by using this script in px.perl
#!/usr/bin/perl -i.bak -p
if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) {
s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|;
}
if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) {
s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|;
}
and running:
$ git grep -l strncmp -- '*.c' | xargs perl px.perl
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20 10:53:29 +01:00
|
|
|
if (!prefixcmp(line, "have ")) {
|
2006-07-06 06:28:20 +02:00
|
|
|
switch (got_sha1(line+5, sha1)) {
|
|
|
|
|
case -1: /* they have what we do not */
|
2011-03-15 00:48:39 +01:00
|
|
|
got_other = 1;
|
2009-10-31 01:47:25 +01:00
|
|
|
if (multi_ack && ok_to_give_up()) {
|
|
|
|
|
const char *hex = sha1_to_hex(sha1);
|
2011-03-29 21:29:10 +02:00
|
|
|
if (multi_ack == 2) {
|
|
|
|
|
sent_ready = 1;
|
2009-10-31 01:47:25 +01:00
|
|
|
packet_write(1, "ACK %s ready\n", hex);
|
2011-03-29 21:29:10 +02:00
|
|
|
} else
|
2009-10-31 01:47:25 +01:00
|
|
|
packet_write(1, "ACK %s continue\n", hex);
|
|
|
|
|
}
|
2006-07-06 06:28:20 +02:00
|
|
|
break;
|
|
|
|
|
default:
|
2011-03-15 00:48:39 +01:00
|
|
|
got_common = 1;
|
2009-10-31 01:47:25 +01:00
|
|
|
memcpy(last_hex, sha1_to_hex(sha1), 41);
|
|
|
|
|
if (multi_ack == 2)
|
|
|
|
|
packet_write(1, "ACK %s common\n", last_hex);
|
|
|
|
|
else if (multi_ack)
|
|
|
|
|
packet_write(1, "ACK %s continue\n", last_hex);
|
2006-07-06 03:12:12 +02:00
|
|
|
else if (have_obj.nr == 1)
|
2009-10-31 01:47:25 +01:00
|
|
|
packet_write(1, "ACK %s\n", last_hex);
|
2006-07-06 06:28:20 +02:00
|
|
|
break;
|
2005-10-25 23:55:24 +02:00
|
|
|
}
|
2005-07-04 22:26:53 +02:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
if (!strcmp(line, "done")) {
|
2006-07-06 03:00:02 +02:00
|
|
|
if (have_obj.nr > 0) {
|
2005-10-28 04:49:16 +02:00
|
|
|
if (multi_ack)
|
2006-07-06 03:12:12 +02:00
|
|
|
packet_write(1, "ACK %s\n", last_hex);
|
2005-10-28 04:49:16 +02:00
|
|
|
return 0;
|
|
|
|
|
}
|
2005-07-04 22:26:53 +02:00
|
|
|
packet_write(1, "NAK\n");
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
2008-08-31 18:39:19 +02:00
|
|
|
die("git upload-pack: expected SHA1 list, got '%s'", line);
|
2005-07-04 22:26:53 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2006-07-06 03:00:02 +02:00
|
|
|
static void receive_needs(void)
|
2005-07-05 00:29:17 +02:00
|
|
|
{
|
2010-08-29 04:04:17 +02:00
|
|
|
struct object_array shallows = OBJECT_ARRAY_INIT;
|
2005-07-05 00:29:17 +02:00
|
|
|
static char line[1000];
|
allow cloning a repository "shallowly"
By specifying a depth, you can now clone a repository such that
all fetched ancestor-chains' length is at most "depth". For example,
if the upstream repository has only 2 branches ("A" and "B"), which
are linear, and you specify depth 3, you will get A, A~1, A~2, A~3,
B, B~1, B~2, and B~3. The ends are automatically made shallow
commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-30 20:09:29 +01:00
|
|
|
int len, depth = 0;
|
2005-07-05 00:29:17 +02:00
|
|
|
|
2009-06-10 01:50:18 +02:00
|
|
|
shallow_nr = 0;
|
2008-03-03 03:35:18 +01:00
|
|
|
if (debug_fd)
|
use write_str_in_full helper to avoid literal string lengths
In 2d14d65 (Use a clearer style to issue commands to remote helpers,
2009-09-03) I happened to notice two changes like this:
- write_in_full(helper->in, "list\n", 5);
+
+ strbuf_addstr(&buf, "list\n");
+ write_in_full(helper->in, buf.buf, buf.len);
+ strbuf_reset(&buf);
IMHO, it would be better to define a new function,
static inline ssize_t write_str_in_full(int fd, const char *str)
{
return write_in_full(fd, str, strlen(str));
}
and then use it like this:
- strbuf_addstr(&buf, "list\n");
- write_in_full(helper->in, buf.buf, buf.len);
- strbuf_reset(&buf);
+ write_str_in_full(helper->in, "list\n");
Thus not requiring the added allocation, and still avoiding
the maintenance risk of literal string lengths.
These days, compilers are good enough that strlen("literal")
imposes no run-time cost.
Transformed via this:
perl -pi -e \
's/write_in_full\((.*?), (".*?"), \d+\)/write_str_in_full($1, $2)/'\
$(git grep -l 'write_in_full.*"')
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-12 10:54:32 +02:00
|
|
|
write_str_in_full(debug_fd, "#S\n");
|
2005-07-05 00:29:17 +02:00
|
|
|
for (;;) {
|
2005-10-25 03:59:18 +02:00
|
|
|
struct object *o;
|
2006-07-06 02:41:39 +02:00
|
|
|
unsigned char sha1_buf[20];
|
2005-07-05 00:29:17 +02:00
|
|
|
len = packet_read_line(0, line, sizeof(line));
|
2005-10-19 23:27:01 +02:00
|
|
|
reset_timeout();
|
2005-07-05 00:29:17 +02:00
|
|
|
if (!len)
|
2006-10-30 20:09:06 +01:00
|
|
|
break;
|
2008-03-03 03:35:18 +01:00
|
|
|
if (debug_fd)
|
|
|
|
|
write_in_full(debug_fd, line, len);
|
2005-10-05 23:49:54 +02:00
|
|
|
|
2007-02-20 10:54:00 +01:00
|
|
|
if (!prefixcmp(line, "shallow ")) {
|
2006-10-30 20:09:06 +01:00
|
|
|
unsigned char sha1[20];
|
|
|
|
|
struct object *object;
|
|
|
|
|
if (get_sha1(line + 8, sha1))
|
|
|
|
|
die("invalid shallow line: %s", line);
|
|
|
|
|
object = parse_object(sha1);
|
|
|
|
|
if (!object)
|
|
|
|
|
die("did not find object for %s", line);
|
2006-10-30 20:09:53 +01:00
|
|
|
object->flags |= CLIENT_SHALLOW;
|
2006-10-30 20:09:06 +01:00
|
|
|
add_object_array(object, NULL, &shallows);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2007-02-20 10:54:00 +01:00
|
|
|
if (!prefixcmp(line, "deepen ")) {
|
allow cloning a repository "shallowly"
By specifying a depth, you can now clone a repository such that
all fetched ancestor-chains' length is at most "depth". For example,
if the upstream repository has only 2 branches ("A" and "B"), which
are linear, and you specify depth 3, you will get A, A~1, A~2, A~3,
B, B~1, B~2, and B~3. The ends are automatically made shallow
commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-30 20:09:29 +01:00
|
|
|
char *end;
|
|
|
|
|
depth = strtol(line + 7, &end, 0);
|
|
|
|
|
if (end == line + 7 || depth <= 0)
|
|
|
|
|
die("Invalid deepen: %s", line);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2007-02-20 10:54:00 +01:00
|
|
|
if (prefixcmp(line, "want ") ||
|
2006-07-06 02:41:39 +02:00
|
|
|
get_sha1_hex(line+5, sha1_buf))
|
2008-08-31 18:39:19 +02:00
|
|
|
die("git upload-pack: protocol error, "
|
2005-10-05 23:49:54 +02:00
|
|
|
"expected to get sha, not '%s'", line);
|
2009-10-31 01:47:25 +01:00
|
|
|
if (strstr(line+45, "multi_ack_detailed"))
|
|
|
|
|
multi_ack = 2;
|
|
|
|
|
else if (strstr(line+45, "multi_ack"))
|
2005-10-28 04:49:16 +02:00
|
|
|
multi_ack = 1;
|
2011-03-29 21:29:10 +02:00
|
|
|
if (strstr(line+45, "no-done"))
|
|
|
|
|
no_done = 1;
|
2006-02-20 09:38:39 +01:00
|
|
|
if (strstr(line+45, "thin-pack"))
|
|
|
|
|
use_thin_pack = 1;
|
2006-09-26 17:27:39 +02:00
|
|
|
if (strstr(line+45, "ofs-delta"))
|
|
|
|
|
use_ofs_delta = 1;
|
2006-09-11 01:27:08 +02:00
|
|
|
if (strstr(line+45, "side-band-64k"))
|
|
|
|
|
use_sideband = LARGE_PACKET_MAX;
|
|
|
|
|
else if (strstr(line+45, "side-band"))
|
|
|
|
|
use_sideband = DEFAULT_PACKET_MAX;
|
2007-02-23 20:03:10 +01:00
|
|
|
if (strstr(line+45, "no-progress"))
|
|
|
|
|
no_progress = 1;
|
2008-03-04 04:27:33 +01:00
|
|
|
if (strstr(line+45, "include-tag"))
|
|
|
|
|
use_include_tag = 1;
|
2005-10-25 03:59:18 +02:00
|
|
|
|
|
|
|
|
/* We have sent all our refs already, and the other end
|
|
|
|
|
* should have chosen out of them; otherwise they are
|
|
|
|
|
* asking for nonsense.
|
|
|
|
|
*
|
|
|
|
|
* Hmph. We may later want to allow "want" line that
|
|
|
|
|
* asks for something like "master~10" (symbolic)...
|
|
|
|
|
* would it make sense? I don't know.
|
|
|
|
|
*/
|
|
|
|
|
o = lookup_object(sha1_buf);
|
|
|
|
|
if (!o || !(o->flags & OUR_REF))
|
2010-07-31 22:11:46 +02:00
|
|
|
die("git upload-pack: not our ref %s",
|
|
|
|
|
sha1_to_hex(sha1_buf));
|
2005-10-25 03:59:18 +02:00
|
|
|
if (!(o->flags & WANTED)) {
|
|
|
|
|
o->flags |= WANTED;
|
2006-07-06 03:00:02 +02:00
|
|
|
add_object_array(o, NULL, &want_obj);
|
2005-10-25 03:59:18 +02:00
|
|
|
}
|
2005-07-05 00:29:17 +02:00
|
|
|
}
|
2008-03-03 03:35:18 +01:00
|
|
|
if (debug_fd)
|
use write_str_in_full helper to avoid literal string lengths
In 2d14d65 (Use a clearer style to issue commands to remote helpers,
2009-09-03) I happened to notice two changes like this:
- write_in_full(helper->in, "list\n", 5);
+
+ strbuf_addstr(&buf, "list\n");
+ write_in_full(helper->in, buf.buf, buf.len);
+ strbuf_reset(&buf);
IMHO, it would be better to define a new function,
static inline ssize_t write_str_in_full(int fd, const char *str)
{
return write_in_full(fd, str, strlen(str));
}
and then use it like this:
- strbuf_addstr(&buf, "list\n");
- write_in_full(helper->in, buf.buf, buf.len);
- strbuf_reset(&buf);
+ write_str_in_full(helper->in, "list\n");
Thus not requiring the added allocation, and still avoiding
the maintenance risk of literal string lengths.
These days, compilers are good enough that strlen("literal")
imposes no run-time cost.
Transformed via this:
perl -pi -e \
's/write_in_full\((.*?), (".*?"), \d+\)/write_str_in_full($1, $2)/'\
$(git grep -l 'write_in_full.*"')
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-12 10:54:32 +02:00
|
|
|
write_str_in_full(debug_fd, "#E\n");
|
2009-06-16 20:41:16 +02:00
|
|
|
|
|
|
|
|
if (!use_sideband && daemon_mode)
|
|
|
|
|
no_progress = 1;
|
|
|
|
|
|
2006-10-30 20:09:53 +01:00
|
|
|
if (depth == 0 && shallows.nr == 0)
|
|
|
|
|
return;
|
allow cloning a repository "shallowly"
By specifying a depth, you can now clone a repository such that
all fetched ancestor-chains' length is at most "depth". For example,
if the upstream repository has only 2 branches ("A" and "B"), which
are linear, and you specify depth 3, you will get A, A~1, A~2, A~3,
B, B~1, B~2, and B~3. The ends are automatically made shallow
commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-30 20:09:29 +01:00
|
|
|
if (depth > 0) {
|
|
|
|
|
struct commit_list *result, *backup;
|
2006-10-30 20:09:53 +01:00
|
|
|
int i;
|
|
|
|
|
backup = result = get_shallow_commits(&want_obj, depth,
|
|
|
|
|
SHALLOW, NOT_SHALLOW);
|
allow cloning a repository "shallowly"
By specifying a depth, you can now clone a repository such that
all fetched ancestor-chains' length is at most "depth". For example,
if the upstream repository has only 2 branches ("A" and "B"), which
are linear, and you specify depth 3, you will get A, A~1, A~2, A~3,
B, B~1, B~2, and B~3. The ends are automatically made shallow
commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-30 20:09:29 +01:00
|
|
|
while (result) {
|
2006-10-30 20:09:53 +01:00
|
|
|
struct object *object = &result->item->object;
|
2006-11-24 15:58:25 +01:00
|
|
|
if (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) {
|
2006-10-30 20:09:53 +01:00
|
|
|
packet_write(1, "shallow %s",
|
|
|
|
|
sha1_to_hex(object->sha1));
|
|
|
|
|
register_shallow(object->sha1);
|
2009-06-10 01:50:18 +02:00
|
|
|
shallow_nr++;
|
2006-10-30 20:09:53 +01:00
|
|
|
}
|
allow cloning a repository "shallowly"
By specifying a depth, you can now clone a repository such that
all fetched ancestor-chains' length is at most "depth". For example,
if the upstream repository has only 2 branches ("A" and "B"), which
are linear, and you specify depth 3, you will get A, A~1, A~2, A~3,
B, B~1, B~2, and B~3. The ends are automatically made shallow
commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-30 20:09:29 +01:00
|
|
|
result = result->next;
|
|
|
|
|
}
|
|
|
|
|
free_commit_list(backup);
|
2006-10-30 20:09:53 +01:00
|
|
|
for (i = 0; i < shallows.nr; i++) {
|
|
|
|
|
struct object *object = shallows.objects[i].item;
|
|
|
|
|
if (object->flags & NOT_SHALLOW) {
|
|
|
|
|
struct commit_list *parents;
|
|
|
|
|
packet_write(1, "unshallow %s",
|
|
|
|
|
sha1_to_hex(object->sha1));
|
|
|
|
|
object->flags &= ~CLIENT_SHALLOW;
|
|
|
|
|
/* make sure the real parents are parsed */
|
|
|
|
|
unregister_shallow(object->sha1);
|
2006-11-14 07:47:46 +01:00
|
|
|
object->parsed = 0;
|
2008-02-18 21:48:03 +01:00
|
|
|
if (parse_commit((struct commit *)object))
|
|
|
|
|
die("invalid commit");
|
2006-10-30 20:09:53 +01:00
|
|
|
parents = ((struct commit *)object)->parents;
|
|
|
|
|
while (parents) {
|
|
|
|
|
add_object_array(&parents->item->object,
|
|
|
|
|
NULL, &want_obj);
|
|
|
|
|
parents = parents->next;
|
|
|
|
|
}
|
2009-09-04 01:08:33 +02:00
|
|
|
add_object_array(object, NULL, &extra_edge_obj);
|
2006-10-30 20:09:53 +01:00
|
|
|
}
|
|
|
|
|
/* make sure commit traversal conforms to client */
|
|
|
|
|
register_shallow(object->sha1);
|
|
|
|
|
}
|
|
|
|
|
packet_flush(1);
|
|
|
|
|
} else
|
|
|
|
|
if (shallows.nr > 0) {
|
|
|
|
|
int i;
|
|
|
|
|
for (i = 0; i < shallows.nr; i++)
|
|
|
|
|
register_shallow(shallows.objects[i].item->sha1);
|
|
|
|
|
}
|
2009-06-10 01:50:18 +02:00
|
|
|
|
|
|
|
|
shallow_nr += shallows.nr;
|
2006-10-30 20:09:53 +01:00
|
|
|
free(shallows.objects);
|
2005-07-05 00:29:17 +02:00
|
|
|
}
|
|
|
|
|
|
2006-09-21 07:02:01 +02:00
|
|
|
static int send_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
|
2005-07-04 22:26:53 +02:00
|
|
|
{
|
2006-10-30 20:09:06 +01:00
|
|
|
static const char *capabilities = "multi_ack thin-pack side-band"
|
2008-03-04 04:27:33 +01:00
|
|
|
" side-band-64k ofs-delta shallow no-progress"
|
2009-10-31 01:47:25 +01:00
|
|
|
" include-tag multi_ack_detailed";
|
2005-10-14 03:57:40 +02:00
|
|
|
struct object *o = parse_object(sha1);
|
|
|
|
|
|
2006-02-18 01:14:52 +01:00
|
|
|
if (!o)
|
2008-08-31 18:39:19 +02:00
|
|
|
die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
|
2006-02-18 01:14:52 +01:00
|
|
|
|
2005-10-28 05:56:41 +02:00
|
|
|
if (capabilities)
|
2011-03-29 19:24:59 +02:00
|
|
|
packet_write(1, "%s %s%c%s%s\n", sha1_to_hex(sha1), refname,
|
|
|
|
|
0, capabilities,
|
|
|
|
|
stateless_rpc ? " no-done" : "");
|
2005-10-28 05:56:41 +02:00
|
|
|
else
|
|
|
|
|
packet_write(1, "%s %s\n", sha1_to_hex(sha1), refname);
|
|
|
|
|
capabilities = NULL;
|
2005-10-25 03:59:18 +02:00
|
|
|
if (!(o->flags & OUR_REF)) {
|
|
|
|
|
o->flags |= OUR_REF;
|
|
|
|
|
nr_our_refs++;
|
|
|
|
|
}
|
2006-07-12 05:45:31 +02:00
|
|
|
if (o->type == OBJ_TAG) {
|
2005-11-03 00:19:13 +01:00
|
|
|
o = deref_tag(o, refname, 0);
|
2008-02-18 08:31:54 +01:00
|
|
|
if (o)
|
|
|
|
|
packet_write(1, "%s %s^{}\n", sha1_to_hex(o->sha1), refname);
|
2005-10-14 03:57:40 +02:00
|
|
|
}
|
2005-07-04 22:26:53 +02:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2009-10-31 01:47:33 +01:00
|
|
|
static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
|
|
|
|
|
{
|
|
|
|
|
struct object *o = parse_object(sha1);
|
|
|
|
|
if (!o)
|
|
|
|
|
die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
|
|
|
|
|
if (!(o->flags & OUR_REF)) {
|
|
|
|
|
o->flags |= OUR_REF;
|
|
|
|
|
nr_our_refs++;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2006-08-14 22:40:51 +02:00
|
|
|
static void upload_pack(void)
|
2005-07-04 22:26:53 +02:00
|
|
|
{
|
2009-10-31 01:47:33 +01:00
|
|
|
if (advertise_refs || !stateless_rpc) {
|
|
|
|
|
reset_timeout();
|
|
|
|
|
head_ref(send_ref, NULL);
|
|
|
|
|
for_each_ref(send_ref, NULL);
|
|
|
|
|
packet_flush(1);
|
|
|
|
|
} else {
|
|
|
|
|
head_ref(mark_our_ref, NULL);
|
|
|
|
|
for_each_ref(mark_our_ref, NULL);
|
|
|
|
|
}
|
|
|
|
|
if (advertise_refs)
|
|
|
|
|
return;
|
|
|
|
|
|
2006-07-06 03:00:02 +02:00
|
|
|
receive_needs();
|
2006-08-14 22:40:51 +02:00
|
|
|
if (want_obj.nr) {
|
|
|
|
|
get_common_commits();
|
|
|
|
|
create_pack_file();
|
|
|
|
|
}
|
2005-07-04 22:26:53 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int main(int argc, char **argv)
|
|
|
|
|
{
|
2005-11-17 20:37:14 +01:00
|
|
|
char *dir;
|
2005-10-19 23:27:01 +02:00
|
|
|
int i;
|
|
|
|
|
int strict = 0;
|
|
|
|
|
|
2011-02-24 15:30:19 +01:00
|
|
|
packet_trace_identity("upload-pack");
|
2009-01-18 13:00:12 +01:00
|
|
|
git_extract_argv0_path(argv[0]);
|
2009-01-23 10:07:46 +01:00
|
|
|
read_replace_refs = 0;
|
2009-01-18 13:00:12 +01:00
|
|
|
|
2005-10-19 23:27:01 +02:00
|
|
|
for (i = 1; i < argc; i++) {
|
|
|
|
|
char *arg = argv[i];
|
|
|
|
|
|
|
|
|
|
if (arg[0] != '-')
|
|
|
|
|
break;
|
2009-10-31 01:47:33 +01:00
|
|
|
if (!strcmp(arg, "--advertise-refs")) {
|
|
|
|
|
advertise_refs = 1;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
if (!strcmp(arg, "--stateless-rpc")) {
|
|
|
|
|
stateless_rpc = 1;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2005-10-19 23:27:01 +02:00
|
|
|
if (!strcmp(arg, "--strict")) {
|
|
|
|
|
strict = 1;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
Mechanical conversion to use prefixcmp()
This mechanically converts strncmp() to use prefixcmp(), but only when
the parameters match specific patterns, so that they can be verified
easily. Leftover from this will be fixed in a separate step, including
idiotic conversions like
if (!strncmp("foo", arg, 3))
=>
if (!(-prefixcmp(arg, "foo")))
This was done by using this script in px.perl
#!/usr/bin/perl -i.bak -p
if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) {
s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|;
}
if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) {
s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|;
}
and running:
$ git grep -l strncmp -- '*.c' | xargs perl px.perl
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20 10:53:29 +01:00
|
|
|
if (!prefixcmp(arg, "--timeout=")) {
|
2005-10-19 23:27:01 +02:00
|
|
|
timeout = atoi(arg+10);
|
2009-06-16 20:41:16 +02:00
|
|
|
daemon_mode = 1;
|
2005-10-19 23:27:01 +02:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
if (!strcmp(arg, "--")) {
|
|
|
|
|
i++;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2007-06-07 09:04:01 +02:00
|
|
|
|
2005-10-19 23:27:01 +02:00
|
|
|
if (i != argc-1)
|
2005-07-04 22:26:53 +02:00
|
|
|
usage(upload_pack_usage);
|
2008-02-12 12:28:01 +01:00
|
|
|
|
2008-07-21 21:19:52 +02:00
|
|
|
setup_path();
|
2008-02-12 12:28:01 +01:00
|
|
|
|
2005-10-19 23:27:01 +02:00
|
|
|
dir = argv[i];
|
2005-07-09 01:22:22 +02:00
|
|
|
|
2005-11-17 20:37:14 +01:00
|
|
|
if (!enter_repo(dir, strict))
|
2009-03-04 09:32:29 +01:00
|
|
|
die("'%s' does not appear to be a git repository", dir);
|
2007-01-22 07:23:58 +01:00
|
|
|
if (is_repository_shallow())
|
|
|
|
|
die("attempt to fetch/clone from a shallow repository");
|
2008-03-03 03:35:18 +01:00
|
|
|
if (getenv("GIT_DEBUG_SEND_PACK"))
|
|
|
|
|
debug_fd = atoi(getenv("GIT_DEBUG_SEND_PACK"));
|
2005-07-04 22:26:53 +02:00
|
|
|
upload_pack();
|
|
|
|
|
return 0;
|
|
|
|
|
}
|