Re: In favor of "git commit --no-parent"

From: Michael Witten <mfwitten@gmail.com>
Date: Sep 30, 2011, 00:51 UTC
Message-ID: <CAMOZ1BuUvuyrf3Tio+9EZR_-b3zy-RWpq36+0rmDO+QKWaVmxQ@mail.gmail.com>
In-Reply-To: <7vd3ejq74z.fsf@alter.siamese.dyndns.org>

On Thu, Sep 29, 2011 at 23:08, Junio C Hamano <gitster@pobox.com> wrote:

Show 7 quoted lines

> 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.