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

From: Theodore Tso <tytso@mit.edu>
Date: Jun 25, 2008, 02:26 UTC
Message-ID: <20080625022610.GB20361@mit.edu>
In-Reply-To: <7vod5qa0tu.fsf@gitster.siamese.dyndns.org>

On Tue, Jun 24, 2008 at 04:07:57PM -0700, Junio C Hamano wrote:

Show 5 quoted lines

> > 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