Re: Question regarding git fetch

Jeff King [off-list ref] writes:

  # we usually fetch the remote's master straight into our production
  # branch for deployment
  $ git config remote.origin.fetch refs/heads/master:refs/heads/production

  # but today let's demo it first
  $ git fetch origin master:demo

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").

On Thu, Aug 27, 2009 at 02:44:54PM -0700, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

  # we usually fetch the remote's master straight into our production
  # branch for deployment
  $ git config remote.origin.fetch refs/heads/master:refs/heads/production

  # but today let's demo it first
  $ git fetch origin master:demo

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.

-Peff

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

On Thu, Aug 27, 2009 at 9:50 PM, Jeff King[off-list ref] wrote:

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.

Is the "precious remote ref" concept perhaps an imaginary one?

After all, if I *really* care about the prior state of the remote, I
can just make it a remote branch.  And if (as often happens) I just
want to know what's new in that ref since last time I merged, it's
simply

   git log master..origin/master

This works even if master has extra commits vs. origin/master, since
the double-dot invokes git-merge-base.

I think this might be a much more common than the case where people
actually want to see "what's changed since last time I checked what's
changed."  At least, the latter question has never been very
interesting to me, or if it is, it's easy for me to tell by eye.

Avery

On Thu, Aug 27, 2009 at 10:12:50PM +0000, Avery Pennarun wrote:

quoted

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.

Is the "precious remote ref" concept perhaps an imaginary one?

Maybe. I certainly don't use it. But I am trying to consider corner
cases where somebody who _isn't_ me is going to get screwed by a
change we make.

After all, if I *really* care about the prior state of the remote, I
can just make it a remote branch.  And if (as often happens) I just

Do you mean "local branch" here?

want to know what's new in that ref since last time I merged, it's
simply

   git log master..origin/master

This works even if master has extra commits vs. origin/master, since
the double-dot invokes git-merge-base.

Well, ".." doesn't use git-merge-base. But yes, I actually do this,
except I do:

  gitk master...origin/master

-Peff

On Thu, Aug 27, 2009 at 10:16 PM, Jeff King[off-list ref] wrote:

On Thu, Aug 27, 2009 at 10:12:50PM +0000, Avery Pennarun wrote:

quoted

After all, if I *really* care about the prior state of the remote, I
can just make it a remote branch.  And if (as often happens) I just

Do you mean "local branch" here?

Yes.

quoted

want to know what's new in that ref since last time I merged, it's
simply

   git log master..origin/master

This works even if master has extra commits vs. origin/master, since
the double-dot invokes git-merge-base.

Well, ".." doesn't use git-merge-base. But yes, I actually do this,
except I do:

 gitk master...origin/master

Sorry, not my day for accuracy, it seems.  I use both, and I should
have remembered that the triple-dot is the one that worries about the
merge-base.

Have fun,

Avery