threads / bug / 45366

Possible tiny bug in reset's error message

Subject: Possible tiny bug in reset's error message

## tl;dr

One message between Mar 13, 2017 and Mar 13, 2017.

replies: 0people: 1as markdown or json

Martin Kletzander· Mar 13, 2017, 14:55 UTC · lore
Hi,

when I was trying to learn some details about various types of resets, I found out that the default reset type is --mixed, but not specifying it is not the same as specifying it. That's mostly because there are some checks for reset_type before setting it to default value. Since one of the checks seem deliberate, I'm rather asking here before sending wrong patch.

The "bug" I am talking about is:
  $ g reset -p --mixed
  fatal: --patch is incompatible with --{hard,mixed,soft}
  $ g reset -p
  No changes.
Despite the fact that `git help reset` says:
  If <mode> is omitted, defaults to "--mixed".

The reason why I'm rather asking is the part of the code that handles the warning message for:

  $ git reset --mixed -- path
  warning: --mixed with paths is deprecated; use 'git reset -- <paths>'
  instead.
Specifically:
	/* git reset tree [--] paths... can be used to
	 * load chosen paths from the tree into the index without
	 * affecting the working tree nor HEAD. */
	if (pathspec.nr) {
		if (reset_type == MIXED)
			warning(_("--mixed with paths is deprecated; use 'git reset -- <paths>' instead."));
		else if (reset_type != NONE)
			die(_("Cannot do %s reset with paths."),
					_(reset_type_names[reset_type]));
	}
See how NONE and MIXED are both purposefully checked?

So my question is, should reset_type be set to MIXED if it was not specified on the command-line before all these checks? If not, what's the reason for that?

Have a nice day, Martin

← back to recent threads