I can answer the question to why I ended up using reset at least, though
I can imagine more scenarios. I wanted to do a reset on the current
working directory (read subdirectory of the repository) instead of on
the whole repository, and assumed git would do as I intuitively expected
it to, without specifying the path.
I should have stopped to think about this, and look up the behavior in
the docs, but since I was concerned with other things I simply didn't.
Actually, I still think it would be more intuitive to let git act upon
the current working directory if none is specified, to prevent harm.
Nonetheless, I would be happy with the proposed wrapper, but need some
help to realize it.
It is not that this is a need to have feature, since I normally commit
most of the stuff in my working directory regularly. But it would be
nice to have.
On 16.03.2014 00:56, Philip Oakley wrote:
> To me, the "--hard" is a good indicator of a destructive reset.
> However the question should be more about why one ends up using a
> destructive reset when one either hasn't fully thought through the
> options, or perhaps should have used a softer option (and what would it
> So the rehetorical question is should it be an alternate option, and how
> would it work, to counter the problems of the destructive reset and
> trying to protect ourselves from ourselves - Is it a catch 22 problem?
> Perhaps there needs to be an extra git env variable
> (GIT_RESET_HARD_HEAD) that holds the sha1 of a faked 'commit -A' just
> before the 'reset --hard' is performed. This would avoid leaving lots of
> dummy/waste branches around. The variable name can be modelled on the
> various other FETCH_HEAD MERGE_HEAD and various others).
> So have a think about broader options...
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.