Re: Notes on Subproject Support

From: Daniel Barkalow <barkalow@iabervon.org>
Date: 2006-01-24 03:31:11
On Sun, 22 Jan 2006, Junio C Hamano wrote:

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

> 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*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Tue Jan 24 03:29:45 2006

This archive was generated by hypermail 2.1.8 : 2006-01-24 03:29:53 EST