git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Baudis <pasky@suse.cz>
To: Nigel Magnay <nigel.magnay@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] Teach git submodule update to use distributed repositories
Date: Thu, 17 Jul 2008 16:38:33 +0200	[thread overview]
Message-ID: <20080717143833.GV32184@machine.or.cz> (raw)
In-Reply-To: <320075ff0807170508j3d3c1ef8j49df576fc47debe2@mail.gmail.com>

On Thu, Jul 17, 2008 at 01:08:19PM +0100, Nigel Magnay wrote:
> When doing a git submodule update, it fetches any missing submodule
> commits from the repository specified in .gitmodules. If you instead
> want to pull from another repository, you currently need to do a fetch
> in each submodule by hand.
> 
> Signed-off-by: Nigel Magnay <nigel.magnay@gmail.com>

I don't think it is good idea to hijack git submodule update for this.
This command has a specific purpose:

	"When I pulled new version of the main tree, bring my
	submodule checkouts in line with whatever is specified
	within the new tree revision."

Your usage scenario has nothing to do with that, it is about "batch
manipulation" of all the submodules at once in a certain way. I think
using the same command for two conceptually pretty much unrelated
purposes will only clutter up the UI, and we should think of a better
general interface pattern for these operations.

In the new git-submodule description, it is said that

	"This command will manage the tree entries and contents of the
	gitmodules file for you."

and I think we should keep it at this; anything that is related to
submodules, but does not do this directly, would IMHO live better
as some kind of "submodule-recursive" extension of other existing
commands. Say, would this particular need of yours be served by a
hypothetical command like

	git checkout --submodules nifty

to check out branch nifty of all submodules or am I misunderstanding
what are you trying to achieve?

If not, then actually even _much_ more elegant solution for this
particular problem would be to store submodule.*.branch in .gitmodules
appropriate to the -b parameter of git submodule add. Then, in branch
'nifty' of the main project, you would set submodule.*.branch to 'nifty'
too.  Then, in order to bring all the submodules to the latest version,
I could imagine something like

	git pull --submodules

(and possibly just abort at the first sight of a conflict, for
starters).

Let's figure up some UI that is nifty and clean. ;-)

-- 
				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

      parent reply	other threads:[~2008-07-17 14:39 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
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 [this message]

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=20080717143833.GV32184@machine.or.cz \
    --to=pasky@suse.cz \
    --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).