From: Antony Male <antony.male@gmail.com>
To: git@vger.kernel.org
Subject: Suggestion: git fetch <remote> <branch> to update remote-tracking branch
Date: Mon, 05 Mar 2012 16:45:53 +0000 [thread overview]
Message-ID: <4F54EDC1.80608@gmail.com> (raw)
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
next reply other threads:[~2012-03-05 16:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-05 16:45 Antony Male [this message]
2012-03-05 17:42 ` Suggestion: git fetch <remote> <branch> to update remote-tracking branch Junio C Hamano
2012-03-06 8:59 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F54EDC1.80608@gmail.com \
--to=antony.male@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.