Re: Question regarding git fetch
- From
Jeff King <peff@peff.net>
- Date
- Aug 27, 2009, 21:53 UTC
- Message-ID
- <20090827215305.GA6348@coredump.intra.peff.net>
- In-Reply-To
- <20090827215007.GA6231@coredump.intra.peff.net>
On Thu, Aug 27, 2009 at 05:50:07PM -0400, Jeff King wrote:
Show 14 quoted lines
> > I think this is a good example that any change results from this > > discussion should apply _only_ to cases where command line refspecs lack > > colon (i.e. used to mean "do not store this anywhere but in FETCH_HEAD"). > > I don't think the colon is the issue. Consider the same situation, but I > say: > > # but today let's demo it first > $ git fetch origin master > $ git checkout -b demo FETCH_HEAD > > I'm still screwed. The issue is that you consider your configured > refspec destinations to be precious, and not merely a cache for what's > happening on the remote side.
Which, btw, led me to consider whether there are heuristics for deciding when a fetch refspec means one thing and not the other. I don't think there are reliable ones (probably the default configured refs/remotes/$remotename/* would not yield false positives, but I think limiting to that would yield false negatives). So maybe this is something that should be configurable, disabled by default for now, and maybe enabled by default in the future (v1.7.0?).
-Peff