Re: Notes on Subproject Support

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

Daniel Barkalow <barkalow@iabervon.org> writes:

Show 7 quoted lines

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

That is certainly an issue, which we have had already for quite some time, I am afraid. We can get interrupted during "switch branches" flow after read-tree -u -m but before updating HEAD. We can also get interrupted during "commit" flow after writing the commit object out before updating the ref pointed at by HEAD. No?

If we are truly serious about solving the issue of getting interrupted in the middle, I suspect we have to take the "index is a staging area for the next commit" approach I digressed into last night. It would involve introducing a git-atomic-checkout command to replace the current "git-rev-parse, git-read-tree, then git-symbolic-ref" sequence in the checkout flow. In the commit flow, we would need git-commit-index command to replace the current "git-write-tree, git-commit-tree, then git-update-ref" sequence.

I am not particularly opposed to that, but I suspect it might be a moderate amount of work for very little gain. Continuing with the digression, the updated index file may contain:

  1. list of <blob path, object name>
  2. list of parent commit object names for the next commit
  3. the name of the local branch to create the next commit on
  4. for each bound path:
     list of parent commit object names for that path.

1. is what we have in the current (version 2) index file.

2. contains:
 - 0 commit in an index file before the initial commit
 - 1 commit in an index file after a fresh checkout and records
   the commit object name we checked out (replaces HEAD+heads/$branch)
 - 2 commits in an index file after 3-way read-tree, or more
   during an Octopus merge (replaces HEAD+MERGE_HEAD)

3. may not be needed, but if we did so, it would replace HEAD.

4. is similar to 2 but for bound subprojects.  Usually we have
   one commit per bound path to record the "bind" line commit we
   read from the commit object after a fresh checkout.  During a
   subproject merge, we would:
   - start out with 1 commit read from the "bind" line;
   - merging in another subproject commit would add that commit;
   - when making a new subproject commit, the recorded commits
     are used as its parents.