Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
- From
Avery Pennarun <apenwarr@gmail.com>
- Date
- Jun 25, 2008, 20:22 UTC
- Message-ID
- <32541b130806251322l478faa87gc9f2016254689022@mail.gmail.com>
- In-Reply-To
- <7vlk0tz33n.fsf@gitster.siamese.dyndns.org>
On 6/25/08, Junio C Hamano <gitster@pobox.com> wrote:
Show 8 quoted lines
> "Avery Pennarun" <apenwarr@gmail.com> writes: > > > How about making "git checkout" default to HEAD if no revision is > > supplied? There's precedent for this in, say, git-diff (and I think a > > few others). > > Won't fly. 'git checkout -- "$@"' is to revert to the last staged > version.
Ah, I didn't catch the difference between HEAD and index there.
> * You say "git checkout -- file" when you want to "check out the file > from the index";
The real question here is the --. Is it strictly needed? It's optional in things like git-diff, which just do their best to guess what you mean if you don't use the --.
If reset and checkout made the -- optional, then you could do:
git reset filename # undo an accidental "add" git checkout filename # undo accidental modifications that haven't been added
...and save git reset --hard for people willing to take that risk. (The fact that git-gui includes git reset --hard as a really easy-to-click GUI command scared me the first time I saw it, too.)
I think simplifying the syntax might help to make the role of the index less mysterious in the whole "revert" operation. It's not obvious to me at all whether a revert-file ought to get the one from HEAD or the one from the index. But I can easily understand and explain checkout (copy index to working copy) and reset (undo an add).
Thanks,
Avery