Re: why is git destructive by default? (i suggest it not be!)

[Theodore Tso <tytso@mit.edu>]

On Tue, Jun 24, 2008 at 04:07:57PM -0700, Junio C Hamano wrote:
> > Instead, I've just learned to be careful and my use of git reset
> > --hard is mainly for historical reasons.
> 
> This makes it sound as if avoiding "reset --hard" is a good thing, but I
> do not understand why.

Well, it was Brandon Casey who was asserting that git reset --hard was
evil, which I generally don't agree with.  I do use workflows that use
it a fair amount, usually because its more convenient to type "git
checkout <foo>; git reset --hard <baz>" than something involving "git
update-ref refs/heads/<foo> <baz>".  The former has more characters
than the latter, and involves more disk I/O since it mutates the
working directory; but it's something about needing to type
"refs/heads/" such that I generally tend to type "git checkout....
git reset".  I can't explain why; maybe it's just psychological.

The reason why I've been thinking that I should change my shell script
from:

	git checkout integration
	git reset --hard <foo>

to:

	git update-ref ref/heads/integration HEAD
	git checkout integration

Is actually because the first tends to touch more files in the working
directory than the second (because if the integration branch is a week
or two old, the git checkout unwinds the global state by two weeks,
and then the git reset --hard has to bring the state back up to
recentcy; the second generally involves a smaller set of files
changing).  That's a very minor point, granted.

> The reason you have the diff-index check in the second sequence is because
> update-ref does not have the "local changes" check either.  You could have
> used the same diff-index check in front of "reset --hard".

Definitely true.  The reason why I don't have this check is because
I'm generally careful and I run a "git stat" to make sure there are no
local changes in the tree before I run the script.

> Moreover, in your original sequence above, doesn't "git checkout
> integration" list your local changes when you have any, and wouldn't that
> be a clue enough that the next "reset --hard origin" would discard them?

... because it's in a shell script; being fundamentally lazy, instead
of typing that sequence over and over again, I've scripted it.  :-)

	     	  	 	     	   - Ted