Re: Notes on Subproject Support

[Junio C Hamano <junkio@cox.net>]

Daniel Barkalow <barkalow@iabervon.org> writes:

> ... Do you see an advantage to having the index only record the 
> information used for making a tree, and keeping the information for making 
> a commit in other files?

If somebody else already did the work and presented me two git
implementations, one with the index file capable of generating a
tree and uses separate files to keep track of other information
for commits, and the other with the index file with everything
needed for a commit, I'd certainly take the latter.  In that
sense, I do not see such an advantage at all.  The practical
advantage of keeping them separate is to keep things simple,
minimizing the changes.  I see the subproject support as a
secondary issue, and so far I haven't found a reason convincing
enough to tell me that it is better to put HEAD+heads/$branch
information in the index itself when used in a subproject-less
setup.  It perhaps would make us more robust when interrupted in
the middle of switching branches or making a commit, but that is
about it (I do not particularly see that a serious problem).

>> *1* One good property of "gitlink" approach is that we *could*
>> extend this blob-like object to store arbitrary human readable
>> information to represent a point-in-time from an arbitrary
>> foreign SCM system.  IOW, we do not necessarily have to require
>> `commit` line that name a git commit to be there.  It could say
>> "Please slurp http://www.kernel.org/pub/software/.../git.tar.gz
>> and extract it in git/ directory".
>> ...
> I don't think this would really be useful. The reason to have the included 
> revision stored in a way that's explicitly marked for git to find is that 
> git can do useful things with the information ...
> but more importantly, making sure that changes to what revision 
> you're working with propagate to changes in what revision you specify 
> should be there)...

My example was taking things to the extreme to be illustrative.

To be more practical, it could have pointed at "git-1.0.tar.gz"
or an "svn://" URL with explicit revision name, which ought to
be enough to recreate the exact state.