Jeff King [off-list ref] writes:
Previously, git-reset always required a work directory. For
--mixed and --hard resets, this makes sense, as the bare
repo doesn't have an index or a working tree. However, for
--soft, there's no reason to prohibit this behavior.
Signed-off-by: Jeff King <redacted>
---
Somebody asked about this on irc ("how do I rewind history in a bare
repo"). The only other ways right now are to update the ref manually
(which involves plumbing), or to "git-push -f" from a non-bare
repository. I can't think of any good reason why a soft reset shouldn't
be allowed.
How about "git branch -f this $that"???
On Fri, Jul 13, 2007 at 10:19:23PM -0700, Junio C Hamano wrote:
quoted
Somebody asked about this on irc ("how do I rewind history in a bare
repo"). The only other ways right now are to update the ref manually
(which involves plumbing), or to "git-push -f" from a non-bare
repository. I can't think of any good reason why a soft reset shouldn't
be allowed.
How about "git branch -f this $that"???
Ah, I hadn't thought of that. It seems a bit of a contortion, though,
since git-branch is usually used for _making_ a branch, whereas
git-reset is usually used for _changing_ a branch. But maybe that's just
me.
At any rate, it might still be worth applying the patch. It should be
harmless to loosen the restriction, and even if there are several ways
to accomplish the same thing, why punish people who try git-reset first?
On the other hand, this is the first time I've seen it come up, so maybe
this isn't confusing people.
-Peff
Jeff King [off-list ref] writes:
Ah, I hadn't thought of that. It seems a bit of a contortion, though,
since git-branch is usually used for _making_ a branch, whereas
git-reset is usually used for _changing_ a branch. But maybe that's just
me.
"branch -f" is very often used to "reset the branch tip". My
git day typically begins with "branch -f pu next".
At any rate, it might still be worth applying the patch. It should be
harmless to loosen the restriction, and even if there are several ways
to accomplish the same thing, why punish people who try git-reset first?
On the other hand, this is the first time I've seen it come up, so maybe
this isn't confusing people.
Actually, after thinking about this a bit more, I have become
somewhat reluctant, as this might confuse new users by giving
them a wrong mental model of what "reset" is about.
To my mind, as an old time git user, reset (any variant) has
always been about reshaping the relationship among the HEAD, the
index and the working tree; if there is no index nor the working
tree (iow, a bare repository), there can be no "relationship"
among them.
We initially had only --mixed and --hard (and the former was not
even called --mixed as there were only two kinds). Then --soft
was invented as a stop-gap measure before "commit --amend" came.
In all cases, the user is saying "I want to make the next commit
I'll make on top of that commit (which may or may not be
different from the HEAD), and I'd want to start working towards
that goal, starting from such and such index and working tree
state". And that "such and such state" is different among three
variants:
* "reset --mixed" means "I like what I have in the working
tree, but I'd want to discard the index and start from what
is in (possibly updated) HEAD instead";
* "reset --hard" means "I want to restart both index and
working tree from scratch, starting from (possibly updated)
HEAD";
* "reset --soft" means "I like what I have in the index and
also I like what I have in the working tree -- do not touch
them -- I want the next commit to go on top of that commit".
"reset --soft" happens to be a variant of reset that does not
touch index nor working tree, but conceptually, "not touching"
and "not having either is Ok" are two quite different things.
On Sat, Jul 14, 2007 at 01:33:31AM -0700, Junio C Hamano wrote:
quoted
since git-branch is usually used for _making_ a branch, whereas
"branch -f" is very often used to "reset the branch tip". My
git day typically begins with "branch -f pu next".
I think we just have a different perspective of what is "usual" here.
Actually, after thinking about this a bit more, I have become
somewhat reluctant, as this might confuse new users by giving
them a wrong mental model of what "reset" is about.
OK, as I said on irc, I don't think this is a huge issue in the first
place, and your argument about encouraging a particular workflow for
git-reset makes some sense (even if that hasn't been my approach to
git-reset in the past).
-Peff