On Thu, Sep 29, 2011 at 23:08, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> The branch switching semantics of Git is designed to work well when all
> the branches you check out in the working tree are somewhat related
> content-wise. You create a new file, or make modifications to an existing
> file, realize that the change wants to go to a branch different from the
> current one. You _can_ switch to the branch the change should belong to,
> because the contents in the working tree is defined to be not tied to any
> branch, but is floating on top of the current branch.
That's exactly why "git commit --no-parent" is so useful.
Look at the difference:
Creating a Hidden History (git commit --no-parent)
$ 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 Hidden History (git checkout --orphan):
$ cd repo
$ git checkout --orphan hidden-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