Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
> Wouldn't it make sense to make "git reset" basically a synonym for
> "git rm --cached" when in the 'branch yet to be born' case?
Hmm,...
While you are on 'master', shouldn't these behave identically?
$ git reset master -- frotz.c
$ git reset HEAD -- frotz.c
$ git reset -- frotz.c
while shouldn't this fail if there is no 'naster' branch?
$ git reset naster -- frotz.c
It is probably Ok to limit the scope of this change to the case without
any explicit rev, e.g. "git reset -- frotz.c", but at that point I somehow
don't think it will reduce confusion but rather will make things worse.
> + if (!strcmp(rev, "HEAD")) {
Comparing the address of the "HEAD" used for initialization with rev may
make sure that the code will catch only "no explicit rev" case here, but
that is not what is happening here, which is even less consistent.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html