Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html