git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [bug in next ?] git-fetch/git-push issue

From
Daniel Barkalow <barkalow@iabervon.org>
Date
Nov 5, 2007, 18:17 UTC
Message-ID
<Pine.LNX.4.64.0711051259580.7357@iabervon.org>
In-Reply-To
<20071105175654.GD6205@artemis.corp>
On Mon, 5 Nov 2007, Pierre Habouzit wrote:
Show 21 quoted lines
> With the current tip of next[0], I have this bizare issue:
> 
>   * I have two branches say master, and next, I'm on next.
> 
>   * my master lags behind origin/master, but next is a fast-forward wrt
>     origin/next.
> 
> Now I git push:
> 
>     error: remote 'refs/heads/master' is not an ancestor of
>      local  'refs/heads/master'.
>      Maybe you are not up-to-date and need to pull first?
>     updating 'refs/heads/next'
>       from xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>       to   yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
>     Counting objects: 24, done.
>     Compressing objects: 100% (14/14), done.
>     Writing objects: 100% (14/14), done.
>     Total 14 (delta 12), reused 0 (delta 0)
>     refs/heads/next: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -> yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
>     updating local tracking ref 'refs/remotes/origin/master'
I think this is the bit that's wrong. I blame Jeff, in 334f4831. :)

The issue is that, in the previous version, we'd hit a continue on the not-an-ancestor message and not reach the update_tracking_ref() section for that ref. In 334f4831, all of the updating is after the loop, and it doesn't filter out the refs that didn't actually get pushed.

Probably, all of the "continue;"s in do_send_pack() should also strip off the peer_ref. Something like (totally untested):

diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 947c42b..6141672 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -254,12 +254,16 @@ static int do_send_pack(int in, int out, struct remote *remote, int nr_refspec,
 		if (will_delete_ref && !allow_deleting_refs) {
 			error("remote does not support deleting refs");
 			ret = -2;
+			free(ref->peer_ref);
+			ref->peer_ref = NULL;
 			continue;
 		}
 		if (!will_delete_ref &&
 		    !hashcmp(ref->old_sha1, ref->peer_ref->new_sha1)) {
 			if (args.verbose)
 				fprintf(stderr, "'%s': up-to-date\n", ref->name);
+			free(ref->peer_ref);
+			ref->peer_ref = NULL;
 			continue;
 		}
 
@@ -303,6 +307,8 @@ static int do_send_pack(int in, int out, struct remote *remote, int nr_refspec,
 				      ref->name,
 				      ref->peer_ref->name);
 				ret = -2;
+				free(ref->peer_ref);
+				ref->peer_ref = NULL;
 				continue;
 			}
 		}
Previous: Pierre HabouzitNext: Jeff King
Message 2 of 16 in “[bug in next ?] git-fetch/git-push issue”
  1. Pierre HabouzitNov 5, 2007
  2. Daniel BarkalowNov 5, 2007
  3. Jeff KingNov 5, 2007
  4. Daniel BarkalowNov 5, 2007
  5. Jeff KingNov 5, 2007
  6. Junio C HamanoNov 5, 2007
  7. Daniel BarkalowNov 5, 2007
  8. Daniel BarkalowNov 5, 2007
  9. Jeff KingNov 6, 2007
  10. Pierre HabouzitNov 5, 2007
  11. Pierre HabouzitNov 6, 2007
  12. Jeff KingNov 6, 2007
  13. Junio C HamanoNov 6, 2007
  14. Jeff KingNov 6, 2007
  15. Pierre HabouzitNov 6, 2007
  16. Pierre HabouzitNov 7, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.