pull/push inconsistencies

pull/push inconsistencies

[Martin Langhoff]

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

Re: pull/push inconsistencies

[Jakub Narebski]

Martin Langhoff wrote:

> 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

Re: pull/push inconsistencies

[Junio C Hamano]

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

> 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.

> 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.

Re: pull/push inconsistencies

[Martin Langhoff]

On 5/16/07, Junio C Hamano <junkio@cox.net> wrote:
> "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.

> > 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.

> > 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

Re: pull/push inconsistencies

[Junio C Hamano]

"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.

> - 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).

Re: pull/push inconsistencies

[J. Bruce Fields]

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.

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.

Re: pull/push inconsistencies

[Martin Langhoff]

On 5/16/07, J. Bruce Fields <bfields@fieldses.org> wrote:
> 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

Re: pull/push inconsistencies

[Junio C Hamano]

"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 :-/

> 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.

>> 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).

[PATCH] Re: pull/push inconsistencies

[Daniel Barkalow]

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

Re: pull/push inconsistencies

[Jeff King]

On Tue, May 15, 2007 at 05:24:28PM -0700, Junio C Hamano 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. :-/
> 
> 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.

> 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

Re: pull/push inconsistencies

[Martin Langhoff]

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