Ghanshyam Thakkar <shyamthakkar001@xxxxxxxxx> writes:
> +test_expect_success '-i/--include includes staged changes' '
> + echo newcontent >file &&
> + echo newcontent >baz &&
> + git add file &&
> + git commit --include -m "file baz" baz &&
I may have said this already, but the command invocation that does
not result in an error smells like a bug, and I doubt that we want
to etch the current behaviour into stone, which may make it harder
to fix [*].
Another related behaviour that I suspect is a bug is that if you did
git add -u baz
instead of this "git commit -i baz", I think the command will
silently succeed without doing anything. They may be the same bug,
because "git commit -i <pathspec>" is an equivalent to "git add -u
<pathspec>" followed by "git commit" after all. Both should say
"there is no such path to update that matches the pathspec <baz>"
and error out, I suspect.
Thanks.
[Footnote]
* A reasonable way out to unblock this particular patch may be to
clarify that this test is only documenting the current behaviour
without necessarily endorsing it. Perhaps
echo more >>file &&
echo more >>baz &&
git add file &&
# Note: "git commit -i baz" is like "git add -u baz"
# followed by "git commit" but because baz is untracked,
# only "file" is committed.
# This test only documents this current behaviour, which we
# may want to fix, and when it happens, this needs to be
# adjusted to the new behaviour.
git commit -i -m "file and baz" baz &&
or something, probably.
