Jeff King [off-list ref] writes:
... For your workflow, I
doubt it matters, but it is potentially destructive.
Yes; I thought the implication of "-f" to be destructive would be a
justification enough, but I agree with you that conflating the two may be
a bad idea. When a user says "git checkout -f -b jch" after seeing the
command without "-f" fail due to existing "jch", it is quite clear that
the user wants to clobber the history of existing "jch" branch (why else
would he giving "-f"), but it is not a justification to clobber local
changes he has in the index and the work tree.
Hi,
On Mon, Jun 21, 2010 at 8:09 AM, Junio C Hamano [off-list ref] wrote:
Jeff King [off-list ref] writes:
quoted
... For your workflow, I
doubt it matters, but it is potentially destructive.
Yes; I thought the implication of "-f" to be destructive would be a
justification enough, but I agree with you that conflating the two may be
a bad idea. When a user says "git checkout -f -b jch" after seeing the
command without "-f" fail due to existing "jch", it is quite clear that
the user wants to clobber the history of existing "jch" branch (why else
would he giving "-f"), but it is not a justification to clobber local
changes he has in the index and the work tree.
How about doing
git checkout -f -f -b <branch>
?
By having the user to specify "-f" twice, we're can be really sure
that the user wants to
1) throw away local changes, which is what the current "-f" is
supposed to do, and
2) reset an existing branch - new behaviour.
--
Cheers,
Ray Chuan