Daniel Barkalow <barkalow@iabervon.org> writes:

quoted text
> At one point, I was arguing for storing the information of what commits 
> were the starting point of the current index in the index itself, instead 
> of relying on external files and external links to refs, but I wasn't 
> really working on git enough to argue for it effectively. Among other 
> things, it would allow git to know what's going on if the head changes 
> without the index getting updated. (Of course, all of the cases it 
> supports are really ones where git should just tell you that you've done 
> something wrong,...

I think if you really wanted to, you could put it in the index
extension section along with the cache-tree data.  We would need
to implement a way to query and manipulate data in the index
extension and update git-commit (it should check HEAD matches
the commit you placed in the extension earlier, and after making
a commit and updating HEAD, you should update the index with the
new commit as well), git-checkout (after switching branches you
should update the index with the branch head you switched to; I
think you should sanity check before switching to see if the
current index and HEAD are reasonable as well but I am not
sure), git-reset --hard (set to the resetted HEAD), git-am,
git-applymbox, and git-merge (check before and set after when
successful).

-
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