* Re: [PATCH v8 3/4] worktree add: add --orphan flag
From: Jacob Abel @ 2023-01-14 22:47 UTC (permalink / raw)
To: phillip.wood
Cc: git, Ævar Arnfjörð Bjarmason, Eric Sunshine,
Junio C Hamano, Phillip Wood, Rubén Justo, Taylor Blau,
rsbecker
In-Reply-To: <e5aadd5d-9b85-4dc9-e9f7-117892b4b283@dunelm.org.uk>
On 23/01/13 10:20AM, Phillip Wood wrote:
> Hi Jacob
>
> On 09/01/2023 17:33, Jacob Abel wrote:
> > [...]
>
> It's perhaps a bit late to bring this up but I've only just realized
> that it is unfortunate that --orphan takes a branch name rather than
> working in conjunction with -b/-B. It means that in the common case
> where the branch name is the same as the worktree the user has to repeat
> it on the command line as shown above. It also means there is no way to
> force an orphan branch (that's admittedly quite niche). If instead
> --orphan did not take an argument we could have
>
> git worktree add --orphan main
> git worktree add --orphan -b topic main
> git worktree add --orphan -B topic main
>
> Best Wishes
>
> Phillip
>
> > [...]
I think this is a good idea and something similar was brought up previously
however I originally wanted to handle this and a common --orphan DWYM in a later
patch.
> git worktree add --orphan main
I am OK implementing this option and have been workshopping it prior to
responding. I think I have it worked out now as an additional patch which can be
be applied on top of the v8 patchset.
I'll reply to this message with the one-off patch to get feedback. Since this is
essentially a discrete change on top of v8, I can either keep it as a separate
patch or reroll depending on how much needs to be changed (and what would be
easier for everyone).
> git worktree add --orphan -b topic main
> git worktree add --orphan -B topic main
I am hesitant to add these as they break away from the syntax used in
`git switch` and `git checkout`.
Also apologies for the tangent but while researching this path, I noticed that
--orphan behaves unexpectedly on both `git switch` and `git checkout` when mixed
with `-c` and `-b` respectively.
% git switch --orphan -c foobar
fatal: invalid reference: foobar
% git switch -c --orphan foobar
fatal: invalid reference: foobar
% git checkout -b --orphan foobar
fatal: 'foobar' is not a commit and a branch '--orphan' cannot be created from it
% git checkout --orphan -b foobar
fatal: 'foobar' is not a commit and a branch '-b' cannot be created from it
I tried this on my system install as well as from a fresh fetch of next FWIW.
[Info: fresh build from next]
git version 2.39.0.287.g8cbeef4abd
cpu: x86_64
built from commit: 8cbeef4abda4907dd68ea144d9dcb85f0b49c3e6
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
[Info: system install]
git version 2.38.2
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
If this bug is something that needs to be addressed, I can dig a bit deeper and
put together a patch for it in the next few days.
VR,
Abel
^ permalink raw reply
* Segmentation fault within git read-tree
From: Frédéric Fort @ 2023-01-14 22:14 UTC (permalink / raw)
To: git
Hello,
I am doing some tests trying to do a sparse checkout of a partial clone
within a subtree.
However, I get a segfault when trying to run git read-tree as is done by
git subtree internally.
Maybe what I am doing isn't supposed to work at all, but I suppose it
shouldn't at least cause git read-tree to segfault.
Here should be a MWE to reproduce my error:
# Run this to create the repo that will become your subtree
git init subtree.git
cd subtree.git
touch x y
git add .
git commit -m "first commit"
# Run this to create the repo that has a sparse checkout of a partial
clone within a subtree
git init repo
cd repo
git commit --allow-empty "first commit"
git sparse-checkout set "subtree/x"
git remote add origin-subtree git@my.server:/with/the/subtree.git
git fetch --filter=blob:none origin-subtree
git rev-parse --verify "FETCH_HEAD^{commit}"
git read-tree --debug-unpack --prefix="subtree" FETCH_HEAD
Yours sincerely,
Frédéric Fort
^ permalink raw reply
* Re: [PATCH 3/4] ls-files: clarify descriptions of status tags for -t
From: Elijah Newren @ 2023-01-14 20:26 UTC (permalink / raw)
To: ZheNing Hu; +Cc: Elijah Newren via GitGitGadget, git
In-Reply-To: <CAOLTT8RXgw0CC7TBUunCPnnk1=5gKkyYZcFQyWu29QM9bn9s9w@mail.gmail.com>
On Sat, Jan 14, 2023 at 12:27 AM ZheNing Hu <adlternative@gmail.com> wrote:
>
> Elijah Newren via GitGitGadget <gitgitgadget@gmail.com> 于2023年1月13日周五 12:41写道：
> >
> > From: Elijah Newren <newren@gmail.com>
> >
> > Much like the file selection options we tweaked in the last commit, the
> > status tags printed with -t had descriptions that were easy to
> > misunderstand, and for many of the same reasons. Clarify them.
> >
> > Also, while at it, remove the "semi-deprecated" comment for "git
> > ls-files -t". The -t option was marked as semi-deprecated in 5bc0e247c4
> > ("Document ls-files -t as semi-obsolete.", 2010-07-28) because:
> >
> > "git ls-files -t" is [...] badly documented, hence we point the
> > users to superior alternatives.
> > The feature is marked as "semi-obsolete" but not "scheduled for removal"
> > since it's a plumbing command, scripts might use it, and Git testsuite
> > already uses it to test the state of the index.
> >
> > Marking it as obsolete because it was easily misunderstood, which I
> > think was primarily due to documentation problems, is one strategy, but
> > I think fixing the documentation is a better option. Especially since
> > in the intervening time, "git ls-files -t" has become heavily used by
> > sparse-checkout users where the same confusion just doesn't apply.
> >
> > Signed-off-by: Elijah Newren <newren@gmail.com>
> > ---
> > Documentation/git-ls-files.txt | 28 +++++++++++++++-------------
> > 1 file changed, 15 insertions(+), 13 deletions(-)
> >
> > diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> > index f89ab1bfc98..3886d58d178 100644
> > --- a/Documentation/git-ls-files.txt
> > +++ b/Documentation/git-ls-files.txt
> > @@ -137,25 +137,27 @@ OPTIONS
> > with `-s` or `-u` options does not make any sense.
> >
> > -t::
> > - This feature is semi-deprecated. For scripting purpose,
> > - linkgit:git-status[1] `--porcelain` and
> > + Show status tags together with filenames. Note that for
> > + scripting purposes, linkgit:git-status[1] `--porcelain` and
> > linkgit:git-diff-files[1] `--name-status` are almost always
> > superior alternatives, and users should look at
> > linkgit:git-status[1] `--short` or linkgit:git-diff[1]
> > `--name-status` for more user-friendly alternatives.
> > +
> > --
> > -This option identifies the file status with the following tags (followed by
> > -a space) at the start of each line:
> > -
> > - H:: cached
> > - S:: skip-worktree
> > - M:: unmerged
> > - R:: removed/deleted
> > - C:: modified/changed
> > - K:: to be killed
> > - ?:: other
> > - U:: resolve-undo
> > +This option provides a reason for showing each filename, in the form
> > +of a status tag (which is followed by a space and then the filename).
> > +The status tags are all single characters from the following list:
> > +
> > + H:: tracked file that is not either unmerged or skip-worktree
> > + S:: tracked file that is skip-worktree
> > + M:: tracked file that is unmerged
> > + R:: tracked file with unstaged removal/deletion
> > + C:: tracked file with unstaged modification/change
> > + K:: untracked paths which are part of file/directory conflicts
> > + which prevent checking out tracked files
> > + ?:: untracked file
> > + U:: file with resolve-undo information
> > --
> >
>
> Good to see these tags describe are changed, especially "K" (reader
> don't know what is "to be killed")
>
> Maybe we should mention which option will output these tags?
> e.g. default -> "H"/"S" ,`--other` -> "?", `--modified` -> "C",
> `--killed` -> "K"...
We could, but...
* It's H/S/M, not just H/S that is shown by default.
* It gets weird because other options aren't added to the default,
so if someone specifies "-m" then suddenly H/S/M go away...unless they
also specify "-c".
Trying to explain all that feels like we're getting close to repeating
the documentation of the individual options. But maybe we could just
ignore everything around default behavior and find a way to be brief
such as with:
Note that H, S, and M entries are shown with --cached; R entries
are shown with --deleted, C entries are shown with --modified, K
entries are shown with --killed, ? entries are shown with
--others, and U entries are shown with --resolve-undo.
I'm not sure if I like the documentation better with or without this
added paragraph. What do others think?
^ permalink raw reply
* Re: [PATCH 2/4] ls-files: clarify descriptions of file selection options
From: Elijah Newren @ 2023-01-14 19:42 UTC (permalink / raw)
To: ZheNing Hu; +Cc: Elijah Newren via GitGitGadget, git
In-Reply-To: <CAOLTT8Qx6chcA7MEY9Hzeq9U5pfR-fC8aOxhZMvYvi8ZtQeVdA@mail.gmail.com>
On Sat, Jan 14, 2023 at 12:21 AM ZheNing Hu <adlternative@gmail.com> wrote:
>
> Elijah Newren via GitGitGadget <gitgitgadget@gmail.com> 于2023年1月13日周五 12:41写道：
[...]
> > diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> > index cb071583f8b..f89ab1bfc98 100644
> > --- a/Documentation/git-ls-files.txt
> > +++ b/Documentation/git-ls-files.txt
> > @@ -29,21 +29,26 @@ This merges the file listing in the index with the actual working
> > directory list, and shows different combinations of the two.
> >
> > One or more of the options below may be used to determine the files
> > -shown:
> > +shown, and each file may be printed multiple times if there are
> > +multiple entries in the index or multiple statuses are applicable for
> > +the relevant file selection options.
> >
>
> `--deduplicate` option can be used to remove deduped output.
Yes, I'm aware.
If you're suggesting adding this text at this point in the document,
it occurred to me already, but I chose not to put it here. The reason
is that this is a brief synopsis. The "relevant file selection
options" of this brief synopsis could also be expanded to mention what
they are or what the default selection is or whatever. But folks can
read on to learn that `deduplicate` can be used to remove duplicate
options. Likewise, anyone who reads the text about "relevant file
selections" and wants to learn more is inclined to read on to the
other options to find out.
In contrast, no one will be motivated to read on to find out that
files can be printed multiple times if we don't mention it right here.
And they are likely to get confused when it happens, thinking it is a
bug (in fact, I can point out emails from the archives where that has
happened). Without mentioning the possibility of multiple files at
this point, we have a discoverability problem.
There is no similar discoverability and negative-surprise problem I
can think of by omitting other details, so there is no need to expand
this brief synopsis any further.
The one place we could potentially change thing that might help, is
moving the text about -c being the default from under the -c option
and putting it here. That's a toss-up to me, but for now I elected to
keep it where it is.
> > OPTIONS
> > -------
> > -c::
> > --cached::
> > - Show cached files in the output (default)
> > + Show all files cached in Git's index, i.e. all tracked files.
> > + (This is the default if no -c/-s/-d/-o/-u/-k/-m/--resolve-undo
> > + options are specified.)
> >
> > -d::
> > --deleted::
> > - Show deleted files in the output
> > + Show files with an unstaged deletion
> >
>
> This is a nice fix: make it clear to the user that only files in the
> working tree are deleted, not in the index.
>
> > -m::
> > --modified::
> > - Show modified files in the output
> > + Show files with an unstaged modification (note that an unstaged
> > + deletion also counts as an unstaged modification)
> >
>
> Good to mention that deleted files are also modified, otherwise no one
> looking at the documentation would know that.
>
> > -o::
> > --others::
[...]
Thanks for taking a look!
^ permalink raw reply
* Re: ja/worktree-orphan (was What's cooking in git.git (Jan 2023, #04; Sat, 14))
From: Phillip Wood @ 2023-01-14 19:28 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Jacob Abel, Ævar Arnfjörð Bjarmason
In-Reply-To: <xmqqilh9ms1p.fsf@gitster.g>
On 14/01/2023 08:36, Junio C Hamano wrote:
> * ja/worktree-orphan (2023-01-13) 4 commits
> - worktree add: add hint to direct users towards --orphan
> - worktree add: add --orphan flag
> - worktree add: refactor opt exclusion tests
> - worktree add: include -B in usage docs
>
> 'git worktree add' learned how to create a worktree based on an
> orphaned branch with `--orphan`.
>
> Will merge to 'next'.
> source: <20230109173227.29264-1-jacobabel@nullpo.dev>
If possible it would be nice to clean up the ui before merging this, I
think it would be quite a small change to the implementation. cf
<e5aadd5d-9b85-4dc9-e9f7-117892b4b283@dunelm.org.uk>
Best Wishes
Phillip
^ permalink raw reply
* [PATCH v2] t6426: fix TODO about making test more comprehensive
From: Elijah Newren via GitGitGadget @ 2023-01-14 18:49 UTC (permalink / raw)
To: git; +Cc: Andrei Rybak, Elijah Newren, Elijah Newren, Elijah Newren
In-Reply-To: <pull.1462.git.1673584084761.gitgitgadget@gmail.com>
From: Elijah Newren <newren@gmail.com>
t6426.7 (a rename/add testcase) long had a TODO/FIXME comment about
how the test could be improved (with some commented out sample code
that had a few small errors), but those improvements were blocked on
other changes still in progress. The necessary changes were put in
place years ago but the comment was forgotten. Remove and fix the
commented out code section and finally remove the big TODO/FIXME
comment.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
t6426: fix TODO about making test more comprehensive
See
https://lore.kernel.org/git/CABPp-BFxK7SGs3wsOfozSw_Uvr-ynr+x8ciPV2Rmfx6Nr4si6g@mail.gmail.com/
Changes since v1:
* Removed spurious line, rearranged some lines so that checks on file
"b" come before file "c".
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1462%2Fnewren%2Ft6426-fix-todo-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1462/newren/t6426-fix-todo-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/1462
Range-diff vs v1:
1: 6de47daaeeb ! 1: 68fd28e2547 t6426: fix TODO about making test more comprehensive
@@ Commit message
## t/t6426-merge-skip-unneeded-updates.sh ##
@@ t/t6426-merge-skip-unneeded-updates.sh: test_expect_success '2c: Modify b & add c VS rename b->c' '
+ test_i18ngrep "CONFLICT (.*/add):" out &&
+ test_must_be_empty err &&
- # Make sure c WAS updated
+- # Make sure c WAS updated
++ git ls-files -s >index_files &&
++ test_line_count = 2 index_files &&
++
++ # Ensure b was removed
++ test_path_is_missing b &&
++
++ # Make sure c WAS updated...
test-tool chmtime --get c >new-mtime &&
- test $(cat old-mtime) -lt $(cat new-mtime)
-
@@ t/t6426-merge-skip-unneeded-updates.sh: test_expect_success '2c: Modify b & add
- #test_path_is_missing b
+ test $(cat old-mtime) -lt $(cat new-mtime) &&
+
-+ git ls-files -s >index_files &&
-+ test_line_count = 2 index_files &&
-+
++ # ...and has correct index entries and working tree contents
+ git rev-parse >actual :2:c :3:c &&
+ git rev-parse >expect A:c A:b &&
+ test_cmp expect actual &&
@@ t/t6426-merge-skip-unneeded-updates.sh: test_expect_success '2c: Modify b & add
+ -L "" \
+ -L "B^0" \
+ merged empty merge-me &&
-+ sed -e "s/^\([<=>]\)/\1\1\1/" merged >merged-internal &&
-+
-+ test_cmp merged c &&
-+
-+ test_path_is_missing b
++ test_cmp merged c
)
'
t/t6426-merge-skip-unneeded-updates.sh | 58 ++++++++++----------------
1 file changed, 23 insertions(+), 35 deletions(-)
diff --git a/t/t6426-merge-skip-unneeded-updates.sh b/t/t6426-merge-skip-unneeded-updates.sh
index 2bb8e7f09bb..fd21c1a4863 100755
--- a/t/t6426-merge-skip-unneeded-updates.sh
+++ b/t/t6426-merge-skip-unneeded-updates.sh
@@ -378,42 +378,30 @@ test_expect_success '2c: Modify b & add c VS rename b->c' '
test_i18ngrep "CONFLICT (.*/add):" out &&
test_must_be_empty err &&
- # Make sure c WAS updated
+ git ls-files -s >index_files &&
+ test_line_count = 2 index_files &&
+
+ # Ensure b was removed
+ test_path_is_missing b &&
+
+ # Make sure c WAS updated...
test-tool chmtime --get c >new-mtime &&
- test $(cat old-mtime) -lt $(cat new-mtime)
-
- # FIXME: rename/add conflicts are horribly broken right now;
- # when I get back to my patch series fixing it and
- # rename/rename(2to1) conflicts to bring them in line with
- # how add/add conflicts behave, then checks like the below
- # could be added. But that patch series is waiting until
- # the rename-directory-detection series lands, which this
- # is part of. And in the mean time, I do not want to further
- # enforce broken behavior. So for now, the main test is the
- # one above that err is an empty file.
-
- #git ls-files -s >index_files &&
- #test_line_count = 2 index_files &&
-
- #git rev-parse >actual :2:c :3:c &&
- #git rev-parse >expect A:b A:c &&
- #test_cmp expect actual &&
-
- #git cat-file -p A:b >>merged &&
- #git cat-file -p A:c >>merge-me &&
- #>empty &&
- #test_must_fail git merge-file \
- # -L "Temporary merge branch 1" \
- # -L "" \
- # -L "Temporary merge branch 2" \
- # merged empty merge-me &&
- #sed -e "s/^\([<=>]\)/\1\1\1/" merged >merged-internal &&
-
- #git hash-object c >actual &&
- #git hash-object merged-internal >expect &&
- #test_cmp expect actual &&
-
- #test_path_is_missing b
+ test $(cat old-mtime) -lt $(cat new-mtime) &&
+
+ # ...and has correct index entries and working tree contents
+ git rev-parse >actual :2:c :3:c &&
+ git rev-parse >expect A:c A:b &&
+ test_cmp expect actual &&
+
+ git cat-file -p A:b >>merge-me &&
+ git cat-file -p A:c >>merged &&
+ >empty &&
+ test_must_fail git merge-file \
+ -L "HEAD" \
+ -L "" \
+ -L "B^0" \
+ merged empty merge-me &&
+ test_cmp merged c
)
'
base-commit: 2b4f5a4e4bb102ac8d967cea653ed753b608193c
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH] ls-tree: fix expansion of repeated %(path)
From: René Scharfe @ 2023-01-14 18:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Ævar Arnfjörð Bjarmason
In-Reply-To: <xmqqmt6lkqrp.fsf@gitster.g>
Am 14.01.2023 um 17:46 schrieb Junio C Hamano:
> René Scharfe <l.s.r@web.de> writes:
>
>> expand_show_tree() borrows the base strbuf given to us by read_tree() to
>> build the full path of the current entry when handling %(path). Only
>> its indirect caller, show_tree_fmt(), removes the added entry name.
>> That works fine as long as %(path) is only included once in the format
>> string, but accumulates duplicates if it's repeated:
>>
>> $ git ls-tree --format='%(path) %(path) %(path)' HEAD M*
>> Makefile MakefileMakefile MakefileMakefileMakefile
>>
>> Reset the length after each use to get the same expansion every time;
>> here's the behavior with this patch:
>>
>> $ ./git ls-tree --format='%(path) %(path) %(path)' HEAD M*
>> Makefile Makefile Makefile
>>
>> Signed-off-by: René Scharfe <l.s.r@web.de>
>> ---
>> builtin/ls-tree.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> I wonder if this was broken from its introduction at 455923e0
> (ls-tree: introduce "--format" option, 2022-03-23)?
Yes.
> It seems to be the case. With the following applied on top of
> 455923e0, the new test fails as expected, and your patch fixes
> the breakage, so I am tempted to squash the tests in ;-)
I didn't include a test because it's an odd bug which I didn't expect to
ever return. But its current existence proves that it can happen. So I
don't mind this addition.
>
> Thanks.
>
> t/t3104-ls-tree-format.sh | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git c/t/t3104-ls-tree-format.sh w/t/t3104-ls-tree-format.sh
> index 7f1eb699d3..7e6c4dc5da 100755
> --- c/t/t3104-ls-tree-format.sh
> +++ w/t/t3104-ls-tree-format.sh
> @@ -37,6 +37,12 @@ test_ls_tree_format () {
> '
> }
>
> +test_expect_success "ls-tree --format='%(path) %(path) %(path)' HEAD top-file" '
> + git ls-tree --format="%(path) %(path) %(path)" HEAD top-file.t >actual &&
> + echo top-file.t top-file.t top-file.t >expect &&
> + test_cmp expect actual
> +'
> +
> test_ls_tree_format \
> "%(objectmode) %(objecttype) %(objectname)%x09%(path)" \
> ""
^ permalink raw reply
* Re: test_pause giving '__git_ps1: not found' warning
From: Philip Oakley @ 2023-01-14 17:49 UTC (permalink / raw)
To: Git List, Philippe Blain, Elijah Newren
In-Reply-To: <bce6ac3a-17a6-beed-43ef-5a1e0dd92a5d@iee.email>
On 14/01/2023 14:54, Philip Oakley wrote:
> I was trying to refine a test_expect_failure test [1] and tried
> inserting a `test_pause &&` test line [2].
>
> I then found, when it paused, I was repeatedly given the warning line
> /bin/sh: 1: __git_ps1: not found
> in the terminal until I expected the test shell.
>
> my PS1 is working normally in the terminal, but not here. Is this
> expected, or do I need to set up anything else?
>
> Normally I'm on Git for Windows, but this was on my old laptop (Acer
> 7741 i5 4GB ram..) converted to Ubuntu 20.04, which I use when away.
>
> The basic sequence was
>
> ~$ cd repos/git
> ~/repos/git (doctrunc *)$ cd t
> ~/repos/git/t (doctrunc *)$ ./t4205-log-pretty-formats.sh -i -x -v
> Initialized empty Git repository in /home/philip/repos/git/t/trash
> directory.t4205-log-pretty-formats/.git/
>
> [... ...]
>
> + git log --format=%<(5,mtrunc)%s -4
> + test_pause
> + PAUSE_TERM=dumb
> + PAUSE_SHELL=/bin/sh
> + PAUSE_HOME=/home/philip/repos/git/t/trash
> directory.t4205-log-pretty-formats
> + test 0 != 0
> + TERM=dumb HOME=/home/philip/repos/git/t/trash
> directory.t4205-log-pretty-formats /bin/sh
I think the 'gotcha' is here in the setting of HOME within the
test_pause which in some ways conflicts with the setting of the
__git_ps1 instructions [3].
My local .bashrc has
. /home/philip/git-completion.bash
. ~/git-prompt.sh
export GIT_PS1_SHOWDIRTYSTATE=1
export PS1='\w$(__git_ps1 " (%s)")\$ '
Not sure why I have a relative and an absolute path but... , so I'll
try updating the git-prompt.sh to an absolute path, and if that works,
maybe think about adding an extra comment to the `test-lib-functions.sh`
to note the change of HOME and potential '__git_ps1' problem
[3]
https://git-scm.com/book/uz/v2/Appendix-A%3A-Git-in-Other-Environments-Git-in-Bash
> /bin/sh: 1: __git_ps1: not found
> \w$ git status
> On branch source-b
> [...]
> nothing added to commit but untracked files present (use "git add" to
> track)
> /bin/sh: 1: __git_ps1: not found
>
> I added the gits status to see when/where the warning was emitted.
>
> [1]
> https://github.com/PhilipOakley/git/blob/doctrunc/t/t4205-log-pretty-formats.sh#L1021-L1046
> [2]
> https://github.com/git/git/blob/master/t/test-lib-functions.sh#L137-L188
>
>
> Any suggestions as to how to set this up correctly to avoid the warning?
> --
> Philip
^ permalink raw reply
* Re: [PATCH] env-helper: move this built-in to to "test-tool env-helper"
From: Andrei Rybak @ 2023-01-14 17:43 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason, git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <patch-1.1-e662c570f1d-20230112T155226Z-avarab@gmail.com>
Hi Ævar,
Here's a drive-by nitpick:
On 12/01/2023 17:03, Ævar Arnfjörð Bjarmason wrote:
> diff --git a/Makefile b/Makefile
> index db447d07383..f2f342683c1 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -799,6 +799,7 @@ TEST_BUILTINS_OBJS += test-dump-fsmonitor.o
> TEST_BUILTINS_OBJS += test-dump-split-index.o
> TEST_BUILTINS_OBJS += test-dump-untracked-cache.o
> TEST_BUILTINS_OBJS += test-example-decorate.o
> +TEST_BUILTINS_OBJS += test-env-helper.o
The .o files are sorted alphabetically in TEST_BUILTINS_OBJS, so
test-env-helper.o should be above test-example-decorate.o
Compare it to changes in t/helper/test-tool.[ch]:
> diff --git a/t/helper/test-tool.c b/t/helper/test-tool.c
> index 7eb1a26a305..abe8a785eb6 100644
> --- a/t/helper/test-tool.c
> +++ b/t/helper/test-tool.c
> @@ -28,6 +28,7 @@ static struct test_cmd cmds[] = {
> { "dump-fsmonitor", cmd__dump_fsmonitor },
> { "dump-split-index", cmd__dump_split_index },
> { "dump-untracked-cache", cmd__dump_untracked_cache },
> + { "env-helper", cmd__env_helper },
> { "example-decorate", cmd__example_decorate },
> { "fast-rebase", cmd__fast_rebase },
> { "fsmonitor-client", cmd__fsmonitor_client },
> diff --git a/t/helper/test-tool.h b/t/helper/test-tool.h
> index 2e20a16eb82..ea2672436c9 100644
> --- a/t/helper/test-tool.h
> +++ b/t/helper/test-tool.h
> @@ -22,6 +22,7 @@ int cmd__dump_fsmonitor(int argc, const char **argv);
> int cmd__dump_split_index(int argc, const char **argv);
> int cmd__dump_untracked_cache(int argc, const char **argv);
> int cmd__dump_reftable(int argc, const char **argv);
> +int cmd__env_helper(int argc, const char **argv);
> int cmd__example_decorate(int argc, const char **argv);
> int cmd__fast_rebase(int argc, const char **argv);
> int cmd__fsmonitor_client(int argc, const char **argv);
^ permalink raw reply
* Re: [PATCH v2] ci: do not die on deprecated-declarations warning
From: Jeff King @ 2023-01-14 17:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ramsay Jones
In-Reply-To: <xmqq7cxpkpjp.fsf@gitster.g>
On Sat, Jan 14, 2023 at 09:13:14AM -0800, Junio C Hamano wrote:
> +# Libraries deprecate symbols while retaining them for a long time to
> +# keep software working with both older and newer versions of them.
> +# Getting warnings does help the developers' awareness, but we cannot
> +# afford to update too aggressively. E.g. CURLOPT_REDIR_PROTOCOLS_STR
> +# is only available in 7.85.0 that deprecates CURLOPT_REDIR_PROTOCOLS
> +# but we cannot rewrite the uses of the latter with the former until
> +# 7.85.0, which was released in August 2022, becomes ubiquitous.
> +DEVELOPER_CFLAGS += -DCURL_DISABLE_DEPRECATION
This seems like a reasonable middle ground to me.
Though we could perhaps even just add it to the main Makefile, and
always pass it. People who aren't using DEVELOPER=1 might be annoyed by
the warnings (and might even be using -Werror themselves!).
-Peff
^ permalink raw reply
* Re: [PATCH] ci: do not die on deprecated-declarations warning
From: Jeff King @ 2023-01-14 17:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramsay Jones, git
In-Reply-To: <xmqqv8l9ks86.fsf@gitster.g>
On Sat, Jan 14, 2023 at 08:15:21AM -0800, Junio C Hamano wrote:
> Yeah, I like that approach.
>
> But not this one ...
>
> > + CURL_IGNORE_DEPRECATION(
> > + curl_easy_setopt(result, CURLOPT_REDIR_PROTOCOLS,
> > + get_curl_allowed_protocols(0));
> > + curl_easy_setopt(result, CURLOPT_PROTOCOLS,
> > + get_curl_allowed_protocols(-1));
> > + )
> >
> > though I think that was introduced only in 7.87.0 along with the
> > deprecation warnings themselves, so we'd need to have a fallback like:
> >
> > #ifndef CURL_IGNORE_DEPRECATION(x)
> > #define CURL_IGNORE_DEPRECATION(x) x
> > #endif
>
> ... as much.
I agree it's pretty ugly. The one advantage it has is that we'd be
informed of _other_ curl deprecations that might be more interesting to
us.
On the other hand, I don't know how useful those deprecations are going
to be, as it depends on the timeframe. If the deprecation is added for
the same version of libcurl that implements the alternative (which is
roughly the case here), then we'd always be stuck supporting the old and
new forms (old for backwards compatibility, and new to silence the
deprecation warning). We care a lot more about the deprecation once the
alternative has been around for a while, and/or the old way of doing
things is about to be removed. And if we just wait until that removal,
then we do not have to rely on deprecation warnings. The build will
break just fine on its own. :)
-Peff
^ permalink raw reply
* [PATCH v2] ci: do not die on deprecated-declarations warning
From: Junio C Hamano @ 2023-01-14 17:13 UTC (permalink / raw)
To: git; +Cc: Jeff King, Ramsay Jones
In-Reply-To: <xmqqv8l9n5fj.fsf@gitster.g>
Like a recent GitHub CI run on linux-musl [1] shows, we seem to be
getting a bunch of errors of the form:
Error: http.c:1002:9: 'CURLOPT_REDIR_PROTOCOLS' is deprecated:
since 7.85.0. Use CURLOPT_REDIR_PROTOCOLS_STR
[-Werror=deprecated-declarations]
For some of them, it may be reasonable to follow the deprecation
notice and update the code, but some symbols like the above is not.
According to the release table [2], 7.85.0 that deprecates
CURLOPT_REDIR_PROTOCOLS was released on 2022-08-31, less than a year
ago, and according to the symbols-in-versions table [3],
CURLOPT_REDIR_PROTOCOLS_STR was introduced in 7.85.0, so it will
make us incompatible with anything older than a year if we rewrote
the call as the message suggests.
For now, let's disable the deprecation warnings from libcURL
altogether. Ideally we may still want to see them to learn about
urgency of future need to rewrite our code (we only want to avoid
-Werror to stop our build).
[1] https://github.com/git/git/actions/runs/3915509922/jobs/6693756050
[2] https://curl.se/docs/releases.html
[3] https://github.com/curl/curl/blob/master/docs/libcurl/symbols-in-versions
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
config.mak.dev | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/config.mak.dev b/config.mak.dev
index 981304727c..03a0bac8c9 100644
--- a/config.mak.dev
+++ b/config.mak.dev
@@ -69,6 +69,15 @@ DEVELOPER_CFLAGS += -Wno-missing-braces
endif
endif
+# Libraries deprecate symbols while retaining them for a long time to
+# keep software working with both older and newer versions of them.
+# Getting warnings does help the developers' awareness, but we cannot
+# afford to update too aggressively. E.g. CURLOPT_REDIR_PROTOCOLS_STR
+# is only available in 7.85.0 that deprecates CURLOPT_REDIR_PROTOCOLS
+# but we cannot rewrite the uses of the latter with the former until
+# 7.85.0, which was released in August 2022, becomes ubiquitous.
+DEVELOPER_CFLAGS += -DCURL_DISABLE_DEPRECATION
+
# Old versions of clang complain about initializaing a
# struct-within-a-struct using just "{0}" rather than "{{0}}". This
# error is considered a false-positive and not worth fixing, because
--
2.39.0-198-ga38d39a4c5
^ permalink raw reply related
* Re: [PATCH] ci: do not die on deprecated-declarations warning
From: Junio C Hamano @ 2023-01-14 16:55 UTC (permalink / raw)
To: Jeff King; +Cc: Ramsay Jones, git
In-Reply-To: <Y8LAim4D3g6qnZdq@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> +# Libraries deprecate symbols while retaining them for a long time to
>> +# keep software working with both older and newer versions of them.
>> +# Getting warnings does help the developers' awareness, but we cannot
>> +# afford to update too aggressively. E.g. CURLOPT_REDIR_PROTOCOLS_STR
>> +# is only available in 7.85.0 that deprecates CURLOPT_REDIR_PROTOCOLS
>> +# but we cannot rewrite the uses of the latter with the former until
>> +# 7.85.0, which was released in August 2022, becomes ubiquitous.
>> +DEVELOPER_CFLAGS += -Wno-error=deprecated-declarations
>
> That's a pretty broad hammer. And I think it may stomp on the hack to
> rely on deprecated() in the UNUSED macro.
True.
> As Ramsay suggested, we could probably use CURL_DISABLE_DEPRECATION to
> limit this just to the problematic case. An even more focused option is
> to use curl's helper here:
One possible downside of the use of CURL_DISABLE_DEPRECATION is that
we may still want to see deprecation warning to learn about upcoming
change. We just do not want the -Werror to make us die when it
happens.
But anyway, let's use CURL_DISABLE_DEPRECATION first to see how it
goes.
Thanks.
^ permalink raw reply
* Re: [PATCH] ls-tree: fix expansion of repeated %(path)
From: Junio C Hamano @ 2023-01-14 16:46 UTC (permalink / raw)
To: René Scharfe; +Cc: Git List, Ævar Arnfjörð Bjarmason
In-Reply-To: <59f0a3f8-2dae-db47-5075-0cf50aada335@web.de>
René Scharfe <l.s.r@web.de> writes:
> expand_show_tree() borrows the base strbuf given to us by read_tree() to
> build the full path of the current entry when handling %(path). Only
> its indirect caller, show_tree_fmt(), removes the added entry name.
> That works fine as long as %(path) is only included once in the format
> string, but accumulates duplicates if it's repeated:
>
> $ git ls-tree --format='%(path) %(path) %(path)' HEAD M*
> Makefile MakefileMakefile MakefileMakefileMakefile
>
> Reset the length after each use to get the same expansion every time;
> here's the behavior with this patch:
>
> $ ./git ls-tree --format='%(path) %(path) %(path)' HEAD M*
> Makefile Makefile Makefile
>
> Signed-off-by: René Scharfe <l.s.r@web.de>
> ---
> builtin/ls-tree.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
I wonder if this was broken from its introduction at 455923e0
(ls-tree: introduce "--format" option, 2022-03-23)?
It seems to be the case. With the following applied on top of
455923e0, the new test fails as expected, and your patch fixes
the breakage, so I am tempted to squash the tests in ;-)
Thanks.
t/t3104-ls-tree-format.sh | 6 ++++++
1 file changed, 6 insertions(+)
diff --git c/t/t3104-ls-tree-format.sh w/t/t3104-ls-tree-format.sh
index 7f1eb699d3..7e6c4dc5da 100755
--- c/t/t3104-ls-tree-format.sh
+++ w/t/t3104-ls-tree-format.sh
@@ -37,6 +37,12 @@ test_ls_tree_format () {
'
}
+test_expect_success "ls-tree --format='%(path) %(path) %(path)' HEAD top-file" '
+ git ls-tree --format="%(path) %(path) %(path)" HEAD top-file.t >actual &&
+ echo top-file.t top-file.t top-file.t >expect &&
+ test_cmp expect actual
+'
+
test_ls_tree_format \
"%(objectmode) %(objecttype) %(objectname)%x09%(path)" \
""
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2023, #04; Sat, 14)
From: Junio C Hamano @ 2023-01-14 16:35 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <Y8Kkjswoy3ELmAxR@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Jan 14, 2023 at 12:36:18AM -0800, Junio C Hamano wrote:
>
>> * ab/test-env-helper (2023-01-13) 1 commit
>> - env-helper: move this built-in to to "test-tool env-helper"
>>
>> Remove "git env--helper" and demote it to a test-tool subcommand.
>>
>> Will merge to 'next'.
>> source: <patch-1.1-e662c570f1d-20230112T155226Z-avarab@gmail.com>
>
> There's a typo in the subject: s/to to/to/. Not a big deal, but since it
> hasn't quite hit next yet, maybe worth fixing.
Indeed. Thanks for reminding me.
^ permalink raw reply
* Re: [PATCH] ci: do not die on deprecated-declarations warning
From: Junio C Hamano @ 2023-01-14 16:15 UTC (permalink / raw)
To: Jeff King; +Cc: Ramsay Jones, git
In-Reply-To: <Y8LAim4D3g6qnZdq@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> +DEVELOPER_CFLAGS += -Wno-error=deprecated-declarations
>
> That's a pretty broad hammer. And I think it may stomp on the hack to
> rely on deprecated() in the UNUSED macro.
>
> As Ramsay suggested, we could probably use CURL_DISABLE_DEPRECATION to
> limit this just to the problematic case.
Yeah, I like that approach.
But not this one ...
> + CURL_IGNORE_DEPRECATION(
> + curl_easy_setopt(result, CURLOPT_REDIR_PROTOCOLS,
> + get_curl_allowed_protocols(0));
> + curl_easy_setopt(result, CURLOPT_PROTOCOLS,
> + get_curl_allowed_protocols(-1));
> + )
>
> though I think that was introduced only in 7.87.0 along with the
> deprecation warnings themselves, so we'd need to have a fallback like:
>
> #ifndef CURL_IGNORE_DEPRECATION(x)
> #define CURL_IGNORE_DEPRECATION(x) x
> #endif
... as much.
^ permalink raw reply
* Re: [PATCH] ci: do not die on deprecated-declarations warning
From: Junio C Hamano @ 2023-01-14 16:13 UTC (permalink / raw)
To: Ramsay Jones; +Cc: git, Ævar Arnfjörð Bjarmason, Adam Dinwoodie
In-Reply-To: <11dccdea-0e33-6669-9554-19f064df6010@ramsayjones.plus.com>
Ramsay Jones <ramsay@ramsayjones.plus.com> writes:
> Yes, on 30-Dec-2022 I updated my cygwin installation, which updated
> the curl package(s) from v7.86.0 to v7.87.0, and caused my build
> to fail. I had a quick look at the new 'curl.h' header file and
> disabled the deprecation warnings to fix my build. I used vim to
> add the following to my config.mak:
>
> CFLAGS += -DCURL_DISABLE_DEPRECATION
>
> .. and then promptly forgot about it for a couple of weeks! :)
Ahh, this is why I love to be working with this community, where I
can float a problem with a possible solution and fellow developers
respond with better solutions very quickly.
>> +DEVELOPER_CFLAGS += -Wno-error=deprecated-declarations
>> +
>
> Rather than suppressing 'deprecated-declarations' globally, we could
> just add '-DCURL_DISABLE_DEPRECATION' to the compilation of http.c,
> http-push.c and remote-curl.c; similar to how we use target specific
> rules to pass '-DCURL_DISABLE_TYPECHECK' to sparse (only) to a similar
> set of files.
OK, or, assuming that non-curl including code will not be affected
with the macro, we can globally add -DCURL_DISABLE_DEPRECATION to
CFLAGS or DEVELOPER_CFLAGS.
I guess I can sit back and wait until a better version materializes
;-)?
Thanks.
^ permalink raw reply
* Re: BUG: git grep behave oddly with alternatives
From: Junio C Hamano @ 2023-01-14 16:08 UTC (permalink / raw)
To: Diomidis Spinellis
Cc: René Scharfe, Ævar Arnfjörð Bjarmason,
Jeff King, Marco Nenciarini, git
In-Reply-To: <ab50c16f-dbb0-0661-4d08-fa150d31f88b@aueb.gr>
Diomidis Spinellis <dds@aueb.gr> writes:
> Indeed, I removed the alternation handling functionality by accident.
> I was not aware of the BRE-handling difference between the GNU and the
> macOS native regex library. I think having git-grep behave the same
> as grep(1) on each platform is consistent with the principle of least
> astonishment (POLA). This would mean that on macOS plain git-grep
> should use enhanced basic REs as proposed in René's patch.
Thanks. I am fine with what René's patch does, which we already
queued, then ;-)
Let's merge 54463d32 (use enhanced basic regular expressions on
macOS, 2023-01-08) down to 'next'.
^ permalink raw reply
* Re: [PATCH v5 2/2] send-email: expose header information to git-send-email's sendemail-validate hook
From: Junio C Hamano @ 2023-01-14 16:06 UTC (permalink / raw)
To: Strawbridge, Michael; +Cc: git@vger.kernel.org, Tuikov, Luben
In-Reply-To: <xmqqedrxm7bn.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> "Strawbridge, Michael" <Michael.Strawbridge@amd.com> writes:
>
>> +test_expect_success $PREREQ "--validate hook supports header argument" '
>> + test_when_finished "rm my-hooks.ran" &&
>> + write_script my-hooks/sendemail-validate <<-\EOF &&
>> + filesize=$(stat -c%s "$2")
>
> That "stat -c" is a GNU-ism, I think. macOS CI jobs at GitHub do
> not seem to like it.
>
>> + if [ "$filesize" != "0" ]; then
>
> Also, please see Documentation/CodingGuidelines to learn the subset
> of shell script syntax and style we adopted for this project.
Sorry, forgot to say that if you are merely interested to react to
the fact that a file has non-empty contents,
if test -s "$2"
then
... file $2 is not empty ...
fi &&
...
should be a way to do so.
Thanks.
^ permalink raw reply
* Re: [PATCH v5 2/2] send-email: expose header information to git-send-email's sendemail-validate hook
From: Junio C Hamano @ 2023-01-14 16:03 UTC (permalink / raw)
To: Strawbridge, Michael; +Cc: git@vger.kernel.org, Tuikov, Luben
In-Reply-To: <20230110211452.2568535-3-michael.strawbridge@amd.com>
"Strawbridge, Michael" <Michael.Strawbridge@amd.com> writes:
> +test_expect_success $PREREQ "--validate hook supports header argument" '
> + test_when_finished "rm my-hooks.ran" &&
> + write_script my-hooks/sendemail-validate <<-\EOF &&
> + filesize=$(stat -c%s "$2")
That "stat -c" is a GNU-ism, I think. macOS CI jobs at GitHub do
not seem to like it.
> + if [ "$filesize" != "0" ]; then
Also, please see Documentation/CodingGuidelines to learn the subset
of shell script syntax and style we adopted for this project.
Thanks.
^ permalink raw reply
* Re: [PATCH] ci: do not die on deprecated-declarations warning
From: Ramsay Jones @ 2023-01-14 15:14 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <11dccdea-0e33-6669-9554-19f064df6010@ramsayjones.plus.com>
On 14/01/2023 14:29, Ramsay Jones wrote:
> Hi Junio,
[snip]
> Sorry for not looking into this (and notifying the list) sooner.
Ah, that reminds me...
When I updated to Linux Mint v21.0 (based on latest Ubuntu LTS) last
year, sparse started failing. This was due to a change to the 'regex.h'
header file (the libc6-dev package version was updated from 2.31 to
2.35), where (among other things) the diff looked like:
..
524a525,548
> #ifndef _REGEX_NELTS
> # if (defined __STDC_VERSION__ && 199901L <= __STDC_VERSION__ \
> && !defined __STDC_NO_VLA__)
> # define _REGEX_NELTS(n) n
> # else
> # define _REGEX_NELTS(n)
> # endif
> #endif
>
..
645c681,682
< regmatch_t __pmatch[_Restrict_arr_],
---
> regmatch_t __pmatch[_Restrict_arr_
> _REGEX_NELTS (__nmatch)],
..
The last hunk is the declaration of regexec(), thus:
extern int regexec (const regex_t *_Restrict_ __preg,
const char *_Restrict_ __String, size_t __nmatch,
regmatch_t __pmatch[_Restrict_arr_
_REGEX_NELTS (__nmatch)],
int __eflags);
So, sparse falls over on the '__nmatch' as part of the __pmatch
argument declaration. [Actually, it doesn't bomb out on the
declaration, but at each regexec() call site].
To fix my build, I added the following to my config.mak file on linux:
SPARSE_FLAGS += -D__STDC_NO_VLA__
.. and forgot about it! :)
I need to fix this sometime.
ATB,
Ramsay Jones
^ permalink raw reply
* [BONUS][PATCH] ls-tree: remove dead store and strbuf for quote_c_style()
From: René Scharfe @ 2023-01-14 15:03 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason
In-Reply-To: <59f0a3f8-2dae-db47-5075-0cf50aada335@web.de>
Stop initializing "name" because it is set again before use.
Let quote_c_style() write directly to "sb" instead of taking a detour
through "quoted". This avoids an allocation and a string copy. The
result is the same because the function only appends.
Signed-off-by: René Scharfe <l.s.r@web.de>
---
builtin/ls-tree.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/builtin/ls-tree.c b/builtin/ls-tree.c
index 120fff9fa0..9b804cd13b 100644
--- a/builtin/ls-tree.c
+++ b/builtin/ls-tree.c
@@ -94,18 +94,15 @@ static size_t expand_show_tree(struct strbuf *sb, const char *start,
} else if (skip_prefix(start, "(objectname)", &p)) {
strbuf_add_unique_abbrev(sb, data->oid, abbrev);
} else if (skip_prefix(start, "(path)", &p)) {
- const char *name = data->base->buf;
+ const char *name;
const char *prefix = chomp_prefix ? ls_tree_prefix : NULL;
- struct strbuf quoted = STRBUF_INIT;
struct strbuf sbuf = STRBUF_INIT;
size_t baselen = data->base->len;
strbuf_addstr(data->base, data->pathname);
name = relative_path(data->base->buf, prefix, &sbuf);
- quote_c_style(name, "ed, NULL, 0);
+ quote_c_style(name, sb, NULL, 0);
strbuf_setlen(data->base, baselen);
- strbuf_addbuf(sb, "ed);
strbuf_release(&sbuf);
- strbuf_release("ed);
} else {
errlen = (unsigned long)len;
die(_("bad ls-tree format: %%%.*s"), errlen, start);
--
2.39.0
^ permalink raw reply related
* Re: [PATCH] ci: do not die on deprecated-declarations warning
From: Jeff King @ 2023-01-14 14:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramsay Jones, git
In-Reply-To: <Y8LAim4D3g6qnZdq@coredump.intra.peff.net>
On Sat, Jan 14, 2023 at 09:47:38AM -0500, Jeff King wrote:
> As Ramsay suggested, we could probably use CURL_DISABLE_DEPRECATION to
> limit this just to the problematic case. An even more focused option is
> to use curl's helper here:
>
> diff --git a/http.c b/http.c
> index 17d954dd95..21891493d9 100644
> --- a/http.c
> +++ b/http.c
> @@ -1,3 +1,4 @@
> +#define CURL_DISABLE_TYPECHECK 1
Oops, this line snuck in from my testing. See my other message for why
it's relevant. ;)
-Peff
^ permalink raw reply
* Re: [PATCH] ci: do not die on deprecated-declarations warning
From: Jeff King @ 2023-01-14 14:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramsay Jones, Daniel Stenberg, Patrick Monnerat, git
In-Reply-To: <xmqqv8l9n5fj.fsf@gitster.g>
On Fri, Jan 13, 2023 at 07:47:12PM -0800, Junio C Hamano wrote:
> Like a recent GitHub CI run on linux-musl [1] shows, we seem to be
> getting a bunch of errors of the form:
>
> Error: http.c:1002:9: 'CURLOPT_REDIR_PROTOCOLS' is deprecated:
> since 7.85.0. Use CURLOPT_REDIR_PROTOCOLS_STR
> [-Werror=deprecated-declarations]
By the way, it seemed odd to me that this failed in just the linux-musl
job, and not elsewhere (nor on my development machine, which has curl
7.87.0). It looks like there's a bad interaction within curl between the
typecheck and deprecation macros. Here's a minimal reproduction:
-- >8 --
cat >foo.c <<-\EOF
#include <curl/curl.h>
void foo(CURL *c)
{
curl_easy_setopt(c, CURLOPT_PROTOCOLS, 0);
}
EOF
# this will complain about deprecated CURLOPT_PROTOCOLS
gcc -DCURL_DISABLE_TYPECHECK -Wdeprecated-declarations -c foo.c
# this will not
gcc -Wdeprecated-declarations -c foo.c
-- 8< --
I didn't look into why the musl build behaves differently, but
presumably it has an older compiler or something that causes curl to
decide not to trigger the typecheck macros.
Adding relevant curl folks to the cc (the curl list itself is
subscriber-only).
-Peff
^ permalink raw reply
* test_pause giving '__git_ps1: not found' warning
From: Philip Oakley @ 2023-01-14 14:54 UTC (permalink / raw)
To: Git List, Philippe Blain, Elijah Newren; +Cc: Philip Oakley
I was trying to refine a test_expect_failure test [1] and tried
inserting a `test_pause &&` test line [2].
I then found, when it paused, I was repeatedly given the warning line
/bin/sh: 1: __git_ps1: not found
in the terminal until I expected the test shell.
my PS1 is working normally in the terminal, but not here. Is this
expected, or do I need to set up anything else?
Normally I'm on Git for Windows, but this was on my old laptop (Acer
7741 i5 4GB ram..) converted to Ubuntu 20.04, which I use when away.
The basic sequence was
~$ cd repos/git
~/repos/git (doctrunc *)$ cd t
~/repos/git/t (doctrunc *)$ ./t4205-log-pretty-formats.sh -i -x -v
Initialized empty Git repository in /home/philip/repos/git/t/trash
directory.t4205-log-pretty-formats/.git/
[... ...]
+ git log --format=%<(5,mtrunc)%s -4
+ test_pause
+ PAUSE_TERM=dumb
+ PAUSE_SHELL=/bin/sh
+ PAUSE_HOME=/home/philip/repos/git/t/trash
directory.t4205-log-pretty-formats
+ test 0 != 0
+ TERM=dumb HOME=/home/philip/repos/git/t/trash
directory.t4205-log-pretty-formats /bin/sh
/bin/sh: 1: __git_ps1: not found
\w$ git status
On branch source-b
[...]
nothing added to commit but untracked files present (use "git add" to track)
/bin/sh: 1: __git_ps1: not found
I added the gits status to see when/where the warning was emitted.
[1]
https://github.com/PhilipOakley/git/blob/doctrunc/t/t4205-log-pretty-formats.sh#L1021-L1046
[2] https://github.com/git/git/blob/master/t/test-lib-functions.sh#L137-L188
Any suggestions as to how to set this up correctly to avoid the warning?
--
Philip
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox