Re: [Bug] branch.*.merge interpreted too strictly by tracking logic
Jeff King writes: > Did your report come > out of a real case, or was it just something you noticed? Some git-wrappers (like "repo") are reported to muck with the configuration files. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug] branch.*.merge interpreted too strictly by tracking logic
On Wed, Feb 05, 2014 at 01:05:04PM -0800, Junio C Hamano wrote: > > I don't recall us ever doing anything after that. I don't have a problem > > with making it work, of course, but I am not sure if it is really a bug. > > Once people get used to us being extra nice in some places, other > less nice places start looking more and more like bugs. It is an > unfortunate fact of life, but fixing them up is a good thing for > users. As long as we can make those less nice places nicer > uniformly without bending backwards or introducing unnecessary > ambiguities, that is, and I think this one can be done without > such downsides. Oh, absolutely, and I do not think we are breaking anything to start handling it better (my "I don't have a problem..." above). But I guess I am doubting that people are actually doing this at all now. I'd expect most people to have the config set automatically by "branch" or "checkout", or to use "branch --set-upstream-to". Did your report come out of a real case, or was it just something you noticed? -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug] branch.*.merge interpreted too strictly by tracking logic
Jeff King writes: > Is it legal to put an unqualified ref there? A wise man once said[1]: > > > Actually, it is broken in a lot of places. for-each-ref relies on > > the same code as "git status", "git checkout", etc, which will all > > fail to display tracking info. I believe the same code is also used > > for updating tracking branches on push. So I'm not sure if it was > > ever intended to be a valid setting. > > It wasn't. Some places may accept them gracefully by either being > extra nice or by accident. > > I don't recall us ever doing anything after that. I don't have a problem > with making it work, of course, but I am not sure if it is really a bug. Once people get used to us being extra nice in some places, other less nice places start looking more and more like bugs. It is an unfortunate fact of life, but fixing them up is a good thing for users. As long as we can make those less nice places nicer uniformly without bending backwards or introducing unnecessary ambiguities, that is, and I think this one can be done without such downsides. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug] branch.*.merge interpreted too strictly by tracking logic
On Tue, Feb 04, 2014 at 02:49:16PM -0800, Junio C Hamano wrote:
> Let's tell these branches that they are both supposed to be building
> on top of 'master'.
>
> : gitster track/master; git config branch.foo.remote .
> : gitster track/master; git config branch.foo.merge refs/heads/master
> : gitster track/master; git config branch.bar.remote .
> : gitster track/master; git config branch.bar.merge master
>
> The difference between the two is that 'foo' spells the @{upstream}
> branch in full (which is the recommended practice), while 'bar' is
> loose and asks for 'master'.
Is it legal to put an unqualified ref there? A wise man once said[1]:
> Actually, it is broken in a lot of places. for-each-ref relies on
> the same code as "git status", "git checkout", etc, which will all
> fail to display tracking info. I believe the same code is also used
> for updating tracking branches on push. So I'm not sure if it was
> ever intended to be a valid setting.
It wasn't. Some places may accept them gracefully by either being
extra nice or by accident.
I don't recall us ever doing anything after that. I don't have a problem
with making it work, of course, but I am not sure if it is really a bug.
-Peff
[1] http://thread.gmane.org/gmane.comp.version-control.git/121671
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug] branch.*.merge interpreted too strictly by tracking logic
Start from an empty repository like so:
: gitster track; git init
Initialized empty Git repository in /var/tmp/x/track/.git/
: gitster track/master; git commit --allow-empty -m initial
[master (root-commit) abdcd1c] initial
: gitster track/master; git branch foo
: gitster track/master; git branch bar
: gitster track/master; git commit --allow-empty -m second
[master 78e28f4] second
Now, 'master' has two commits, while 'foo' and 'bar' both are one
commit behind, pointing at 'master^1'.
Let's tell these branches that they are both supposed to be building
on top of 'master'.
: gitster track/master; git config branch.foo.remote .
: gitster track/master; git config branch.foo.merge refs/heads/master
: gitster track/master; git config branch.bar.remote .
: gitster track/master; git config branch.bar.merge master
The difference between the two is that 'foo' spells the @{upstream}
branch in full (which is the recommended practice), while 'bar' is
loose and asks for 'master'.
Let's see what happens on these two branches. First 'foo':
: gitster track/master; git checkout foo
Switched to branch 'foo'
Your branch is behind 'master' by 1 commit, and can be
fast-forwarded.
(use "git pull" to update your local branch)
: gitster track/foo; git pull
From .
* branchmaster -> FETCH_HEAD
Updating abdcd1c..78e28f4
Fast-forward
The 'checkout' correctly reports that 'foo' is building on (local)
'master'. 'pull' works as expected, of course.
Now, here is the bug part. The same thing on 'bar':
: gitster track/foo; git checkout bar
Switched to branch 'bar'
Your branch is based on 'master', but the upstream is gone.
(use "git branch --unset-upstream" to fixup)
It knows about 'master', but what is "the upstream is gone"? It is
our local repository and it definitely is not gone.
But 'pull' of course works as expected (this behaviour is older and
stable for a long time since even before @{upstream} was invented).
: gitster track/bar; git pull
From .
* branchmaster -> FETCH_HEAD
Updating abdcd1c..78e28f4
Fast-forward
I suspect that the real culprit is somewhere in wt-status.c
: gitster track/bar; git status
On branch bar
Your branch is based on 'master', but the upstream is gone.
(use "git branch --unset-upstream" to fixup)
nothing to commit, working directory clean
Resolving @{upstream} works just fine for both.
: gitster track/bar; git rev-parse --symbolic-full-name foo@{upstream}
refs/heads/master
: gitster track/bar; git rev-parse --symbolic-full-name bar@{upstream}
refs/heads/master
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
