On Wed, Jun 20, 2012 at 08:39:23PM +0100, Chris Webb wrote: > Jeff King <peff@xxxxxxxx> writes: > > > But if the first commit is deleted (or reordered), then it is not > > appropriate to detach to the root; we must detach to the first picked > > commit, which we can only do after we see the final instruction sheet. > > It's worse than that isn't it? If you have > > A -- B -- C > > and the sheet says drop A, pick B, pick C, you can't detach to B. You want > the commit B as a root (i.e. with no parent), not the commit B with parent > A. You need to have the patch from A to B replayed as the first commit on an > empty branch (only without the branch). Oh, you're right. I think you would have to do some custom magic to make the first commit without looking at HEAD, like: 1. Erase the index and working tree. 2. Apply the patch from B^ to B (where B is the first picked commit). 3. git-commit-tree manually with no parents. 4. Point HEAD to the newly made commit. But there is a very good chance of step (2) causing conflicts, at which point you would have to give control back to the user. And what is in HEAD at that point that would give them a meaningful answer to "git diff --cached" or similar? I think the only thing you can do is make a fake sentinel commit (with an empty tree) to put in HEAD, and then remove the sentinel immediately after the first commit is put in place (making sure not to include it in the first commit's parent list). Yuck. -Peff -- 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