Git development
 help / color / mirror / Atom feed
From: Johan Herland <johan@herland.net>
To: git@vger.kernel.org
Subject: [RFC] Referring to a submodule state recorded in a supermodule from within the submodule
Date: Wed, 5 Nov 2008 18:24:28 +0100	[thread overview]
Message-ID: <200811051824.28374.johan@herland.net> (raw)

Hi,

I have a stand-alone project, "foo", that I work on myself. The "foo" 
project is included as a submodule in two other projects, "bar" 
and "baz", that I don't have any direct affiliation with.

Semi-regularly, I like to keep tabs on bar and baz, to see what versions 
of foo they are using, what changes they have made to foo, and if there 
are things I could pick up from them, or maybe even things they could 
learn from eachother.

Doing this currently is quite tedious:
1. Clone/Fetch bar and initialize/update its foo submodule
2. Clone/Fetch baz and initialize/update its foo submodule
3. Set up remotes bar_foo and baz_foo in my main foo repo,
   pointing to bar/foo and baz/foo, respectively. Fetch.
4. Create tags bar_foo_current and baz_foo_current pointing
   to the foo SHA1 sum recorded in baz and baz, respectively.
5. Start comparing bar_foo_current and baz_foo_current to
   eachother, and to my own master branch.


Now, bring this into a larger company setting. There are many (~100) 
different foo-type projects owned by (~50) different developers. These 
projects are included as submodules by several (~20) different 
bar/baz-type projects. In addition, each bar/baz-type project has 
multiple (~3) branches using various versions of the foo-type 
submodules.

Finally, throw in questions like "What are the differences in submodule 
FOO between branch X of BAR, and branch Y of BAZ?", for random values 
of FOO, X, BAR, Y, and BAZ. It is apparent that the above approach just 
doesn't cut it.

Ironically, these questions are fairly easily answered by our current 
CVS setup (which applies the supermodule tags/branches to the entire 
source tree (including submodules)):
1. cd FOO
2. cvs diff -r BAR_X -r BAZ_Y

What I'd like, is some way to refer to the state of a repo as specified 
by the appropriate submodule blob in a superproject commit. Ideally 
this should be done remotely as well, so that I don't have to clone the 
entire superproject just to get at the appropriate submodule blob.


Crude Proposal:

Define a new "git submodule" subcommand that takes three arguments:
   <superURL> <tree-ish> <submoduleName>
The command does the following steps:
1. Locate git repo at <superURL>
2. Resolve <tree-ish> to the tree object within the git repo in #1
3. Locate .gitmodules within the tree object in #2
4. Lookup <submoduleName> in .gitmodules to find its path and URL
5. Locate the submodule blob from the path in #4 within the tree from #2
6. Record the object name (SHA1) stored in the submodule blob from #4
7. Fetch the object name (#7) from the submodule repo (its URL was
   found in #4) into the local git repo
8. Store a reference to the fetched object


Given the above command, the tedious steps described at the top can be 
reduced to the following (which is reasonably close to the equivalent 
CVS commands):
1. git submodule magic-command url/to/bar master foo
2. git submodule magic-command url/to/baz master foo
3. Start comparing the fetched refs to eachother, and
   to my own master branch.

If this sounds reasonable, I'd be happy to start coding the above 
proposal.


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

             reply	other threads:[~2008-11-05 17:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-05 17:24 Johan Herland [this message]
2008-11-05 17:45 ` [RFC] Referring to a submodule state recorded in a supermodule from within the submodule Junio C Hamano
2008-11-05 18:09   ` Johan Herland
2008-11-05 20:45 ` Daniel Barkalow

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=200811051824.28374.johan@herland.net \
    --to=johan@herland.net \
    --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