Michael Witten <mfwitten@xxxxxxxxx> writes:
> 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?
--
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