git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Lehmann <Jens.Lehmann@web.de>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	Git List <git@vger.kernel.org>, Jeff King <peff@peff.net>
Subject: Re: Composing git repositories
Date: Thu, 28 Mar 2013 21:17:59 +0100	[thread overview]
Message-ID: <5154A577.2020103@web.de> (raw)
In-Reply-To: <CALkWK0nreJZX4msFET0a7cuUMWNbQhhqy+ezrkqYGqL4_a2duA@mail.gmail.com>

Am 28.03.2013 11:01, schrieb Ramkumar Ramachandra:
> Jonathan Nieder wrote:
>> Do you mean that you wish you could ignore subrepository boundaries
>> and use commands like
>>
>>         git clone --recurse-submodules http://git.zx2c4.com/cgit
>>         cd cgit
>>         vi git/cache.h
>>         ... edit edit edit ...
>>         git add --recurse-submodules git/cache.h
>>         git commit --recurse-submodules
>>         git push --recurse-submodules
>>
>> , possibly with configuration to allow the --recurse-submodules to be
>> implied, and have everything work out well?
> 
> Do you realize how difficult this is to implement?  We'll need to
> patch all the git commands to essentially do what we'd get for free if
> the submodule were a tree object instead of a commit object (although
> I'm not saying that's the Right thing to do).  Some caveats:
> 
> - If we maintain one global index, and try to emulate git-subtree
> using submodules, we've lost.  It's going to take freakin' ages to
> stat billions of files across hundreds of nested sumodules.  One major
> advantage of having repository boundaries is separate object stores,
> indexes, worktrees: little ones that git is designed to work with.

Are you aware that current Git code already stats all files across
all submodules recursive by default? So (again) no problem here, we
do that already (unless configured otherwise).

> - Auto-splitting commits that touch multiple submodules/ superproject
> at once.  Although git-subtree does this, I think it's horribly ugly.

You don't like it, but what technical argument is hidden here I'm
missing?

> - Auto-propagating commits upwards to the superproject is another big
> challenge.  I think the current design of anchoring to a specific
> commit SHA-1 has its usecases, but is unwieldy when things become big.
>  We have to fix that first.

What??? Again there is nothing to "fix" here, "anchoring to a specific
commit SHA-1" is *the* most prominent use case (think reproducibility
of the whole work tree), floating submodules are the oddball here.

  parent reply	other threads:[~2013-03-28 20:18 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-26  7:56 Composing git repositories Ramkumar Ramachandra
2013-03-26 16:39 ` Junio C Hamano
2013-03-27 11:49   ` Ramkumar Ramachandra
2013-03-27 16:06     ` Junio C Hamano
2013-03-27 17:02       ` Ramkumar Ramachandra
2013-03-27 17:16         ` Junio C Hamano
2013-03-27 19:26         ` Jonathan Nieder
2013-03-27 20:18           ` Junio C Hamano
2013-03-27 20:42             ` Jonathan Nieder
2013-03-28 11:48             ` Ramkumar Ramachandra
2013-03-28 20:25               ` Jens Lehmann
2013-03-28 10:01           ` Ramkumar Ramachandra
2013-03-28 18:21             ` Jonathan Nieder
2013-03-28 20:17             ` Jens Lehmann [this message]
2013-03-27 23:02         ` Jens Lehmann
2013-03-28  9:16           ` Ramkumar Ramachandra
2013-03-28 20:40             ` Jens Lehmann
2013-03-31 20:34               ` Ramkumar Ramachandra
2013-03-31 22:57                 ` Jonathan Nieder
2013-04-02 17:44                   ` Ramkumar Ramachandra
2013-04-02 17:58                     ` Jeff King
2013-04-02 19:33                       ` Ramkumar Ramachandra
2013-04-02 19:56                     ` Jens Lehmann
2013-04-02 18:03                   ` Junio C Hamano
2013-04-04  6:40                     ` Junio C Hamano
2013-04-05  2:36                       ` Duy Nguyen
2013-04-05  4:53                         ` Junio C Hamano
2013-04-05  5:27                           ` Duy Nguyen
2013-04-05  7:15                             ` Jens Lehmann
2013-03-31 23:50                 ` Phil Hord
2013-04-01 12:14                   ` Jens Lehmann
2013-04-01 14:49                     ` Phil Hord
2013-04-02 18:35                     ` Ramkumar Ramachandra
2013-04-02 18:54                       ` Jonathan Nieder
2013-04-02 19:09                         ` Junio C Hamano
2013-04-02 19:11                         ` Ramkumar Ramachandra
2013-04-02 19:20                           ` Jonathan Nieder
2013-04-02 19:29                             ` Ramkumar Ramachandra
2013-04-02 19:49                               ` Ramkumar Ramachandra
2013-04-02 19:59                       ` Jens Lehmann
2013-04-01  9:50                 ` Jens Lehmann
2013-04-01  0:16 ` Seth Robertson
2013-04-02 19:19   ` Ramkumar Ramachandra

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=5154A577.2020103@web.de \
    --to=jens.lehmann@web.de \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    /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).