From: Junio C Hamano Date: Tue, 24 Jan 2006 01:50:57 GMT Subject: Re: Notes on Subproject Support Message-ID: <7v8xt6xuke.fsf@assigned-by-dhcp.cox.net> In-Reply-To: Daniel Barkalow 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.