Re: [RFC] git clean --local
Junio C Hamano writes: > Cameron Boehmer writes: > >> 1) add a new flag >> -l, --local >> Do not consult git config --global core.excludesFile in >> determining what files git ignores. This is useful in conjunction with >> -x/-X to preserve user files while removing build artifacts. > ... > But it might be useful as an option that affects any "git" command, > e.g. "git --local-config-only clean". I dunno. If you only want to say "there is no global excludes file", perhaps $ git -c core.excludesFile=/dev/null clean -x may be sufficient, so for that particular use case, there is no need to introduce a new command, I'd think. In the longer term, however, I think we would want to introduce a distinction among ignored files---we only support "ignored and expendable" class, but not "ignored but precious" class. With the latter class introduced, it would make sense for "git clean -x/-X" to notice that a path is ignored but precious and keep it. If a dir/foo is ignored, dir/bar is tracked in commit A that is currently checked out, and there is no dir/ directory in commit B, checking out commit B would remove dir/foo (because the last tracked file in the directory goes away and all remaining files in the directory would be ignored but expendable). But if we introduced a new "ignored but precious" class and made dir/foo a member of such a class, then you will be prevented from checkout out B until you do something about dir/foo that is now "precious".
Re: [PATCH] rebase -i: introduce the 'test' command
On Sat, Dec 01, 2018 at 09:28:47PM -0500, Eric Sunshine wrote: > On Sat, Dec 1, 2018 at 3:02 PM Jeff King wrote: > > On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote: > > > In reality, I think that it would even make sense to change the default to > > > reschedule failed `exec` commands. Which is why I suggested to also add a > > > config option. > > > > I sometimes add "x false" to the top of the todo list to stop and create > > new commits before the first one. That would be awkward if I could never > > get past that line. However, I think elsewhere a "pause" line has been > > discussed, which would serve the same purpose. > > Are you thinking of the "break" command (not "pause") which Dscho > already added[1]? > > [1]: 71f82465b1 (rebase -i: introduce the 'break' command, 2018-10-12) Yes, thanks (as you can see, I haven't actually used it yet ;) ). -Peff
[L10N] Kickoff for Git 2.20.0 round 3
Hi, Git v2.20.0-rc2 has been released, and there are 5 new messages need to be translated. So let's start new round of l10n for Git 2.20.0. See commit: l10n: git.pot: v2.20.0 round 3 (5 new, 3 removed) Generate po/git.pot from v2.20.0-rc2 for git v2.20.0 l10n round 3. Signed-off-by: Jiang Xin You can get it from the usual place: https://github.com/git-l10n/git-po/ As how to update your XX.po and help to translate Git, please see "Updating a XX.po file" and other sections in “po/README" file. -- Jiang Xin
Re: [PATCH 1/2] config.mak.uname: OpenBSD uses BSD semantics with fread for directories
FWIW this patch doesn't have any other siblings and subject should had been just [PATCH]; apologize for the confusion and the spam (including that other duplicated email, and most likely this one) Carlo
[PATCH 1/2] config.mak.uname: OpenBSD uses BSD semantics with fread for directories
this "fixes" test 23 (proper error on directory "files") from t1308 MirBSD likely also affected but this was only tested with OpenBSD and therefore this specific change only affects that platform the optional 'configure' sets this automatically (tested with 6.1 to 6.4) but considering this is a legacy feature it is likely that it affected all old versions and is probably what most users had been using as a workaround Signed-off-by: Carlo Marcelo Arenas Belón --- config.mak.uname | 1 + 1 file changed, 1 insertion(+) diff --git a/config.mak.uname b/config.mak.uname index 3ee7da0e23..378ca0a582 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -233,6 +233,7 @@ ifeq ($(uname_S),OpenBSD) HAVE_BSD_SYSCTL = YesPlease HAVE_BSD_KERN_PROC_SYSCTL = YesPlease PROCFS_EXECUTABLE_PATH = /proc/curproc/file + FREAD_READS_DIRECTORIES = UnfortunatelyYes endif ifeq ($(uname_S),MirBSD) NO_STRCASESTR = YesPlease -- 2.20.0.rc2
[PATCH] t5004: avoid using tar for empty packages
ea2d20d4c2 ("t5004: avoid using tar for checking emptiness of archive",
2013-05-09), introduced a fake empty tar archive to allow for portable
tests of emptiness without having to invoke tar
4318094047 ("archive: don't add empty directories to archives", 2017-09-13)
changed the expected result for its tests from one containing an empty
directory to a plain empty archive but the portable test wasn't updated
resulting on them failing again in (at least) NetBSD and OpenBSD
Signed-off-by: Carlo Marcelo Arenas Belón
---
t/t5004-archive-corner-cases.sh | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/t/t5004-archive-corner-cases.sh b/t/t5004-archive-corner-cases.sh
index ced44355ca..271eb5a1fd 100755
--- a/t/t5004-archive-corner-cases.sh
+++ b/t/t5004-archive-corner-cases.sh
@@ -3,8 +3,12 @@
test_description='test corner cases of git-archive'
. ./test-lib.sh
-test_expect_success 'create commit with empty tree' '
- git commit --allow-empty -m foo
+# the 10knuls.tar file is used to test for an empty git generated tar
+# without having to invoke tar because an otherwise valid empty GNU tar
+# will be considered broken by {Open,Net}BSD tar
+test_expect_success 'create commit with empty tree and fake empty tar' '
+ git commit --allow-empty -m foo &&
+ perl -e "print \"\\0\" x 10240" >10knuls.tar
'
# Make a dir and clean it up afterwards
@@ -47,7 +51,6 @@ test_expect_success HEADER_ONLY_TAR_OK 'tar archive of commit
with empty tree' '
test_expect_success 'tar archive of empty tree is empty' '
git archive --format=tar HEAD: >empty.tar &&
- perl -e "print \"\\0\" x 10240" >10knuls.tar &&
test_cmp_bin 10knuls.tar empty.tar
'
@@ -106,16 +109,12 @@ test_expect_success 'create a commit with an empty
subtree' '
test_expect_success 'archive empty subtree with no pathspec' '
git archive --format=tar $root_tree >subtree-all.tar &&
- make_dir extract &&
- "$TAR" xf subtree-all.tar -C extract &&
- check_dir extract
+ test_cmp_bin 10knuls.tar subtree-all.tar
'
test_expect_success 'archive empty subtree by direct pathspec' '
git archive --format=tar $root_tree -- sub >subtree-path.tar &&
- make_dir extract &&
- "$TAR" xf subtree-path.tar -C extract &&
- check_dir extract
+ test_cmp_bin 10knuls.tar subtree-path.tar
'
ZIPINFO=zipinfo
--
2.20.0.rc2
[PATCH] t5004: avoid using tar for empty packages
ea2d20d4c2 ("t5004: avoid using tar for checking emptiness of archive",
2013-05-09), introduced a fake empty tar archive to allow for portable
tests of emptiness without having to invoke tar
4318094047 ("archive: don't add empty directories to archives", 2017-09-13)
changed the expected result for its tests from one containing an empty
directory to a plain empty archive but the portable test wasn't updated
resulting on them failing again in (at least) NetBSD and OpenBSD
Signed-off-by: Carlo Marcelo Arenas Belón
---
t/t5004-archive-corner-cases.sh | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/t/t5004-archive-corner-cases.sh b/t/t5004-archive-corner-cases.sh
index ced44355ca..271eb5a1fd 100755
--- a/t/t5004-archive-corner-cases.sh
+++ b/t/t5004-archive-corner-cases.sh
@@ -3,8 +3,12 @@
test_description='test corner cases of git-archive'
. ./test-lib.sh
-test_expect_success 'create commit with empty tree' '
- git commit --allow-empty -m foo
+# the 10knuls.tar file is used to test for an empty git generated tar
+# without having to invoke tar because an otherwise valid empty GNU tar
+# will be considered broken by {Open,Net}BSD tar
+test_expect_success 'create commit with empty tree and fake empty tar' '
+ git commit --allow-empty -m foo &&
+ perl -e "print \"\\0\" x 10240" >10knuls.tar
'
# Make a dir and clean it up afterwards
@@ -47,7 +51,6 @@ test_expect_success HEADER_ONLY_TAR_OK 'tar archive of commit
with empty tree' '
test_expect_success 'tar archive of empty tree is empty' '
git archive --format=tar HEAD: >empty.tar &&
- perl -e "print \"\\0\" x 10240" >10knuls.tar &&
test_cmp_bin 10knuls.tar empty.tar
'
@@ -106,16 +109,12 @@ test_expect_success 'create a commit with an empty
subtree' '
test_expect_success 'archive empty subtree with no pathspec' '
git archive --format=tar $root_tree >subtree-all.tar &&
- make_dir extract &&
- "$TAR" xf subtree-all.tar -C extract &&
- check_dir extract
+ test_cmp_bin 10knuls.tar subtree-all.tar
'
test_expect_success 'archive empty subtree by direct pathspec' '
git archive --format=tar $root_tree -- sub >subtree-path.tar &&
- make_dir extract &&
- "$TAR" xf subtree-path.tar -C extract &&
- check_dir extract
+ test_cmp_bin 10knuls.tar subtree-path.tar
'
ZIPINFO=zipinfo
--
2.20.0.rc2
Re: [PATCH] rebase -i: introduce the 'test' command
On Sat, Dec 1, 2018 at 3:02 PM Jeff King wrote: > On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote: > > In reality, I think that it would even make sense to change the default to > > reschedule failed `exec` commands. Which is why I suggested to also add a > > config option. > > I sometimes add "x false" to the top of the todo list to stop and create > new commits before the first one. That would be awkward if I could never > get past that line. However, I think elsewhere a "pause" line has been > discussed, which would serve the same purpose. Are you thinking of the "break" command (not "pause") which Dscho already added[1]? [1]: 71f82465b1 (rebase -i: introduce the 'break' command, 2018-10-12)
Hi
Good day, My Name is Johann Reimann and i have something important to discuss with you but only with your permission i will proceed. Regards J. Reimann
Re: [RFC] git clean --local
Cameron Boehmer writes: > 1) add a new flag > -l, --local > Do not consult git config --global core.excludesFile in > determining what files git ignores. This is useful in conjunction with > -x/-X to preserve user files while removing build artifacts. This does not belong to the "clean" command (who says the need to ignore the global configuration is limited to "clean" and why?), so "git clean --local" is simply not acceptable. But it might be useful as an option that affects any "git" command, e.g. "git --local-config-only clean". I dunno. > 2) change the behavior of -x/-X This won't happen without a long deprecation period. If you haven't seen and read them, check the recent list archive for the past few weeks, with keywords "trashable", "precious", etc.
[RFC] git clean --local
-x and -X are great, but they remove files that are ignored via my ~/.gitignore that I'd rather keep (personal toolchain dotfiles). If others also would like to see this addressed and we settle on a specific solution, I'd be happy to submit a patch. Some ideas: 1) add a new flag -l, --local Do not consult git config --global core.excludesFile in determining what files git ignores. This is useful in conjunction with -x/-X to preserve user files while removing build artifacts. 2) change the behavior of -x/-X While it would be inconsistent with git's behavior elsewhere to NOT consult the global excludesFile, the intent behind -x/-X seems to have everything to do with the contents of current project's .gitignores, and nothing to do with the global excludes. However, even if this is palatable, it's not backwards compatible, and I'm not sure this meets the threshold of significance for breaking changes. Of course, I'm open to suggestions. Thanks to all for their contributions, Cameron
Re: [PATCH] rebase -i: introduce the 'test' command
On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote: > > > Would it not make more sense to add a command-line option (and a config > > > setting) to re-schedule failed `exec` commands? Like so: > > > > Your proposition would do in most cases, however it is not possible to > > make a distinction between reschedulable and non-reschedulable commands. > > True. But I don't think that's so terrible. > > What I think is something to avoid is two commands that do something very, > very similar, but with two very, very different names. > > In reality, I think that it would even make sense to change the default to > reschedule failed `exec` commands. Which is why I suggested to also add a > config option. I sometimes add "x false" to the top of the todo list to stop and create new commits before the first one. That would be awkward if I could never get past that line. However, I think elsewhere a "pause" line has been discussed, which would serve the same purpose. I wonder how often this kind of "yes, I know it fails, but keep going anyway" situation would come up. And what the interface is like for getting past it. E.g., what if you fixed a bunch of stuff but your tests still fail? You may not want to abandon the changes you've made, but you need to "rebase --continue" to move forward. I encounter this often when the correct fix is actually in an earlier commit than the one that yields the test failure. You can't rewind an interactive rebase, so I complete and restart it, adding an "e"dit at the earlier commit. How would I move past the test that fails to continue? I guess "git rebase --edit-todo" and then manually remove it (and any other remaining test lines)? That's not too bad, but I wonder if people would find it more awkward than the current way (which is to just "rebase --continue" until you get to the end). I dunno. I am not sure if I am for or against changing the default, so these are just some musings. :) -Peff
Re: [PATCH] t5562: skip if NO_CURL is enabled
On Wed, Nov 28, 2018 at 03:56:29PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, Nov 22 2018, Jeff King wrote:
>
> > On Thu, Nov 22, 2018 at 02:17:01AM -0800, Carlo Arenas wrote:
> >> PS. upstreaming the PERL_PATH fix is likely to be good to do soonish
> >> as I presume at least all BSD might be affected, let me know if you
> >> would rather me do that instead as I suspect we might be deadlocked
> >> otherwise ;)
> >
> > Yeah, the $PERL_PATH thing is totally orthogonal, and should graduate
> > separately.
>
> On the subject of orthagonal things: This test fails on AIX with /bin/sh
> (but not /bin/bash) due to some interaction of ssize_b100dots and the
> build_option function. On that system:
>
> $ ./git version --build-options
> git version 2.20.0-rc1
> cpu: 00FA74164C00
> no commit associated with this build
> sizeof-long: 4
> sizeof-size_t: 4
>
> But it somehow ends up in the 'die' condition in that case statement. I
> dug around briefly but couldn't find the cause, probably some limitation
> in the shell constructs it supports. Just leaving a note about this...
That's weird. The functions involved are pretty vanilla. I'd suspect
something funny with the sed invocation:
build_option () {
git version --build-options |
sed -ne "s/^$1: //p"
}
but that's the one thing that shouldn't be dependent on the shell in
use.
Can you manually replicate the shell commands to see where it goes
wrong?
-Peff
Re: [PATCH] t5562: skip if NO_CURL is enabled
On Wed, Nov 28, 2018 at 02:27:08PM +0100, SZEDER Gábor wrote:
> > Curiously, the act.err file also has 54 NUL bytes before the "fatal:"
> > message.
>
> I think those NUL bytes come from the file system.
>
> The contents of 'act.err' from the previous test ('fetch gzipped
> empty') is usually:
>
> fatal: request ended in the middle of the gzip stream
> fatal: the remote end hung up unexpectedly
>
> Notice that the length of the first line is 54 bytes (including the
> trailing newline). So I suspect that the following is happening:
>
> - http-backend in the previous test writes the first line,
> - that test finishes and this one starts,
> - this test truncates 'act.err',
> - and then the still-running http-backend from the previous test
> finally writes the second line.
>
> So at this point 'act.err' is empty, but the offset of the fd of the
> redirection still open from the previous test is at 54, so the file
> system fills those bytes with NULs.
Right, good thinking. Thanks for the explanation!
-Peff
Re: [PATCH 8/9] sha1-file: use loose object cache for quick existence check
On Tue, Nov 27, 2018 at 09:48:57PM +0100, René Scharfe wrote:
> > +static int quick_has_loose(struct repository *r,
> > + const unsigned char *sha1)
> > +{
> > + int subdir_nr = sha1[0];
> > + struct object_id oid;
> > + struct object_directory *odb;
> > +
> > + hashcpy(oid.hash, sha1);
> > +
> > + prepare_alt_odb(r);
> > + for (odb = r->objects->odb; odb; odb = odb->next) {
> > + odb_load_loose_cache(odb, subdir_nr);
>
> Is this thread-safe? What happens if e.g. one index-pack thread resizes
> the array while another one sorts it?
No, but neither is any of the object_info / has_object_file path, which
may use static function-local buffers, or (before my series) alt scratch
bufs, or even call reprepare_packed_git().
In the long run, I think the solution is probably going to be pushing
some mutexes into the right places, and putting one around the cache
fill is an obvious place.
> Loading the cache explicitly up-front would avoid that, and improves
> performance a bit in my (very limited) tests on an SSD. Demo patch for
> next at the bottom. How does it do against your test cases?
It's going to do badly on corner cases where we don't need to load every
object subdirectory, and one or more of them are big. I.e., if I look up
"1234abcd", the current code only needs to fault in $GIT_DIR/objects/12.
Pre-loading means we'd hit them all. Even without a lot of objects, on
NFS that's 256 latencies instead of 1.
-Peff
Re: [RFC 2/2] exclude-promisor-objects: declare when option is allowed
On Fri, Nov 30, 2018 at 05:32:47PM -0800, Matthew DeVore wrote: > > Speaking of which, would this flag work better as a field in > > setup_revision_opt, which is passed to setup_revisions()? The intent > > seem to be to influence how we parse command-line arguments, and that's > > where other similar flags are (e.g., assume_dashdash). > > Good idea. This would solve the problem of mistakenly believing the flag > matters when it doesn't, since it is in the struct which is used as the > arguments of the exact function that cares about it. Here's a new patch - > I'm tweaking e-mail client settings so hopefully this makes it to the list > without mangling - if not I'll resend it with `git-send-email` later. > > From 941c89fe1e226ed4d210ce35d0d906526b8277ed Mon Sep 17 00:00:00 2001 > From: Matthew DeVore > Date: Fri, 30 Nov 2018 16:43:32 -0800 > Subject: [PATCH] revisions.c: put promisor option in specialized struct > > Put the allow_exclude_promisor_objects flag in setup_revision_opt. When > it was in rev_info, it was unclear when it was used, since rev_info is > passed to functions that don't use the flag. This resulted in > unnecessary setting of the flag in prune.c, so fix that as well. Thanks, this looks pretty reasonable overall. Two comments: > repo_init_revisions(the_repository, , NULL); > save_commit_buffer = 0; > - revs.allow_exclude_promisor_objects_opt = 1; > - setup_revisions(ac, av, , NULL); > + > + memset(_r_opt, 0, sizeof(s_r_opt)); > + s_r_opt.allow_exclude_promisor_objects = 1; > + setup_revisions(ac, av, , _r_opt); I wonder if a static initializer for setup_revision_opt is worth it. It would remove the need for this memset. Probably not a big deal either way, though. > static int handle_revision_opt(struct rev_info *revs, int argc, const char > **argv, > -int *unkc, const char **unkv) > +int *unkc, const char **unkv, > +int allow_exclude_promisor_objects) Why not pass in the whole setup_revision_opt struct? We don't need anything else from it yet, but it seems like the point of that struct is to pass around preferences like this. -Peff
Re: [PATCH] Do not fail test if '.' is part of $PATH
On Sat, Dec 01, 2018 at 06:07:57PM +0100, H.Merijn Brand wrote: > When $PATH contains the current directory as .:PATH, PATH:., PATH:.:PATH, > or (maybe worse) as :PATH, PATH:, or PATH::PATH - as an empty entry is > identical to having dot in $PATH - this test used to fail Good catch. The test cares about Git not accidentally adding "." to the PATH, but we can't check that if it is already there. > This patch was tested with PATH=$PATH, PATH=.:$PATH, PATH=$PATH:., > PATH=$PATH:.:/bin, PATH=:$PATH, PATH=$PATH:, and PATH=$PATH::/bin > [...] > +test_lazy_prereq DOT_IN_PATH ' > + case ":$PATH:" in > + *:.:*|*::*) true ;; > + *) false ;; > + esac > +' Since the test is ultimately checking "can we run should-not-run from the current directory", might it be simpler to actually try that as the precondition? I.e., something like: test_expect_success 'create program in current directory' ' write_script should-not-run <<-\EOF && echo yikes EOF ' test_lazy_prereq DOT_IN_PATH ' should-not-run ' test_expect_success !DOT_IN_PATH 'run_command is restricted to PATH' ' test_must_fail test-tool run-command run-command should-not-run ' ? That's more lines, but we don't have to peek into the details of how $PATH works. -Peff
Hello Dear
Hello Dear, how are you today,I hope you are doing great. It is my great pleasure to contact you,I want to make a new and special friend,I hope you don't mind. My name is Tracy William from the United States, Am a french and English nationality. I will give you pictures and more details about my self as soon as i hear from you in my email account bellow, Thanks Tracy
Re: [PATCH] t6036: avoid "cp -a"
Thanks both. Agree with Junio it would be better if squashed; apologize
for not catching it earlier, but the following might help to make it
visible for anyone that care to run the linter:
$ make test-lint-shell-syntax
Carlo
-- >8 --
From: =?UTF-8?q?Carlo=20Marcelo=20Arenas=20Bel=C3=B3n?=
Subject: [PATCH] tests: add lint for non portable cp -a
cp -a, while a common flag isn't in POSIX and will therefore fail
on systems that don't have GNUish tools (like OpenBSD, AIX or Solaris)
Signed-off-by: Carlo Marcelo Arenas Belón
---
t/check-non-portable-shell.pl | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/check-non-portable-shell.pl b/t/check-non-portable-shell.pl
index b45bdac688..8037eef777 100755
--- a/t/check-non-portable-shell.pl
+++ b/t/check-non-portable-shell.pl
@@ -35,6 +35,7 @@ sub err {
chomp;
}
+ /\bcp\s+-a/ and err 'cp -a is not portable';
/\bsed\s+-i/ and err 'sed -i is not portable';
/\becho\s+-[neE]/ and err 'echo with option is not portable (use
printf)';
/^\s*declare\s+/ and err 'arrays/declare not portable';
--
2.20.0.rc2
[PATCH] Do not fail test if '.' is part of $PATH
When $PATH contains the current directory as .:PATH, PATH:., PATH:.:PATH, or (maybe worse) as :PATH, PATH:, or PATH::PATH - as an empty entry is identical to having dot in $PATH - this test used to fail This patch was tested with PATH=$PATH, PATH=.:$PATH, PATH=$PATH:., PATH=$PATH:.:/bin, PATH=:$PATH, PATH=$PATH:, and PATH=$PATH::/bin Signed-off-by: Johannes Schindelin Tested-by: H.Merijn Brand - Tux diff --git a/t/t0061-run-command.sh b/t/t0061-run-command.sh index cf932c851..557f87442 100755 --- a/t/t0061-run-command.sh +++ b/t/t0061-run-command.sh @@ -29,7 +29,14 @@ test_expect_success 'run_command can run a command' ' test_must_be_empty err ' -test_expect_success 'run_command is restricted to PATH' ' +test_lazy_prereq DOT_IN_PATH ' + case ":$PATH:" in + *:.:*|*::*) true ;; + *) false ;; + esac +' + +test_expect_success !DOT_IN_PATH 'run_command is restricted to PATH' ' write_script should-not-run <<-\EOF && echo yikes EOF -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.29 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ pgpAgdP5HESog.pgp Description: OpenPGP digital signature
Re: [PATCH] t6036: avoid "cp -a"
Elijah Newren writes:
> Thanks for the patch!
>
> On Fri, Nov 30, 2018 at 6:52 PM Carlo Marcelo Arenas Belón
> ...
> Oops. Thanks for catching. To be honest, we don't even need -a, -R,
> etc. -- it was just a habit for me to add -a after cp. A simple cp
> would do, though what you have here is fine too.
Thanks, both. I think the topic won't escape 'next' until 2.20
final, and after that we can rewind 'next', so it may be better
to squash it in, but anyway...
-- >8 --
From: Carlo Marcelo Arenas Belón
Date: Fri, 30 Nov 2018 18:52:12 -0800
Subject: [PATCH] t6036: avoid non-portable "cp -a"
b8cd1bb713 ("t6036, t6043: increase code coverage for file collision
handling", 2018-11-07) uses this GNU extension that is not available
in a POSIX complaint cp. In this particular case, there is no need to
use the option, as it is just copying a single file to create another
file.
Signed-off-by: Carlo Marcelo Arenas Belón
Signed-off-by: Junio C Hamano
---
t/t6036-recursive-corner-cases.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t6036-recursive-corner-cases.sh
b/t/t6036-recursive-corner-cases.sh
index b7488b00c0..d23b948f27 100755
--- a/t/t6036-recursive-corner-cases.sh
+++ b/t/t6036-recursive-corner-cases.sh
@@ -1631,7 +1631,7 @@ test_expect_success 'check nested conflicts' '
# Compare m to expected contents
>empty &&
- cp -a m_stage_2 expected_final_m &&
+ cp m_stage_2 expected_final_m &&
test_must_fail git merge-file --diff3 \
-L "HEAD" \
-L "merged common ancestors" \
--
2.20.0-rc1-10-g7068cbc4ab
[L10N] Kickoff for Git 2.20.0 round 2
Hi,
Two typos are fixed in upstream via commit v2.20.0-rc1-7-gd355e46a15:
--- a/http.c
+++ b/http.c
- warning(_("CURLSSLOPT_NO_REVOKE not suported with cURL
< 7.44.0"));
+ warning(_("CURLSSLOPT_NO_REVOKE not supported with
cURL < 7.44.0"));
--- a/midx.c
+++ b/midx.c
- die(_("bad pack-int-id: %u (%u total packs"),
+ die(_("bad pack-int-id: %u (%u total packs)"),
For l10n teams that have already submitted for l10n round 1, I made a
batch commit to fix fuzzy translations, see pull request:
https://github.com/git-l10n/git-po/pull/331
For other l10n teams, please update your translations against the new
pot file from the usual place:
https://github.com/git-l10n/git-po/
--
Jiang Xin
