Nicolas Pitre [off-list ref] writes:
On Wed, 14 Oct 2009, Daniel Barkalow wrote:
quoted
On Wed, 14 Oct 2009, Jay Soffian wrote:
quoted
$ git commit -m "blah"
Cannot commit while not on any branch. Please use git commit -b <branch> to
specify the name of a new branch to commit to, or use git commit -f to
force a detached commit.
The difference is that some experienced users depend on being able to
commit while not on a branch, and want to not get a warning for every
commit while not on a branch.
I assume that the -f would silence any warning?
It won't help to alleviate my irritation if I need to give -f to each and
every invocation of "git commit" while detached, though.
On Wed, 14 Oct 2009, Junio C Hamano wrote:
Nicolas Pitre [off-list ref] writes:
quoted
On Wed, 14 Oct 2009, Daniel Barkalow wrote:
quoted
On Wed, 14 Oct 2009, Jay Soffian wrote:
quoted
$ git commit -m "blah"
Cannot commit while not on any branch. Please use git commit -b <branch> to
specify the name of a new branch to commit to, or use git commit -f to
force a detached commit.
The difference is that some experienced users depend on being able to
commit while not on a branch, and want to not get a warning for every
commit while not on a branch.
I assume that the -f would silence any warning?
It won't help to alleviate my irritation if I need to give -f to each and
every invocation of "git commit" while detached, though.
Agreed. Presumably some expert mode config would imply -f
automatically.
Nicolas
Junio C Hamano <gitster <at> pobox.com> writes:
It won't help to alleviate my irritation if I need to give -f to each and
every invocation of "git commit" while detached, though.
I'm missing something fundamental here, I think.
I simply don't see the advantage of branching after committing
over branching before committing.
At worst, a temporary is cheap, eh? So what is the value
of even allowing committing while HEAD is detached
(aside from the historical argument)?