Thread (192 messages) flat view 192 messages, 22 authors, 2016-08-11

Re: [RFC] Submodules in GIT

From: Torgil Svensson <hidden>
Date: 2016-08-11 19:25:20

On 12/16/06, Jakub Narebski [off-list ref] wrote:
Well, I just rather have than <sha1 of tree/blob> the definition
of sparse checkout (for example subdirectory name, or file name,
or glob pattern).
This is entirely an UI issue:

On 12/16/06, Torgil Svensson [off-list ref] wrote:
is based around Linus 'module'-file and keep things simple. A git
configuration file that specifies:
* link name for reference
* local path to link
* submodule source
* submodule path to tree/blob
* submodule commit / HEAD / branch
* options (depth-limit , ...)


On 12/16/06, Jakub Narebski [off-list ref] wrote:
And if you have that, you don't need <sha1 of tree/blob> in repository, in link object.
Correct. Since the commit contains all the version information, the
following combinations should give the same information iff we keep
the commit in the database:
1. <sha1 of commit> + <sha1 of tree/blob>
2. <sha1 of commit> + <symlink to tree/blob>

I used the sha1 because I wanted them to behave exactly like
trees/blobs in the database for operations that can disregard the
commit info. Now, if we keep the commit in the database as Linus
suggests we can reach the target from there with a symlink. This would
be more readable but also cost a few object lookups extra iterating
over the symlink.

With sparse (for example defined by 'src/*.h') or partial (for example
defined by 'Documentation/') checkout you should be able to merge
upstream... unless conflicts are in the not checked out part.
This would be a great feature! Will this conflict with path shortcuts?
If so, we might consider two types of objects: "link" which cannot
merge upstream and "module" which can merge upstream and contains a
.git object repository.

IMHO, "module" is a more intuitive name for specifying a
(functionality wise fully fledged) submodule with a repository inside.
"link" could be used for just mirroring a tree/blob. I'm not sure if a
separation is needed on a technical level.

Have you read  http://git.or.cz/gitwiki/SubprojectSupport on GitWiki?
Yes
Have you tested the experimental submodule support (proof of concept)
Not yet

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help