All of lore.kernel.org
 help / color / mirror / Atom feed
* Submodules implementation
@ 2010-02-23 23:50 Christoph Bartoschek
  2010-02-23 23:59 ` Avery Pennarun
  0 siblings, 1 reply; 4+ messages in thread
From: Christoph Bartoschek @ 2010-02-23 23:50 UTC (permalink / raw)
  To: git

Hi,

what is the main reason that submodules are their own repositories linked 
into the enclosing one and not just additional pointers in the main 
repository?

My impression is that submodules as pointers to existing tree objects would 
make a design more easier to understand and more user friendly. 
Especially I see no need for most of the submodule commands. Maybe "git 
submodule add" but the other commands are already covered by existing ones.

Or is there a tool that uses such additional pointers for submodule 
management?

Thanks
Christoph

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Submodules implementation
  2010-02-23 23:50 Submodules implementation Christoph Bartoschek
@ 2010-02-23 23:59 ` Avery Pennarun
  2010-02-24  0:15   ` Christoph Bartoschek
  0 siblings, 1 reply; 4+ messages in thread
From: Avery Pennarun @ 2010-02-23 23:59 UTC (permalink / raw)
  To: Christoph Bartoschek; +Cc: git

2010/2/23 Christoph Bartoschek <bartoschek@gmx.de>:
> what is the main reason that submodules are their own repositories linked
> into the enclosing one and not just additional pointers in the main
> repository?
>
> My impression is that submodules as pointers to existing tree objects would
> make a design more easier to understand and more user friendly.

The data format itself implements submodules as simply pointers to
commits (not trees) located at a particular point in the supermodule.
This is very elegant and simple.

> Especially I see no need for most of the submodule commands. Maybe "git
> submodule add" but the other commands are already covered by existing ones.
>
> Or is there a tool that uses such additional pointers for submodule
> management?

The implementation of submodule tools, particularly 'git submodule',
is the reason that these submodule pointers are implemented as
separate repositories.  I think the reasons are that a) it seemed
expedient at the time, and b) it's one valid way (although not the
only way) of thinking about what it means to have one repo point at a
commit.

By comparison, my git-subtree tool
(http://github.com/apenwarr/git-subtree) is the opposite: its data
storage format isn't very elegant (it just has a tree stored inside
another tree, as if there were no submodule at all) but its
implementation makes it easier for end users (since they don't have to
deal with separate repositories).

The ideal tool would be elegant *and* easy to use, but it doesn't exist.

Have fun,

Avery

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Submodules implementation
  2010-02-23 23:59 ` Avery Pennarun
@ 2010-02-24  0:15   ` Christoph Bartoschek
  2010-02-24  0:40     ` Junio C Hamano
  0 siblings, 1 reply; 4+ messages in thread
From: Christoph Bartoschek @ 2010-02-24  0:15 UTC (permalink / raw)
  To: Avery Pennarun; +Cc: git

Am Mittwoch 24 Februar 2010 schrieb Avery Pennarun:

> The data format itself implements submodules as simply pointers to
> commits (not trees) located at a particular point in the supermodule.
> This is very elegant and simple.

I see that in the submodule there is a .git directory with its own objects.  
This does not look like as if the submodule objects are part of the 
superproject.

> By comparison, my git-subtree tool
> (http://github.com/apenwarr/git-subtree) is the opposite: its data
> storage format isn't very elegant (it just has a tree stored inside
> another tree, as if there were no submodule at all) but its
> implementation makes it easier for end users (since they don't have to
> deal with separate repositories).

This is exaclty how I would expect it. The tree of the submodule has its root 
somewhere in the tree of the superproject. Then there are commits for the 
superproject that point to the root of the whole tree and commits for the 
submodules that point to nodes in the tree.
A combined tree looks much more elegant for me.

I'll take a look at your tool.

Christop

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Submodules implementation
  2010-02-24  0:15   ` Christoph Bartoschek
@ 2010-02-24  0:40     ` Junio C Hamano
  0 siblings, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2010-02-24  0:40 UTC (permalink / raw)
  To: Christoph Bartoschek; +Cc: Avery Pennarun, git

Christoph Bartoschek <bartoschek@gmx.de> writes:

> I see that in the submodule there is a .git directory with its own objects.  
> This does not look like as if the submodule objects are part of the 
> superproject.

Because they largely aren't.  submodules are freestanding projects on
their own right.

One of the primary design decisions was to support the use of a
superproject without having to clone/checkout all the submodules.

You may want to check earlier design discussion thread:

  http://thread.gmane.org/gmane.comp.version-control.git/31941/focus=32944

It is a huge thread and some of the messages there might be nothing more
than uninformed and unworkable handwaving, except for the ones from Linus
and some others.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2010-02-24  0:41 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-23 23:50 Submodules implementation Christoph Bartoschek
2010-02-23 23:59 ` Avery Pennarun
2010-02-24  0:15   ` Christoph Bartoschek
2010-02-24  0:40     ` Junio C Hamano

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.