git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* Suggestion: git fetch <remote> <branch> to update remote-tracking branch
@ 2012-03-05 16:45 Antony Male
  2012-03-05 17:42 ` Junio C Hamano
  0 siblings, 1 reply; 3+ messages in thread
From: Antony Male @ 2012-03-05 16:45 UTC (permalink / raw
  To: git

Hi all,

First off, this is a very tentative suggestion.  It would result in a 
slight change to established behaviour, which I'm well aware could be a 
Bad Thing(tm).  However, I was encouraged by a number of people on #git 
to make it anyway, so here goes.

The issue is this: the two-argument form of 'git fetch' (e.g. 'git fetch 
<remote> <branch>') fetches the named ref into FETCH_HEAD, but does not 
update the related remote-tracking branch.  While this is intuitive 
behaviour when <remote> is a URL, we see a lot of git beginners 
attempting to run 'git fetch origin branch' and being confused when 
origin/branch isn't updated.  Similarly, 'git pull origin master' will, 
in a simple case, fast-forward the local master but not origin/master.

My suggestion, therefore, is to modify the behaviour of 'git fetch' such 
that 'git fetch <remote> <branch>' will update both FETCH_HEAD and the 
relevant remote-tracking branch, when <remote> is the name of a 
configured remote and <branch> contains only the src part of the 
refspec.  The behaviour would not change when <remote> was a URL or 
path, or when a <src>:<dst> refspec was used.

Of course, it would be desirable to be able to replicate the existing 
behaviour.  Currently, I don't have any good suggestions, although there 
may be an existing trick I'm missing.  Possible suggestions might be 
'git fetch <remote> <branch>:FETCH_HEAD' or 'git fetch <remote> 
<branch>:', or maybe a new flag?

What do people think?

Many thanks for your time and consideration,
Antony Male

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Suggestion: git fetch <remote> <branch> to update remote-tracking branch
  2012-03-05 16:45 Suggestion: git fetch <remote> <branch> to update remote-tracking branch Antony Male
@ 2012-03-05 17:42 ` Junio C Hamano
  2012-03-06  8:59   ` Jeff King
  0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2012-03-05 17:42 UTC (permalink / raw
  To: Antony Male; +Cc: git

Antony Male <antony.male@gmail.com> writes:

> What do people think?

I think this was discussed number of times here, and my vague
recollection of the conclusion last time is that it would be OK to
change the behaviour of single-shot fetch "fetch <remote> <branch>"
against a remote where there is already a default fetch refspec that
covers the <branch> so that such a fetch will update the remote
tracking branch that usually copies from <branch> (and only that
one).

We might need a proper deprecation and migration plan, though.  I
say "might" because offhand I don't know what the extent of damages
to existing users' habits will be if we didn't offer any.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Suggestion: git fetch <remote> <branch> to update remote-tracking branch
  2012-03-05 17:42 ` Junio C Hamano
@ 2012-03-06  8:59   ` Jeff King
  0 siblings, 0 replies; 3+ messages in thread
From: Jeff King @ 2012-03-06  8:59 UTC (permalink / raw
  To: Antony Male; +Cc: git, Junio C Hamano

On Mon, Mar 05, 2012 at 09:42:43AM -0800, Junio C Hamano wrote:

> > What do people think?
> 
> I think this was discussed number of times here, and my vague
> recollection of the conclusion last time is that it would be OK to
> change the behaviour of single-shot fetch "fetch <remote> <branch>"
> against a remote where there is already a default fetch refspec that
> covers the <branch> so that such a fetch will update the remote
> tracking branch that usually copies from <branch> (and only that
> one).
> 
> We might need a proper deprecation and migration plan, though.  I
> say "might" because offhand I don't know what the extent of damages
> to existing users' habits will be if we didn't offer any.

If you (or somebody else) wants to look into it, I've had this patch
hanging around in my repo since 2009, but it does cause a bunch of
failures in the test suite. I don't think I ever investigated whether
the test failures were bad assumptions in the tests, or signs of a real
problem. Those test failures may also give a clue about how unwitting
users would be affected.

---
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 65f5f9b..409c86c 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -156,6 +156,9 @@ static struct ref *get_ref_map(struct transport *transport,
 	const struct ref *remote_refs = transport_get_remote_refs(transport);
 
 	if (ref_count || tags == TAGS_SET) {
+		struct ref *tracking_refs = NULL;
+		struct ref **tracking_tail = &tracking_refs;
+
 		for (i = 0; i < ref_count; i++) {
 			get_fetch_map(remote_refs, &refs[i], &tail, 0);
 			if (refs[i].dst && refs[i].dst[0])
@@ -166,6 +169,12 @@ static struct ref *get_ref_map(struct transport *transport,
 			rm->merge = 1;
 		if (tags == TAGS_SET)
 			get_fetch_map(remote_refs, tag_refspec, &tail, 0);
+
+		for (i = 0; i < transport->remote->fetch_refspec_nr; i++)
+			get_fetch_map(ref_map, &transport->remote->fetch[i],
+					&tracking_tail, 0);
+		*tail = tracking_refs;
+		tail = tracking_tail;
 	} else {
 		/* Use the defaults */
 		struct remote *remote = transport->remote;

^ permalink raw reply related	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-03-06  8:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-05 16:45 Suggestion: git fetch <remote> <branch> to update remote-tracking branch Antony Male
2012-03-05 17:42 ` Junio C Hamano
2012-03-06  8:59   ` Jeff King

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).