From: Petr Baudis <pasky@suse.cz>
To: Nigel Magnay <nigel.magnay@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] Teach git submodule update to use distributed repositories
Date: Fri, 18 Jul 2008 11:16:08 +0200 [thread overview]
Message-ID: <20080718091608.GL10151@machine.or.cz> (raw)
In-Reply-To: <320075ff0807180111q4ca55cc4v15487af35f6fa63c@mail.gmail.com>
Hi,
_please_, trim the parts of quoted e-mails that you are not reacting
to. It makes your mails easier to read.
On Fri, Jul 18, 2008 at 09:11:53AM +0100, Nigel Magnay wrote:
> No.
> "Someone says 'please review the state of my tree, _before_ I push it
> out to a (central) repository"
>
> Fred is a person (and != origin). His tree(s) are entirely correct and
> consistent, and he doesn't yet wish to push to origin (and perhaps he
> cannot, because he does not have permission to do so).
>
> All the tutorials give credit to the fact that in git you don't need a
> central server - you can pull directly from people. Except in the case
> where you're using submodules, where you're basically forced to
> hand-modify .git/config (in this instance, to point to where 'fred' is
> storing his submodule trees) before doing a submodule update. This
> makes git complicated for users.
Ok! Handling this case makes sense, though I would have wished you to
word this use case this clearly from the beginning; or maybe I'm just
slow. :-)
Now, we (at least we two) agree that this use case is worth supporting,
I still don't like the solution you propose, though. The problem that we
are trying to solve is:
"How do we mass-supply custom submodule URLs when publishing the
customized main repository at a custom location too?"
Now, the most natural solution is for Fred to actually customize
.gitmodules content when committing the submodule updates:
(i) Either just give submodule update a hypothetical flag that will
ignore .git/config for that particular run or,
(ii) even much better, actually change logical submodule names in
.gitmodules; this is appropriate as you want the modules to actually
point at a significantly different repository. Thus,
[submodule "boo"]
path=boo
url=git://repo.or.cz/boo.git
will become
[submodule "boo/fred"]
path=boo
url=git://repo.or.cz/boo/fred.git
Also, you will be able to redefine the URL of boo/fred too in
.git/config (e.g. you're behind a firewall that lets only HTTP
through; I'm actually behind such a firewall these days at my
(non-SUSE ;) work).
This should be reasonably elegant, works with no Git changes, however
still has one significant problem - you very much do not want such a
.gitmodules change in any of the commits you merge, since it breaks
bisectability in case Fred or his repositories go away.
In that case, several possibilities come up on my mind:
(1) Fred will prepare special branch for testing with modified
.gitmodules and then for a merge he offers a different branch with clean
.gitmodules. This works, but it is obnoxious.
(2) Fred will pass a patch for .gitmodules as a part of his review
request. This works too and is obnoxious in slightly different aspects
than (1).
(3) Fred will offer a rewrite rule that you will pass to submodule
update, like your solution proposed, but much more universal so that it
is not tailored just to your particular repository hierarchy. A simple
sed script could work fine.
(4) Something else that I'm not realizing.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
next prev parent reply other threads:[~2008-07-18 9:17 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-17 12:08 [PATCH] Teach git submodule update to use distributed repositories Nigel Magnay
2008-07-17 12:13 ` Johannes Schindelin
[not found] ` <320075ff0807170520r200e546ejbad2ed103bd65f82@mail.gmail.com>
2008-07-17 12:21 ` Nigel Magnay
2008-07-17 12:58 ` Johannes Schindelin
2008-07-17 14:03 ` Nigel Magnay
2008-07-17 14:16 ` Johannes Schindelin
2008-07-17 15:07 ` Nigel Magnay
2008-07-17 18:22 ` Petr Baudis
2008-07-18 8:11 ` Nigel Magnay
2008-07-18 8:45 ` Jakub Narebski
2008-07-18 9:00 ` Junio C Hamano
2008-07-18 9:07 ` Jakub Narebski
2008-07-18 9:18 ` Nigel Magnay
2008-07-18 9:16 ` Petr Baudis [this message]
2008-07-18 9:36 ` Nigel Magnay
2008-07-18 10:00 ` Petr Baudis
2008-07-18 11:20 ` Nigel Magnay
2008-07-18 14:43 ` Petr Baudis
2008-07-18 15:09 ` Nigel Magnay
2008-07-18 15:49 ` Petr Baudis
2008-07-18 22:38 ` Mark Levedahl
2008-07-21 10:59 ` Nigel Magnay
2008-07-17 14:38 ` Petr Baudis
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=20080718091608.GL10151@machine.or.cz \
--to=pasky@suse.cz \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=nigel.magnay@gmail.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).