Re: [RFC PATCH 3/7] t3705: add tests for `git add` in sparse checkouts

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

 



Matheus Tavares Bernardino <matheus.bernardino@xxxxxx> writes:

>> > +test_expect_success "git add -A does not remove SKIP_WORKTREE entries" '
>> > +     setup_sparse_entry &&
>> > +     rm sparse_entry &&
>> > +     git add -A &&
>> > +     test_sparse_entry_unchanged
>> > +'
>>
>> OK.  As there is nothing other than sparse_entry in the working tree
>> or in the index, the above two should be equivalent.
>
> I just realized that the "actual" file created by the previous
> test_sparse_entry_unchanged would also be added to the index here.
> This doesn't affect the current test or the next ones, but I guess we
> could use `git add -A sparse_entry` to avoid any future problems.
> ...
> Hmm, I think it might be better to test only `add -A sparse_entry`, to
> avoid adding the "actual" file or others that might be introduced in
> future changes.

Rewriting 'git add -A' to 'git add -A sparse_entry' may not be wrong
but it will invite "does -A somehow misbehave without pathspec?" and
other puzzlements.

If adding 'actual' or 'expect' do not matter, I think it would be OK
to just add it, but if it bothers you, we can prepare an .gitignore
and list them early in the test with a comment that says "we will do
many 'git add .' and the like and do not want to be affected by what
the test needs to use to verify the result".

> Oh, that is a problem... We could use `git ls-files --debug` and
> directly compare the mtime field. But the ls-files doc says that
> --debug format may change at any time... Any other idea?

The option is to help us developers; if somebody wants to change it
and breaks your tests, they are responsible for rewriting their
change in such a way to keep your tests working or adjust your tests
to their new output format.



[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