From: Luben Tuikov <ltuikov@yahoo.com>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org, "J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
Date: Mon, 1 Jan 2007 18:05:11 -0800 (PST) [thread overview]
Message-ID: <405044.6078.qm@web31809.mail.mud.yahoo.com> (raw)
In-Reply-To: <7vd55y46ta.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> What's going on is clean-up towards v1.5.0-rc1 ;-).
>
> - 'git clone' does not create a file that has a line that looks
> like "Pull: master:origin" anywhere anymore.
>
> - 'git clone' also does not create the traditional "'master' is
> special and we map that to origin, others are mapped as is
> under refs/heads/, and we have to drop 'origin' from the
> remote side because that name we want to use to store their
> 'master'" layout.
>
> So after a clone, you would get:
>
> [remote "origin"]
> url = ....
> fetch = refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> remote = origin
> merge = refs/heads/master
>
> This configuration still causes "git pull" or "git pull origin"
> while on "master" to fetch and store the remote side's master as
> what you can refer to as 'origin' (because it expands to
> 'remotes/origin/HEAD' thanks to sha1_name.c::get_sha1_basic()),
> and then merges that to your current branch, so there is no
> change in the user experience in the big picture, but what is
> created to achieve that effect is different from what was
> described.
Ah, I see. Thanks Junio.
... And this is why I see some objections as to what I'm proposing
because it extends too far the extension itself of the old
behavior. (See below.)
Questions:
What is the reasonining of defining branch.<name>.merge to point
to the "remote's setup"? I would much, much rather stop the leak
of the remote's setup right at [remote] and contain it there,
while everything in [branch] would refer to local stuff.
So the above configuration would become:
[remote "origin"]
url = ....
fetch = refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
# merge gives the place and name of the remote branch locally mapped
merge = refs/heads/origin/master
# OR, better yet
# merge gives the name only of the remote branch to be merged
# the local mapping can be found from "remote = " above
merge = master
The reasoning is that the remote's setup should only leak into
[remote] and no further. I.e. [remote] is the only one concerned
with the mapping between the remote repo and the local repo.
Then, [branch] only talks about local relationships. Now
since [branch] does refer to _where_ the local mapping resolves
to, i.e. the right hand part of `:', then there is a redundancy
in branch.<name>.merge, since branch.<name>.remote _does refer_
to [remote] where we can find where it is locally mapped.
Thus, by reducibility, branch.name.merge should only contain
a name. Here is the dependency graph:
branch.name.merge <- (gives a local name)
branch.name.remote <- (gives the remote)
remote.rname.fetch <- (gives the remote:local name mapping)
remote.rname.url (gives the URL).
Now as to what I'm talking about, should be able to be had with:
[remote "parent"]
url = .
fetch = :
[branch "A"]
remote = parent
merge = master
[branch "B"]
remote = parent
merge = A
[branch "C"]
remote = parent
merge = B
Luben
next prev parent reply other threads:[~2007-01-02 2:05 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-31 23:47 [PATCH] Docs: update cvs-migration.txt to reflect clone's new default behavior bfields
2006-12-31 23:47 ` [PATCH] Documentation: update git-clone.txt for " bfields
2006-12-31 23:47 ` [PATCH] Documentation: update git-pull.txt " bfields
2006-12-31 23:47 ` [PATCH] Documentation: update glossary entry for "origin" bfields
2006-12-31 23:47 ` [PATCH] Documentation: remove master:origin example from pull-fetch-param.txt bfields
2006-12-31 23:47 ` [PATCH] Documentation: update tutorial's discussion of origin bfields
2007-01-01 0:35 ` [PATCH] Documentation: update git-pull.txt for clone's new default behavior Junio C Hamano
2007-01-01 1:12 ` J. Bruce Fields
2007-01-01 1:44 ` Junio C Hamano
2007-01-01 3:29 ` Luben Tuikov
2007-01-01 3:48 ` J. Bruce Fields
2007-01-01 5:13 ` Luben Tuikov
2007-01-01 5:45 ` J. Bruce Fields
2007-01-01 7:53 ` Luben Tuikov
2007-01-01 7:38 ` Junio C Hamano
2007-01-01 8:19 ` Luben Tuikov
2007-01-01 13:17 ` Theodore Tso
2007-01-01 23:56 ` Luben Tuikov
2007-01-02 1:08 ` Theodore Tso
2007-01-02 2:17 ` Luben Tuikov
2007-01-02 3:45 ` Junio C Hamano
2007-01-02 18:39 ` Luben Tuikov
2007-01-01 21:39 ` J. Bruce Fields
2007-01-01 21:40 ` J. Bruce Fields
2007-01-02 0:01 ` Luben Tuikov
2007-01-02 0:10 ` J. Bruce Fields
2007-01-02 0:57 ` Theodore Tso
2007-01-02 1:28 ` Luben Tuikov
2007-01-02 6:32 ` Junio C Hamano
2007-01-02 2:09 ` Luben Tuikov
2007-01-02 0:21 ` Junio C Hamano
2007-01-02 0:38 ` Jakub Narebski
2007-01-02 2:05 ` Luben Tuikov [this message]
2007-01-02 3:36 ` Junio C Hamano
2007-01-02 11:31 ` Jakub Narebski
2007-01-02 18:48 ` Luben Tuikov
2007-01-02 19:22 ` Jakub Narebski
2007-01-02 19:30 ` Junio C Hamano
2007-01-05 23:15 ` Luben Tuikov
2007-01-05 23:20 ` Junio C Hamano
2007-01-05 23:32 ` Junio C Hamano
2007-01-06 0:32 ` Luben Tuikov
2007-01-06 0:22 ` Luben Tuikov
2007-01-06 1:17 ` Junio C Hamano
2007-01-01 23:59 ` Luben Tuikov
2007-01-02 0:06 ` J. Bruce Fields
2007-01-02 0:12 ` Junio C Hamano
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=405044.6078.qm@web31809.mail.mud.yahoo.com \
--to=ltuikov@yahoo.com \
--cc=bfields@fieldses.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.