Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to

Hi,

just to add to Junio's comments:

On Wed, 25 Jun 2008, Boaz Harrosh wrote:

Junio C Hamano wrote:

quoted

Steven Walter [off-list ref] writes:

quoted

@@ -225,6 +243,10 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
 	if (reset_type == HARD && is_bare_repository())
 		die("hard reset makes no sense in a bare repository");
 
+        if (reset_type == HARD && !force && index_is_dirty()) {
+                die("Uncommitted changes; re-run with -f to trash them");
+        }
+

Please don't.  With your change, does the testsuite even pass?

"reset --hard" has *ALWAYS* meant to be destructive --- discarding
potential local cruft is the whole point of the operation.

I was under the impression that --hard means working-directory-also
as opposed to tree-and-index-only. Nothing to do with 
destructive-discarding.

But "reset" _means_ to discard something.

Frankly, we could introduce "git reset --hard --force --really 
--really-i-mean-it --do-reset-the-fscking-working-directory-NOW", but I do 
not think that it makes sense.

If you want to reset the working directory, you want to reset the working 
directory.  If you wanted to save the changes somewhere, you should have 
done that.  We have enough ways to do that.

quoted

Learn the lingo, and get over it.

I did lern the lingo and got bitten.

Apparently not.  So again, "reset --hard" means to reset HEAD, index and 
working directory to the revision you pass (defaulting to the HEAD).

The fact that you do not lose the information which used to be HEAD, is 
just a side-effect of Git storing all the revisions in one big graph.  It 
is _not_ implied by "reset", which, as I pointed out, means "re-set".

there is:
git-reset --clean - destructive-discarding any local changes

What would be a "nondestructive-discarding", /me wonders.

git-reset --hard - move tree index and working directory to new head

That is not "git reset --hard".

"move" to a new head is called "switching branches" in Git lingo (and BTW 
in many other SCM lingos, too, so you might just as well get used to it), 
and it is another command: "git checkout <branch>".

Incidentally, a friend just told me that "checkout" is everything but 
intuitive, and he would have preferred "git branch switch <branch>", but 
then settled for my proposed "git branch --switch <branch>", which I did 
not have time to implement yet, unfortunately.

Ciao,
Dscho