Torsten Bögershausen writes:
> On 23/06/17 20:04, Junio C Hamano wrote:
>...
>> At this point in the test sequence, there is no modified path that
>> need to be further added before committing; the working tree is
>> empty except for .gitattributes which was just added to the index.
>> So we coul
On 23/06/17 20:04, Junio C Hamano wrote:
Junio C Hamano writes:
Sorry for my mess, see below
I am not sure if we even want the dot there, but at least that is
what the original author of the test intended to do when s/he
decided to pass an empty string as the pathspec.
t/t0027-auto-crl
Junio C Hamano writes:
> I am not sure if we even want the dot there, but at least that is
> what the original author of the test intended to do when s/he
> decided to pass an empty string as the pathspec.
>
> t/t0027-auto-crlf.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
I'll que
Junio C Hamano writes:
> Emily Xie writes:
>
>> I ran the tests and none of them failed.
>
> This is not about a test you touched, but applied to or merged to
> any of the recent integration branches (like 'master' or 'maint')
>
> $ make
> $ cd t
> $ GIT_TEST_LONG=YesPlease sh ./t00
Emily Xie writes:
> I ran the tests and none of them failed.
This is not about a test you touched, but applied to or merged to
any of the recent integration branches (like 'master' or 'maint')
$ make
$ cd t
$ GIT_TEST_LONG=YesPlease sh ./t0027-*.sh
fails at the very beginning. I
I ran the tests and none of them failed. Technically, the state of the
index would indeed be different with these new changes, but this
shouldn't be an issue. In the current version, there's one only item
added to the index that ends up getting used in subsequent tests. That
is, foo1, which is test
Jeff King writes:
> That's long enough for people who actually ran the intermediate
> versions. But what about people on distros who jump from v2.10 or lower
> straight to v2.14?
>
> I think to catch them we'd literally need years on our deprecation
> schedules. Maybe it's not worth caring about
On Sat, Jun 10, 2017 at 01:28:54AM +0900, Junio C Hamano wrote:
> Emily Xie writes:
>
> > An empty string as a pathspec element matches all paths. A buggy
> > script, however, could accidentally assign an empty string to a
> > variable that then gets passed to a Git command invocation, e.g.:
>
Emily Xie writes:
> diff --git a/t/t3700-add.sh b/t/t3700-add.sh
> index f3a4b4a..40a0d2b 100755
> --- a/t/t3700-add.sh
> +++ b/t/t3700-add.sh
> @@ -331,9 +331,8 @@ test_expect_success 'git add --dry-run --ignore-missing
> of non-existing file out
> test_i18ncmp expect.err actual.err
> '
On 06/06, Emily Xie wrote:
> An empty string as a pathspec element matches all paths. A buggy
> script, however, could accidentally assign an empty string to a
> variable that then gets passed to a Git command invocation, e.g.:
>
> path=... compute a path to be removed in $path ...
> gi
Emily Xie writes:
> An empty string as a pathspec element matches all paths. A buggy
> script, however, could accidentally assign an empty string to a
> variable that then gets passed to a Git command invocation, e.g.:
>
> path=... compute a path to be removed in $path ...
> git rm -r
An empty string as a pathspec element matches all paths. A buggy
script, however, could accidentally assign an empty string to a
variable that then gets passed to a Git command invocation, e.g.:
path=... compute a path to be removed in $path ...
git rm -r "$path"
which would unintentio
12 matches
Mail list logo
