From: Michael J Gruber <git@drmicha.warpmail.net>
To: Marc Branchaud <marcnarc@xiplink.com>
Cc: Peter Harris <git@peter.is-a-geek.org>, git@vger.kernel.org
Subject: Re: Working with remotes; cloning remote references
Date: Wed, 22 Oct 2008 16:59:58 +0200 [thread overview]
Message-ID: <48FF3FEE.8020209@drmicha.warpmail.net> (raw)
In-Reply-To: <48FDF28A.9060606@xiplink.com>
Marc Branchaud venit, vidit, dixit 10/21/08 17:17:
> I believe git lets you track the origin's _branches_ not the origin's
> _remotes_. I don't think --mirror does what I'm looking for, because
> (side effects aside) it only deals with branches, not remotes.
>
> I find myself getting confused, and I think it's because the files in
> .git/refs/remotes/ are indeed tracking branches on remote repositories.
> So I think our conversation gets a bit circular because our ideas of a
> "remote" differ.
Yes, I think there are multiple uses:
- a remote repository (referenced to by an URL)
- a remote config (as created by git remote add)
- a remote branch (a branch in your local repo which is a copy of a
branch in a remote repo; stored under refs/remotes, never to be modified
locally)
- a (remote) tracking branch (a local branch which is set up to pull
from a remote branch by default)
Only the first of these 4 is something resides "remotely". Of course,
"remote URL" could be a path on the local file system or even ".".
> "git remote add" does two things (maybe more?): It adds a [remote]
> section to the .git/config file, and it adds a branch reference in
> .git/refs/remotes/.
Yes.
> I think what I'd like is for the clone to be able
> to obtain both these things from the origin. The reason I think it's
> useful is that it would let the clone pull directly from the origin's
> remote repositories, without having to directly specify the remote
> repository's URL and branch name.
>
> Fundamentally, I'm looking to do exactly
>
> clone/$ git pull -s subtree /path/to/ThingOne master
>
> i.e. pull stuff from one of main's remotes directly into the clone. But
> I want to replace the "/path/to/ThingOne master" part with something
> that means "use whatever URL and branch name was defined in the origin
> for this remote".
>
> My questions are: Am I right in thinking this is desirable?
I've got the strong impression you desire it...
Seriously, it seems desirable in cases where the remote URL changes
frequently; say, because the upstream maintainer (maintainer of
ThingOne) gets hit by a bus frequently, or walks the wrong streets in LA
at the wrong time of the day. (I guess my seriousness ended with the
";".) Clones would follow those changes transparently then (if that
feature existed).
> Is there
> already some way to do this?
None that I know of.
> If not, is it something worth
> implementing? (I'm happy to roll up my own sleeves here...)
First you should decide whether it is worth for you. Comments on the
list tend to kick in once people see a proposed implementation. A viable
strategy could be, mimicking git submodule behaviour in part:
- Implement "git remote export reponame" which takes an existing remote
config from .git/config, writes it to .gitremotes and checks in (or
better: stages for commit) the file .gitremotes [you would use this on main]
- Implement "git remote import" which reads the file .gitremotes and
adds remote config to .git/config. [you would use this on clones]
- Change "git remote update" to take updates to .gitremotes into account
before doing its usual routine (perhaps based on a config with default
off, or a command line option, or better both)
Downside is that .gitremotes is tracked would show up as a file in the
repo, but I can't come up with a better way which is as simple as the
above. .gitremotes could be stored in a specially named branch, though.
> I hope that clarifies things. Sorry for taking so long to get here!
Don't worry. I take partial blame ;)
And thanks for trying to match up your workflow with git.
Cheers,
Michael
next prev parent reply other threads:[~2008-10-22 15:01 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-16 18:17 Working with remotes; cloning remote references Marc Branchaud
2008-10-16 19:20 ` Peter Harris
2008-10-16 20:29 ` Marc Branchaud
2008-10-16 20:45 ` Peter Harris
2008-10-16 22:09 ` Marc Branchaud
2008-10-17 7:33 ` Michael J Gruber
2008-10-17 14:44 ` Marc Branchaud
2008-10-17 15:08 ` Michael J Gruber
2008-10-17 19:50 ` Marc Branchaud
2008-10-20 13:22 ` Michael J Gruber
2008-10-20 16:50 ` Marc Branchaud
2008-10-21 9:49 ` Michael J Gruber
2008-10-21 15:17 ` Marc Branchaud
2008-10-22 14:59 ` Michael J Gruber [this message]
2008-10-22 16:13 ` Terminology question: "tracking" branches Björn Steinbrink
2008-10-23 8:07 ` Michael J Gruber
2008-10-27 15:43 ` Marc Branchaud
2008-10-27 16:17 ` Björn Steinbrink
2008-10-27 18:44 ` Johannes Schindelin
2008-10-27 16:28 ` Björn Steinbrink
2008-10-28 8:01 ` Björn Steinbrink
2008-10-27 19:54 ` Working with remotes; cloning remote references Marc Branchaud
2008-10-28 8:12 ` Michael J Gruber
2008-10-28 16:27 ` Marc Branchaud
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=48FF3FEE.8020209@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@peter.is-a-geek.org \
--cc=git@vger.kernel.org \
--cc=marcnarc@xiplink.com \
/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).