git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH 4/5] Be more specific if upstream branch is not fetched
Date: Thu, 12 Apr 2012 11:15:35 +0200	[thread overview]
Message-ID: <4F869D37.1050508@in.waw.pl> (raw)
In-Reply-To: <20120412053017.GA27369@sigill.intra.peff.net>

On 04/12/2012 07:30 AM, Jeff King wrote:
> On Wed, Apr 11, 2012 at 06:17:14PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> 
>> If the branch configured as upstream was missing from
>> remote.<remote>.fetch, git said "Upstream branch not found".
>> We can be more helpful, and separate the cases when upstream
>> is not configured, and when it is configured, but specific
>> branch is not fetched.
> 
> I very much like the direction of this series, but I found this one a
> little confusing. If you have upstream config, but the configured merge
> branch is not part of the remote's refspecs, what does it mean? You
> would be able to "git pull", but you would not have a remote tracking
> branch representing what the remote has. So this message:
> 
>> -		return error("No upstream branch found for '%s'", upstream->name);
>> +		if (!upstream->merge)
>> +			return error("No upstream configured for branch '%s'",
>> +				     upstream->name);
>> +		return error("Upstream branch '%s' not fetched from remote '%s'",
>> +			     upstream->merge[0]->src, upstream->remote_name);
> 
> doesn't seem right to me. The upstream branch can be fetched just fine;
> it is simply that we do not maintain a tracking branch for it.
Hi,

maybe I'm missing something, but I think that git will not fetch branches
(or commits) which are not part of remote's refspecs. The fact that we do
not have a remote-tracking branch would be secondary.

% git init repo6
Initialized empty Git repository in /var/tmp/repo6/.git/
% cd repo6
% git commit -m init --allow-empty
[master (root-commit) 46c16de] init
% git checkout -b side
% git commit -m side --allow-empty
[side 6a0f0e9] side
% git clone . clone
Cloning into 'clone'...
done.
% cd clone
% git config remote.origin.fetch refs/heads/master:refs/remotes/master
% git fetch -v
From /var/tmp/repo6/.
 * [new branch]      master     -> master
% git show 6a0f0e9
fatal: ambiguous argument '6a0f0e9': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

The scenario leading to this error message would be:
1. user clones
2. user sets remote's refspec to avoid fetching too much stuff
3. user creates a side branch
4. user edits .git/config by hand to create [branch "side"]
based on [branch "master]. (I think that this is a pretty common thing to do.)
5. side@{u} is not fetched

A second scenario:

Actually, the fact that we have a remote tracking branch is ignored, if it is
missing from the remote's refspec. (Such situation will arise if the remote's
refspec is set after the remote branch was fetched.)

% git branch -a
  master
* side
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/side
% git show side@{u}
error: Upstream branch 'refs/heads/origin/side' not fetched from remote 'origin'
error: Upstream branch 'refs/heads/origin/side' not fetched from remote 'origin'
fatal: ambiguous argument 'side@{u}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
% git config remote.origin.fetch
refs/heads/master:refs/remotes/master
% tail -3 .git/config
[branch "side"]
        remote = origin
        merge = refs/heads/origin/side

So I think that the proposed error message is OK.

Zbyszek

> Having worked it out in my head, I think that is maybe even what you
> meant, but reading the message the first time left me very confused.
> I'm not sure what a better wording would be, though. I was thinking
> something like:
> 
>    Upstream branch '%s' is not stored as a remote-tracking branch.
> 
> or something, but I know we have had trouble with the term "tracking
> branch" in the past. Maybe there is a less loaded term.
> 
> -Peff
> 

  reply	other threads:[~2012-04-12  9:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-11 16:17 [PATCH 0/5] provide better error messages for @{upstream} Zbigniew Jędrzejewski-Szmek
2012-04-11 16:17 ` [PATCH 1/5] t1507: add additional tests " Zbigniew Jędrzejewski-Szmek
2012-04-11 17:52   ` Junio C Hamano
2012-04-11 17:57     ` Junio C Hamano
2012-04-11 21:51       ` Zbigniew Jędrzejewski-Szmek
2012-04-11 17:59     ` Matthieu Moy
2012-04-11 22:05       ` Zbigniew Jędrzejewski-Szmek
2012-04-11 16:17 ` [PATCH 2/5] Provide branch name in error message when using @{u} Zbigniew Jędrzejewski-Szmek
2012-04-11 18:00   ` Junio C Hamano
2012-04-11 22:13     ` Zbigniew Jędrzejewski-Szmek
2012-04-11 16:17 ` [PATCH 3/5] Provide better message for barnhc_wiht_tpyo@{u} Zbigniew Jędrzejewski-Szmek
2012-04-11 16:17 ` [PATCH 4/5] Be more specific if upstream branch is not fetched Zbigniew Jędrzejewski-Szmek
2012-04-12  5:30   ` Jeff King
2012-04-12  9:15     ` Zbigniew Jędrzejewski-Szmek [this message]
2012-04-12 15:15       ` Junio C Hamano
2012-04-12 20:40         ` Jeff King
2012-04-14  7:54           ` [PATCH v2 0/5] provide better error messages for @{upstream} Zbigniew Jędrzejewski-Szmek
2012-04-14  7:54             ` [PATCH v2 1/5] t1507: add tests to document @{upstream} behaviour Zbigniew Jędrzejewski-Szmek
2012-04-14  7:54             ` [PATCH v2 2/5] Provide branch name in error message when using @{u} Zbigniew Jędrzejewski-Szmek
2012-04-14  7:54             ` [PATCH v2 3/5] Provide better message for barnhc_wiht_tpyo@{u} Zbigniew Jędrzejewski-Szmek
2012-04-14  7:54             ` [PATCH v2 4/5] Be more specific if upstream branch is not tracked Zbigniew Jędrzejewski-Szmek
2012-04-14  7:54             ` [PATCH v2 5/5] i18n: mark @{upstream} error messages for translation Zbigniew Jędrzejewski-Szmek
2012-04-14  8:09             ` [PATCH v2 0/5] provide better error messages for @{upstream} Jeff King
2012-04-11 16:17 ` [PATCH 5/5] i18n: mark @{upstream} error messages for translation Zbigniew Jędrzejewski-Szmek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F869D37.1050508@in.waw.pl \
    --to=zbyszek@in.waw.pl \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).