On Thu, Sep 29, 2011 at 22:07, Phil Hord <phil.hord@xxxxxxxxx> wrote: > If I understand right, the mechanics of the initial creation is what > bothers you. Is that right? If so, we're on the same page here, > because it bothers me too. The commit or checkout alternatives seem > like two halves of a turd sandwich. Both ends are wrong somehow, and > it's because of the state of the working directory in the interim. Creating a Hidden History (Junio is OK with this usage): $ cd repo $ git checkout -b hidden-history $ # Hack away as usual or not $ git status # As with any other commit. $ git commit --no-parent Creating a completely Separate History (Junio doesn't like this): $ cd repo $ git checkout --orphan separate-history $ git rm -rf . # This SHOULD be automatic. $ # add files as with an empty repo. $ git status # As with an empty new repo; lots of "new file" $ git commit Those are the 2 halves, and they are correct for their purposes; however, I would agree that "git init" is better instead of "git checkout", especially when there should be an automatic use of "git rm -rf .". Consider trying the "Hidden History" scenario with the current approach, which only allows for "git checkout --orphan": $ cd repo $ git checkout --orphan separate-history $ # Hack away as usual or not $ git status # lots of "new file" notifications obscuring my changes $ git commit The main issue with "git commit --no-parent" is [supposedly] safety, but it can be made pretty safe: $ cd repo $ # Hack away as usual or not $ git status # As with any other commit. $ git commit --no-parent Error! There must be another branch head directly referencing the same commit that is directly referenced by the current branch head! $ git checkout -b hidden-history $ git commit --no-parent In the vast majority of cases, that rule will prevent people from losing history inadvertantly, and no extra "--force" is required. -- 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