Thread (6 messages) flat view 6 messages, 3 authors, 2016-06-15

Re: Question regarding git fetch

From: Jeff King <hidden>
Date: 2016-06-15 22:47:19

On Thu, Aug 27, 2009 at 05:50:07PM -0400, Jeff King wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help