git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 06:22:49 +02:00
|
|
|
/*
|
|
|
|
|
* "git push"
|
|
|
|
|
*/
|
|
|
|
|
#include "cache.h"
|
|
|
|
|
#include "refs.h"
|
|
|
|
|
#include "run-command.h"
|
|
|
|
|
#include "builtin.h"
|
2007-05-12 17:45:53 +02:00
|
|
|
#include "remote.h"
|
2007-09-11 05:03:04 +02:00
|
|
|
#include "transport.h"
|
2007-11-05 04:35:37 +01:00
|
|
|
#include "parse-options.h"
|
2011-08-20 00:08:47 +02:00
|
|
|
#include "submodule.h"
|
git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 06:22:49 +02:00
|
|
|
|
2007-11-05 04:35:37 +01:00
|
|
|
static const char * const push_usage[] = {
|
2012-08-20 14:32:33 +02:00
|
|
|
N_("git push [<options>] [<repository> [<refspec>...]]"),
|
2007-11-05 04:35:37 +01:00
|
|
|
NULL,
|
|
|
|
|
};
|
git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 06:22:49 +02:00
|
|
|
|
2013-08-12 15:55:55 +02:00
|
|
|
static int thin = 1;
|
2009-12-30 20:57:42 +01:00
|
|
|
static int deleterefs;
|
2007-01-19 13:49:27 +01:00
|
|
|
static const char *receivepack;
|
2010-02-24 13:50:24 +01:00
|
|
|
static int verbosity;
|
2012-02-13 21:17:15 +01:00
|
|
|
static int progress = -1;
|
git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 06:22:49 +02:00
|
|
|
|
remote.c: add command line option parser for "--force-with-lease"
Update "git push" and "git send-pack" to parse this commnd line
option.
The intended sematics is:
* "--force-with-lease" alone, without specifying the details, will
protect _all_ remote refs that are going to be updated by
requiring their current value to be the same as some reasonable
default, unless otherwise specified;
* "--force-with-lease=refname", without specifying the expected
value, will protect that refname, if it is going to be updated,
by requiring its current value to be the same as some reasonable
default.
* "--force-with-lease=refname:value" will protect that refname, if
it is going to be updated, by requiring its current value to be
the same as the specified value; and
* "--no-force-with-lease" will cancel all the previous --force-with-lease on the
command line.
For now, "some reasonable default" is tentatively defined as "the
value of the remote-tracking branch we have for the ref of the
remote being updated", and it is an error if we do not have such a
remote-tracking branch. But this is known to be fragile, its use is
not yet recommended, and hopefully we will find more reasonable
default as we gain experience with this feature. The manual marks
the feature as experimental unless the expected value is specified
explicitly for this reason.
Because the command line options are parsed _before_ we know which
remote we are pushing to, there needs further processing to the
parsed data after we instantiate the transport object to:
* expand "refname" given by the user to a full refname to be
matched with the list of "struct ref" used in match_push_refs()
and set_ref_status_for_push(); and
* learning the actual local ref that is the remote-tracking branch
for the specified remote ref.
Further, some processing need to be deferred until we find the set
of remote refs and match_push_refs() returns in order to find the
ones that need to be checked after explicit ones have been processed
for "--force-with-lease" (no specific details).
These post-processing will be the topic of the next patch.
This option was originally called "cas" (for "compare and swap"),
the name which nobody liked because it was too technical. The
second attempt called it "lockref" (because it is conceptually like
pushing after taking a lock) but the word "lock" was hated because
it implied that it may reject push by others, which is not the way
this option works. This round calls it "force-with-lease". You
assume you took the lease on the ref when you fetched to decide what
the rebased history should be, and you can push back only if the
lease has not been broken.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 00:34:36 +02:00
|
|
|
static struct push_cas_option cas;
|
|
|
|
|
|
2006-08-15 19:23:48 +02:00
|
|
|
static const char **refspec;
|
|
|
|
|
static int refspec_nr;
|
2010-07-31 14:54:55 +02:00
|
|
|
static int refspec_alloc;
|
git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 06:22:49 +02:00
|
|
|
|
|
|
|
|
static void add_refspec(const char *ref)
|
|
|
|
|
{
|
2010-07-31 14:54:55 +02:00
|
|
|
refspec_nr++;
|
|
|
|
|
ALLOC_GROW(refspec, refspec_nr, refspec_alloc);
|
|
|
|
|
refspec[refspec_nr-1] = ref;
|
git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 06:22:49 +02:00
|
|
|
}
|
|
|
|
|
|
push: use remote.$name.push as a refmap
Since f2690487 (fetch: opportunistically update tracking refs,
2013-05-11), we stopped taking a non-storing refspec given on the
command line of "git fetch" literally, and instead started mapping
it via remote.$name.fetch refspecs. This allows
$ git fetch origin master
from the 'origin' repository, which is configured with
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
to update refs/remotes/origin/master with the result, as if the
command line were
$ git fetch origin +master:refs/remotes/origin/master
to reduce surprises and improve usability. Before that change, a
refspec on the command line without a colon was only to fetch the
history and leave the result in FETCH_HEAD, without updating the
remote-tracking branches.
When you are simulating a fetch from you by your mothership with a
push by you into your mothership, instead of having:
[remote "satellite"]
fetch = +refs/heads/*:refs/remotes/satellite/*
on the mothership repository and running:
mothership$ git fetch satellite
you would have:
[remote "mothership"]
push = +refs/heads/*:refs/remotes/satellite/*
on your satellite machine, and run:
satellite$ git push mothership
Because we so far did not make the corresponding change to the push
side, this command:
satellite$ git push mothership master
does _not_ allow you on the satellite to only push 'master' out but
still to the usual destination (i.e. refs/remotes/satellite/master).
Implement the logic to map an unqualified refspec given on the
command line via the remote.$name.push refspec. This will bring a
bit more symmetry between "fetch" and "push".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04 00:41:15 +01:00
|
|
|
static const char *map_refspec(const char *ref,
|
|
|
|
|
struct remote *remote, struct ref *local_refs)
|
git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 06:22:49 +02:00
|
|
|
{
|
push: use remote.$name.push as a refmap
Since f2690487 (fetch: opportunistically update tracking refs,
2013-05-11), we stopped taking a non-storing refspec given on the
command line of "git fetch" literally, and instead started mapping
it via remote.$name.fetch refspecs. This allows
$ git fetch origin master
from the 'origin' repository, which is configured with
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
to update refs/remotes/origin/master with the result, as if the
command line were
$ git fetch origin +master:refs/remotes/origin/master
to reduce surprises and improve usability. Before that change, a
refspec on the command line without a colon was only to fetch the
history and leave the result in FETCH_HEAD, without updating the
remote-tracking branches.
When you are simulating a fetch from you by your mothership with a
push by you into your mothership, instead of having:
[remote "satellite"]
fetch = +refs/heads/*:refs/remotes/satellite/*
on the mothership repository and running:
mothership$ git fetch satellite
you would have:
[remote "mothership"]
push = +refs/heads/*:refs/remotes/satellite/*
on your satellite machine, and run:
satellite$ git push mothership
Because we so far did not make the corresponding change to the push
side, this command:
satellite$ git push mothership master
does _not_ allow you on the satellite to only push 'master' out but
still to the usual destination (i.e. refs/remotes/satellite/master).
Implement the logic to map an unqualified refspec given on the
command line via the remote.$name.push refspec. This will bring a
bit more symmetry between "fetch" and "push".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04 00:41:15 +01:00
|
|
|
struct ref *matched = NULL;
|
|
|
|
|
|
|
|
|
|
/* Does "ref" uniquely name our ref? */
|
|
|
|
|
if (count_refspec_match(ref, local_refs, &matched) != 1)
|
|
|
|
|
return ref;
|
|
|
|
|
|
|
|
|
|
if (remote->push) {
|
|
|
|
|
struct refspec query;
|
|
|
|
|
memset(&query, 0, sizeof(struct refspec));
|
|
|
|
|
query.src = matched->name;
|
|
|
|
|
if (!query_refspecs(remote->push, remote->push_refspec_nr, &query) &&
|
|
|
|
|
query.dst) {
|
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
strbuf_addf(&buf, "%s%s:%s",
|
|
|
|
|
query.force ? "+" : "",
|
|
|
|
|
query.src, query.dst);
|
|
|
|
|
return strbuf_detach(&buf, NULL);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-04 01:23:35 +01:00
|
|
|
if (push_default == PUSH_DEFAULT_UPSTREAM &&
|
2014-03-08 00:18:17 +01:00
|
|
|
starts_with(matched->name, "refs/heads/")) {
|
2013-12-04 01:23:35 +01:00
|
|
|
struct branch *branch = branch_get(matched->name + 11);
|
|
|
|
|
if (branch->merge_nr == 1 && branch->merge[0]->src) {
|
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
strbuf_addf(&buf, "%s:%s",
|
|
|
|
|
ref, branch->merge[0]->src);
|
|
|
|
|
return strbuf_detach(&buf, NULL);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
push: use remote.$name.push as a refmap
Since f2690487 (fetch: opportunistically update tracking refs,
2013-05-11), we stopped taking a non-storing refspec given on the
command line of "git fetch" literally, and instead started mapping
it via remote.$name.fetch refspecs. This allows
$ git fetch origin master
from the 'origin' repository, which is configured with
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
to update refs/remotes/origin/master with the result, as if the
command line were
$ git fetch origin +master:refs/remotes/origin/master
to reduce surprises and improve usability. Before that change, a
refspec on the command line without a colon was only to fetch the
history and leave the result in FETCH_HEAD, without updating the
remote-tracking branches.
When you are simulating a fetch from you by your mothership with a
push by you into your mothership, instead of having:
[remote "satellite"]
fetch = +refs/heads/*:refs/remotes/satellite/*
on the mothership repository and running:
mothership$ git fetch satellite
you would have:
[remote "mothership"]
push = +refs/heads/*:refs/remotes/satellite/*
on your satellite machine, and run:
satellite$ git push mothership
Because we so far did not make the corresponding change to the push
side, this command:
satellite$ git push mothership master
does _not_ allow you on the satellite to only push 'master' out but
still to the usual destination (i.e. refs/remotes/satellite/master).
Implement the logic to map an unqualified refspec given on the
command line via the remote.$name.push refspec. This will bring a
bit more symmetry between "fetch" and "push".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04 00:41:15 +01:00
|
|
|
return ref;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void set_refspecs(const char **refs, int nr, const char *repo)
|
|
|
|
|
{
|
|
|
|
|
struct remote *remote = NULL;
|
|
|
|
|
struct ref *local_refs = NULL;
|
2007-05-25 07:20:56 +02:00
|
|
|
int i;
|
push: use remote.$name.push as a refmap
Since f2690487 (fetch: opportunistically update tracking refs,
2013-05-11), we stopped taking a non-storing refspec given on the
command line of "git fetch" literally, and instead started mapping
it via remote.$name.fetch refspecs. This allows
$ git fetch origin master
from the 'origin' repository, which is configured with
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
to update refs/remotes/origin/master with the result, as if the
command line were
$ git fetch origin +master:refs/remotes/origin/master
to reduce surprises and improve usability. Before that change, a
refspec on the command line without a colon was only to fetch the
history and leave the result in FETCH_HEAD, without updating the
remote-tracking branches.
When you are simulating a fetch from you by your mothership with a
push by you into your mothership, instead of having:
[remote "satellite"]
fetch = +refs/heads/*:refs/remotes/satellite/*
on the mothership repository and running:
mothership$ git fetch satellite
you would have:
[remote "mothership"]
push = +refs/heads/*:refs/remotes/satellite/*
on your satellite machine, and run:
satellite$ git push mothership
Because we so far did not make the corresponding change to the push
side, this command:
satellite$ git push mothership master
does _not_ allow you on the satellite to only push 'master' out but
still to the usual destination (i.e. refs/remotes/satellite/master).
Implement the logic to map an unqualified refspec given on the
command line via the remote.$name.push refspec. This will bring a
bit more symmetry between "fetch" and "push".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04 00:41:15 +01:00
|
|
|
|
2007-05-25 07:20:56 +02:00
|
|
|
for (i = 0; i < nr; i++) {
|
|
|
|
|
const char *ref = refs[i];
|
|
|
|
|
if (!strcmp("tag", ref)) {
|
2013-12-03 23:33:10 +01:00
|
|
|
struct strbuf tagref = STRBUF_INIT;
|
2007-05-25 07:20:56 +02:00
|
|
|
if (nr <= ++i)
|
2011-02-23 00:42:11 +01:00
|
|
|
die(_("tag shorthand without <tag>"));
|
2013-12-03 23:33:10 +01:00
|
|
|
ref = refs[i];
|
|
|
|
|
if (deleterefs)
|
|
|
|
|
strbuf_addf(&tagref, ":refs/tags/%s", ref);
|
|
|
|
|
else
|
|
|
|
|
strbuf_addf(&tagref, "refs/tags/%s", ref);
|
|
|
|
|
ref = strbuf_detach(&tagref, NULL);
|
|
|
|
|
} else if (deleterefs) {
|
|
|
|
|
struct strbuf delref = STRBUF_INIT;
|
|
|
|
|
if (strchr(ref, ':'))
|
|
|
|
|
die(_("--delete only accepts plain target ref names"));
|
|
|
|
|
strbuf_addf(&delref, ":%s", ref);
|
|
|
|
|
ref = strbuf_detach(&delref, NULL);
|
push: use remote.$name.push as a refmap
Since f2690487 (fetch: opportunistically update tracking refs,
2013-05-11), we stopped taking a non-storing refspec given on the
command line of "git fetch" literally, and instead started mapping
it via remote.$name.fetch refspecs. This allows
$ git fetch origin master
from the 'origin' repository, which is configured with
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
to update refs/remotes/origin/master with the result, as if the
command line were
$ git fetch origin +master:refs/remotes/origin/master
to reduce surprises and improve usability. Before that change, a
refspec on the command line without a colon was only to fetch the
history and leave the result in FETCH_HEAD, without updating the
remote-tracking branches.
When you are simulating a fetch from you by your mothership with a
push by you into your mothership, instead of having:
[remote "satellite"]
fetch = +refs/heads/*:refs/remotes/satellite/*
on the mothership repository and running:
mothership$ git fetch satellite
you would have:
[remote "mothership"]
push = +refs/heads/*:refs/remotes/satellite/*
on your satellite machine, and run:
satellite$ git push mothership
Because we so far did not make the corresponding change to the push
side, this command:
satellite$ git push mothership master
does _not_ allow you on the satellite to only push 'master' out but
still to the usual destination (i.e. refs/remotes/satellite/master).
Implement the logic to map an unqualified refspec given on the
command line via the remote.$name.push refspec. This will bring a
bit more symmetry between "fetch" and "push".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04 00:41:15 +01:00
|
|
|
} else if (!strchr(ref, ':')) {
|
|
|
|
|
if (!remote) {
|
|
|
|
|
/* lazily grab remote and local_refs */
|
|
|
|
|
remote = remote_get(repo);
|
|
|
|
|
local_refs = get_local_heads();
|
2009-12-30 20:57:42 +01:00
|
|
|
}
|
push: use remote.$name.push as a refmap
Since f2690487 (fetch: opportunistically update tracking refs,
2013-05-11), we stopped taking a non-storing refspec given on the
command line of "git fetch" literally, and instead started mapping
it via remote.$name.fetch refspecs. This allows
$ git fetch origin master
from the 'origin' repository, which is configured with
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
to update refs/remotes/origin/master with the result, as if the
command line were
$ git fetch origin +master:refs/remotes/origin/master
to reduce surprises and improve usability. Before that change, a
refspec on the command line without a colon was only to fetch the
history and leave the result in FETCH_HEAD, without updating the
remote-tracking branches.
When you are simulating a fetch from you by your mothership with a
push by you into your mothership, instead of having:
[remote "satellite"]
fetch = +refs/heads/*:refs/remotes/satellite/*
on the mothership repository and running:
mothership$ git fetch satellite
you would have:
[remote "mothership"]
push = +refs/heads/*:refs/remotes/satellite/*
on your satellite machine, and run:
satellite$ git push mothership
Because we so far did not make the corresponding change to the push
side, this command:
satellite$ git push mothership master
does _not_ allow you on the satellite to only push 'master' out but
still to the usual destination (i.e. refs/remotes/satellite/master).
Implement the logic to map an unqualified refspec given on the
command line via the remote.$name.push refspec. This will bring a
bit more symmetry between "fetch" and "push".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04 00:41:15 +01:00
|
|
|
ref = map_refspec(ref, remote, local_refs);
|
2013-12-03 23:33:10 +01:00
|
|
|
}
|
2007-05-25 07:20:56 +02:00
|
|
|
add_refspec(ref);
|
git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 06:22:49 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
push: error out when the "upstream" semantics does not make sense
The user can say "git push" without specifying any refspec. When using
the "upstream" semantics via the push.default configuration, the user
wants to update the "upstream" branch of the current branch, which is the
branch at a remote repository the current branch is set to integrate with,
with this command.
However, there are cases that such a "git push" that uses the "upstream"
semantics does not make sense:
- The current branch does not have branch.$name.remote configured. By
definition, "git push" that does not name where to push to will not
know where to push to. The user may explicitly say "git push $there",
but again, by definition, no branch at repository $there is set to
integrate with the current branch in this case and we wouldn't know
which remote branch to update.
- The current branch does have branch.$name.remote configured, but it
does not specify branch.$name.merge that names what branch at the
remote this branch integrates with. "git push" knows where to push in
this case (or the user may explicitly say "git push $remote" to tell us
where to push), but we do not know which remote branch to update.
- The current branch does have its remote and upstream branch configured,
but the user said "git push $there", where $there is not the remote
named by "branch.$name.remote". By definition, no branch at repository
$there is set to integrate with the current branch in this case, and
this push is not meant to update any branch at the remote repository
$there.
The first two cases were already checked correctly, but the third case was
not checked and we ended up updating the branch named branch.$name.merge
at repository $there, which was totally bogus.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-31 01:07:12 +02:00
|
|
|
static int push_url_of_remote(struct remote *remote, const char ***url_p)
|
|
|
|
|
{
|
|
|
|
|
if (remote->pushurl_nr) {
|
|
|
|
|
*url_p = remote->pushurl;
|
|
|
|
|
return remote->pushurl_nr;
|
|
|
|
|
}
|
|
|
|
|
*url_p = remote->url;
|
|
|
|
|
return remote->url_nr;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-24 09:50:03 +02:00
|
|
|
static NORETURN int die_push_simple(struct branch *branch, struct remote *remote) {
|
|
|
|
|
/*
|
|
|
|
|
* There's no point in using shorten_unambiguous_ref here,
|
|
|
|
|
* as the ambiguity would be on the remote side, not what
|
|
|
|
|
* we have locally. Plus, this is supposed to be the simple
|
|
|
|
|
* mode. If the user is doing something crazy like setting
|
|
|
|
|
* upstream to a non-branch, we should probably be showing
|
|
|
|
|
* them the big ugly fully qualified ref.
|
|
|
|
|
*/
|
|
|
|
|
const char *advice_maybe = "";
|
refactor skip_prefix to return a boolean
The skip_prefix() function returns a pointer to the content
past the prefix, or NULL if the prefix was not found. While
this is nice and simple, in practice it makes it hard to use
for two reasons:
1. When you want to conditionally skip or keep the string
as-is, you have to introduce a temporary variable.
For example:
tmp = skip_prefix(buf, "foo");
if (tmp)
buf = tmp;
2. It is verbose to check the outcome in a conditional, as
you need extra parentheses to silence compiler
warnings. For example:
if ((cp = skip_prefix(buf, "foo"))
/* do something with cp */
Both of these make it harder to use for long if-chains, and
we tend to use starts_with() instead. However, the first line
of "do something" is often to then skip forward in buf past
the prefix, either using a magic constant or with an extra
strlen(3) (which is generally computed at compile time, but
means we are repeating ourselves).
This patch refactors skip_prefix() to return a simple boolean,
and to provide the pointer value as an out-parameter. If the
prefix is not found, the out-parameter is untouched. This
lets you write:
if (skip_prefix(arg, "foo ", &arg))
do_foo(arg);
else if (skip_prefix(arg, "bar ", &arg))
do_bar(arg);
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-18 21:44:19 +02:00
|
|
|
const char *short_upstream = branch->merge[0]->src;
|
|
|
|
|
|
|
|
|
|
skip_prefix(short_upstream, "refs/heads/", &short_upstream);
|
2012-04-24 09:50:03 +02:00
|
|
|
|
|
|
|
|
/*
|
2013-07-29 10:18:21 +02:00
|
|
|
* Don't show advice for people who explicitly set
|
2012-04-24 09:50:03 +02:00
|
|
|
* push.default.
|
|
|
|
|
*/
|
|
|
|
|
if (push_default == PUSH_DEFAULT_UNSPECIFIED)
|
|
|
|
|
advice_maybe = _("\n"
|
|
|
|
|
"To choose either option permanently, "
|
|
|
|
|
"see push.default in 'git help config'.");
|
|
|
|
|
die(_("The upstream branch of your current branch does not match\n"
|
|
|
|
|
"the name of your current branch. To push to the upstream branch\n"
|
|
|
|
|
"on the remote, use\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" git push %s HEAD:%s\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"To push to the branch of the same name on the remote, use\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" git push %s %s\n"
|
|
|
|
|
"%s"),
|
|
|
|
|
remote->name, short_upstream,
|
|
|
|
|
remote->name, branch->name, advice_maybe);
|
|
|
|
|
}
|
|
|
|
|
|
2013-05-29 21:21:49 +02:00
|
|
|
static const char message_detached_head_die[] =
|
|
|
|
|
N_("You are not currently on a branch.\n"
|
|
|
|
|
"To push the history leading to the current (detached HEAD)\n"
|
|
|
|
|
"state now, use\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" git push %s HEAD:<name-of-remote-branch>\n");
|
|
|
|
|
|
2013-06-19 13:11:41 +02:00
|
|
|
static void setup_push_upstream(struct remote *remote, struct branch *branch,
|
|
|
|
|
int triangular)
|
2009-03-16 16:42:51 +01:00
|
|
|
{
|
|
|
|
|
struct strbuf refspec = STRBUF_INIT;
|
2013-06-19 13:11:41 +02:00
|
|
|
|
2009-03-16 16:42:51 +01:00
|
|
|
if (!branch)
|
2013-05-29 21:21:49 +02:00
|
|
|
die(_(message_detached_head_die), remote->name);
|
push: error out when the "upstream" semantics does not make sense
The user can say "git push" without specifying any refspec. When using
the "upstream" semantics via the push.default configuration, the user
wants to update the "upstream" branch of the current branch, which is the
branch at a remote repository the current branch is set to integrate with,
with this command.
However, there are cases that such a "git push" that uses the "upstream"
semantics does not make sense:
- The current branch does not have branch.$name.remote configured. By
definition, "git push" that does not name where to push to will not
know where to push to. The user may explicitly say "git push $there",
but again, by definition, no branch at repository $there is set to
integrate with the current branch in this case and we wouldn't know
which remote branch to update.
- The current branch does have branch.$name.remote configured, but it
does not specify branch.$name.merge that names what branch at the
remote this branch integrates with. "git push" knows where to push in
this case (or the user may explicitly say "git push $remote" to tell us
where to push), but we do not know which remote branch to update.
- The current branch does have its remote and upstream branch configured,
but the user said "git push $there", where $there is not the remote
named by "branch.$name.remote". By definition, no branch at repository
$there is set to integrate with the current branch in this case, and
this push is not meant to update any branch at the remote repository
$there.
The first two cases were already checked correctly, but the third case was
not checked and we ended up updating the branch named branch.$name.merge
at repository $there, which was totally bogus.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-31 01:07:12 +02:00
|
|
|
if (!branch->merge_nr || !branch->merge || !branch->remote_name)
|
2011-04-02 02:55:55 +02:00
|
|
|
die(_("The current branch %s has no upstream branch.\n"
|
2011-03-02 21:12:10 +01:00
|
|
|
"To push the current branch and set the remote as upstream, use\n"
|
|
|
|
|
"\n"
|
2011-04-02 02:55:55 +02:00
|
|
|
" git push --set-upstream %s %s\n"),
|
2011-03-02 21:12:10 +01:00
|
|
|
branch->name,
|
|
|
|
|
remote->name,
|
2009-03-16 16:42:51 +01:00
|
|
|
branch->name);
|
|
|
|
|
if (branch->merge_nr != 1)
|
2011-04-02 02:55:55 +02:00
|
|
|
die(_("The current branch %s has multiple upstream branches, "
|
2011-02-23 00:42:11 +01:00
|
|
|
"refusing to push."), branch->name);
|
2013-06-19 13:11:41 +02:00
|
|
|
if (triangular)
|
push: error out when the "upstream" semantics does not make sense
The user can say "git push" without specifying any refspec. When using
the "upstream" semantics via the push.default configuration, the user
wants to update the "upstream" branch of the current branch, which is the
branch at a remote repository the current branch is set to integrate with,
with this command.
However, there are cases that such a "git push" that uses the "upstream"
semantics does not make sense:
- The current branch does not have branch.$name.remote configured. By
definition, "git push" that does not name where to push to will not
know where to push to. The user may explicitly say "git push $there",
but again, by definition, no branch at repository $there is set to
integrate with the current branch in this case and we wouldn't know
which remote branch to update.
- The current branch does have branch.$name.remote configured, but it
does not specify branch.$name.merge that names what branch at the
remote this branch integrates with. "git push" knows where to push in
this case (or the user may explicitly say "git push $remote" to tell us
where to push), but we do not know which remote branch to update.
- The current branch does have its remote and upstream branch configured,
but the user said "git push $there", where $there is not the remote
named by "branch.$name.remote". By definition, no branch at repository
$there is set to integrate with the current branch in this case, and
this push is not meant to update any branch at the remote repository
$there.
The first two cases were already checked correctly, but the third case was
not checked and we ended up updating the branch named branch.$name.merge
at repository $there, which was totally bogus.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-31 01:07:12 +02:00
|
|
|
die(_("You are pushing to remote '%s', which is not the upstream of\n"
|
|
|
|
|
"your current branch '%s', without telling me what to push\n"
|
|
|
|
|
"to update which remote branch."),
|
|
|
|
|
remote->name, branch->name);
|
2013-06-19 13:11:41 +02:00
|
|
|
|
|
|
|
|
if (push_default == PUSH_DEFAULT_SIMPLE) {
|
|
|
|
|
/* Additional safety */
|
|
|
|
|
if (strcmp(branch->refname, branch->merge[0]->src))
|
|
|
|
|
die_push_simple(branch, remote);
|
|
|
|
|
}
|
push: error out when the "upstream" semantics does not make sense
The user can say "git push" without specifying any refspec. When using
the "upstream" semantics via the push.default configuration, the user
wants to update the "upstream" branch of the current branch, which is the
branch at a remote repository the current branch is set to integrate with,
with this command.
However, there are cases that such a "git push" that uses the "upstream"
semantics does not make sense:
- The current branch does not have branch.$name.remote configured. By
definition, "git push" that does not name where to push to will not
know where to push to. The user may explicitly say "git push $there",
but again, by definition, no branch at repository $there is set to
integrate with the current branch in this case and we wouldn't know
which remote branch to update.
- The current branch does have branch.$name.remote configured, but it
does not specify branch.$name.merge that names what branch at the
remote this branch integrates with. "git push" knows where to push in
this case (or the user may explicitly say "git push $remote" to tell us
where to push), but we do not know which remote branch to update.
- The current branch does have its remote and upstream branch configured,
but the user said "git push $there", where $there is not the remote
named by "branch.$name.remote". By definition, no branch at repository
$there is set to integrate with the current branch in this case, and
this push is not meant to update any branch at the remote repository
$there.
The first two cases were already checked correctly, but the third case was
not checked and we ended up updating the branch named branch.$name.merge
at repository $there, which was totally bogus.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-31 01:07:12 +02:00
|
|
|
|
2009-03-16 16:42:51 +01:00
|
|
|
strbuf_addf(&refspec, "%s:%s", branch->name, branch->merge[0]->src);
|
|
|
|
|
add_refspec(refspec.buf);
|
|
|
|
|
}
|
|
|
|
|
|
2013-06-19 13:11:41 +02:00
|
|
|
static void setup_push_current(struct remote *remote, struct branch *branch)
|
|
|
|
|
{
|
|
|
|
|
if (!branch)
|
|
|
|
|
die(_(message_detached_head_die), remote->name);
|
|
|
|
|
add_refspec(branch->name);
|
|
|
|
|
}
|
|
|
|
|
|
2012-06-24 13:01:37 +02:00
|
|
|
static char warn_unspecified_push_default_msg[] =
|
2013-01-05 01:02:29 +01:00
|
|
|
N_("push.default is unset; its implicit value has changed in\n"
|
2012-06-24 13:01:37 +02:00
|
|
|
"Git 2.0 from 'matching' to 'simple'. To squelch this message\n"
|
2013-01-05 01:02:29 +01:00
|
|
|
"and maintain the traditional behavior, use:\n"
|
2012-06-24 13:01:37 +02:00
|
|
|
"\n"
|
|
|
|
|
" git config --global push.default matching\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"To squelch this message and adopt the new behavior now, use:\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" git config --global push.default simple\n"
|
|
|
|
|
"\n"
|
2013-10-04 16:20:07 +02:00
|
|
|
"When push.default is set to 'matching', git will push local branches\n"
|
|
|
|
|
"to the remote branches that already exist with the same name.\n"
|
|
|
|
|
"\n"
|
2013-01-05 01:02:29 +01:00
|
|
|
"Since Git 2.0, Git defaults to the more conservative 'simple'\n"
|
2013-10-04 16:20:07 +02:00
|
|
|
"behavior, which only pushes the current branch to the corresponding\n"
|
|
|
|
|
"remote branch that 'git pull' uses to update the current branch.\n"
|
|
|
|
|
"\n"
|
2012-06-24 13:01:37 +02:00
|
|
|
"See 'git help config' and search for 'push.default' for further information.\n"
|
|
|
|
|
"(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode\n"
|
|
|
|
|
"'current' instead of 'simple' if you sometimes use older versions of Git)");
|
|
|
|
|
|
|
|
|
|
static void warn_unspecified_push_default_configuration(void)
|
|
|
|
|
{
|
|
|
|
|
static int warn_once;
|
|
|
|
|
|
|
|
|
|
if (warn_once++)
|
|
|
|
|
return;
|
|
|
|
|
warning("%s\n", _(warn_unspecified_push_default_msg));
|
|
|
|
|
}
|
|
|
|
|
|
2013-06-19 13:11:41 +02:00
|
|
|
static int is_workflow_triangular(struct remote *remote)
|
|
|
|
|
{
|
|
|
|
|
struct remote *fetch_remote = remote_get(NULL);
|
|
|
|
|
return (fetch_remote && fetch_remote != remote);
|
|
|
|
|
}
|
|
|
|
|
|
2011-03-02 21:12:10 +01:00
|
|
|
static void setup_default_push_refspecs(struct remote *remote)
|
2009-03-16 16:42:51 +01:00
|
|
|
{
|
2013-06-19 13:11:41 +02:00
|
|
|
struct branch *branch = branch_get(NULL);
|
|
|
|
|
int triangular = is_workflow_triangular(remote);
|
2013-05-29 21:21:50 +02:00
|
|
|
|
2009-03-16 16:42:51 +01:00
|
|
|
switch (push_default) {
|
2009-07-19 02:19:47 +02:00
|
|
|
default:
|
2009-03-16 16:42:51 +01:00
|
|
|
case PUSH_DEFAULT_MATCHING:
|
|
|
|
|
add_refspec(":");
|
|
|
|
|
break;
|
|
|
|
|
|
2013-01-05 01:02:29 +01:00
|
|
|
case PUSH_DEFAULT_UNSPECIFIED:
|
|
|
|
|
warn_unspecified_push_default_configuration();
|
|
|
|
|
/* fallthru */
|
|
|
|
|
|
2012-04-24 09:50:03 +02:00
|
|
|
case PUSH_DEFAULT_SIMPLE:
|
2013-06-19 13:11:41 +02:00
|
|
|
if (triangular)
|
|
|
|
|
setup_push_current(remote, branch);
|
|
|
|
|
else
|
|
|
|
|
setup_push_upstream(remote, branch, triangular);
|
2012-04-24 09:50:03 +02:00
|
|
|
break;
|
|
|
|
|
|
2011-02-16 01:54:24 +01:00
|
|
|
case PUSH_DEFAULT_UPSTREAM:
|
2013-06-19 13:11:41 +02:00
|
|
|
setup_push_upstream(remote, branch, triangular);
|
2009-03-16 16:42:51 +01:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case PUSH_DEFAULT_CURRENT:
|
2013-06-19 13:11:41 +02:00
|
|
|
setup_push_current(remote, branch);
|
2009-03-16 16:42:51 +01:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case PUSH_DEFAULT_NOTHING:
|
2011-02-23 00:42:11 +01:00
|
|
|
die(_("You didn't specify any refspecs to push, and "
|
|
|
|
|
"push.default is \"nothing\"."));
|
2009-03-16 16:42:51 +01:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
push: Provide situational hints for non-fast-forward errors
Pushing a non-fast-forward update to a remote repository will result in
an error, but the hint text doesn't provide the correct resolution in
every case. Give better resolution advice in three push scenarios:
1) If you push your current branch and it triggers a non-fast-forward
error, you should merge remote changes with 'git pull' before pushing
again.
2) If you push to a shared repository others push to, and your local
tracking branches are not kept up to date, the 'matching refs' default
will generate non-fast-forward errors on outdated branches. If this is
your workflow, the 'matching refs' default is not for you. Consider
setting the 'push.default' configuration variable to 'current' or
'upstream' to ensure only your current branch is pushed.
3) If you explicitly specify a ref that is not your current branch or
push matching branches with ':', you will generate a non-fast-forward
error if any pushed branch tip is out of date. You should checkout the
offending branch and merge remote changes before pushing again.
Teach transport.c to recognize these scenarios and configure push.c
to hint for them. If 'git push's default behavior changes or we
discover more scenarios, extension is easy. Standardize on the
advice API and add three new advice variables, 'pushNonFFCurrent',
'pushNonFFDefault', and 'pushNonFFMatching'. Setting any of these
to 'false' will disable their affiliated advice. Setting
'pushNonFastForward' to false will disable all three, thus preserving the
config option for users who already set it, but guaranteeing new
users won't disable push advice accidentally.
Based-on-patch-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christopher Tiwald <christiwald@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-20 05:31:33 +01:00
|
|
|
static const char message_advice_pull_before_push[] =
|
|
|
|
|
N_("Updates were rejected because the tip of your current branch is behind\n"
|
2013-07-07 21:02:14 +02:00
|
|
|
"its remote counterpart. Integrate the remote changes (e.g.\n"
|
|
|
|
|
"'git pull ...') before pushing again.\n"
|
push: Provide situational hints for non-fast-forward errors
Pushing a non-fast-forward update to a remote repository will result in
an error, but the hint text doesn't provide the correct resolution in
every case. Give better resolution advice in three push scenarios:
1) If you push your current branch and it triggers a non-fast-forward
error, you should merge remote changes with 'git pull' before pushing
again.
2) If you push to a shared repository others push to, and your local
tracking branches are not kept up to date, the 'matching refs' default
will generate non-fast-forward errors on outdated branches. If this is
your workflow, the 'matching refs' default is not for you. Consider
setting the 'push.default' configuration variable to 'current' or
'upstream' to ensure only your current branch is pushed.
3) If you explicitly specify a ref that is not your current branch or
push matching branches with ':', you will generate a non-fast-forward
error if any pushed branch tip is out of date. You should checkout the
offending branch and merge remote changes before pushing again.
Teach transport.c to recognize these scenarios and configure push.c
to hint for them. If 'git push's default behavior changes or we
discover more scenarios, extension is easy. Standardize on the
advice API and add three new advice variables, 'pushNonFFCurrent',
'pushNonFFDefault', and 'pushNonFFMatching'. Setting any of these
to 'false' will disable their affiliated advice. Setting
'pushNonFastForward' to false will disable all three, thus preserving the
config option for users who already set it, but guaranteeing new
users won't disable push advice accidentally.
Based-on-patch-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christopher Tiwald <christiwald@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-20 05:31:33 +01:00
|
|
|
"See the 'Note about fast-forwards' in 'git push --help' for details.");
|
|
|
|
|
|
|
|
|
|
static const char message_advice_checkout_pull_push[] =
|
|
|
|
|
N_("Updates were rejected because a pushed branch tip is behind its remote\n"
|
2013-07-07 21:02:14 +02:00
|
|
|
"counterpart. Check out this branch and integrate the remote changes\n"
|
|
|
|
|
"(e.g. 'git pull ...') before pushing again.\n"
|
push: Provide situational hints for non-fast-forward errors
Pushing a non-fast-forward update to a remote repository will result in
an error, but the hint text doesn't provide the correct resolution in
every case. Give better resolution advice in three push scenarios:
1) If you push your current branch and it triggers a non-fast-forward
error, you should merge remote changes with 'git pull' before pushing
again.
2) If you push to a shared repository others push to, and your local
tracking branches are not kept up to date, the 'matching refs' default
will generate non-fast-forward errors on outdated branches. If this is
your workflow, the 'matching refs' default is not for you. Consider
setting the 'push.default' configuration variable to 'current' or
'upstream' to ensure only your current branch is pushed.
3) If you explicitly specify a ref that is not your current branch or
push matching branches with ':', you will generate a non-fast-forward
error if any pushed branch tip is out of date. You should checkout the
offending branch and merge remote changes before pushing again.
Teach transport.c to recognize these scenarios and configure push.c
to hint for them. If 'git push's default behavior changes or we
discover more scenarios, extension is easy. Standardize on the
advice API and add three new advice variables, 'pushNonFFCurrent',
'pushNonFFDefault', and 'pushNonFFMatching'. Setting any of these
to 'false' will disable their affiliated advice. Setting
'pushNonFastForward' to false will disable all three, thus preserving the
config option for users who already set it, but guaranteeing new
users won't disable push advice accidentally.
Based-on-patch-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christopher Tiwald <christiwald@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-20 05:31:33 +01:00
|
|
|
"See the 'Note about fast-forwards' in 'git push --help' for details.");
|
|
|
|
|
|
push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE
When we push to update an existing ref, if:
* the object at the tip of the remote is not a commit; or
* the object we are pushing is not a commit,
it won't be correct to suggest to fetch, integrate and push again,
as the old and new objects will not "merge". We should explain that
the push must be forced when there is a non-committish object is
involved in such a case.
If we do not have the current object at the tip of the remote, we do
not even know that object, when fetched, is something that can be
merged. In such a case, suggesting to pull first just like
non-fast-forward case may not be technically correct, but in
practice, most such failures are seen when you try to push your work
to a branch without knowing that somebody else already pushed to
update the same branch since you forked, so "pull first" would work
as a suggestion most of the time. And if the object at the tip is
not a commit, "pull first" will fail, without making any permanent
damage. As a side effect, it also makes the error message the user
will get during the next "push" attempt easier to understand, now
the user is aware that a non-commit object is involved.
In these cases, the current code already rejects such a push on the
client end, but we used the same error and advice messages as the
ones used when rejecting a non-fast-forward push, i.e. pull from
there and integrate before pushing again.
Introduce new rejection reasons and reword the messages
appropriately.
[jc: with help by Peff on message details]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-23 22:55:30 +01:00
|
|
|
static const char message_advice_ref_fetch_first[] =
|
|
|
|
|
N_("Updates were rejected because the remote contains work that you do\n"
|
|
|
|
|
"not have locally. This is usually caused by another repository pushing\n"
|
2013-07-07 21:02:14 +02:00
|
|
|
"to the same ref. You may want to first integrate the remote changes\n"
|
|
|
|
|
"(e.g., 'git pull ...') before pushing again.\n"
|
push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE
When we push to update an existing ref, if:
* the object at the tip of the remote is not a commit; or
* the object we are pushing is not a commit,
it won't be correct to suggest to fetch, integrate and push again,
as the old and new objects will not "merge". We should explain that
the push must be forced when there is a non-committish object is
involved in such a case.
If we do not have the current object at the tip of the remote, we do
not even know that object, when fetched, is something that can be
merged. In such a case, suggesting to pull first just like
non-fast-forward case may not be technically correct, but in
practice, most such failures are seen when you try to push your work
to a branch without knowing that somebody else already pushed to
update the same branch since you forked, so "pull first" would work
as a suggestion most of the time. And if the object at the tip is
not a commit, "pull first" will fail, without making any permanent
damage. As a side effect, it also makes the error message the user
will get during the next "push" attempt easier to understand, now
the user is aware that a non-commit object is involved.
In these cases, the current code already rejects such a push on the
client end, but we used the same error and advice messages as the
ones used when rejecting a non-fast-forward push, i.e. pull from
there and integrate before pushing again.
Introduce new rejection reasons and reword the messages
appropriately.
[jc: with help by Peff on message details]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-23 22:55:30 +01:00
|
|
|
"See the 'Note about fast-forwards' in 'git push --help' for details.");
|
|
|
|
|
|
2012-11-30 02:41:34 +01:00
|
|
|
static const char message_advice_ref_already_exists[] =
|
2013-01-25 06:09:00 +01:00
|
|
|
N_("Updates were rejected because the tag already exists in the remote.");
|
2012-11-30 02:41:34 +01:00
|
|
|
|
push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE
When we push to update an existing ref, if:
* the object at the tip of the remote is not a commit; or
* the object we are pushing is not a commit,
it won't be correct to suggest to fetch, integrate and push again,
as the old and new objects will not "merge". We should explain that
the push must be forced when there is a non-committish object is
involved in such a case.
If we do not have the current object at the tip of the remote, we do
not even know that object, when fetched, is something that can be
merged. In such a case, suggesting to pull first just like
non-fast-forward case may not be technically correct, but in
practice, most such failures are seen when you try to push your work
to a branch without knowing that somebody else already pushed to
update the same branch since you forked, so "pull first" would work
as a suggestion most of the time. And if the object at the tip is
not a commit, "pull first" will fail, without making any permanent
damage. As a side effect, it also makes the error message the user
will get during the next "push" attempt easier to understand, now
the user is aware that a non-commit object is involved.
In these cases, the current code already rejects such a push on the
client end, but we used the same error and advice messages as the
ones used when rejecting a non-fast-forward push, i.e. pull from
there and integrate before pushing again.
Introduce new rejection reasons and reword the messages
appropriately.
[jc: with help by Peff on message details]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-23 22:55:30 +01:00
|
|
|
static const char message_advice_ref_needs_force[] =
|
|
|
|
|
N_("You cannot update a remote ref that points at a non-commit object,\n"
|
|
|
|
|
"or update a remote ref to make it point at a non-commit object,\n"
|
|
|
|
|
"without using the '--force' option.\n");
|
2012-11-30 02:41:34 +01:00
|
|
|
|
push: Provide situational hints for non-fast-forward errors
Pushing a non-fast-forward update to a remote repository will result in
an error, but the hint text doesn't provide the correct resolution in
every case. Give better resolution advice in three push scenarios:
1) If you push your current branch and it triggers a non-fast-forward
error, you should merge remote changes with 'git pull' before pushing
again.
2) If you push to a shared repository others push to, and your local
tracking branches are not kept up to date, the 'matching refs' default
will generate non-fast-forward errors on outdated branches. If this is
your workflow, the 'matching refs' default is not for you. Consider
setting the 'push.default' configuration variable to 'current' or
'upstream' to ensure only your current branch is pushed.
3) If you explicitly specify a ref that is not your current branch or
push matching branches with ':', you will generate a non-fast-forward
error if any pushed branch tip is out of date. You should checkout the
offending branch and merge remote changes before pushing again.
Teach transport.c to recognize these scenarios and configure push.c
to hint for them. If 'git push's default behavior changes or we
discover more scenarios, extension is easy. Standardize on the
advice API and add three new advice variables, 'pushNonFFCurrent',
'pushNonFFDefault', and 'pushNonFFMatching'. Setting any of these
to 'false' will disable their affiliated advice. Setting
'pushNonFastForward' to false will disable all three, thus preserving the
config option for users who already set it, but guaranteeing new
users won't disable push advice accidentally.
Based-on-patch-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christopher Tiwald <christiwald@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-20 05:31:33 +01:00
|
|
|
static void advise_pull_before_push(void)
|
|
|
|
|
{
|
2012-12-03 04:27:50 +01:00
|
|
|
if (!advice_push_non_ff_current || !advice_push_update_rejected)
|
push: Provide situational hints for non-fast-forward errors
Pushing a non-fast-forward update to a remote repository will result in
an error, but the hint text doesn't provide the correct resolution in
every case. Give better resolution advice in three push scenarios:
1) If you push your current branch and it triggers a non-fast-forward
error, you should merge remote changes with 'git pull' before pushing
again.
2) If you push to a shared repository others push to, and your local
tracking branches are not kept up to date, the 'matching refs' default
will generate non-fast-forward errors on outdated branches. If this is
your workflow, the 'matching refs' default is not for you. Consider
setting the 'push.default' configuration variable to 'current' or
'upstream' to ensure only your current branch is pushed.
3) If you explicitly specify a ref that is not your current branch or
push matching branches with ':', you will generate a non-fast-forward
error if any pushed branch tip is out of date. You should checkout the
offending branch and merge remote changes before pushing again.
Teach transport.c to recognize these scenarios and configure push.c
to hint for them. If 'git push's default behavior changes or we
discover more scenarios, extension is easy. Standardize on the
advice API and add three new advice variables, 'pushNonFFCurrent',
'pushNonFFDefault', and 'pushNonFFMatching'. Setting any of these
to 'false' will disable their affiliated advice. Setting
'pushNonFastForward' to false will disable all three, thus preserving the
config option for users who already set it, but guaranteeing new
users won't disable push advice accidentally.
Based-on-patch-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christopher Tiwald <christiwald@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-20 05:31:33 +01:00
|
|
|
return;
|
|
|
|
|
advise(_(message_advice_pull_before_push));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void advise_checkout_pull_push(void)
|
|
|
|
|
{
|
2012-12-03 04:27:50 +01:00
|
|
|
if (!advice_push_non_ff_matching || !advice_push_update_rejected)
|
push: Provide situational hints for non-fast-forward errors
Pushing a non-fast-forward update to a remote repository will result in
an error, but the hint text doesn't provide the correct resolution in
every case. Give better resolution advice in three push scenarios:
1) If you push your current branch and it triggers a non-fast-forward
error, you should merge remote changes with 'git pull' before pushing
again.
2) If you push to a shared repository others push to, and your local
tracking branches are not kept up to date, the 'matching refs' default
will generate non-fast-forward errors on outdated branches. If this is
your workflow, the 'matching refs' default is not for you. Consider
setting the 'push.default' configuration variable to 'current' or
'upstream' to ensure only your current branch is pushed.
3) If you explicitly specify a ref that is not your current branch or
push matching branches with ':', you will generate a non-fast-forward
error if any pushed branch tip is out of date. You should checkout the
offending branch and merge remote changes before pushing again.
Teach transport.c to recognize these scenarios and configure push.c
to hint for them. If 'git push's default behavior changes or we
discover more scenarios, extension is easy. Standardize on the
advice API and add three new advice variables, 'pushNonFFCurrent',
'pushNonFFDefault', and 'pushNonFFMatching'. Setting any of these
to 'false' will disable their affiliated advice. Setting
'pushNonFastForward' to false will disable all three, thus preserving the
config option for users who already set it, but guaranteeing new
users won't disable push advice accidentally.
Based-on-patch-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christopher Tiwald <christiwald@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-20 05:31:33 +01:00
|
|
|
return;
|
|
|
|
|
advise(_(message_advice_checkout_pull_push));
|
|
|
|
|
}
|
|
|
|
|
|
2012-11-30 02:41:34 +01:00
|
|
|
static void advise_ref_already_exists(void)
|
|
|
|
|
{
|
2012-12-03 04:27:51 +01:00
|
|
|
if (!advice_push_already_exists || !advice_push_update_rejected)
|
|
|
|
|
return;
|
2012-11-30 02:41:34 +01:00
|
|
|
advise(_(message_advice_ref_already_exists));
|
|
|
|
|
}
|
|
|
|
|
|
push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE
When we push to update an existing ref, if:
* the object at the tip of the remote is not a commit; or
* the object we are pushing is not a commit,
it won't be correct to suggest to fetch, integrate and push again,
as the old and new objects will not "merge". We should explain that
the push must be forced when there is a non-committish object is
involved in such a case.
If we do not have the current object at the tip of the remote, we do
not even know that object, when fetched, is something that can be
merged. In such a case, suggesting to pull first just like
non-fast-forward case may not be technically correct, but in
practice, most such failures are seen when you try to push your work
to a branch without knowing that somebody else already pushed to
update the same branch since you forked, so "pull first" would work
as a suggestion most of the time. And if the object at the tip is
not a commit, "pull first" will fail, without making any permanent
damage. As a side effect, it also makes the error message the user
will get during the next "push" attempt easier to understand, now
the user is aware that a non-commit object is involved.
In these cases, the current code already rejects such a push on the
client end, but we used the same error and advice messages as the
ones used when rejecting a non-fast-forward push, i.e. pull from
there and integrate before pushing again.
Introduce new rejection reasons and reword the messages
appropriately.
[jc: with help by Peff on message details]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-23 22:55:30 +01:00
|
|
|
static void advise_ref_fetch_first(void)
|
|
|
|
|
{
|
|
|
|
|
if (!advice_push_fetch_first || !advice_push_update_rejected)
|
|
|
|
|
return;
|
|
|
|
|
advise(_(message_advice_ref_fetch_first));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void advise_ref_needs_force(void)
|
|
|
|
|
{
|
|
|
|
|
if (!advice_push_needs_force || !advice_push_update_rejected)
|
|
|
|
|
return;
|
|
|
|
|
advise(_(message_advice_ref_needs_force));
|
|
|
|
|
}
|
|
|
|
|
|
2009-11-18 02:42:22 +01:00
|
|
|
static int push_with_options(struct transport *transport, int flags)
|
|
|
|
|
{
|
|
|
|
|
int err;
|
2012-11-30 02:41:33 +01:00
|
|
|
unsigned int reject_reasons;
|
2010-02-24 13:50:24 +01:00
|
|
|
|
2010-02-24 13:50:27 +01:00
|
|
|
transport_set_verbosity(transport, verbosity, progress);
|
2010-02-24 13:50:24 +01:00
|
|
|
|
2009-11-18 02:42:22 +01:00
|
|
|
if (receivepack)
|
|
|
|
|
transport_set_option(transport,
|
|
|
|
|
TRANS_OPT_RECEIVEPACK, receivepack);
|
2013-08-12 15:55:55 +02:00
|
|
|
transport_set_option(transport, TRANS_OPT_THIN, thin ? "yes" : NULL);
|
2009-11-18 02:42:22 +01:00
|
|
|
|
2013-07-09 20:01:06 +02:00
|
|
|
if (!is_empty_cas(&cas)) {
|
|
|
|
|
if (!transport->smart_options)
|
|
|
|
|
die("underlying transport does not support --%s option",
|
|
|
|
|
CAS_OPT_NAME);
|
|
|
|
|
transport->smart_options->cas = &cas;
|
|
|
|
|
}
|
|
|
|
|
|
2010-02-24 13:50:24 +01:00
|
|
|
if (verbosity > 0)
|
2011-02-23 00:42:11 +01:00
|
|
|
fprintf(stderr, _("Pushing to %s\n"), transport->url);
|
2009-11-18 02:42:22 +01:00
|
|
|
err = transport_push(transport, refspec_nr, refspec, flags,
|
2012-11-30 02:41:33 +01:00
|
|
|
&reject_reasons);
|
2009-12-04 00:31:44 +01:00
|
|
|
if (err != 0)
|
2011-02-23 00:42:11 +01:00
|
|
|
error(_("failed to push some refs to '%s'"), transport->url);
|
2009-12-04 00:31:44 +01:00
|
|
|
|
2009-11-18 02:42:22 +01:00
|
|
|
err |= transport_disconnect(transport);
|
|
|
|
|
if (!err)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2012-11-30 02:41:33 +01:00
|
|
|
if (reject_reasons & REJECT_NON_FF_HEAD) {
|
push: Provide situational hints for non-fast-forward errors
Pushing a non-fast-forward update to a remote repository will result in
an error, but the hint text doesn't provide the correct resolution in
every case. Give better resolution advice in three push scenarios:
1) If you push your current branch and it triggers a non-fast-forward
error, you should merge remote changes with 'git pull' before pushing
again.
2) If you push to a shared repository others push to, and your local
tracking branches are not kept up to date, the 'matching refs' default
will generate non-fast-forward errors on outdated branches. If this is
your workflow, the 'matching refs' default is not for you. Consider
setting the 'push.default' configuration variable to 'current' or
'upstream' to ensure only your current branch is pushed.
3) If you explicitly specify a ref that is not your current branch or
push matching branches with ':', you will generate a non-fast-forward
error if any pushed branch tip is out of date. You should checkout the
offending branch and merge remote changes before pushing again.
Teach transport.c to recognize these scenarios and configure push.c
to hint for them. If 'git push's default behavior changes or we
discover more scenarios, extension is easy. Standardize on the
advice API and add three new advice variables, 'pushNonFFCurrent',
'pushNonFFDefault', and 'pushNonFFMatching'. Setting any of these
to 'false' will disable their affiliated advice. Setting
'pushNonFastForward' to false will disable all three, thus preserving the
config option for users who already set it, but guaranteeing new
users won't disable push advice accidentally.
Based-on-patch-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christopher Tiwald <christiwald@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-20 05:31:33 +01:00
|
|
|
advise_pull_before_push();
|
2012-11-30 02:41:33 +01:00
|
|
|
} else if (reject_reasons & REJECT_NON_FF_OTHER) {
|
2013-01-05 01:02:29 +01:00
|
|
|
advise_checkout_pull_push();
|
2012-11-30 02:41:34 +01:00
|
|
|
} else if (reject_reasons & REJECT_ALREADY_EXISTS) {
|
|
|
|
|
advise_ref_already_exists();
|
push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE
When we push to update an existing ref, if:
* the object at the tip of the remote is not a commit; or
* the object we are pushing is not a commit,
it won't be correct to suggest to fetch, integrate and push again,
as the old and new objects will not "merge". We should explain that
the push must be forced when there is a non-committish object is
involved in such a case.
If we do not have the current object at the tip of the remote, we do
not even know that object, when fetched, is something that can be
merged. In such a case, suggesting to pull first just like
non-fast-forward case may not be technically correct, but in
practice, most such failures are seen when you try to push your work
to a branch without knowing that somebody else already pushed to
update the same branch since you forked, so "pull first" would work
as a suggestion most of the time. And if the object at the tip is
not a commit, "pull first" will fail, without making any permanent
damage. As a side effect, it also makes the error message the user
will get during the next "push" attempt easier to understand, now
the user is aware that a non-commit object is involved.
In these cases, the current code already rejects such a push on the
client end, but we used the same error and advice messages as the
ones used when rejecting a non-fast-forward push, i.e. pull from
there and integrate before pushing again.
Introduce new rejection reasons and reword the messages
appropriately.
[jc: with help by Peff on message details]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-23 22:55:30 +01:00
|
|
|
} else if (reject_reasons & REJECT_FETCH_FIRST) {
|
|
|
|
|
advise_ref_fetch_first();
|
|
|
|
|
} else if (reject_reasons & REJECT_NEEDS_FORCE) {
|
|
|
|
|
advise_ref_needs_force();
|
2009-11-18 02:42:22 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
2007-09-11 05:03:04 +02:00
|
|
|
static int do_push(const char *repo, int flags)
|
git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 06:22:49 +02:00
|
|
|
{
|
2007-05-12 17:45:53 +02:00
|
|
|
int i, errs;
|
remote.c: introduce a way to have different remotes for fetch/push
Currently, do_push() in push.c calls remote_get(), which gets the
configured remote for fetching and pushing. Replace this call with a
call to pushremote_get() instead, a new function that will return the
remote configured specifically for pushing. This function tries to
work with the string pushremote_name, before falling back to the
codepath of remote_get(). This patch has no visible impact, but
serves to enable future patches to introduce configuration variables
to set pushremote_name. For example, you can now do the following in
handle_config():
if (!strcmp(key, "remote.pushdefault"))
git_config_string(&pushremote_name, key, value);
Then, pushes will automatically go to the remote specified by
remote.pushdefault.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-02 09:40:32 +02:00
|
|
|
struct remote *remote = pushremote_get(repo);
|
2009-06-09 18:01:34 +02:00
|
|
|
const char **url;
|
|
|
|
|
int url_nr;
|
git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 06:22:49 +02:00
|
|
|
|
Give error when no remote is configured
When there's no explicitly-named remote, we use the remote specified
for the current branch, which in turn defaults to "origin". But it
this case should require the remote to actually be configured, and not
fall back to the path "origin".
Possibly, the config file's "remote = something" should require the
something to be a configured remote instead of a bare repository URL,
but we actually test with a bare repository URL.
In fetch, we were giving the sensible error message when coming up
with a URL failed, but this wasn't actually reachable, so move that
error up and use it when appropriate.
In push, we need a new error message, because the old one (formerly
unreachable without a lot of help) used the repo name, which was NULL.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-11 06:47:20 +01:00
|
|
|
if (!remote) {
|
|
|
|
|
if (repo)
|
2011-02-23 00:42:11 +01:00
|
|
|
die(_("bad repository '%s'"), repo);
|
2011-04-02 02:55:55 +02:00
|
|
|
die(_("No configured push destination.\n"
|
2011-03-02 21:12:11 +01:00
|
|
|
"Either specify the URL from the command-line or configure a remote repository using\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" git remote add <name> <url>\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"and then push using the remote name\n"
|
|
|
|
|
"\n"
|
2011-04-02 02:55:55 +02:00
|
|
|
" git push <name>\n"));
|
Give error when no remote is configured
When there's no explicitly-named remote, we use the remote specified
for the current branch, which in turn defaults to "origin". But it
this case should require the remote to actually be configured, and not
fall back to the path "origin".
Possibly, the config file's "remote = something" should require the
something to be a configured remote instead of a bare repository URL,
but we actually test with a bare repository URL.
In fetch, we were giving the sensible error message when coming up
with a URL failed, but this wasn't actually reachable, so move that
error up and use it when appropriate.
In push, we need a new error message, because the old one (formerly
unreachable without a lot of help) used the repo name, which was NULL.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-11 06:47:20 +01:00
|
|
|
}
|
git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 06:22:49 +02:00
|
|
|
|
2008-04-17 13:17:20 +02:00
|
|
|
if (remote->mirror)
|
|
|
|
|
flags |= (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE);
|
|
|
|
|
|
2008-08-16 19:58:32 +02:00
|
|
|
if ((flags & TRANSPORT_PUSH_ALL) && refspec) {
|
|
|
|
|
if (!strcmp(*refspec, "refs/tags/*"))
|
2011-02-23 00:42:11 +01:00
|
|
|
return error(_("--all and --tags are incompatible"));
|
|
|
|
|
return error(_("--all can't be combined with refspecs"));
|
2008-08-16 19:58:32 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ((flags & TRANSPORT_PUSH_MIRROR) && refspec) {
|
|
|
|
|
if (!strcmp(*refspec, "refs/tags/*"))
|
2011-02-23 00:42:11 +01:00
|
|
|
return error(_("--mirror and --tags are incompatible"));
|
|
|
|
|
return error(_("--mirror can't be combined with refspecs"));
|
2008-08-16 19:58:32 +02:00
|
|
|
}
|
2008-04-17 13:17:20 +02:00
|
|
|
|
|
|
|
|
if ((flags & (TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) ==
|
|
|
|
|
(TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) {
|
2011-02-23 00:42:11 +01:00
|
|
|
return error(_("--all and --mirror are incompatible"));
|
2008-04-17 13:17:20 +02:00
|
|
|
}
|
|
|
|
|
|
2009-03-16 16:42:51 +01:00
|
|
|
if (!refspec && !(flags & TRANSPORT_PUSH_ALL)) {
|
|
|
|
|
if (remote->push_refspec_nr) {
|
|
|
|
|
refspec = remote->push_refspec;
|
|
|
|
|
refspec_nr = remote->push_refspec_nr;
|
|
|
|
|
} else if (!(flags & TRANSPORT_PUSH_MIRROR))
|
2011-03-02 21:12:10 +01:00
|
|
|
setup_default_push_refspecs(remote);
|
2007-05-12 17:45:53 +02:00
|
|
|
}
|
2007-04-07 08:04:53 +02:00
|
|
|
errs = 0;
|
push: error out when the "upstream" semantics does not make sense
The user can say "git push" without specifying any refspec. When using
the "upstream" semantics via the push.default configuration, the user
wants to update the "upstream" branch of the current branch, which is the
branch at a remote repository the current branch is set to integrate with,
with this command.
However, there are cases that such a "git push" that uses the "upstream"
semantics does not make sense:
- The current branch does not have branch.$name.remote configured. By
definition, "git push" that does not name where to push to will not
know where to push to. The user may explicitly say "git push $there",
but again, by definition, no branch at repository $there is set to
integrate with the current branch in this case and we wouldn't know
which remote branch to update.
- The current branch does have branch.$name.remote configured, but it
does not specify branch.$name.merge that names what branch at the
remote this branch integrates with. "git push" knows where to push in
this case (or the user may explicitly say "git push $remote" to tell us
where to push), but we do not know which remote branch to update.
- The current branch does have its remote and upstream branch configured,
but the user said "git push $there", where $there is not the remote
named by "branch.$name.remote". By definition, no branch at repository
$there is set to integrate with the current branch in this case, and
this push is not meant to update any branch at the remote repository
$there.
The first two cases were already checked correctly, but the third case was
not checked and we ended up updating the branch named branch.$name.merge
at repository $there, which was totally bogus.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-31 01:07:12 +02:00
|
|
|
url_nr = push_url_of_remote(remote, &url);
|
2009-11-18 02:42:22 +01:00
|
|
|
if (url_nr) {
|
|
|
|
|
for (i = 0; i < url_nr; i++) {
|
|
|
|
|
struct transport *transport =
|
|
|
|
|
transport_get(remote, url[i]);
|
|
|
|
|
if (push_with_options(transport, flags))
|
|
|
|
|
errs++;
|
2009-08-08 09:51:08 +02:00
|
|
|
}
|
2009-11-18 02:42:22 +01:00
|
|
|
} else {
|
|
|
|
|
struct transport *transport =
|
|
|
|
|
transport_get(remote, NULL);
|
|
|
|
|
|
|
|
|
|
if (push_with_options(transport, flags))
|
|
|
|
|
errs++;
|
git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 06:22:49 +02:00
|
|
|
}
|
2007-04-07 08:04:53 +02:00
|
|
|
return !!errs;
|
git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 06:22:49 +02:00
|
|
|
}
|
|
|
|
|
|
2011-08-20 00:08:47 +02:00
|
|
|
static int option_parse_recurse_submodules(const struct option *opt,
|
|
|
|
|
const char *arg, int unset)
|
|
|
|
|
{
|
|
|
|
|
int *flags = opt->value;
|
2012-03-29 09:21:24 +02:00
|
|
|
|
|
|
|
|
if (*flags & (TRANSPORT_RECURSE_SUBMODULES_CHECK |
|
|
|
|
|
TRANSPORT_RECURSE_SUBMODULES_ON_DEMAND))
|
|
|
|
|
die("%s can only be used once.", opt->long_name);
|
|
|
|
|
|
2011-08-20 00:08:47 +02:00
|
|
|
if (arg) {
|
|
|
|
|
if (!strcmp(arg, "check"))
|
|
|
|
|
*flags |= TRANSPORT_RECURSE_SUBMODULES_CHECK;
|
2012-03-29 09:21:24 +02:00
|
|
|
else if (!strcmp(arg, "on-demand"))
|
|
|
|
|
*flags |= TRANSPORT_RECURSE_SUBMODULES_ON_DEMAND;
|
2011-08-20 00:08:47 +02:00
|
|
|
else
|
|
|
|
|
die("bad %s argument: %s", opt->long_name, arg);
|
|
|
|
|
} else
|
2012-03-29 09:21:24 +02:00
|
|
|
die("option %s needs an argument (check|on-demand)",
|
|
|
|
|
opt->long_name);
|
2011-08-20 00:08:47 +02:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2014-10-22 16:57:49 +02:00
|
|
|
static int git_push_config(const char *k, const char *v, void *cb)
|
|
|
|
|
{
|
|
|
|
|
struct wt_status *s = cb;
|
|
|
|
|
int status;
|
|
|
|
|
|
|
|
|
|
status = git_gpg_config(k, v, NULL);
|
|
|
|
|
if (status)
|
|
|
|
|
return status;
|
|
|
|
|
return git_default_config(k, v, s);
|
|
|
|
|
}
|
|
|
|
|
|
2006-07-29 07:44:25 +02:00
|
|
|
int cmd_push(int argc, const char **argv, const char *prefix)
|
git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 06:22:49 +02:00
|
|
|
{
|
2007-09-11 05:03:04 +02:00
|
|
|
int flags = 0;
|
2007-11-05 04:35:37 +01:00
|
|
|
int tags = 0;
|
2008-04-17 13:17:20 +02:00
|
|
|
int rc;
|
2007-05-12 17:45:53 +02:00
|
|
|
const char *repo = NULL; /* default repository */
|
2007-11-05 04:35:37 +01:00
|
|
|
struct option options[] = {
|
2010-02-24 13:50:24 +01:00
|
|
|
OPT__VERBOSITY(&verbosity),
|
2012-08-20 14:32:33 +02:00
|
|
|
OPT_STRING( 0 , "repo", &repo, N_("repository"), N_("repository")),
|
|
|
|
|
OPT_BIT( 0 , "all", &flags, N_("push all refs"), TRANSPORT_PUSH_ALL),
|
|
|
|
|
OPT_BIT( 0 , "mirror", &flags, N_("mirror all refs"),
|
2008-07-20 14:02:20 +02:00
|
|
|
(TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE)),
|
2013-08-03 13:51:19 +02:00
|
|
|
OPT_BOOL( 0, "delete", &deleterefs, N_("delete refs")),
|
|
|
|
|
OPT_BOOL( 0 , "tags", &tags, N_("push tags (can't be used with --all or --mirror)")),
|
2012-08-20 14:32:33 +02:00
|
|
|
OPT_BIT('n' , "dry-run", &flags, N_("dry run"), TRANSPORT_PUSH_DRY_RUN),
|
|
|
|
|
OPT_BIT( 0, "porcelain", &flags, N_("machine-readable output"), TRANSPORT_PUSH_PORCELAIN),
|
|
|
|
|
OPT_BIT('f', "force", &flags, N_("force updates"), TRANSPORT_PUSH_FORCE),
|
remote.c: add command line option parser for "--force-with-lease"
Update "git push" and "git send-pack" to parse this commnd line
option.
The intended sematics is:
* "--force-with-lease" alone, without specifying the details, will
protect _all_ remote refs that are going to be updated by
requiring their current value to be the same as some reasonable
default, unless otherwise specified;
* "--force-with-lease=refname", without specifying the expected
value, will protect that refname, if it is going to be updated,
by requiring its current value to be the same as some reasonable
default.
* "--force-with-lease=refname:value" will protect that refname, if
it is going to be updated, by requiring its current value to be
the same as the specified value; and
* "--no-force-with-lease" will cancel all the previous --force-with-lease on the
command line.
For now, "some reasonable default" is tentatively defined as "the
value of the remote-tracking branch we have for the ref of the
remote being updated", and it is an error if we do not have such a
remote-tracking branch. But this is known to be fragile, its use is
not yet recommended, and hopefully we will find more reasonable
default as we gain experience with this feature. The manual marks
the feature as experimental unless the expected value is specified
explicitly for this reason.
Because the command line options are parsed _before_ we know which
remote we are pushing to, there needs further processing to the
parsed data after we instantiate the transport object to:
* expand "refname" given by the user to a full refname to be
matched with the list of "struct ref" used in match_push_refs()
and set_ref_status_for_push(); and
* learning the actual local ref that is the remote-tracking branch
for the specified remote ref.
Further, some processing need to be deferred until we find the set
of remote refs and match_push_refs() returns in order to find the
ones that need to be checked after explicit ones have been processed
for "--force-with-lease" (no specific details).
These post-processing will be the topic of the next patch.
This option was originally called "cas" (for "compare and swap"),
the name which nobody liked because it was too technical. The
second attempt called it "lockref" (because it is conceptually like
pushing after taking a lock) but the word "lock" was hated because
it implied that it may reject push by others, which is not the way
this option works. This round calls it "force-with-lease". You
assume you took the lease on the ref when you fetched to decide what
the rebased history should be, and you can push back only if the
lease has not been broken.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 00:34:36 +02:00
|
|
|
{ OPTION_CALLBACK,
|
|
|
|
|
0, CAS_OPT_NAME, &cas, N_("refname>:<expect"),
|
|
|
|
|
N_("require old value of ref to be at this value"),
|
|
|
|
|
PARSE_OPT_OPTARG, parseopt_push_cas_option },
|
2012-08-20 14:32:33 +02:00
|
|
|
{ OPTION_CALLBACK, 0, "recurse-submodules", &flags, N_("check"),
|
2012-08-20 14:32:55 +02:00
|
|
|
N_("control recursive pushing of submodules"),
|
2011-08-20 00:08:47 +02:00
|
|
|
PARSE_OPT_OPTARG, option_parse_recurse_submodules },
|
2013-08-03 13:51:19 +02:00
|
|
|
OPT_BOOL( 0 , "thin", &thin, N_("use thin pack")),
|
2012-08-20 14:32:33 +02:00
|
|
|
OPT_STRING( 0 , "receive-pack", &receivepack, "receive-pack", N_("receive pack program")),
|
|
|
|
|
OPT_STRING( 0 , "exec", &receivepack, "receive-pack", N_("receive pack program")),
|
|
|
|
|
OPT_BIT('u', "set-upstream", &flags, N_("set upstream for git pull/status"),
|
2010-01-16 22:45:31 +01:00
|
|
|
TRANSPORT_PUSH_SET_UPSTREAM),
|
2012-08-20 14:32:33 +02:00
|
|
|
OPT_BOOL(0, "progress", &progress, N_("force progress reporting")),
|
|
|
|
|
OPT_BIT(0, "prune", &flags, N_("prune locally removed refs"),
|
2012-02-22 23:43:41 +01:00
|
|
|
TRANSPORT_PUSH_PRUNE),
|
2013-01-13 06:17:03 +01:00
|
|
|
OPT_BIT(0, "no-verify", &flags, N_("bypass pre-push hook"), TRANSPORT_PUSH_NO_HOOK),
|
2013-03-04 21:09:50 +01:00
|
|
|
OPT_BIT(0, "follow-tags", &flags, N_("push missing but relevant tags"),
|
|
|
|
|
TRANSPORT_PUSH_FOLLOW_TAGS),
|
push: the beginning of "git push --signed"
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it does not mean I want to push it out to my
'master' branch---it is likely that I only want it in 'maint', so
the signature on the object alone is insufficient.
The only assurance to you that 'maint' points at what I wanted to
place there comes from your trust on the hosting site and my
authentication with it, which cannot easily audited later.
Introduce a mechanism that allows you to sign a "push certificate"
(for the lack of better name) every time you push, asserting that
what object you are pushing to update which ref that used to point
at what other object. Think of it as a cryptographic protection for
ref updates, similar to signed tags/commits but working on an
orthogonal axis.
The basic flow based on this mechanism goes like this:
1. You push out your work with "git push --signed".
2. The sending side learns where the remote refs are as usual,
together with what protocol extension the receiving end
supports. If the receiving end does not advertise the protocol
extension "push-cert", an attempt to "git push --signed" fails.
Otherwise, a text file, that looks like the following, is
prepared in core:
certificate version 0.1
pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700
7339ca65... 21580ecb... refs/heads/master
3793ac56... 12850bec... refs/heads/next
The file begins with a few header lines, which may grow as we
gain more experience. The 'pusher' header records the name of
the signer (the value of user.signingkey configuration variable,
falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the
certificate generation. After the header, a blank line follows,
followed by a copy of the protocol message lines.
Each line shows the old and the new object name at the tip of
the ref this push tries to update, in the way identical to how
the underlying "git push" protocol exchange tells the ref
updates to the receiving end (by recording the "old" object
name, the push certificate also protects against replaying). It
is expected that new command packet types other than the
old-new-refname kind will be included in push certificate in the
same way as would appear in the plain vanilla command packets in
unsigned pushes.
The user then is asked to sign this push certificate using GPG,
formatted in a way similar to how signed tag objects are signed,
and the result is sent to the other side (i.e. receive-pack).
In the protocol exchange, this step comes immediately before the
sender tells what the result of the push should be, which in
turn comes before it sends the pack data.
3. When the receiving end sees a push certificate, the certificate
is written out as a blob. The pre-receive hook can learn about
the certificate by checking GIT_PUSH_CERT environment variable,
which, if present, tells the object name of this blob, and make
the decision to allow or reject this push. Additionally, the
post-receive hook can also look at the certificate, which may be
a good place to log all the received certificates for later
audits.
Because a push certificate carry the same information as the usual
command packets in the protocol exchange, we can omit the latter
when a push certificate is in use and reduce the protocol overhead.
This however is not included in this patch to make it easier to
review (in other words, the series at this step should never be
released without the remainder of the series, as it implements an
interim protocol that will be incompatible with the final one).
As such, the documentation update for the protocol is left out of
this step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 20:17:07 +02:00
|
|
|
OPT_BIT(0, "signed", &flags, N_("GPG sign the push"), TRANSPORT_PUSH_CERT),
|
2007-11-05 04:35:37 +01:00
|
|
|
OPT_END()
|
|
|
|
|
};
|
git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 06:22:49 +02:00
|
|
|
|
2011-02-24 15:30:19 +01:00
|
|
|
packet_trace_identity("push");
|
2014-10-22 16:57:49 +02:00
|
|
|
git_config(git_push_config, NULL);
|
2009-05-23 20:53:12 +02:00
|
|
|
argc = parse_options(argc, argv, prefix, options, push_usage, 0);
|
2007-11-05 04:35:37 +01:00
|
|
|
|
2009-12-30 20:57:42 +01:00
|
|
|
if (deleterefs && (tags || (flags & (TRANSPORT_PUSH_ALL | TRANSPORT_PUSH_MIRROR))))
|
2011-02-23 00:42:11 +01:00
|
|
|
die(_("--delete is incompatible with --all, --mirror and --tags"));
|
2009-12-30 20:57:42 +01:00
|
|
|
if (deleterefs && argc < 2)
|
2011-02-23 00:42:11 +01:00
|
|
|
die(_("--delete doesn't make sense without any refs"));
|
2009-12-30 20:57:42 +01:00
|
|
|
|
2007-11-05 04:35:37 +01:00
|
|
|
if (tags)
|
|
|
|
|
add_refspec("refs/tags/*");
|
|
|
|
|
|
|
|
|
|
if (argc > 0) {
|
|
|
|
|
repo = argv[0];
|
push: use remote.$name.push as a refmap
Since f2690487 (fetch: opportunistically update tracking refs,
2013-05-11), we stopped taking a non-storing refspec given on the
command line of "git fetch" literally, and instead started mapping
it via remote.$name.fetch refspecs. This allows
$ git fetch origin master
from the 'origin' repository, which is configured with
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
to update refs/remotes/origin/master with the result, as if the
command line were
$ git fetch origin +master:refs/remotes/origin/master
to reduce surprises and improve usability. Before that change, a
refspec on the command line without a colon was only to fetch the
history and leave the result in FETCH_HEAD, without updating the
remote-tracking branches.
When you are simulating a fetch from you by your mothership with a
push by you into your mothership, instead of having:
[remote "satellite"]
fetch = +refs/heads/*:refs/remotes/satellite/*
on the mothership repository and running:
mothership$ git fetch satellite
you would have:
[remote "mothership"]
push = +refs/heads/*:refs/remotes/satellite/*
on your satellite machine, and run:
satellite$ git push mothership
Because we so far did not make the corresponding change to the push
side, this command:
satellite$ git push mothership master
does _not_ allow you on the satellite to only push 'master' out but
still to the usual destination (i.e. refs/remotes/satellite/master).
Implement the logic to map an unqualified refspec given on the
command line via the remote.$name.push refspec. This will bring a
bit more symmetry between "fetch" and "push".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04 00:41:15 +01:00
|
|
|
set_refspecs(argv + 1, argc - 1, repo);
|
git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 06:22:49 +02:00
|
|
|
}
|
2007-05-25 07:20:56 +02:00
|
|
|
|
2008-04-17 13:17:20 +02:00
|
|
|
rc = do_push(repo, flags);
|
|
|
|
|
if (rc == -1)
|
2007-11-10 00:32:25 +01:00
|
|
|
usage_with_options(push_usage, options);
|
2008-04-17 13:17:20 +02:00
|
|
|
else
|
|
|
|
|
return rc;
|
git builtin "push"
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 06:22:49 +02:00
|
|
|
}
|