Re: Notes on Subproject Support

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jan 23, 2006, 16:31 UTC
Message-ID: <Pine.LNX.4.64.0601231116550.25300@iabervon.org>
In-Reply-To: <7v7j8r7e7s.fsf@assigned-by-dhcp.cox.net>

On Sun, 22 Jan 2006, Junio C Hamano wrote:

Show 24 quoted lines

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> >> Switching branches
> >> ------------------
> >> 
> >> Along with the traditional two-way merge by `read-tree -m -u`,
> >> we would need to look at:
> >> 
> >> . `bind` lines in the current `HEAD` commit.
> >> 
> >> . `bind` lines in the commit we are switching to.
> >> 
> >> . subproject binding information in the index file.
> >> 
> >> to make sure we do sensible things.
> >
> > This is one place I think storing the bindings in the commit is awkward. 
> > read-tree deals in trees (hence the name), but will need information from 
> > the commit.
> 
> That's why it is 'along with'.  Dealing with binding information
> can be done between commits and index without bothering tree
> objects.  read-tree would not have to deal with it, and I think
> keeping it that way is probably a good idea.

I think it would be a lot more fragile if switching branches requires multiple programs interacting with the index file. If things get interrupted after the tree is read but before the bindings are changed, the user will probably generate an inconsistant commit or have to deal with figuring out what's going on. It is a nice property of the current system that the index file never exists under the usual filename without being consistant.

Show 8 quoted lines

> In other words, I think the design so far does not require us to
> touch tree objects at all, and I'd be happy if we do not have to.
>
> One reason I started the bound commit approach was exactly
> because I only needed to muck with commit objects and did not
> have to touch trees and blobs; after trying to implement the
> core level for "gitlink", which I ended up touching quite a lot
> and have abandoned for now.

I think that the same thing that worked with the index file would work for minimizing the impact of the changes as far as the code sees. If the struct tree parser reported the tree at a path when it found a commit at a path, it would work just as if the original tree had used trees (like in your proposal).

	-Daniel
*This .sig left intentionally blank*