Re: Notes on Subproject Support

From: Junio C Hamano <junkio@cox.net>
Date: Jan 24, 2006, 01:50 UTC
Message-ID: <7v8xt6xuke.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0601231200380.25300@iabervon.org>

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).

Show 14 quoted lines

>> *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.