mirrors/git
0
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-24 10:26:17 +08:00
Code Issues Packages Projects Releases Wiki Activity
a3431febfe
git/send-pack.c

327 lines
7.2 KiB
C
Raw Normal View History

Start of "git-send-pack", the local part of sending off a pack Like git-receive-pack, this is only partway done.
2005-06-30 10:09:05 +08:00
#include "cache.h"
git-send-pack: verify that sender is a proper superset of receiver This should make sure that if you have multiple people pushing to the same tree, they cannot overwrite each others work, but have to merge before being able to update the common reference tree.
2005-07-19 19:03:47 +08:00
#include "commit.h"
Fix send-pack for non-commitish tags. Again I left the v2.6.11-tree tag behind. My bad. This commit makes sure that we do not barf when pushing a ref that is a non-commitish tag. You can update a remote ref under the following conditions: * You can always use --force. * Creating a brand new ref is OK. * If the remote ref is exactly the same as what you are pushing, it is OK (nothing is pushed). * You can replace a commitish with another commitish which is a descendant of it, if you can verify the ancestry between them; this and the above means you have to have what you are replacing. * Otherwise you cannot update; you need to use --force. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-05 15:47:56 +08:00
#include "tag.h"
Teach 'git-send-pack' to send new branches and tags. The protocol always supported it, but send-pack didn't actually know how to tell the other side about a new branch/tag. NOTE! You'll have to name it explicitly on the command line: if you don't name any branches, git-send-pack will default to the branches that already exist.
2005-07-09 04:58:40 +08:00
#include "refs.h"
Make send/receive-pack be closer to doing something interesting
2005-06-30 11:50:15 +08:00
#include "pkt-line.h"
Start of "git-send-pack", the local part of sending off a pack Like git-receive-pack, this is only partway done.
2005-06-30 10:09:05 +08:00
[PATCH] Documentation: send/receive. This adds documentation for 'smarter push' family of commands. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-14 15:10:05 +08:00
static const char send_pack_usage[] =
Make send-pack --all and explicit ref mutually exclusive. send-pack had a confusing misfeature that "send-pack --all master" updated all refs, while "send-pack --all" did not do anything. Make --all and explicit refs mutually exclusive, and make sure "send-pack --all" updates all refs. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-03 03:20:27 +08:00
"git-send-pack [--all] [--exec=git-receive-pack] <remote> [<head>...]\n"
" --all and explicit <head> specification are mutually exclusive.";
Start of "git-send-pack", the local part of sending off a pack Like git-receive-pack, this is only partway done.
2005-06-30 10:09:05 +08:00
static const char *exec = "git-receive-pack";
git-send-pack: add "--all" option to send all refs to the other side This affects only refs that the other side doesn't already have. The ones it has are still filtered by the ref selection.
2005-07-17 04:26:33 +08:00
static int send_all = 0;
git-send-pack: verify that sender is a proper superset of receiver This should make sure that if you have multiple people pushing to the same tree, they cannot overwrite each others work, but have to merge before being able to update the common reference tree.
2005-07-19 19:03:47 +08:00
static int force_update = 0;
Start of "git-send-pack", the local part of sending off a pack Like git-receive-pack, this is only partway done.
2005-06-30 10:09:05 +08:00
Teach 'git-send-pack' to send new branches and tags. The protocol always supported it, but send-pack didn't actually know how to tell the other side about a new branch/tag. NOTE! You'll have to name it explicitly on the command line: if you don't name any branches, git-send-pack will default to the branches that already exist.
2005-07-09 04:58:40 +08:00
static int is_zero_sha1(const unsigned char *sha1)
{
int i;
for (i = 0; i < 20; i++) {
if (*sha1++)
return 0;
}
return 1;
}
git-send-pack: actually send the object pack This concludes this lesson. I've actually successfully sent an update using the git-send-pack command. Probably tons of work still to do, and nasty debugging, but it's now actually potentially useful.
2005-07-01 01:17:39 +08:00
static void exec_pack_objects(void)
{
static char *args[] = {
"git-pack-objects",
"--stdout",
NULL
};
execvp("git-pack-objects", args);
die("git-pack-objects exec failed (%s)", strerror(errno));
}
static void exec_rev_list(struct ref *refs)
{
static char *args[1000];
int i = 0;
args[i++] = "git-rev-list"; /* 0 */
args[i++] = "--objects"; /* 1 */
while (refs) {
char *buf = malloc(100);
if (i > 900)
die("git-rev-list environment overflow");
send-pack: handle partial pushes correctly. When pushing into multi-user repository, or when pushing to a repository from a local repository that has rebased branches that has been pruned, the destination repository can have head commits that are missing from the local repository. This should not matter as long as the local head of the branch being pushed is a proper superset of the destination branch, but we ended up trying to run rev-list telling it to exclude objects reachable from those heads missing from the local repository, causing it to barf. Prune those heads from the rev-list parameter list, and make sure we do not try to push a branch whose remote head is something we lack. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 03:41:12 +08:00
if (!is_zero_sha1(refs->old_sha1) &&
has_sha1_file(refs->old_sha1)) {
Teach 'git-send-pack' to send new branches and tags. The protocol always supported it, but send-pack didn't actually know how to tell the other side about a new branch/tag. NOTE! You'll have to name it explicitly on the command line: if you don't name any branches, git-send-pack will default to the branches that already exist.
2005-07-09 04:58:40 +08:00
args[i++] = buf;
snprintf(buf, 50, "^%s", sha1_to_hex(refs->old_sha1));
buf += 50;
}
if (!is_zero_sha1(refs->new_sha1)) {
args[i++] = buf;
snprintf(buf, 50, "%s", sha1_to_hex(refs->new_sha1));
}
git-send-pack: actually send the object pack This concludes this lesson. I've actually successfully sent an update using the git-send-pack command. Probably tons of work still to do, and nasty debugging, but it's now actually potentially useful.
2005-07-01 01:17:39 +08:00
refs = refs->next;
}
args[i] = NULL;
execvp("git-rev-list", args);
die("git-rev-list exec failed (%s)", strerror(errno));
}
static void rev_list(int fd, struct ref *refs)
{
int pipe_fd[2];
pid_t pack_objects_pid;
if (pipe(pipe_fd) < 0)
die("rev-list setup: pipe failed");
pack_objects_pid = fork();
if (!pack_objects_pid) {
dup2(pipe_fd[0], 0);
dup2(fd, 1);
close(pipe_fd[0]);
close(pipe_fd[1]);
close(fd);
exec_pack_objects();
die("pack-objects setup failed");
}
if (pack_objects_pid < 0)
die("pack-objects fork failed");
dup2(pipe_fd[1], 1);
close(pipe_fd[0]);
close(pipe_fd[1]);
close(fd);
exec_rev_list(refs);
}
static int pack_objects(int fd, struct ref *refs)
{
pid_t rev_list_pid;
rev_list_pid = fork();
if (!rev_list_pid) {
rev_list(fd, refs);
die("rev-list setup failed");
}
if (rev_list_pid < 0)
die("rev-list fork failed");
/*
* We don't wait for the rev-list pipeline in the parent:
* we end up waiting for the other end instead
*/
Fix gcc warning in send-pack.c send_pack() was declared to return "int" (although nobody cared), but didn't actually return anything.
2005-07-04 01:00:01 +08:00
return 0;
git-send-pack: actually send the object pack This concludes this lesson. I've actually successfully sent an update using the git-send-pack command. Probably tons of work still to do, and nasty debugging, but it's now actually potentially useful.
2005-07-01 01:17:39 +08:00
}
git-send-pack: start parsing local/remote reference differences Right now it just shows which refs it picks up, and whether they are the same or changed on the remote end. Getting there..
2005-06-30 13:31:41 +08:00
Fix ref_newer() in send-pack. When more than two references need to be checked with ref_newer() function, the second and later calls did not work correctly. This was because the later calls found commits retained by the "struct object" layer that still had smudges made by earlier calls. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-06 14:05:33 +08:00
static void unmark_and_free(struct commit_list *list, unsigned int mark)
{
while (list) {
struct commit_list *temp = list;
temp->item->object.flags &= ~mark;
list = temp->next;
free(temp);
}
}
Fix send-pack for non-commitish tags. Again I left the v2.6.11-tree tag behind. My bad. This commit makes sure that we do not barf when pushing a ref that is a non-commitish tag. You can update a remote ref under the following conditions: * You can always use --force. * Creating a brand new ref is OK. * If the remote ref is exactly the same as what you are pushing, it is OK (nothing is pushed). * You can replace a commitish with another commitish which is a descendant of it, if you can verify the ancestry between them; this and the above means you have to have what you are replacing. * Otherwise you cannot update; you need to use --force. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-05 15:47:56 +08:00
static int ref_newer(const unsigned char *new_sha1,
const unsigned char *old_sha1)
Teach 'git-send-pack' to send new branches and tags. The protocol always supported it, but send-pack didn't actually know how to tell the other side about a new branch/tag. NOTE! You'll have to name it explicitly on the command line: if you don't name any branches, git-send-pack will default to the branches that already exist.
2005-07-09 04:58:40 +08:00
{
Fix send-pack for non-commitish tags. Again I left the v2.6.11-tree tag behind. My bad. This commit makes sure that we do not barf when pushing a ref that is a non-commitish tag. You can update a remote ref under the following conditions: * You can always use --force. * Creating a brand new ref is OK. * If the remote ref is exactly the same as what you are pushing, it is OK (nothing is pushed). * You can replace a commitish with another commitish which is a descendant of it, if you can verify the ancestry between them; this and the above means you have to have what you are replacing. * Otherwise you cannot update; you need to use --force. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-05 15:47:56 +08:00
struct object *o;
struct commit *old, *new;
Fix ref_newer() in send-pack. When more than two references need to be checked with ref_newer() function, the second and later calls did not work correctly. This was because the later calls found commits retained by the "struct object" layer that still had smudges made by earlier calls. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-06 14:05:33 +08:00
struct commit_list *list, *used;
int found = 0;
git-send-pack: verify that sender is a proper superset of receiver This should make sure that if you have multiple people pushing to the same tree, they cannot overwrite each others work, but have to merge before being able to update the common reference tree.
2005-07-19 19:03:47 +08:00
Fix send-pack for non-commitish tags. Again I left the v2.6.11-tree tag behind. My bad. This commit makes sure that we do not barf when pushing a ref that is a non-commitish tag. You can update a remote ref under the following conditions: * You can always use --force. * Creating a brand new ref is OK. * If the remote ref is exactly the same as what you are pushing, it is OK (nothing is pushed). * You can replace a commitish with another commitish which is a descendant of it, if you can verify the ancestry between them; this and the above means you have to have what you are replacing. * Otherwise you cannot update; you need to use --force. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-05 15:47:56 +08:00
/* Both new and old must be commit-ish and new is descendant of
* old. Otherwise we require --force.
*/
Be careful when dereferencing tags. One caller of deref_tag() was not careful enough to make sure what deref_tag() returned was not NULL (i.e. we found a tag object that points at an object we do not have). Fix it, and warn about refs that point at such an incomplete tag where needed. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-03 07:19:13 +08:00
o = deref_tag(parse_object(old_sha1), NULL, 0);
Fix send-pack for non-commitish tags. Again I left the v2.6.11-tree tag behind. My bad. This commit makes sure that we do not barf when pushing a ref that is a non-commitish tag. You can update a remote ref under the following conditions: * You can always use --force. * Creating a brand new ref is OK. * If the remote ref is exactly the same as what you are pushing, it is OK (nothing is pushed). * You can replace a commitish with another commitish which is a descendant of it, if you can verify the ancestry between them; this and the above means you have to have what you are replacing. * Otherwise you cannot update; you need to use --force. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-05 15:47:56 +08:00
if (!o || o->type != commit_type)
Teach 'git-send-pack' to send new branches and tags. The protocol always supported it, but send-pack didn't actually know how to tell the other side about a new branch/tag. NOTE! You'll have to name it explicitly on the command line: if you don't name any branches, git-send-pack will default to the branches that already exist.
2005-07-09 04:58:40 +08:00
return 0;
Fix send-pack for non-commitish tags. Again I left the v2.6.11-tree tag behind. My bad. This commit makes sure that we do not barf when pushing a ref that is a non-commitish tag. You can update a remote ref under the following conditions: * You can always use --force. * Creating a brand new ref is OK. * If the remote ref is exactly the same as what you are pushing, it is OK (nothing is pushed). * You can replace a commitish with another commitish which is a descendant of it, if you can verify the ancestry between them; this and the above means you have to have what you are replacing. * Otherwise you cannot update; you need to use --force. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-05 15:47:56 +08:00
old = (struct commit *) o;
Be careful when dereferencing tags. One caller of deref_tag() was not careful enough to make sure what deref_tag() returned was not NULL (i.e. we found a tag object that points at an object we do not have). Fix it, and warn about refs that point at such an incomplete tag where needed. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-03 07:19:13 +08:00
o = deref_tag(parse_object(new_sha1), NULL, 0);
Fix send-pack for non-commitish tags. Again I left the v2.6.11-tree tag behind. My bad. This commit makes sure that we do not barf when pushing a ref that is a non-commitish tag. You can update a remote ref under the following conditions: * You can always use --force. * Creating a brand new ref is OK. * If the remote ref is exactly the same as what you are pushing, it is OK (nothing is pushed). * You can replace a commitish with another commitish which is a descendant of it, if you can verify the ancestry between them; this and the above means you have to have what you are replacing. * Otherwise you cannot update; you need to use --force. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-05 15:47:56 +08:00
if (!o || o->type != commit_type)
git-send-pack: verify that sender is a proper superset of receiver This should make sure that if you have multiple people pushing to the same tree, they cannot overwrite each others work, but have to merge before being able to update the common reference tree.
2005-07-19 19:03:47 +08:00
return 0;
Fix send-pack for non-commitish tags. Again I left the v2.6.11-tree tag behind. My bad. This commit makes sure that we do not barf when pushing a ref that is a non-commitish tag. You can update a remote ref under the following conditions: * You can always use --force. * Creating a brand new ref is OK. * If the remote ref is exactly the same as what you are pushing, it is OK (nothing is pushed). * You can replace a commitish with another commitish which is a descendant of it, if you can verify the ancestry between them; this and the above means you have to have what you are replacing. * Otherwise you cannot update; you need to use --force. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-05 15:47:56 +08:00
new = (struct commit *) o;
git-send-pack: verify that sender is a proper superset of receiver This should make sure that if you have multiple people pushing to the same tree, they cannot overwrite each others work, but have to merge before being able to update the common reference tree.
2005-07-19 19:03:47 +08:00
if (parse_commit(new) < 0)
return 0;
Fix ref_newer() in send-pack. When more than two references need to be checked with ref_newer() function, the second and later calls did not work correctly. This was because the later calls found commits retained by the "struct object" layer that still had smudges made by earlier calls. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-06 14:05:33 +08:00
used = list = NULL;
git-send-pack: verify that sender is a proper superset of receiver This should make sure that if you have multiple people pushing to the same tree, they cannot overwrite each others work, but have to merge before being able to update the common reference tree.
2005-07-19 19:03:47 +08:00
commit_list_insert(new, &list);
Fix potential send-pack SIGSEGV The check that the source is ahead of the destination incorrectly expects pop_most_recent_commit() to gracefully handle an empty list. Fix by just checking the list itself, rather than the return value of the pop function. [jc: I did the test script that demonstrated the problem] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-27 11:04:22 +08:00
while (list) {
new = pop_most_recent_commit(&list, 1);
Fix ref_newer() in send-pack. When more than two references need to be checked with ref_newer() function, the second and later calls did not work correctly. This was because the later calls found commits retained by the "struct object" layer that still had smudges made by earlier calls. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-06 14:05:33 +08:00
commit_list_insert(new, &used);
if (new == old) {
found = 1;
break;
}
git-send-pack: verify that sender is a proper superset of receiver This should make sure that if you have multiple people pushing to the same tree, they cannot overwrite each others work, but have to merge before being able to update the common reference tree.
2005-07-19 19:03:47 +08:00
}
Fix ref_newer() in send-pack. When more than two references need to be checked with ref_newer() function, the second and later calls did not work correctly. This was because the later calls found commits retained by the "struct object" layer that still had smudges made by earlier calls. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-06 14:05:33 +08:00
unmark_and_free(list, 1);
unmark_and_free(used, 1);
return found;
Teach 'git-send-pack' to send new branches and tags. The protocol always supported it, but send-pack didn't actually know how to tell the other side about a new branch/tag. NOTE! You'll have to name it explicitly on the command line: if you don't name any branches, git-send-pack will default to the branches that already exist.
2005-07-09 04:58:40 +08:00
}
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
static struct ref *local_refs, **local_tail;
static struct ref *remote_refs, **remote_tail;
Teach 'git-send-pack' to send new branches and tags. The protocol always supported it, but send-pack didn't actually know how to tell the other side about a new branch/tag. NOTE! You'll have to name it explicitly on the command line: if you don't name any branches, git-send-pack will default to the branches that already exist.
2005-07-09 04:58:40 +08:00
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
static int one_local_ref(const char *refname, const unsigned char *sha1)
Teach 'git-send-pack' to send new branches and tags. The protocol always supported it, but send-pack didn't actually know how to tell the other side about a new branch/tag. NOTE! You'll have to name it explicitly on the command line: if you don't name any branches, git-send-pack will default to the branches that already exist.
2005-07-09 04:58:40 +08:00
{
struct ref *ref;
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
int len = strlen(refname) + 1;
ref = xcalloc(1, sizeof(*ref) + len);
Teach 'git-send-pack' to send new branches and tags. The protocol always supported it, but send-pack didn't actually know how to tell the other side about a new branch/tag. NOTE! You'll have to name it explicitly on the command line: if you don't name any branches, git-send-pack will default to the branches that already exist.
2005-07-09 04:58:40 +08:00
memcpy(ref->new_sha1, sha1, 20);
memcpy(ref->name, refname, len);
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
*local_tail = ref;
local_tail = &ref->next;
Teach 'git-send-pack' to send new branches and tags. The protocol always supported it, but send-pack didn't actually know how to tell the other side about a new branch/tag. NOTE! You'll have to name it explicitly on the command line: if you don't name any branches, git-send-pack will default to the branches that already exist.
2005-07-09 04:58:40 +08:00
return 0;
}
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
static void get_local_heads(void)
{
local_tail = &local_refs;
for_each_ref(one_local_ref);
}
static int send_pack(int in, int out, int nr_refspec, char **refspec)
Start of "git-send-pack", the local part of sending off a pack Like git-receive-pack, this is only partway done.
2005-06-30 10:09:05 +08:00
{
Slow but steady progress on git pack receive/send
2005-06-30 13:50:48 +08:00
struct ref *ref;
Teach 'git-send-pack' to send new branches and tags. The protocol always supported it, but send-pack didn't actually know how to tell the other side about a new branch/tag. NOTE! You'll have to name it explicitly on the command line: if you don't name any branches, git-send-pack will default to the branches that already exist.
2005-07-09 04:58:40 +08:00
int new_refs;
Make git-send-pack exit with error when some refs couldn't be pushed out In case some refs couldn't be pushed out due to an error (mostly the not-a-proper-subset error), make git-send-pack exit with non-zero status after the push is over (that is, it still tries to push out the rest of the refs). [jc: I adjusted a test for this change.] Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-14 08:45:40 +08:00
int ret = 0;
Slow but steady progress on git pack receive/send
2005-06-30 13:50:48 +08:00
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
/* No funny business with the matcher */
Ignore funny refname sent from remote This allows the remote side (most notably, upload-pack) to show additional information without affecting the downloader. Peek-remote does not ignore them -- this is to make it useful for Pasky's automatic tag following. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-14 09:57:40 +08:00
remote_tail = get_remote_heads(in, &remote_refs, 0, NULL, 1);
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
get_local_heads();
Teach 'git-send-pack' to send new branches and tags. The protocol always supported it, but send-pack didn't actually know how to tell the other side about a new branch/tag. NOTE! You'll have to name it explicitly on the command line: if you don't name any branches, git-send-pack will default to the branches that already exist.
2005-07-09 04:58:40 +08:00
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
/* match them up */
if (!remote_tail)
remote_tail = &remote_refs;
if (match_refs(local_refs, remote_refs, &remote_tail,
nr_refspec, refspec, send_all))
return -1;
Warn when send-pack does nothing If you try to push into an empty repository with no ref arguments to git push, it doesn't do anything and doesn't say anything. This adds a warning when send-pack isn't going to push anything, so you don't assume that it silently did what you wanted. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-05 00:59:37 +08:00
if (!remote_refs) {
fprintf(stderr, "No refs in common and none specified; doing nothing.\n");
return 0;
}
Teach 'git-send-pack' to send new branches and tags. The protocol always supported it, but send-pack didn't actually know how to tell the other side about a new branch/tag. NOTE! You'll have to name it explicitly on the command line: if you don't name any branches, git-send-pack will default to the branches that already exist.
2005-07-09 04:58:40 +08:00
/*
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
* Finally, tell the other end!
Teach 'git-send-pack' to send new branches and tags. The protocol always supported it, but send-pack didn't actually know how to tell the other side about a new branch/tag. NOTE! You'll have to name it explicitly on the command line: if you don't name any branches, git-send-pack will default to the branches that already exist.
2005-07-09 04:58:40 +08:00
*/
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
new_refs = 0;
for (ref = remote_refs; ref; ref = ref->next) {
char old_hex[60], *new_hex;
if (!ref->peer_ref)
Slow but steady progress on git pack receive/send
2005-06-30 13:50:48 +08:00
continue;
Fix send-pack for non-commitish tags. Again I left the v2.6.11-tree tag behind. My bad. This commit makes sure that we do not barf when pushing a ref that is a non-commitish tag. You can update a remote ref under the following conditions: * You can always use --force. * Creating a brand new ref is OK. * If the remote ref is exactly the same as what you are pushing, it is OK (nothing is pushed). * You can replace a commitish with another commitish which is a descendant of it, if you can verify the ancestry between them; this and the above means you have to have what you are replacing. * Otherwise you cannot update; you need to use --force. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-05 15:47:56 +08:00
if (!memcmp(ref->old_sha1, ref->peer_ref->new_sha1, 20)) {
fprintf(stderr, "'%s': up-to-date\n", ref->name);
continue;
}
/* This part determines what can overwrite what.
* The rules are:
*
Support +<src>:<dst> format in push as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 15:40:14 +08:00
* (0) you can always use --force or +A:B notation to
* selectively force individual ref pairs.
Fix send-pack for non-commitish tags. Again I left the v2.6.11-tree tag behind. My bad. This commit makes sure that we do not barf when pushing a ref that is a non-commitish tag. You can update a remote ref under the following conditions: * You can always use --force. * Creating a brand new ref is OK. * If the remote ref is exactly the same as what you are pushing, it is OK (nothing is pushed). * You can replace a commitish with another commitish which is a descendant of it, if you can verify the ancestry between them; this and the above means you have to have what you are replacing. * Otherwise you cannot update; you need to use --force. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-05 15:47:56 +08:00
*
* (1) if the old thing does not exist, it is OK.
*
* (2) if you do not have the old thing, you are not allowed
* to overwrite it; you would not know what you are losing
* otherwise.
*
* (3) if both new and old are commit-ish, and new is a
* descendant of old, it is OK.
*/
Support +<src>:<dst> format in push as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 15:40:14 +08:00
if (!force_update &&
!is_zero_sha1(ref->old_sha1) &&
!ref->force) {
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
if (!has_sha1_file(ref->old_sha1)) {
error("remote '%s' object %s does not "
"exist on local",
ref->name, sha1_to_hex(ref->old_sha1));
Make git-send-pack exit with error when some refs couldn't be pushed out In case some refs couldn't be pushed out due to an error (mostly the not-a-proper-subset error), make git-send-pack exit with non-zero status after the push is over (that is, it still tries to push out the rest of the refs). [jc: I adjusted a test for this change.] Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-14 08:45:40 +08:00
ret = -2;
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
continue;
}
Support +<src>:<dst> format in push as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 15:40:14 +08:00
Fix send-pack for non-commitish tags. Again I left the v2.6.11-tree tag behind. My bad. This commit makes sure that we do not barf when pushing a ref that is a non-commitish tag. You can update a remote ref under the following conditions: * You can always use --force. * Creating a brand new ref is OK. * If the remote ref is exactly the same as what you are pushing, it is OK (nothing is pushed). * You can replace a commitish with another commitish which is a descendant of it, if you can verify the ancestry between them; this and the above means you have to have what you are replacing. * Otherwise you cannot update; you need to use --force. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-05 15:47:56 +08:00
/* We assume that local is fsck-clean. Otherwise
Support +<src>:<dst> format in push as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 15:40:14 +08:00
* you _could_ have an old tag which points at
* something you do not have, which may or may not
Fix send-pack for non-commitish tags. Again I left the v2.6.11-tree tag behind. My bad. This commit makes sure that we do not barf when pushing a ref that is a non-commitish tag. You can update a remote ref under the following conditions: * You can always use --force. * Creating a brand new ref is OK. * If the remote ref is exactly the same as what you are pushing, it is OK (nothing is pushed). * You can replace a commitish with another commitish which is a descendant of it, if you can verify the ancestry between them; this and the above means you have to have what you are replacing. * Otherwise you cannot update; you need to use --force. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-05 15:47:56 +08:00
* be a commit.
*/
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
if (!ref_newer(ref->peer_ref->new_sha1,
ref->old_sha1)) {
error("remote ref '%s' is not a strict "
"subset of local ref '%s'.", ref->name,
ref->peer_ref->name);
Make git-send-pack exit with error when some refs couldn't be pushed out In case some refs couldn't be pushed out due to an error (mostly the not-a-proper-subset error), make git-send-pack exit with non-zero status after the push is over (that is, it still tries to push out the rest of the refs). [jc: I adjusted a test for this change.] Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-14 08:45:40 +08:00
ret = -2;
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
continue;
}
git-send-pack: start parsing local/remote reference differences Right now it just shows which refs it picks up, and whether they are the same or changed on the remote end. Getting there..
2005-06-30 13:31:41 +08:00
}
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
memcpy(ref->new_sha1, ref->peer_ref->new_sha1, 20);
if (is_zero_sha1(ref->new_sha1)) {
error("cannot happen anymore");
Make git-send-pack exit with error when some refs couldn't be pushed out In case some refs couldn't be pushed out due to an error (mostly the not-a-proper-subset error), make git-send-pack exit with non-zero status after the push is over (that is, it still tries to push out the rest of the refs). [jc: I adjusted a test for this change.] Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-14 08:45:40 +08:00
ret = -3;
Teach 'git-send-pack' to send new branches and tags. The protocol always supported it, but send-pack didn't actually know how to tell the other side about a new branch/tag. NOTE! You'll have to name it explicitly on the command line: if you don't name any branches, git-send-pack will default to the branches that already exist.
2005-07-09 04:58:40 +08:00
continue;
}
new_refs++;
Slow but steady progress on git pack receive/send
2005-06-30 13:50:48 +08:00
strcpy(old_hex, sha1_to_hex(ref->old_sha1));
new_hex = sha1_to_hex(ref->new_sha1);
packet_write(out, "%s %s %s", old_hex, new_hex, ref->name);
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
fprintf(stderr, "updating '%s'", ref->name);
if (strcmp(ref->name, ref->peer_ref->name))
fprintf(stderr, " using '%s'", ref->peer_ref->name);
fprintf(stderr, "\n from %s\n to %s\n", old_hex, new_hex);
Start of "git-send-pack", the local part of sending off a pack Like git-receive-pack, this is only partway done.
2005-06-30 10:09:05 +08:00
}
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
Make send/receive-pack be closer to doing something interesting
2005-06-30 11:50:15 +08:00
packet_flush(out);
Teach 'git-send-pack' to send new branches and tags. The protocol always supported it, but send-pack didn't actually know how to tell the other side about a new branch/tag. NOTE! You'll have to name it explicitly on the command line: if you don't name any branches, git-send-pack will default to the branches that already exist.
2005-07-09 04:58:40 +08:00
if (new_refs)
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
pack_objects(out, remote_refs);
Start of "git-send-pack", the local part of sending off a pack Like git-receive-pack, this is only partway done.
2005-06-30 10:09:05 +08:00
close(out);
Make git-send-pack exit with error when some refs couldn't be pushed out In case some refs couldn't be pushed out due to an error (mostly the not-a-proper-subset error), make git-send-pack exit with non-zero status after the push is over (that is, it still tries to push out the rest of the refs). [jc: I adjusted a test for this change.] Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-14 08:45:40 +08:00
return ret;
Start of "git-send-pack", the local part of sending off a pack Like git-receive-pack, this is only partway done.
2005-06-30 10:09:05 +08:00
}
Renaming push. This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-04 07:35:29 +08:00
Start of "git-send-pack", the local part of sending off a pack Like git-receive-pack, this is only partway done.
2005-06-30 10:09:05 +08:00
int main(int argc, char **argv)
{
int i, nr_heads = 0;
char *dest = NULL;
char **heads = NULL;
Slow but steady progress on git pack receive/send
2005-06-30 13:50:48 +08:00
int fd[2], ret;
pid_t pid;
Start of "git-send-pack", the local part of sending off a pack Like git-receive-pack, this is only partway done.
2005-06-30 10:09:05 +08:00
Make networking commands to work from a subdirectory. These are whole-tree operations and there is not much point making them operable from within a subdirectory, but it is easy to do so, and using setup_git_directory() upfront helps git:// proxy specification picked up from the correct place. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-26 16:47:59 +08:00
setup_git_directory();
Start of "git-send-pack", the local part of sending off a pack Like git-receive-pack, this is only partway done.
2005-06-30 10:09:05 +08:00
argv++;
git-send-pack: add "--all" option to send all refs to the other side This affects only refs that the other side doesn't already have. The ones it has are still filtered by the ref selection.
2005-07-17 04:26:33 +08:00
for (i = 1; i < argc; i++, argv++) {
char *arg = *argv;
Start of "git-send-pack", the local part of sending off a pack Like git-receive-pack, this is only partway done.
2005-06-30 10:09:05 +08:00
if (*arg == '-') {
if (!strncmp(arg, "--exec=", 7)) {
exec = arg + 7;
continue;
}
git-send-pack: add "--all" option to send all refs to the other side This affects only refs that the other side doesn't already have. The ones it has are still filtered by the ref selection.
2005-07-17 04:26:33 +08:00
if (!strcmp(arg, "--all")) {
send_all = 1;
continue;
}
git-send-pack: verify that sender is a proper superset of receiver This should make sure that if you have multiple people pushing to the same tree, they cannot overwrite each others work, but have to merge before being able to update the common reference tree.
2005-07-19 19:03:47 +08:00
if (!strcmp(arg, "--force")) {
force_update = 1;
continue;
}
Start of "git-send-pack", the local part of sending off a pack Like git-receive-pack, this is only partway done.
2005-06-30 10:09:05 +08:00
usage(send_pack_usage);
}
git-send-pack: add "--all" option to send all refs to the other side This affects only refs that the other side doesn't already have. The ones it has are still filtered by the ref selection.
2005-07-17 04:26:33 +08:00
if (!dest) {
dest = arg;
continue;
}
Start of "git-send-pack", the local part of sending off a pack Like git-receive-pack, this is only partway done.
2005-06-30 10:09:05 +08:00
heads = argv;
git-send-pack: add "--all" option to send all refs to the other side This affects only refs that the other side doesn't already have. The ones it has are still filtered by the ref selection.
2005-07-17 04:26:33 +08:00
nr_heads = argc - i;
Start of "git-send-pack", the local part of sending off a pack Like git-receive-pack, this is only partway done.
2005-06-30 10:09:05 +08:00
break;
}
if (!dest)
usage(send_pack_usage);
Make send-pack --all and explicit ref mutually exclusive. send-pack had a confusing misfeature that "send-pack --all master" updated all refs, while "send-pack --all" did not do anything. Make --all and explicit refs mutually exclusive, and make sure "send-pack --all" updates all refs. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-03 03:20:27 +08:00
if (heads && send_all)
usage(send_pack_usage);
Factor out the ssh connection stuff from send-pack.c I want to use it for git-fetch-pack too.
2005-07-05 02:57:58 +08:00
pid = git_connect(fd, dest, exec);
Slow but steady progress on git pack receive/send
2005-06-30 13:50:48 +08:00
if (pid < 0)
Start of "git-send-pack", the local part of sending off a pack Like git-receive-pack, this is only partway done.
2005-06-30 10:09:05 +08:00
return 1;
Do ref matching on the sender side rather than on receiver This makes the receiver always send a full list of valid refs, which will allow us to do better packs, as well as handle creation of new refs. Eventually. Right now we just moved the matching and enabled it. So now you can do git-send-pack host:path branch1 branch2 to only send branches "branch1" and "branch2".
2005-07-01 03:28:24 +08:00
ret = send_pack(fd[0], fd[1], nr_heads, heads);
Slow but steady progress on git pack receive/send
2005-06-30 13:50:48 +08:00
close(fd[0]);
close(fd[1]);
Factor out the ssh connection stuff from send-pack.c I want to use it for git-fetch-pack too.
2005-07-05 02:57:58 +08:00
finish_connect(pid);
Slow but steady progress on git pack receive/send
2005-06-30 13:50:48 +08:00
return ret;
Start of "git-send-pack", the local part of sending off a pack Like git-receive-pack, this is only partway done.
2005-06-30 10:09:05 +08:00
}
Reference in New Issue Copy Permalink