Jeff King [off-list ref] writes:
On Tue, Sep 27, 2011 at 11:28:14PM +0000, Michael Witten wrote:
quoted
With "git commit --no-parent", you would be altering the current
branch head, which means you are potentially leaving as a dangling
commit the commit to which that branch head originally pointed.
I.e., it is about as dangerous as "git reset --hard <new_root_commit>",
something for which we do NOT provide any protection.
Didn't I already mention that example? And then say that I think the
lack of protection there has been the source of a lot of confusion and
hardship?
Repeating the problems of "git reset" does not seem like a good idea to
me. Especially not with a command like "commit", which is usually very
safe.
That being said, I did say in my last email that one option would be for
the documentation to be very clear about leaving the old history
dangling. That at least keeps clueless people from stumbling into using
the option accidentally.
Both of you are right and I agree "commit --root" is a bad idea (I can
change my mind ;-). Especially it is rare (and I would even say it should
be discouraged) to create a new root commit in a repository that already
has history, we should try to make it _very_ hard to lose history by
mistake, even though that means creating a new root commit has to be done
as a multi-step process (e.g. "checkout --orphan" to dissociate the new
state from the current history and then "commit").
Thanks for a bit of sanity.
On Wed, Sep 28, 2011 at 00:32, Junio C Hamano [off-list ref] wrote:
Jeff King [off-list ref] writes:
quoted
On Tue, Sep 27, 2011 at 11:28:14PM +0000, Michael Witten wrote:
quoted
With "git commit --no-parent", you would be altering the current
branch head, which means you are potentially leaving as a dangling
commit the commit to which that branch head originally pointed.
I.e., it is about as dangerous as "git reset --hard <new_root_commit>",
something for which we do NOT provide any protection.
Didn't I already mention that example? And then say that I think the
lack of protection there has been the source of a lot of confusion and
hardship?
Repeating the problems of "git reset" does not seem like a good idea to
me. Especially not with a command like "commit", which is usually very
safe.
That being said, I did say in my last email that one option would be for
the documentation to be very clear about leaving the old history
dangling. That at least keeps clueless people from stumbling into using
the option accidentally.
Both of you are right and I agree "commit --root" is a bad idea (I can
change my mind ;-). Especially it is rare (and I would even say it should
be discouraged) to create a new root commit in a repository that already
has history, we should try to make it _very_ hard to lose history by
mistake, even though that means creating a new root commit has to be done
as a multi-step process (e.g. "checkout --orphan" to dissociate the new
state from the current history and then "commit").
Thanks for a bit of sanity.
Well, I think Jeff already proferred a solution. We could have:
git commit --no-parent
act like:
git branch -d
in that it would require a "--force" when the commit to which the
current branch head points would be left dangling. In fact, we
could go one step further:
git commit --no-parent
should require "--force" unless there exists another branch head
that points to the exact same commit as the current branch head; this
would tacitly enforce the notion that a new branch should be created
prior to the use of "--no-parent".