From: Luben Tuikov <ltuikov@yahoo•com>
To: Junio C Hamano <junkio@cox•net>
Cc: git@vger•kernel.org
Subject: Re: New way of tracking remote branches -- question
Date: Fri, 5 Jan 2007 16:39:21 -0800 (PST) [thread overview]
Message-ID: <386533.4292.qm@web31809.mail.mud.yahoo.com> (raw)
In-Reply-To: <7vmz4xcacr.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox•net> wrote:
> Junio C Hamano <junkio@cox•net> writes:
>
> > Luben Tuikov <ltuikov@yahoo•com> writes:
> >
> >> I can see that the remote heads are where they are supposed to be
> >> but no local tracking heads are created (by default). I had
> >> to do this manually.
> >>
> >> Old behavior was that git did that for you automatically.
> >> So I suppose this is another newbie protection.
> >
> > A very fuzzily stated question which is hard to answer, but I do
> > not think it is another newbie protection, if it apparently is
> > actively hurting you. Also the documentation may need to be
> > updated to teach you enough about how to achieve what you want.
>
> Can you state the problem you observed about the recent git in a
> way that is easier to debug?
>
> For example, you could state:
>
> With older git (I verified that v1.3.0 still works like
> this), I used to be able to just say:
>
> $ git fetch
>
> (this is the exact command line -- I am not giving a URL
> nor even "origin" after "git fetch"). When the upstream
> created a new branch 'blah', the above command created a
> new local branch 'blah' automatically for me. With the
> tip of 'master' (e27e609), this does not happen anymore.
>
> My configuration is that I have .git/remotes/origin file
> whose contents is .... I do not have any remote.*.url,
> remote.*.fetch, nor branch.*.remote configuration variables.
>
> to be more helpful.
>
> I am not dismissing your message as whining. You probably have
> hit a regression while we adopted the BCP to encourage separate
> remote layout, and I would like to understand the issue.
And I'm not whining. It just that when I've done something 1000
times and all of a sudden I do the same thing and didn't see the
expected behaviour, I posted.
"git-pull" didn't "create" the branches in the place I was
expecting. I.e. while they are in .git/refs/remotes/origin/
they are not in .git/refs/heads.
Then I manually created the heads in .git/refs/heads
and manually added that to .git/config, i.e. the [branch]
part.
I was hoping I wouldn't need to do that at all, as old
git-pull exposed remote branches, or I was expecting to
at least find a git command to do this 2nd additional
manual step for me.
Luben
next prev parent reply other threads:[~2007-01-06 0:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-05 23:02 New way of tracking remote branches -- question Luben Tuikov
2007-01-05 23:17 ` Junio C Hamano
2007-01-05 23:39 ` Junio C Hamano
2007-01-06 0:39 ` Luben Tuikov [this message]
2007-01-06 0:16 ` Luben Tuikov
2007-01-05 23:50 ` Junio C Hamano
2007-01-06 1:11 ` Junio C Hamano
2007-01-06 2:11 ` Steven Grimm
2007-01-06 14:10 ` Theodore Tso
2007-01-09 7:45 ` Luben Tuikov
2007-01-09 8:28 ` Junio C Hamano
2007-01-09 8:41 ` Luben Tuikov
2007-01-09 8:57 ` Martin Langhoff
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=386533.4292.qm@web31809.mail.mud.yahoo.com \
--to=ltuikov@yahoo$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=junkio@cox$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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