threads / discuss / 8173

pull/push inconsistencies

Subject: pull/push inconsistencies

## tl;dr

11 messages between May 15, 2007 and May 16, 2007.

replies: 10people: 6as markdown or json

Martin Langhoff· May 15, 2007, 22:53 UTC · lore

I am noticing some UI inconsistencies with pull/push. Not sure where they are -- and quite busy atm -- if they are in bash I might be able to hunt them down and fix. In case anyone else cares...

--

When tracking several branches from a repo, git-pull does a fetch (of all the remote heads) and merges _only the tracking branch currently checked out_. That's ok. However, if I checkout another tracking branch and issue git-pull, the merge does not happen because git-fetch finds nothing new on the remote side. git-pull should merge anyway if remotes/origin/<trackinghead> is ahead of the local head.

The workaround is to call git-merge explicitly, but git-pull is misleading the user saying "nothing to merge" instead of completing the merge.

--

My second issue is that git-push does not update remotes/<repo>/<headname> so if I do git-push && gitk --all it looks as if I haven't pushed. Misleading again. :-/

--
Third issue - if I do
  # we start with a cloned repo that is in sync with
  # its "origin" repo. No local commits to speak of...
  # git-fetch brings updates to 3 remote branches - none affecting the current
  # checked out branch...
   git-fetch
   git-commit some/path
   git-push

the output of git-push will show _4_ branches being pushed. For some reason git-push says that it's pushing remotes/origin/branchname -> origin/branchname for all the branches fetched recently -- and not modified! I expect only _1_ branch to be named during push - the only one.

None of the above are showstoppers, but the user feedback of these commands - the very core workflow for beginners - is quite confusing. I know how to check that things are correct in spite of the messages, and by now I trust git internals to do the right thing. But newcomers are getting some frights over here...

cheers,
martin
Jakub Narebski· May 15, 2007, 23:21 UTC · re: Martin Langhoff · lore

Re: pull/push inconsistencies

Martin Langhoff wrote:
Show 10 quoted lines
> When tracking several branches from a repo, git-pull does a fetch (of
> all the remote heads) and merges _only the tracking branch currently
> checked out_. That's ok. However, if I checkout another tracking
> branch and issue git-pull, the merge does not happen because git-fetch
> finds nothing new on the remote side. git-pull should merge anyway if
> remotes/origin/<trackinghead> is ahead of the local head.
> 
> The workaround is to call git-merge explicitly, but git-pull is
> misleading the user saying "nothing to merge" instead of completing
> the merge.

Strange. This would be regression, but in my experience "git pull" _always_ merges, even if there is nothing to fetch. But I don't have branch to merge configured...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Junio C Hamano· May 16, 2007, 00:24 UTC · re: Martin Langhoff · lore

Re: pull/push inconsistencies

"Martin Langhoff" <martin.langhoff@gmail.com> writes:
Show 12 quoted lines
> I am noticing some UI inconsistencies with pull/push. Not sure where
> they are -- and quite busy atm -- if they are in bash I might be able
> to hunt them down and fix. In case anyone else cares...
>
> --
>
> When tracking several branches from a repo, git-pull does a fetch (of
> all the remote heads) and merges _only the tracking branch currently
> checked out_. That's ok. However, if I checkout another tracking
> branch and issue git-pull, the merge does not happen because git-fetch
> finds nothing new on the remote side. git-pull should merge anyway if
> remotes/origin/<trackinghead> is ahead of the local head.
That's my expectation and I am a bit surprised if it doesn't.
> My second issue is that git-push does not update
> remotes/<repo>/<headname> so if I do git-push && gitk --all it looks
> as if I haven't pushed. Misleading again. :-/

The standard answer is not to push into a live repository without understanding what you are doing.

I've been debating this myself, but I do not think of a good canned configuration to satisfy different workflows.

 - Central repository setup a la CVS would want to:
	$ git clone $remote
   would create
	[remote "origin"]
        	url = $remote
                pull = refs/heads/*:refs/remotes/origin/*
   and would want to rely on the "only-fast-forward" safety to
   push into the corresonding branch.
	$ git push
   would push only corresponding branch, so there is no need for
   configuration.
   However, this is usually good only for the CVS-style shared
   central bare repository.
 - When using multiple private repositories, hopping between
   mothership and satellite, often the arrangement to allow
   fetch and push be symmetrical is desired:
	satellite$ git clone $mothership
   would create:
   	[remote "origin"]
        	url = $mothership
                pull = refs/heads/*:refs/remotes/origin/*
   on the satellite.  But if mothership could push into
   satellite, you would also want to have
	[remote "satellite"]
                url = $satellite
                push = refs/heads/*:refs/remotes/origin/*
   to make "git push satellite" run on mothership and "git fetch
   origin" run on satellite be equivalent.
   In this workflow, it is clear that a push from the mothership
   alone would not affect the working tree of the satellite; in
   fact, pushing into tracking branches from the mothership is
   arranged to mirror fetching into tracking branches from the
   satellite, with the explicit purpose of not affecting the
   working tree of the satellite, so there is less room for
   confusion.
   However, we cannot make this the default, which would break
   the traditional CVS-style shared central repository
 - A developer who publishes to his public distribution point
   (bare):
	public$ git clone --bare $my_private_repo
        private$ git push $public
   This pushes the matching refs between the two, which is the
   right thing, without any configuration.  You would not
   accidentally publish newly created throwaway branches you
   used while working inside the private repository.

Unfortunately, historically "git-push" was publisher's tool (the last workflow was the primary target). Later central bare repository support was also documented. The second workflow is not very well supported.

And pushing into live repository using 'matching refs' is almost always a mistake, unless the user knows what he is doing.

Show 15 quoted lines
> Third issue - if I do
>
>  # we start with a cloned repo that is in sync with
>  # its "origin" repo. No local commits to speak of...
>  # git-fetch brings updates to 3 remote branches - none affecting the current
>  # checked out branch...
>   git-fetch
>   git-commit some/path
>   git-push
>
> the output of git-push will show _4_ branches being pushed. For some
> reason git-push says that it's pushing remotes/origin/branchname ->
> origin/branchname for all the branches fetched recently -- and not
> modified! I expect only _1_ branch to be named during push - the only
> one.

git-push without parameters and configuration pushes matching branches. This has been true from day one. Again, I think we should be able to make this safer so that "git-push" in cloned repository would do something more restricted (perhaps limiting to refs/heads?), but I do not think of a universally acceptable canned configuration.

> None of the above are showstoppers, but the user feedback of these
> commands - the very core workflow for beginners - is quite confusing.

Yes, git is distributed and perhaps the expectation to be able to "git push" without saying where to and what to push is coming from some centralized system mindset. If somehow we can disable "git push" before a sensible refspecs are configured, that would be an improvement for new users, but the "push matching refs" behaviour is very handy for already established workflows of people who publish things.

When pushing into your public distribution point, which does _NOT_ have remotes/* hierarchy by definition, what will match between your private working repository and your public distribution point are heads/ and tags/ and all goes well. You do not want to accidentally push your new throwaway branches.

Martin Langhoff· May 16, 2007, 01:11 UTC · re: Junio C Hamano · lore

Re: pull/push inconsistencies

On 5/16/07, Junio C Hamano <junkio@cox.net> wrote:
Show 9 quoted lines
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
> > When tracking several branches from a repo, git-pull does a fetch (of
> > all the remote heads) and merges _only the tracking branch currently
> > checked out_. That's ok. However, if I checkout another tracking
> > branch and issue git-pull, the merge does not happen because git-fetch
> > finds nothing new on the remote side. git-pull should merge anyway if
> > remotes/origin/<trackinghead> is ahead of the local head.
>
> That's my expectation and I am a bit surprised if it doesn't.
I'll try get a repro script then.
Show 6 quoted lines
> > My second issue is that git-push does not update
> > remotes/<repo>/<headname> so if I do git-push && gitk --all it looks
> > as if I haven't pushed. Misleading again. :-/
>
> The standard answer is not to push into a live repository
> without understanding what you are doing.

I don't quite understand that statement. I think I know what I am doing: telling git-push to push new commits from matching local refs to remote refs safely (only ff, unless there's a + in the configuration for that head).

Why can't git match that the remote is the remote in .git/refs/remotes and put the right data SHA1 in .git/refs/remotes/<headname>?

...
> And pushing into live repository using 'matching refs' is almost
> always a mistake, unless the user knows what he is doing.

Hey - I'm only using it because you've recommended it as a migration path! ;-) Combined with tracking branches, it works great.

Show 22 quoted lines
> > Third issue - if I do
> >
> >  # we start with a cloned repo that is in sync with
> >  # its "origin" repo. No local commits to speak of...
> >  # git-fetch brings updates to 3 remote branches - none affecting the current
> >  # checked out branch...
> >   git-fetch
> >   git-commit some/path
> >   git-push
> >
> > the output of git-push will show _4_ branches being pushed. For some
> > reason git-push says that it's pushing remotes/origin/branchname ->
> > origin/branchname for all the branches fetched recently -- and not
> > modified! I expect only _1_ branch to be named during push - the only
> > one.
>
> git-push without parameters and configuration pushes matching
> branches.  This has been true from day one.  Again, I think we
> should be able to make this safer so that "git-push" in cloned
> repository would do something more restricted (perhaps limiting
> to refs/heads?), but I do not think of a universally acceptable
> canned configuration.
There are 2 things that I see as wrong...
 - local .git/refs/remote/origin/foo and refs/heads/foo match - why is
git-push talking about updating them?
 - matching refs should ignore .git/refs/remote

But perhaps I'm naive in thinking that the 'matching refs' thing will ignore the local .git/refs/remotes directory. AFAICS it's the only sane thing to do.

cheers,
martin
Junio C Hamano· May 16, 2007, 01:22 UTC · re: Martin Langhoff · lore

Re: pull/push inconsistencies

"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> There are 2 things that I see as wrong...
> - local .git/refs/remote/origin/foo and refs/heads/foo match - why is
> git-push talking about updating them?
Ooo...

Do you mean if you have refs/remotes/origin/foo locally, and push into a repository that has refs/heads/foo (but not refs/remotes/origin/foo), the push results in refs/heads/foo getting updated? If that is what is happening (without any refspecs to instruct git-push to do so) that sounds quite buggy. I need to look into the code for this one.

And I think earlier one I was confused that I thought you were talking about pushing into refs/heads/branch (where branch is checked out). Sorry.

Show 5 quoted lines
> - matching refs should ignore .git/refs/remote
>
> ... the 'matching refs' thing will
> ignore the local .git/refs/remotes directory. AFAICS it's the only
> sane thing to do.

I think you are probably right in that matching only heads and perhaps tags is a sane thing to do (even tags/ is debatable, as they are supposed to be immutable by convention). As a matter of fact I do not recall which part of refs/ namespace it looks at, but it is a very old part of the system and I would not be surprised if it silently assumed that there are only heads and tags there (and not explicitly matching heads and tags only).

J. Bruce Fields· May 16, 2007, 01:40 UTC · re: Junio C Hamano · lore

Re: pull/push inconsistencies

On Tue, May 15, 2007 at 06:22:29PM -0700, Junio C Hamano wrote:
Show 14 quoted lines
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
> 
> > There are 2 things that I see as wrong...
> > - local .git/refs/remote/origin/foo and refs/heads/foo match - why is
> > git-push talking about updating them?
> 
> Ooo...
> 
> Do you mean if you have refs/remotes/origin/foo locally, and
> push into a repository that has refs/heads/foo (but not
> refs/remotes/origin/foo), the push results in refs/heads/foo
> getting updated?  If that is what is happening (without any
> refspecs to instruct git-push to do so) that sounds quite buggy.
> I need to look into the code for this one.

I understand him to be saying that it *doesn't* do that, and that he *wants* it to.

People think of refs/remotes/origin as a cache of the origin repository's branch heads, and they expect it to be updated on write (push) as well as read (fetch).

--b.
Martin Langhoff· May 16, 2007, 01:51 UTC · re: J. Bruce Fields · lore

Re: pull/push inconsistencies

On 5/16/07, J. Bruce Fields <bfields@fieldses.org> wrote:
Show 18 quoted lines
> On Tue, May 15, 2007 at 06:22:29PM -0700, Junio C Hamano wrote:
> > "Martin Langhoff" <martin.langhoff@gmail.com> writes:
> >
> > > There are 2 things that I see as wrong...
> > > - local .git/refs/remote/origin/foo and refs/heads/foo match - why is
> > > git-push talking about updating them?
> >
> > Ooo...
> >
> > Do you mean if you have refs/remotes/origin/foo locally, and
> > push into a repository that has refs/heads/foo (but not
> > refs/remotes/origin/foo), the push results in refs/heads/foo
> > getting updated?  If that is what is happening (without any
> > refspecs to instruct git-push to do so) that sounds quite buggy.
> > I need to look into the code for this one.
>
> I understand him to be saying that it *doesn't* do that, and that he
> *wants* it to.
I'm probably in a bad-communication day :-/

I have locally .git/refs/remotes/origin/foo, and the remote repo has refs/heads/foo. I don't have .git/refs/heads/foo in this case. When I do git-push, it doesn't really change the remote repo, but it _tells_ me it has.

So - behaviour-wise, it's fine. It's not changing the remote repo. But it tells me it does. It's just plain weird and misleading...

> People think of refs/remotes/origin as a cache of the origin
> repository's branch heads, and they expect it to be updated on write
> (push) as well as read (fetch).
Yes ;-)
cheers,
martin
Junio C Hamano· May 16, 2007, 02:30 UTC · re: Martin Langhoff · lore

Re: pull/push inconsistencies

"Martin Langhoff" <martin.langhoff@gmail.com> writes:
>> I understand him to be saying that it *doesn't* do that, and that he
>> *wants* it to.
>
> I'm probably in a bad-communication day :-/
Sorry, I think I am lacking my medication :-/
Show 7 quoted lines
> I have locally .git/refs/remotes/origin/foo, and the remote repo has
> refs/heads/foo. I don't have .git/refs/heads/foo in this case. When I
> do git-push, it doesn't really change the remote repo, but it _tells_
> me it has.
>
> So - behaviour-wise, it's fine. It's not changing the remote repo. But
> it tells me it does. It's just plain weird and misleading...

I would agree with that it is misleading or plain wrong if it says it updated something that it didn't.

Show 5 quoted lines
>> People think of refs/remotes/origin as a cache of the origin
>> repository's branch heads, and they expect it to be updated on write
>> (push) as well as read (fetch).
>
> Yes ;-)

On a related note, I think recent series from Daniel, parked in 'pu' while 1.5.2 is prepared, contained a new feature to update the refs/remotes/origin/* on the pushing repository after git-push, to save one round of fetch (that is, pretend that you fetched immediately after you pushed).

Martin Langhoff· May 16, 2007, 22:35 UTC · re: Martin Langhoff · lore

Re: pull/push inconsistencies

On 5/16/07, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> I'm probably in a bad-communication day :-/
Ok - I just repro'd the problem -- maybe this helps clarify...

I have a checkout of http://git.catalyst.net.nz/git/moodle-r2.git ( see http://git.catalyst.net.nz/gitweb ) where I have the following tracking branches:

  $ git branch
    mdl17-polhn
  * mdl18-local

I know that I am "all pushed out" - no local commits to push here. So I start my day and do

 $ git-pull
 # brings some commits, but nothing to mdl18-local
 $ git-merge origin/MOODLE_18_STABLE
 # messy merge from the upstream branch I track...
 $ git-commit
 $ git-push
 $ git-push
 updating 'refs/heads/mdl18-local'
    from f3f1ae5c9f73fe6e0872dfe0e072521b6fe26463
    to   3af93dafbd9162423e5f0a720d4d2081313789e2
  updating 'refs/remotes/origin/MOODLE_18_STABLE'
    from 52abd5d7c4f0ac54cfc0463d5276c159a02a76c0
    to   4cfaa3c85ee54ec8c0891157a6becdd8db34eb52
  updating 'refs/remotes/origin/cvshead'
    from 7bf579b243717c470770b1457a7d1c50f6a8dff6
    to   e835361626c5cd27cabdc046fc0e23a2c6ff98db
  updating 'refs/remotes/origin/mdl18-ldc'
    from eb91f220ccbbeb1e8b43496d0172e6cd1b6549ea
    to   af4c6ee952057d11b2dbf55103a5c3134640b70f
  updating 'refs/remotes/origin/mdl18-topnz'
    from a08fdb4decfa7b92c3030801c08378ee629c038d
    to   347bc44adbfdf7b800334cbb532d436fa73e87ac
   (removed some tag-related noise)
  Generating pack...
  Done counting 212 objects.
  Result has 72 objects.
  Deltifying 72 objects...
   100% (72/72) done
  Writing 72 objects...
  Unpacking 72 objects
   100% (72/72) done
  Total 72 (delta 65), reused 0 (delta 0)
  refs/heads/mdl18-local: f3f1ae5c9f73fe6e0872dfe0e072521b6fe26463 ->
 3af93dafbd9162423e5f0a720d4d2081313789e2
  refs/remotes/origin/MOODLE_18_STABLE:
52abd5d7c4f0ac54cfc0463d5276c159a02a76c0 ->
4cfaa3c85ee54ec8c0891157a6becdd8db34eb52
  refs/remotes/origin/cvshead:
7bf579b243717c470770b1457a7d1c50f6a8dff6 ->
e835361626c5cd27cabdc046fc0e23a2c6ff98db
  refs/remotes/origin/mdl18-ldc:
eb91f220ccbbeb1e8b43496d0172e6cd1b6549ea ->
af4c6ee952057d11b2dbf55103a5c3134640b70f
  refs/remotes/origin/mdl18-topnz:
a08fdb4decfa7b92c3030801c08378ee629c038d ->
347bc44adbfdf7b800334cbb532d436fa73e87ac

As you can see, it talks about updating lots of refs. Nonsense -- I think it's a bug. The only ref being updated is origin/mdl18-local on the remote repo, and it should update the local refs/remotes/origin/mdl18-local.

cheers,
m
Jeff King· May 16, 2007, 12:02 UTC · re: Junio C Hamano · lore

Re: pull/push inconsistencies

On Tue, May 15, 2007 at 05:24:28PM -0700, Junio C Hamano wrote:
Show 6 quoted lines
> > My second issue is that git-push does not update
> > remotes/<repo>/<headname> so if I do git-push && gitk --all it looks
> > as if I haven't pushed. Misleading again. :-/
> 
> The standard answer is not to push into a live repository
> without understanding what you are doing.

My impression here is that Martin is saying that pushing does not update the remote tracking branch in the local repository (as, e.g., cogito has always done). But I thought somebody (Ted?) recently submitted a patch to change that.

Show 6 quoted lines
> git-push without parameters and configuration pushes matching
> branches.  This has been true from day one.  Again, I think we
> should be able to make this safer so that "git-push" in cloned
> repository would do something more restricted (perhaps limiting
> to refs/heads?), but I do not think of a universally acceptable
> canned configuration.

I had done a patch in that direction (actually, it just avoided pushing refs/remotes/) and have been planning to follow up with restricting git-push to just refs/heads/. I'll try to work on that in the next day or so.

-Peff
Daniel Barkalow· May 16, 2007, 02:50 UTC · re: Martin Langhoff · lore

[PATCH] Re: pull/push inconsistencies

On Wed, 16 May 2007, Martin Langhoff wrote:
> My second issue is that git-push does not update
> remotes/<repo>/<headname> so if I do git-push && gitk --all it looks
> as if I haven't pushed. Misleading again. :-/

This patch is based on my "remote" series, currently in "pu". I'm not 100% sure that this is the right behavior for the case where the change isn't a fast-forward; if the push worked, it just assumes that you don't care if the tracking ref would be rewound, even if the fetch wouldn't force it. In this case, you must have rewound your head, and forced the push, so it's implausible that you want the tracking ref to go strictly forward when you've made the source of the ref rewind.

	-Daniel
*This .sig left intentionally blank*

---- cut here ---- Update local tracking refs when pushing

This also adds a --remote option to send-pack, which specifies the configured remote being used. It is provided automatically by git-push, and must match the url (which is still needed, since there could be multiple urls).

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
 builtin-push.c |    9 +++++++--
 send-pack.c    |   55 ++++++++++++++++++++++++++++++++++++++++++++++---------
 2 files changed, 53 insertions(+), 11 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 0e602f3..6084899 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -178,8 +178,13 @@ static int do_push(const char *repo)
 		if (!prefixcmp(dest, "http://") ||
 		    !prefixcmp(dest, "https://"))
 			sender = "http-push";
-		else if (thin)
-			argv[dest_argc++] = "--thin";
+		else {
+			char *rem = xmalloc(strlen(remote->name) + 10);
+			sprintf(rem, "--remote=%s", remote->name);
+			argv[dest_argc++] = rem;
+			if (thin)
+				argv[dest_argc++] = "--thin";
+		}
 		argv[0] = sender;
 		argv[dest_argc++] = dest;
 		while (dest_refspec_nr--)
diff --git a/send-pack.c b/send-pack.c
index 6851043..eabadbe 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -177,7 +177,7 @@ static int receive_status(int in)
 	return ret;
 }
 
-static int send_pack(int in, int out, int nr_refspec, char **refspec)
+static int send_pack(int in, int out, struct remote *remote, int nr_refspec, char **refspec)
 {
 	struct ref *ref;
 	int new_refs;
@@ -214,18 +214,19 @@ static int send_pack(int in, int out, int nr_refspec, char **refspec)
 	new_refs = 0;
 	for (ref = remote_refs; ref; ref = ref->next) {
 		char old_hex[60], *new_hex;
-		int delete_ref;
+		int will_delete_ref;
 
 		if (!ref->peer_ref)
 			continue;
 
-		delete_ref = is_null_sha1(ref->peer_ref->new_sha1);
-		if (delete_ref && !allow_deleting_refs) {
+
+		will_delete_ref = is_null_sha1(ref->peer_ref->new_sha1);
+		if (will_delete_ref && !allow_deleting_refs) {
 			error("remote does not support deleting refs");
 			ret = -2;
 			continue;
 		}
-		if (!delete_ref &&
+		if (!will_delete_ref &&
 		    !hashcmp(ref->old_sha1, ref->peer_ref->new_sha1)) {
 			if (verbose)
 				fprintf(stderr, "'%s': up-to-date\n", ref->name);
@@ -252,7 +253,7 @@ static int send_pack(int in, int out, int nr_refspec, char **refspec)
 		 */
 
 		if (!force_update &&
-		    !delete_ref &&
+		    !will_delete_ref &&
 		    !is_null_sha1(ref->old_sha1) &&
 		    !ref->force) {
 			if (!has_sha1_file(ref->old_sha1) ||
@@ -276,7 +277,7 @@ static int send_pack(int in, int out, int nr_refspec, char **refspec)
 			}
 		}
 		hashcpy(ref->new_sha1, ref->peer_ref->new_sha1);
-		if (!delete_ref)
+		if (!will_delete_ref)
 			new_refs++;
 		strcpy(old_hex, sha1_to_hex(ref->old_sha1));
 		new_hex = sha1_to_hex(ref->new_sha1);
@@ -291,7 +292,7 @@ static int send_pack(int in, int out, int nr_refspec, char **refspec)
 		else
 			packet_write(out, "%s %s %s",
 				     old_hex, new_hex, ref->name);
-		if (delete_ref)
+		if (will_delete_ref)
 			fprintf(stderr, "deleting '%s'\n", ref->name);
 		else {
 			fprintf(stderr, "updating '%s'", ref->name);
@@ -301,6 +302,28 @@ static int send_pack(int in, int out, int nr_refspec, char **refspec)
 			fprintf(stderr, "\n  from %s\n  to   %s\n",
 				old_hex, new_hex);
 		}
+		if (remote) {
+			struct refspec rs;
+			rs.src = ref->name;
+			remote_find_tracking(remote, &rs);
+			if (rs.dst) {
+				struct ref_lock *lock;
+				fprintf(stderr, " Also local %s\n", rs.dst);
+				if (will_delete_ref) {
+					if (delete_ref(rs.dst, NULL)) {
+						error("Failed to delete");
+					}
+				} else {
+					lock = lock_any_ref_for_update(rs.dst, NULL);
+					if (!lock)
+						error("Failed to lock");
+					else
+						write_ref_sha1(lock, ref->new_sha1,
+							       "update by push");
+				}
+				free(rs.dst);
+			}
+		}
 	}
 
 	packet_flush(out);
@@ -345,6 +368,8 @@ int main(int argc, char **argv)
 	char **heads = NULL;
 	int fd[2], ret;
 	pid_t pid;
+	char *remote_name = NULL;
+	struct remote *remote = NULL;
 
 	setup_git_directory();
 	git_config(git_default_config);
@@ -362,6 +387,10 @@ int main(int argc, char **argv)
 				receivepack = arg + 7;
 				continue;
 			}
+			if (!prefixcmp(arg, "--remote=")) {
+				remote_name = arg + 9;
+				continue;
+			}
 			if (!strcmp(arg, "--all")) {
 				send_all = 1;
 				continue;
@@ -394,10 +423,18 @@ int main(int argc, char **argv)
 		usage(send_pack_usage);
 	verify_remote_names(nr_heads, heads);
 
+	if (remote_name) {
+		remote = remote_get(remote_name);
+		if (!remote_has_uri(remote, dest)) {
+			die("Destination %s is not a uri for %s",
+			    dest, remote_name);
+		}
+	}
+
 	pid = git_connect(fd, dest, receivepack);
 	if (pid < 0)
 		return 1;
-	ret = send_pack(fd[0], fd[1], nr_heads, heads);
+	ret = send_pack(fd[0], fd[1], remote, nr_heads, heads);
 	close(fd[0]);
 	close(fd[1]);
 	ret |= finish_connect(pid);
-- 
1.5.2.rc2.90.gc593-dirty

← back to recent threads