From: Junio C Hamano <hidden> Date: 2016-06-15 22:57:18
Felipe Contreras [off-list ref] writes:
This is irrelevant, it's an implementation detail of 'git pull'. *THE
USER* is not running 'git fetch .'
To those who fear running "git pull", the following has worked as a
quick way to "preview" what they would be getting.
git fetch
git log ..FETCH_HEAD
and then they can "git merge FETCH_HEAD" to conclude it, or run a
"git pull" for real. We teach the more explicit form to end users
in our tutorial, but it shows the explicit form only because we want
to illustrate what goes on. Over time we added support to "git fetch"
(and "git pull") to make it possible for users to type less when the
remote and branch involved are obvious, but we carefully avoided
breaking this expectation.
So when "the user" is running "git fetch" on "mywork" branch that
happens to be forked from a local "master", i.e. her configuration
is set as
[branch "mywork"]
remote = .
merge = refs/heads/master
we still need to have FETCH_HEAD updated to point at what we would
be merging if she did a "git pull". It may be OK to additionally
fetch objects from 'origin' and update the remote tracking branches
associated with 'origin', but anything from 'origin' should not
contaminate what results in FETCH_HEAD---it should record whatever
we record when we did fetch refs/heads/master from '.'.
As I said in the very beginning, it was a mistake for me to suggest
adding a special case behaviour for '.' remote in the first place.
It breaks a long-standing expectation and workflow built around it.
So sorry for wasting our time, and consider this as a misguided
excursion.
From: Felipe Contreras <hidden> Date: 2016-06-15 22:57:19
On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano [off-list ref] wrote:
Felipe Contreras [off-list ref] writes:
quoted
This is irrelevant, it's an implementation detail of 'git pull'. *THE
USER* is not running 'git fetch .'
To those who fear running "git pull", the following has worked as a
quick way to "preview" what they would be getting.
git fetch
git log ..FETCH_HEAD
and then they can "git merge FETCH_HEAD" to conclude it, or run a
"git pull" for real. We teach the more explicit form to end users
in our tutorial,
That "tutorial" is mostly irrelevant; it has not been properly updated
in years, and it doesn't do it's job properly.
Nowadays most people use the Pro Git book, which doesn't mention
FETCH_HEAD even once. And why would it? It's not a useful concept for
typical users.
So when "the user" is running "git fetch" on "mywork" branch that
happens to be forked from a local "master", i.e. her configuration
is set as
[branch "mywork"]
remote = .
merge = refs/heads/master
we still need to have FETCH_HEAD updated to point at what we would
be merging if she did a "git pull".
No, we don't need that. That is only needed by 'git pull', and in
fact, it should be possible to reimplement 'git pull' so that it skips
FETCH_HEAD when the remote is local.
These are mere implementation details.
As I said in the very beginning, it was a mistake for me to suggest
adding a special case behaviour for '.' remote in the first place.
It breaks a long-standing expectation and workflow built around it.
The fact that it's "long-standing" doesn't mean it's sane.
So sorry for wasting our time, and consider this as a misguided
excursion.
It doesn't matter, the problem that 'git fetch' does something totally
and completely uses is still there.
--
Felipe Contreras
So when "the user" is running "git fetch" on "mywork" branch that
happens to be forked from a local "master", i.e. her configuration
is set as
[branch "mywork"]
remote = .
merge = refs/heads/master
Was the '.' example illustrative rather than exact. I see no case of
using '.' in my configs. Or am I completely missing the point? (e.g.
that the use of '.' an example of possible future usage)?
we still need to have FETCH_HEAD updated to point at what we would
be merging if she did a "git pull". It may be OK to additionally
fetch objects from 'origin' and update the remote tracking branches
associated with 'origin', but anything from 'origin' should not
contaminate what results in FETCH_HEAD---it should record whatever
we record when we did fetch refs/heads/master from '.'.
As I said in the very beginning, it was a mistake for me to suggest
adding a special case behaviour for '.' remote in the first place.
It breaks a long-standing expectation and workflow built around it.
So sorry for wasting our time, and consider this as a misguided
excursion.
--
So when "the user" is running "git fetch" on "mywork" branch that
happens to be forked from a local "master", i.e. her configuration
is set as
[branch "mywork"]
remote = .
merge = refs/heads/master
Was the '.' example illustrative rather than exact. I see no case of using
'.' in my configs. Or am I completely missing the point? (e.g. that the use
of '.' an example of possible future usage)?
% git checkout -t -b feature master
# work
% git rebase -i
--
Felipe Contreras
So when "the user" is running "git fetch" on "mywork" branch that
happens to be forked from a local "master", i.e. her configuration
is set as
[branch "mywork"]
remote = .
merge = refs/heads/master
Was the '.' example illustrative rather than exact. I see no case of
using
'.' in my configs. Or am I completely missing the point? (e.g. that
the use
of '.' an example of possible future usage)?
% git checkout -t -b feature master
# work
% git rebase -i
--
Felipe Contreras
--
OK, I see it (the dot '.' in the config file) now.
I've also located the documentation hidden at the end of git-config(1)
under branch.<name>.merge, even though your worked example has it
under remote not merge.
[branch "feature"]
remote = .
merge = refs/heads/master
"If you wish to setup git pull so that it merges into <name> from
another branch in the local repository, you can point
branch.<name>.merge to the desired branch, and use the special setting .
(a period) for branch.<name>.remote."
It feels as if this dwimmery(?) should also be listed in the gitcli(7)
documenation and under branch.<name>.remote in git-config(1) above it.
The use of dot '.' occured in a reply a couple of weeks ago:
Sent: Saturday, May 04, 2013 7:51 PM
Subject: Re: Pitfalls in auto-fast-forwarding heads that are not checked
out?
"Jonathan Nieder" [off-list ref] wrote:
Another trick is to use "git push":
git push . $production_sha1:refs/heads/master
So when "the user" is running "git fetch" on "mywork" branch that
happens to be forked from a local "master", i.e. her configuration
is set as
[branch "mywork"]
remote = .
merge = refs/heads/master
Was the '.' example illustrative rather than exact. I see no case of
using
'.' in my configs. Or am I completely missing the point? (e.g. that
the use
of '.' an example of possible future usage)?
% git checkout -t -b feature master
# work
% git rebase -i
--
Felipe Contreras
--
OK, I see it (the dot '.' in the config file) now.
I've also located the documentation hidden at the end of git-config(1)
under branch.<name>.merge, even though your worked example has it
under remote not merge.
[branch "feature"]
remote = .
merge = refs/heads/master
"If you wish to setup git pull so that it merges into <name> from
another branch in the local repository, you can point
branch.<name>.merge to the desired branch, and use the special setting .
(a period) for branch.<name>.remote."
This is called the upstream branch. Go to any branch, and do this:
% git checkout feature
% git branch --set-upstream-to master
And it would set:
remote = .
merge = refs/heads/master
Now you can do things like:
% git log feature@{upstream}..feature
Which gets translated to:
% git log master..feature
And:
% git rebase -i
Which gets translated to:
% git rebase -i master
This is nothing new.
--
Felipe Contreras