While looking at how to handle "git rebase --root", I noticed that "git cherry-pick" fails with the following when run on an unborn branch: error: You do not have a valid HEAD fatal: cherry-pick failed I can not see any reason that it shouldn't work. "git cherry-pick -n" does work. (For rebase, "git cherry-pick --ff" would be used, and I think that should also work on an unborn branch.) Also, "git reset" doesn't work on an unborn branch and I can not see any reason that it shouldn't work. This was also asked on stack overflow [1], and of course the solution is to use "git rm --cached", but doesn't mean that "git reset" shouldn't work. I have very limited time to work on git these days, so if anyone else would like to work on any of this, I would be very happy. I _might_ take some time to fix the cherry-pick issue. Btw, every time I run into problems like these with the treatment of root commits, I can't help but wonder how things would look if git had always had a single root commit (naturally with some dummy user, timestamp etc to ensure sameness across repos). With my limited knowledge, it seems like that would complicate a few things, but simplify a lot of things (maybe I'm biased because of the things I have happened to work on?). Has anyone spent some time seriously thinking about this? I suppose it would be hard to introduce backward-compatibly, and maybe this is very unrealistic even for git 2.0, but I would be curious to hear what others think. Martin [1] http://stackoverflow.com/questions/3894808/new-git-repository-and-already-git-reset-does-not-work -- 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