From: Jens Lehmann <Jens.Lehmann@web.de>
To: Phil Hord <phil.hord@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Leif Gruenwoldt <leifer@gmail.com>,
git@vger.kernel.org
Subject: Re: [RFC/PATCH] add update to branch support for "floating submodules"
Date: Mon, 06 Feb 2012 22:32:07 +0100 [thread overview]
Message-ID: <4F3046D7.2010304@web.de> (raw)
In-Reply-To: <CABURp0rt=LcjMfDU61m0de-gLpX1a3x3vhb0zVxCbceSvD9jFw@mail.gmail.com>
Am 06.02.2012 18:31, schrieb Phil Hord:
> On Wed, Feb 1, 2012 at 5:37 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> Hmm, I really think the fact that submodules are unaware that they
>> are part of a superproject is a feature. I'd prefer seeing that kind
>> of problem being tackled by the CI server and/or user education. Or
>> maybe a pre-commit hook which issues a warning in that case?
>
> I agree that submodule isolation is a feature essential to the
> architecture of git and the submodules implementation. But it is also
> a limitation, not just of this example. A pre-commit hook is a nice
> idea, but it doesn't help 'git status' (which is the standard go-to
> answer point for "where am I").
Yes, this feature also is a limitation. To put it in other words: I want
each submodule to be a full fledged repo of its own. IMO it must always
be possible to just clone a submodule without any superproject and run
any git command in it. And the other way around: each superproject must
be usable as a submodule in another superproject. That makes adding some
kind of "superproject awareness" in a sane way rather difficult, as a
repo can't say "I live in a superproject" or "I am the topmost project".
> This has me thinking more about recursing siblings now, though. I find
> myself typing something like this quite a lot:
> git submodule foreach 'git grep "someFunction" || :'
There was an attempt to teach git grep the --recurse-submodules option,
but unfortunately it looks like this didn't lead anywhere so far.
> Or worse (in that the UI is more unwieldy):
> git submodule foreach 'git log --oneline "-SsomeFunction" || :'
This could also be done by teaching git log the --recurse-submodules
option. Me thinks in the long run a lot of git commands should learn
that option to make it easy to optionally include submodules in
whatever they are doing. But my focus is on recursive checkout for the
next time, so I have no idea when I find some time to do that.
> But what I want is this:
> git --git-dir=${TOP}/../.git grep --recurse-submodules "someFunction"
>
> But not really, because I am lazy and that is too much typing.
> git grep --include-siblings "someFunction"
>
> Maybe I can add a "sib" macro to get this:
> git sib grep "someFunction"
And from what you where saying earlier a "git sib status" would be nice
too? What about using alias commands for that functionality? They could
point to a script which searches the topmost repo and calls "git submodule
foreach 'git <command> "$@" || :'" from there ...
next prev parent reply other threads:[~2012-02-06 21:32 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-09 17:40 [RFC/PATCH] add update to branch support for "floating submodules" Heiko Voigt
2011-11-09 18:01 ` Junio C Hamano
2011-11-29 22:08 ` Heiko Voigt
2011-12-10 5:50 ` Leif Gruenwoldt
2011-12-10 6:19 ` Jonathan Nieder
2011-12-10 6:30 ` Junio C Hamano
2011-12-10 15:27 ` Leif Gruenwoldt
2011-12-12 15:34 ` Andreas T.Auer
2011-12-12 18:04 ` Leif Gruenwoldt
2011-12-12 18:42 ` Andreas T.Auer
2011-12-12 19:13 ` Leif Gruenwoldt
2011-12-12 22:31 ` Jens Lehmann
2011-12-12 22:56 ` Phil Hord
2011-12-13 15:35 ` Marc Branchaud
2011-12-13 21:19 ` Jens Lehmann
2011-12-13 22:42 ` Marc Branchaud
2011-12-12 19:36 ` Junio C Hamano
2011-12-13 14:17 ` Phil Hord
2011-12-13 21:09 ` Jens Lehmann
2012-01-30 21:15 ` Phil Hord
2012-01-31 20:55 ` Jens Lehmann
2012-01-31 22:50 ` Phil Hord
2012-02-01 22:37 ` Jens Lehmann
2012-02-06 17:31 ` Phil Hord
2012-02-06 21:32 ` Jens Lehmann [this message]
2011-12-13 0:12 ` Brandon Casey
2011-12-10 14:16 ` Gioele Barabucci
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=4F3046D7.2010304@web.de \
--to=jens.lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=leifer@gmail.com \
--cc=phil.hord@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).