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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 30, 2011, 02:28 UTC
Message-ID: <7v1uuyrcg5.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAMOZ1BuUvuyrf3Tio+9EZR_-b3zy-RWpq36+0rmDO+QKWaVmxQ@mail.gmail.com>

Michael Witten <mfwitten@gmail.com> writes:

Show 9 quoted lines

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

That safety indeed will work, and I kind of like it. I think this is in line with what we try to do when you come back from a detached HEAD state.

You may also want to allow this when HEAD is detached already (I am just thinking aloud here). One possible workflow may be to start from somewhere random, such as the last customer release point:

	git checkout rel-2011-09-01
        # strip proprietary stuff away
	# make sure the result is satisfactory
	git commit --no-parent
        git checkout -b opensource

By the way, I am not convinced enough with the "git status" argument, though.

The output from "status" and "diff" will show what you changed, but in the "strip proprietary stuff" scenario, what you care much more about is what you forgot to remove.

If my current source is littered with a confidencial name of an unreleased device that I need to remove, I am more likely to use "git grep" on the _remaining_ files, and this does not make a difference between "checkout --orphan" or "commit --no-parent".

But I would imagine I would not _know_ what I am looking for until I see it. There may be the name of another confidential device in the source that I need to sanitize, too.

In a "strip" scenario, I suspect that the most natural way to verify would be to run "git diff" between what is about to be committed and an empty tree and inspect the output. That would be what I would do if I were starting from an empty repository, populating the working tree and the index with what I think is releaseable.

Another an advantage of "commit --no-parent" is that we do not have to worry about a corner case like this:

	git checkout --orphan xyzzy
        # time passes, you do many things
        git checkout foo
	git branch | grep xyzzy ;# not found -- what happened to the branch?