From: Marc Branchaud <marcnarc@xiplink.com>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: Peter Harris <git@peter.is-a-geek.org>, git@vger.kernel.org
Subject: Re: Working with remotes; cloning remote references
Date: Mon, 27 Oct 2008 15:54:21 -0400 [thread overview]
Message-ID: <49061C6D.2070407@xiplink.com> (raw)
In-Reply-To: <48FF3FEE.8020209@drmicha.warpmail.net>
Michael J Gruber wrote:
>
> First you should decide whether it is worth for you.
I'm still trying to figure that out...
> 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.
That downside is a bit disappointing. I might as well just make "git
remote export" simply generate a script of "git remote add" commands
based on the contents of .git/config, and check that script in. Then I
could run the script in a clone to recreate the origin's remotes.
It also seems awkward to have an export step in the origin repository.
I don't really see a need for an export step (except as an artifact of
the above implementation).
It seems to me that this would be more natural if our hypothetical "git
remote import <X>" could just grab the remotes from repository <X> (or
the origin, if <X> is unspecified). I assume that would involve
lower-level changes than what you described, but to me it seems like the
more usable approach. (But then I know nothing of Git's internals, so
maybe this kind of change would be too much work?)
Marc
next prev parent reply other threads:[~2008-10-27 19:55 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
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 ` Marc Branchaud [this message]
2008-10-28 8:12 ` Working with remotes; cloning remote references 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=49061C6D.2070407@xiplink.com \
--to=marcnarc@xiplink.com \
--cc=git@drmicha.warpmail.net \
--cc=git@peter.is-a-geek.org \
--cc=git@vger.kernel.org \
/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).