Re: [PATCH v4 1/2] t7501: add tests for --include and --only

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat Jan 13, 2024 at 6:46 AM IST, Junio C Hamano wrote:
> 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 [*].

Yeah, that is why baz is added in the index in the test before the one
you quoted. And as I understand it, when everything is in the index, it
works as intended. Therefore to not get in the way of amending this
behaviour, no untracked files are being (attempted to be) committed in
these tests (except 'fail to commit untracked files' test, but that is
not what you quoted above).

> 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.

Yeah, just checked, that also succeeds silently.

> 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.

as stated above, baz is tracked from the previous test. In any case,
I will add a note just to document that untracked files also do not
give any error (when there are staged changes) but are not committed.

Thanks.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux