From: Drew Northup Date: Sun, 21 Oct 2012 12:15:41 GMT Subject: Re: git fetch documentation problem or bug Message-ID: In-Reply-To: <7vpq4silou.fsf@alter.siamese.dyndns.org> On Mon, Oct 8, 2012 at 7:33 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> In other words, you can do this from the command line if you want >> to do the update. >> >> $ git fetch origin master:refs/remotes/origin/master > > Now having said all that, we should probably revisit this and > possibly other issues and for the ones we can reach concensus, start > coding after 1.8.0 final. > * "git fetch $from $branch..." to update tracking branches > > This is the topic in this thread. > > I personally do not think the downside of breaking backward > compatibility is too bad. If we do this only when we already are > configured to keep remote tracking branch for branch $branch from > remote $from (it has to be given as a nickname, not URL that happens > to have an entry in the configuration), then a promiscuous fetch > that grabs from a URL (or a nickname that is configured not to keep > tracking branches) will not change any behaviour, and when you want > to keep your remote tracking branch intact while doing one-shot > fetch for whatever reason, you can say "git fetch $from $branch:" to > explicitly decline copying. How are we supposed to remember those are different? "git fetch $from $branch..." VS "git fetch $from $branch:" I strongly prefer EXPLICITLY setting tracking than expecting some extreme syntactic nuance to quietly do it for me now and confuse the heck out of me later. -- -Drew Northup -------------------------------------------------------------- "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59