Re: [RFC/PATCH 0/7] Rework git core for native submodules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 4, 2013 at 11:52 AM, Ramkumar Ramachandra
<artagnon@xxxxxxxxx> wrote:
>
> 1. upstream_url: this records the upstream URL.  No need to keep a .gitmodules.
>
> 2. checkout_rev: this records the ref to check out the submodule to.
> As opposed to a concrete SHA-1, this allows for more flexibility; you
> can put refs/heads/master and have truly floating submodules.
>
> 3. ref_name: this specifies what name the ref under
> refs/modules/<branch>/ should use.
>
> 4. floating: this bit specifies whether to record a concrete SHA-1 in
> checkout_rev.
>
> 5. statthrough: this bit specifies whether git should stat() through
> the worktree.  We can turn it off on big repositories for performance
> reasons.

So the thing is (and this was pretty much the original basis for
.gitmodules) that pretty  much *all* of the above fields are quite
possibly site-specific, rather than globally stable.

So I actually conceptually like (and liked) the notion of a link
object, but I just don't think it is necessarily practically useful,
exactly because different installations of the *same* supermodule
might well want to have different setups wrt these submodule fields.

My gut feel is that yes, .gitmodules was always a bit of a hack, but
it's a *working* hack, and it does have advantages exactly because
it's more fluid than an actual git object (which by definition has to
be set 100% in stone). If there are things you feel it does wrong
(like the "git add" bug that is being discussed elsewhere), I wonder
if it's not best to at least try to fix/extend them in the current
model. The features you seem to be after (ie that whole
floating/refname thing) don't seem fundamentally antithetical to the
current model (a "commit" SHA1 of all zeroes for floating, with a new
refname field in .submodules? I dunno)..

                  Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]