* Re: [PATCH] builtin/stash: configs keepIndex, includeUntracked
From: Junio C Hamano @ 2024-02-21 20:09 UTC (permalink / raw)
To: Ricardo C; +Cc: Phillip Wood, phillip.wood, git
In-Reply-To: <b84e77a1-93e4-4de0-a0cd-4d76a5691a9b@gmail.com>
Ricardo C <rpc01234@gmail.com> writes:
> Permanently enabling keepIndex is mainly intended for people that like
> to stash their unstaged changes before committing (e.g., for testing
> them independently of other changes). The main issue with what you
> recommend is that, if they forget to use `-k`, then the entire state
> of the index is lost, which is especially problematic if the changes
> were interactively staged.
Doesn't "git stash pop --index" meant to recover from such a
mistake, though? If you stash, because your "git commit" notices
there is no change after you did "git stash" without "-k", your
recovery to "pop --index" would apply the changes to the index and
to the working tree on top of exactly the same commit, so there is
no risk of losing any changes by doing so, right? IOW, such a pop
will always round-trip.
^ permalink raw reply
* Re: Bug: impure renames may be reported as pure renames
From: Junio C Hamano @ 2024-02-21 21:00 UTC (permalink / raw)
To: Elijah Newren; +Cc: Mário Guimarães, git
In-Reply-To: <xmqqttm1pwsv.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> Alternatively, we could cap p->score to (MAX_SCORE-1) when
> similarity is _computed_ for filepair between non-identical blobs.
> That should happen in diffcore-rename.c:estimate_similarity().
> It would allow us to still _show_ "1 line changed among 1000 lines"
> case as R100 and still reject inexact renames via "-M100" from the
> command line, I think, as the "exact renames only" short-cut works
> with the finer-grained "score" values and not the coarser "percent"
> values, which might give us a better approach.
... the above may be "better" under a specific assumption: in the
future, we would correct the rounding of scaling from 0..MAX_SCORE
(or 0..MAX_SCORE-1) to 0..100 from the current "always round down"
to "below 0.5 is rounded down, 0.5 and above is rounded up". If
that happens, we would still honor the "Give -M100 to limit the
rename detection to exact ones", and will exclude a change that
modifies a single line in 1000, but if you say -M99, we would show
such a change and it would be labelled as R100 as correctly rounded.
^ permalink raw reply
* [PATCH] doc: clarify the format of placeholders
From: Jean-Noël Avila via GitGitGadget @ 2024-02-21 21:18 UTC (permalink / raw)
To: git; +Cc: Jean-Noël Avila, Jean-Noël Avila
From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
Add the new format rule when using placeholders in the description of
commands and options.
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
---
doc: clarify the format of placeholders
Following the patch "Doc placeholders", there was a question about
adding a formal rule on writing placeholders in description paragraphs.
One agreed output was that the placeholders in paragraph must be
surrounded by angle brackets and not set in literal with backticks.
A new rule, to be accepted, is to force placeholders in paragraphs to be
italicized.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1671%2Fjnavila%2Fplaceholders_document_guidelines-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1671/jnavila/placeholders_document_guidelines-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1671
Documentation/CodingGuidelines | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 578587a4715..a6a965609b5 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -666,6 +666,11 @@ Writing Documentation:
<new-branch-name>
--template=<template-directory>
+ When a placeholder is cited in text paragraph, it is enclosed in angle
+ brackets to remind the reader the reference in the synopsis section.
+ For better visibility, the placeholder is typeset in italics:
+ The _<file>_ to be added.
+
Possibility of multiple occurrences is indicated by three dots:
<file>...
(One or more of <file>.)
@@ -751,6 +756,8 @@ Writing Documentation:
Incorrect:
`\--pretty=oneline`
+A placeholder is not enclosed in backticks, as it is not a literal.
+
If some place in the documentation needs to typeset a command usage
example with inline substitutions, it is fine to use +monospaced and
inline substituted text+ instead of `monospaced literal text`, and with
base-commit: 5fdd5b989cbe5096d44e89861a92b2dd47c279d9
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH 1/3] doc: git-rev-parse: enforce command-line description syntax
From: Jean-Noël AVILA @ 2024-02-21 21:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jean-Noël Avila via GitGitGadget, git
In-Reply-To: <xmqqfrxlpvv1.fsf@gitster.g>
On Wednesday, 21 February 2024 18:31:30 CET Junio C Hamano wrote:
> Jean-Noël Avila <jn.avila@free.fr> writes:
>
> >>> ---short[=length]::
> >>> +--short[=<length>]::
> >>> Same as `--verify` but shortens the object name to a unique
> >>> prefix with at least `length` characters. The minimum length
> >> This same comment applies throughout this patch, but in other places
> >> when we use <placeholder> in the option argument description, don't
> >> we use the same <placeholder> in text as well? I am wondering if
> >> the `length` (typeset in fixed-width) should become <length>. What
> >> do other recent[*] documentation pages commonly do?
> >
> > This is another part of the inconsistences in documentation that I'd
> > like to tackle (hopefully, not in another life).
> >
> > Using angle brackets for placeholders everywhere they appear is a
> > visual link to the preceding syntax description, but may feel a bit
> > heavy on some cases. Anyway, I'm all for applying the rule everywhere,
> > for the sake of consistency.
>
> I agree that if <placeholder> is not an appropriate way to spell
> them in the explanation text, we would want to change them
> consistently everywhere, and until then, using the angle-bracketted
> <placeholder> that is common would be better. The text will be
> modified again when we decide to switch from <placeholder> to
> something else, so updating them now may be a wasted effort, but (1)
> we may decide that <placeholder> is good enough after all, or (2) it
> may make it easier to mechanically identify words whose mark-up
> should be converted if we consistently use <placeholder> now, even
> if we know it won't be the final mark-up.
>
> So I am inclined to say that we should first do `length` -> <length>
> in the body text in the short term. But I also think we should
> *not* do so as part of this patch, whose focus is how the option
> enumeration header should mark up the option arguments.
>
> > Backticks and single quotes are used indistinctively (by the way,
> > asciidoctor does not process single quotes as markup) and are not used
> > everywhere they should. Using backticks is also a good hint for
> > translators to mean "verbatim, do not translate". Obviously, the
> > placeholders ask for translation, so the backtick rule should not
> > apply to them, even if another formating would be welcome :
> > _<placeholder>_ for instance?
>
> Yes. The way AsciiDoc renders (at least HTML) an unadorned <placeholder>
> is not so great.
>
> In "git-add.html" manual page, we see these examples. The first one
> (unadorned) does not make the placeholder word stand out enough; the
> second one that does `<file>` makes it stand out better, but as you
> said, the `verbatim` mark-up is semantically wrong.
>
> https://git.github.io/htmldocs/git-add.html#:~:text=For%20more%20details%20about%20the%20%3Cpathspec%3E%20syntax
>
> https://git.github.io/htmldocs/git-add.html#:~:text=Pathspec%20is%20passed%20in%20%3Cfile%3E%20instead%20of%20commandline%20args.%20If%20%3Cfile%3E%20is%20exactly%20%2D%20then%20standard%20input%20is%20used.%20Pathspec
>
> The last part of the Documentation/CodingGuidelines document talks
> about how to mark up placeholders but it does not go beyond saying
> that they are written as <hyphen-in-between-words-in-angle-braket>.
> Whatever mark-up rule we decide to use, we should document it there.
>
> Thanks.
>
>
>
>
Hi,
I just saw that you pushed this series to 'next'. That's embarrassing because I missed other spots in the file were the formating was not correct. I was also preparing the changes of placeholders in paragraphs as suggested.
Should I prepare another PR?
Thanks
^ permalink raw reply
* Re: [PATCH] rebase: make warning less passive aggressive
From: Jean-Noël AVILA @ 2024-02-21 22:05 UTC (permalink / raw)
To: Junio C Hamano, Michal Suchánek
Cc: Harmen Stoppels via GitGitGadget, git, Harmen Stoppels
In-Reply-To: <20240221183018.GB9696@kitsune.suse.cz>
On Wednesday, 21 February 2024 19:30:18 CET Michal Suchánek wrote:
> On Wed, Feb 21, 2024 at 10:02:04AM -0800, Junio C Hamano wrote:
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> > > Michal Suchánek <msuchanek@suse.de> writes:
> > >
> > >> Or if it does touch the po files it could as well update the
> > >> translations.
> > >>
> > >> There are changes that can be trivially translated without any
knowledge
> > >> of the target language.
> > >
> > > You need to know the target language before deciding it is OK and
> > > sufficient to just remove ̉¿? from around a sentence to make it from
> > > a question to a statement of a fact. You may know enough, but
> > > reviewers may not be. In addition, it would allow bypassing the
> > > language teams, which is the most serious problem I see in such an
> > > attitude.
> >
> > Oops, "attitude" -> "approach".
>
> That's certainly true that even if you know how to remove a question
> mark you may not find a reviewer who knows how to remove one.
>
> Nonetheless, if you do find both a patch author and a reviewer that know
> how to remove a question mark what is the problem with not involving
> several language teams to remove a question mark?
>
> Thanks
>
> Michal
>
>
As a translator, I'm less bothered by editing a sentence to remove a question
mark (maybe enforcing a language style and reformulating the sentence by the
way), than by translating again and again similar sentences.
Thanks
JN
^ permalink raw reply
* Re: [PATCH] Add unix domain socket support to HTTP transport.
From: Eric Wong @ 2024-02-21 22:09 UTC (permalink / raw)
To: Leslie Cheng via GitGitGadget; +Cc: git, Leslie Cheng, Leslie Cheng
In-Reply-To: <pull.1681.git.git.1708506863243.gitgitgadget@gmail.com>
Leslie Cheng via GitGitGadget <gitgitgadget@gmail.com> wrote:
> Subject: Re: [PATCH] Add unix domain socket support to HTTP transport.
No need for trailing `.' in commit message titles
<snip>
> @@ -455,6 +458,20 @@ static int http_options(const char *var, const char *value,
> return 0;
> }
>
> + if (!strcmp("http.unixsocket", var)) {
> +#ifdef GIT_CURL_HAVE_CURLOPT_UNIX_SOCKET_PATH
> +#ifndef NO_UNIX_SOCKETS
> + return git_config_string(&curl_unix_socket_path, var, value);
> +#else
> + warning(_("Unix socket support unavailable in this build of Git"));
> + return 0;
> +#endif
> +#else
> + warning(_("Unix socket support is not supported with cURL < 7.40.0"));
> + return 0;
> +#endif
> + }
Personally, I'd hoist the #ifdef part into a standalone function
since I find mixing CPP and C conditionals confusing.
disclaimer: I'm an easily confused person and don't usually
program in C, though.
<snip>
> --- /dev/null
> +++ b/t/t5565-http-unix-domain-socket.sh
<snip>
> + nc -klU "$socket_path" <tcp_to_uds >uds_to_tcp &
> + UDS_PID=$!
> +
> + nc "$host" "$port" >tcp_to_uds <uds_to_tcp &
`nc' isn't widely installed, its supported flags vary between
implementations, and our test suite doesn't currently use it.
I suggest either using a small bit of Perl or writing a t/helper
program to do its job.
Finally, hard tabs should be used for indentation throughout.
I'll wait on others to comment since I haven't looked at git
hacking in a while.
Anyways, I think this feature could be useful for me, too :>
Thanks.
^ permalink raw reply
* Re: [PATCH 1/3] doc: git-rev-parse: enforce command-line description syntax
From: Junio C Hamano @ 2024-02-21 22:36 UTC (permalink / raw)
To: Jean-Noël Avila; +Cc: Jean-Noël Avila via GitGitGadget, git
In-Reply-To: <xmqqfrxlpvv1.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
>> Backticks and single quotes are used indistinctively (by the way,
>> asciidoctor does not process single quotes as markup) ...
Hmph, it sounds like a bug of asciidoctor we'd need to work around?
In any case, I practiced your "_<placeholder>_" rule on git-add.txt
and here is how my local HTML rendition of the updated line in the
first hunk in the attached patch looks like with "AsciiDoc 10.2.0".
https://pasteboard.co/6koO0h0KJAjW.png
The actual HTML for the above part looks like this:
<div class="paragraph"><p>For more details about the
<em><pathspec></em> syntax, see the <em>pathspec</em> entry
in <a href="gitglossary.html">gitglossary(7)</a>.</p></div>
In the first hunk, the updated "_<pathspec>_" is enclosed inside an
<em>..</em> pair, which is made into "font-style: italic" via css,
while 'pathspec' that remains is already inside <em>..</em>.
By the way, I am getting some typesetting effect from the pair of
single quotes with AsciiDoctor. Here is the rendition of the same
part:
https://pasteboard.co/LbDi95G8BNGv.png
The <meta name="generator"> element in the generated HTML claims it
is "Asciidoctor 2.0.20". The actual HTML for that piece looks like
this:
<p>For more details about the <em><pathspec></em> syntax,
see the <em>pathspec</em> entry
in <a href="gitglossary.html">gitglossary(7)</a>.</p>
So, perhaps we do not have to do a lot of 'word' -> _word_
replacements, hopefully?
----- >8 --------- >8 --------- >8 --------- >8 ----
Subject: [PATCH] doc: apply the new placeholder rules to git-add documentation
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index ed44c1cb31..b73071ba47 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -63,7 +63,7 @@ OPTIONS
to ignore removed files; use `--no-all` option if you want
to add modified or new files but ignore removed ones.
+
-For more details about the <pathspec> syntax, see the 'pathspec' entry
+For more details about the _<pathspec>_ syntax, see the 'pathspec' entry
in linkgit:gitglossary[7].
-n::
@@ -119,10 +119,10 @@ apply to the index. See EDITING PATCHES below.
-u::
--update::
Update the index just where it already has an entry matching
- <pathspec>. This removes as well as modifies index entries to
+ _<pathspec>_. This removes as well as modifies index entries to
match the working tree, but adds no new files.
+
-If no <pathspec> is given when `-u` option is used, all
+If no _<pathspec>_ is given when `-u` option is used, all
tracked files in the entire working tree are updated (old versions
of Git used to limit the update to the current directory and its
subdirectories).
@@ -131,11 +131,11 @@ subdirectories).
--all::
--no-ignore-removal::
Update the index not only where the working tree has a file
- matching <pathspec> but also where the index already has an
+ matching _<pathspec>_ but also where the index already has an
entry. This adds, modifies, and removes index entries to
match the working tree.
+
-If no <pathspec> is given when `-A` option is used, all
+If no _<pathspec>_ is given when `-A` option is used, all
files in the entire working tree are updated (old versions
of Git used to limit the update to the current directory and its
subdirectories).
@@ -145,11 +145,11 @@ subdirectories).
Update the index by adding new files that are unknown to the
index and files modified in the working tree, but ignore
files that have been removed from the working tree. This
- option is a no-op when no <pathspec> is used.
+ option is a no-op when no _<pathspec>_ is used.
+
This option is primarily to help users who are used to older
-versions of Git, whose "git add <pathspec>..." was a synonym
-for "git add --no-all <pathspec>...", i.e. ignored removed files.
+versions of Git, whose "git add _<pathspec>_..." was a synonym
+for "git add --no-all _<pathspec>_...", i.e. ignored removed files.
-N::
--intent-to-add::
@@ -198,8 +198,8 @@ for "git add --no-all <pathspec>...", i.e. ignored removed files.
unchanged.
--pathspec-from-file=<file>::
- Pathspec is passed in `<file>` instead of commandline args. If
- `<file>` is exactly `-` then standard input is used. Pathspec
+ Pathspec is passed in _<file>_ instead of commandline args. If
+ _<file>_ is exactly `-` then standard input is used. Pathspec
elements are separated by LF or CR/LF. Pathspec elements can be
quoted as explained for the configuration variable `core.quotePath`
(see linkgit:git-config[1]). See also `--pathspec-file-nul` and
^ permalink raw reply related
* Re: [PATCH] rebase: make warning less passive aggressive
From: Junio C Hamano @ 2024-02-21 22:46 UTC (permalink / raw)
To: Jean-Noël AVILA
Cc: Michal Suchánek, Harmen Stoppels via GitGitGadget, git,
Harmen Stoppels
In-Reply-To: <2324063.ElGaqSPkdT@cayenne>
Jean-Noël AVILA <jn.avila@free.fr> writes:
> As a translator, I'm less bothered by editing a sentence to remove a question
> mark (maybe enforcing a language style and reformulating the sentence by the
> way), than by translating again and again similar sentences.
Sure, but if the original in C locale used to be "FOO BAR?" and you
translated it to "foo bar?" in your language, and then a patch
updates the string in the source to "FOO BAR", doesn't msgmerge
notice that the original as a "fuzzy" matching and offer you
something like
# fuzzy
msgid "FOO BAR"
msgstr "foo bar?"
so that all you have to do is to remove '?' anyway? So I do not
think you'd need to translate the "FOO BAR" part again and again.
But the above assumes that for your language, the ONLY thing to turn
such a rhetorical "passive aggressive" question into grammatically
correct statement of a fact is to remove the question mark. It may
not be universally true for all languages, and for some language,
even after msgmerge did its job correctly, you may need to do more
than just removing the question mark to adjust the remaining "foo
bar" part.
^ permalink raw reply
* script to pre-build all commits in a git-bisect, and use them during testing
From: Britton Kerin @ 2024-02-21 22:57 UTC (permalink / raw)
To: git
Problem: it's annoying to have to build each commit when
git-bisect'ing for something that isn't being tested automatically (so
no git bisect run).
Solution: https://github.com/bkerin/git-batch-bisect
It has an interface almost exactly like native git-bisect so it's
super easy to learn but it handles a couple additional commands to
create worktrees for all the commits, parallel build, and test in
them.
From the README:
git batch-bisect start bad_commit good_commit
git batch-bisect runinall 'autoreconf --install && ./configure && make'
git batch-bisect runincurrent ./test_program
git batch-bisect good
git batch-bisect runincurrent ./test_program
git batch-bisect bad
# etc.
I'd be grateful for any feedback on this script. I don't actually
bisect all that often, so it's only tested on one real-world project
so far. I thought it might live in contrib someday if it's useful to
anyone else.
Britton
^ permalink raw reply
* Re: [PATCH] builtin/stash: configs keepIndex, includeUntracked
From: Ricardo C @ 2024-02-21 23:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Phillip Wood, phillip.wood, git
In-Reply-To: <xmqq4je1o9yu.fsf@gitster.g>
On 2/21/24 15:09, Junio C Hamano wrote:
> Ricardo C <rpc01234@gmail.com> writes:
>
>> Permanently enabling keepIndex is mainly intended for people that like
>> to stash their unstaged changes before committing (e.g., for testing
>> them independently of other changes). The main issue with what you
>> recommend is that, if they forget to use `-k`, then the entire state
>> of the index is lost, which is especially problematic if the changes
>> were interactively staged.
>
> Doesn't "git stash pop --index" meant to recover from such a
> mistake, though? If you stash, because your "git commit" notices
> there is no change after you did "git stash" without "-k", your
> recovery to "pop --index" would apply the changes to the index and
> to the working tree on top of exactly the same commit, so there is
> no risk of losing any changes by doing so, right? IOW, such a pop
> will always round-trip.
Oh, wow, I didn't realize that was a thing (I mistakenly interpreted the
documentation to mean that it added the entire stash to the index). This does
help a lot, thanks! I guess keepIndex is a lot less important, so this should
mainly be about includeUntracked... but now I'm also longing for a config to
have --index on pop/apply by default :P
Interestingly, it seems like frontend support for --index is very variable.
VScode is probably the most popular frontend and doesn't seem to have any
support for it, while more niche frontends like Emacs Magit and vim-fugitive
do support it and moreover have it as the default. Maybe the real issue here
is lack of awareness of that flag, and the solution is just to spread the word
about it.
Thanks again,
Ricardo
^ permalink raw reply
* Re: script to pre-build all commits in a git-bisect, and use them during testing
From: Junio C Hamano @ 2024-02-21 23:20 UTC (permalink / raw)
To: Britton Kerin; +Cc: git
In-Reply-To: <CAC4O8c-tgDQ42upWorMi3Cw+KdPoHT2YxvZEirt_dtjQXreXAw@mail.gmail.com>
Britton Kerin <britton.kerin@gmail.com> writes:
> Problem: it's annoying to have to build each commit when
> git-bisect'ing for something that isn't being tested automatically (so
> no git bisect run).
>
> Solution: https://github.com/bkerin/git-batch-bisect
So, because "git bisect run" would not be usable for whatever reason
to run a "build and then test" from the command line, you would
build all revisions using
git batch-bisect runinall 'autoreconf --install && ./configure && make'
before starting to test any revision, and then after building
everything, you would do:
git batch-bisect runincurrent ./test_program
git batch-bisect good
git batch-bisect runincurrent ./test_program
git batch-bisect bad
...
where ./test_program cannot signal if it is good or bad mechanically
(e.g., by exiting with non-zero status for failure) but the testers
need to judge the good/bad manually before they can say "git
batch-bisect good/bad", I presume.
It's an interesting workaround for a test program that cannot be
automated. You are willing to waste CPU cycles and diskspace to
build upfront and hold the build products for all N revisions in the
range, where with bisection you would have to build far fewer
revisions (which is the point of bisection), to optimize for
developer/tester latency, which tends to be more expensive. The
trade-off may make good sense.
^ permalink raw reply
* Re: [PATCH] builtin/stash: configs keepIndex, includeUntracked
From: Junio C Hamano @ 2024-02-21 23:53 UTC (permalink / raw)
To: Ricardo C; +Cc: Phillip Wood, phillip.wood, git
In-Reply-To: <xmqq4je1o9yu.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> Ricardo C <rpc01234@gmail.com> writes:
>
>> Permanently enabling keepIndex is mainly intended for people that like
>> to stash their unstaged changes before committing (e.g., for testing
>> them independently of other changes). The main issue with what you
>> recommend is that, if they forget to use `-k`, then the entire state
>> of the index is lost, which is especially problematic if the changes
>> were interactively staged.
>
> Doesn't "git stash pop --index" meant to recover from such a
> mistake, though? If you stash, because your "git commit" notices
> there is no change after you did "git stash" without "-k", your
> recovery to "pop --index" would apply the changes to the index and
> to the working tree on top of exactly the same commit, so there is
> no risk of losing any changes by doing so, right? IOW, such a pop
> will always round-trip.
Actually, "git commit" gets into the picture of making and
recovering from such a mistake a bit more costly than I made it
sound in the above. My bad.
The common sequence is
$ edit edit edit
$ git add -p
$ git stash -k
$ build what is in the index and test
and then when you are happy, conclude it with
$ git commit [NO -o/-i/pathspec]
followed by
$ git stash pop
to continue for the next commit. So "git commit" should notice if
your earlier "stash -k" forgot to say "-k", but by that time, you
would have wasted the whole build and test cycle. The HEAD wouldn't
have moved, so the conclusion that "pop --index" would be a good way
to recover from "stash" without "--keep" does not change, though.
^ permalink raw reply
* Re: [PATCH] rebase: make warning less passive aggressive
From: Junio C Hamano @ 2024-02-22 1:43 UTC (permalink / raw)
To: Jean-Noël AVILA
Cc: Michal Suchánek, Harmen Stoppels via GitGitGadget, git,
Harmen Stoppels
In-Reply-To: <xmqq4je1mo5p.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> Jean-Noël AVILA <jn.avila@free.fr> writes:
>
>> As a translator, I'm less bothered by editing a sentence to remove a question
>> mark (maybe enforcing a language style and reformulating the sentence by the
>> way), than by translating again and again similar sentences.
>
> Sure, but if the original in C locale used to be "FOO BAR?" and you
> translated it to "foo bar?" in your language, and then a patch
> updates the string in the source to "FOO BAR", doesn't msgmerge
> notice that the original as a "fuzzy" matching and offer you
> something like
>
> #, fuzzy
> msgid "FOO BAR"
> msgstr "foo bar?"
>
> so that all you have to do is to remove '?' anyway? So I do not
> think you'd need to translate the "FOO BAR" part again and again.
>
> But the above assumes that for your language, the ONLY thing to turn
> such a rhetorical "passive aggressive" question into grammatically
> correct statement of a fact is to remove the question mark. It may
> not be universally true for all languages, and for some language,
> even after msgmerge did its job correctly, you may need to do more
> than just removing the question mark to adjust the remaining "foo
> bar" part.
Hopefully the last message on this topic from me. I just tried this:
* apply v2 of "No rebase in progress?" -> "no rebase in progress"
patch from Harmen. This only changed _("") string, without
touching any po/* files.
* follow po/README.md and pretend as if I were a po/es.po team
member, which involved running the command:
$ make po-update PO_FILE=po/es.po
* view the resulting po/es.po, which will be the starting point of
a new translation.
$ git diff po/es.po
The last one showed me this snippet:
-msgid "No rebase in progress?"
+#: builtin/rebase.c:1257
+#, fuzzy
+msgid "no rebase in progress"
msgstr "¿No hay rebase en progreso?"
The "#, fuzzy" thing is a signal that an old msgid has been updated
and corresponding msgstr may need to be updated.
The primary problem I had with Harmen's v1 was that it touched po/
file in the first place (which was corrected in v2), but the updates
to po files it did looked like so:
-msgid "No rebase in progress?"
+msgid "No rebase in progress"
msgstr "¿No hay rebase en progreso?"
Notice the lack of "#, fuzzy" marking? If v1 were accepted with
these changes, then the "po-update" step I showed earlier would have
produced something like this instead:
+#: builtin/rebase.c:1257
msgid "no rebase in progress"
msgstr "¿No hay rebase en progreso?"
As msgid alone was updated already, the "po-update" step has no idea
that the translated msgstr is out of date. We do not get the
helpful "#, fuzzy" comment to tell the translator which msgstr is
out of date and needs attention.
So it is another reason why we want the developers to concentrate
only on writing good C-locale messages inside _("") and N_(""),
without touching po/ directory at all. It would avoid making
changes that can confuse toolchain l10n people rely on (like the
presence of "fuzzy" comments).
^ permalink raw reply
* Re: [PATCH] Add unix domain socket support to HTTP transport.
From: Leslie Cheng @ 2024-02-22 3:04 UTC (permalink / raw)
To: Eric Wong, Leslie Cheng via GitGitGadget; +Cc: git, Leslie Cheng
In-Reply-To: <20240221220945.M686016@dcvr>
> No need for trailing `.' in commit message titles
Will fix in the next patch, sorry!
> Personally, I'd hoist the #ifdef part into a standalone function
> since I find mixing CPP and C conditionals confusing.
>
> disclaimer: I'm an easily confused person and don't usually
> program in C, though.
I considered extracting it out, but the other conditionals in this
function follow a similar pattern so I didn't want to change it.
However, my use here is also the first time there's both an #ifdef and
nested #ifndef, which I agree makes it a bit confusing to grok.
I'm open to changing it, but I'll let it sit and marinate for a bit.
> `nc' isn't widely installed, its supported flags vary between
> implementations, and our test suite doesn't currently use it.
> I suggest either using a small bit of Perl or writing a t/helper
> program to do its job.
>
> Finally, hard tabs should be used for indentation throughout.
>
> I'll wait on others to comment since I haven't looked at git
> hacking in a while.
>
> Anyways, I think this feature could be useful for me, too :>
> Thanks.
Good catch, I'll fix in the next patch. I've subbed `nc` out for a
simple Perl script to pipe back and forth, just making sure CI is happy
about this before submitting.
^ permalink raw reply
* Re: Git in GSoC 2024
From: Kaartic Sivaraam @ 2024-02-22 4:31 UTC (permalink / raw)
To: Christian Couder, Patrick Steinhardt, Karthik Nayak, git
Cc: Taylor Blau, Junio C Hamano, Victoria Dye
In-Reply-To: <CA+ARAtqicQkhKFcTxoT+GWMhCxnV-BNqd0oOcn2YwznfFnnRPw@mail.gmail.com>
Hi Christian, Patrick, Karthik and all,
On 21/02/24 10:32, Kaartic Sivaraam wrote:
>
> Christian, could you do the following so that I could add you as an Org
> Admin for the 2024 program?
>
> "Visit https://g.co/gsoc site, click on the 2024 bar which will display
> the 2024 Program Rules and Org Member agreement, read and agree to the
> same."
>
> For mentors, as Patrick and Karthik are new to the program, we need to
> invite them first and only after they've accepted the invitation can we
> add them to the program.
>
> Karthik, I was able to get your Gmail address and have sent an invite to
> you. Could you accept the same after reading through the program rules
> and member agreement?
>
> Patrick, could you kindly share with me your Gmail address so that I could
> invite you to the program?
>
Thanks for the quick turnaround all! I've added all of you to the 2024
program. I hope you're able to access the program page at [1]. Let me
know if you're facing any issues.
Also, it's official now. Git has been selected as one of the
participating organizations[2] in GSoC 2024!
Let's look forward towards a summer with great GSoC contributors who
hopefully become continued contributors to the community :-)
[[ References ]]
[1]:
https://summerofcode.withgoogle.com/organizations/git/programs/2024/timeline
[2]: https://summerofcode.withgoogle.com/programs/2024/organizations/git
--
Sivaraam
^ permalink raw reply
* Re: Git in GSoC 2024
From: Patrick Steinhardt @ 2024-02-22 7:49 UTC (permalink / raw)
To: Kaartic Sivaraam
Cc: Christian Couder, Karthik Nayak, git, Taylor Blau, Junio C Hamano,
Victoria Dye
In-Reply-To: <9cec06d8-971b-4c5d-9d85-969021b0dd48@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]
On Thu, Feb 22, 2024 at 10:01:54AM +0530, Kaartic Sivaraam wrote:
> Hi Christian, Patrick, Karthik and all,
>
> On 21/02/24 10:32, Kaartic Sivaraam wrote:
> >
> > Christian, could you do the following so that I could add you as an Org
> > Admin for the 2024 program?
> >
> > "Visit https://g.co/gsoc site, click on the 2024 bar which will display
> > the 2024 Program Rules and Org Member agreement, read and agree to the
> > same."
> >
> > For mentors, as Patrick and Karthik are new to the program, we need to
> > invite them first and only after they've accepted the invitation can we
> > add them to the program.
> >
> > Karthik, I was able to get your Gmail address and have sent an invite to
> > you. Could you accept the same after reading through the program rules
> > and member agreement?
> >
> > Patrick, could you kindly share with me your Gmail address so that I could
> > invite you to the program?
> >
>
> Thanks for the quick turnaround all! I've added all of you to the 2024
> program. I hope you're able to access the program page at [1]. Let me know
> if you're facing any issues.
>
> Also, it's official now. Git has been selected as one of the participating
> organizations[2] in GSoC 2024!
>
> Let's look forward towards a summer with great GSoC contributors who
> hopefully become continued contributors to the community :-)
>
> [[ References ]]
>
> [1]:
> https://summerofcode.withgoogle.com/organizations/git/programs/2024/timeline
>
> [2]: https://summerofcode.withgoogle.com/programs/2024/organizations/git
I can access the second link, but the first one is broken for me. First
it claimed that my Google account wasn't connected to GSoC, and after a
reload it stays blank now.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] rebase: make warning less passive aggressive
From: Patrick Steinhardt @ 2024-02-22 8:15 UTC (permalink / raw)
To: Harmen Stoppels via GitGitGadget; +Cc: git, Harmen Stoppels
In-Reply-To: <pull.1669.v2.git.1708537097448.gitgitgadget@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]
On Wed, Feb 21, 2024 at 05:38:17PM +0000, Harmen Stoppels via GitGitGadget wrote:
> From: Harmen Stoppels <me@harmenstoppels.nl>
>
> When you run `git rebase --continue` when no rebase is in progress, git
> outputs `fatal: No rebase in progress?` which is not a question but a
> statement. Make it appear as a statement, and use lowercase to align
> with error message style.
>
> Signed-off-by: Harmen Stoppels <me@harmenstoppels.nl>
Got nothing else to add, this looks good to me. Thanks!
Patrick
> ---
> rebase: make warning less passive aggressive
>
> cc: Patrick Steinhardt ps@pks.im
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1669%2Fhaampie%2Ffix%2Fpassive-agressive-message-v2
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1669/haampie/fix/passive-agressive-message-v2
> Pull-Request: https://github.com/gitgitgadget/git/pull/1669
>
> Range-diff vs v1:
>
> 1: 4dfc578da84 < -: ----------- rebase: make warning less passive aggressive
> -: ----------- > 1: a6f7a3a2477 rebase: make warning less passive aggressive
>
>
> builtin/rebase.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/rebase.c b/builtin/rebase.c
> index 5b086f651a6..6ead9465a42 100644
> --- a/builtin/rebase.c
> +++ b/builtin/rebase.c
> @@ -1254,7 +1254,7 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
> die(_("options '%s' and '%s' cannot be used together"), "--root", "--fork-point");
>
> if (options.action != ACTION_NONE && !in_progress)
> - die(_("No rebase in progress?"));
> + die(_("no rebase in progress"));
>
> if (options.action == ACTION_EDIT_TODO && !is_merge(&options))
> die(_("The --edit-todo action can only be used during "
>
> base-commit: 96c8a0712e569dd2812bf4fb5e72113caf326500
> --
> gitgitgadget
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (Feb 2024, #07; Tue, 20)
From: Patrick Steinhardt @ 2024-02-22 8:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Karthik Nayak, git
In-Reply-To: <xmqqle7drcm5.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]
On Wed, Feb 21, 2024 at 08:44:18AM -0800, Junio C Hamano wrote:
> Karthik Nayak <karthik.188@gmail.com> writes:
>
> >> * kn/for-all-refs (2024-02-12) 6 commits
> >> - for-each-ref: add new option to include root refs
> >> - ref-filter: rename 'FILTER_REFS_ALL' to 'FILTER_REFS_REGULAR'
> >> - refs: introduce `refs_for_each_include_root_refs()`
> >> - refs: extract out `loose_fill_ref_dir_regular_file()`
> >> - refs: introduce `is_pseudoref()` and `is_headref()`
> >> - Merge branch 'ps/reftable-backend' into kn/for-all-refs
> >> (this branch uses ps/reftable-backend.)
> >>
> >> "git for-each-ref" filters its output with prefixes given from the
> >> command line, but it did not honor an empty string to mean "pass
> >> everything", which has been corrected.
> >>
> >> Will merge to 'next'?
> >> source: <20240211183923.131278-1-karthik.188@gmail.com>
> >
> > Let me know if there's something more I could do here.
>
> Hmph, I do not recall what the plan for this thing was. Wasn't it
> ejected from 'next' so that its UI can be rethought? Or did that
> happen already and what is in 'seen' already with a new UI?
>
> Thanks.
This version already has the updated UI with `--include-root-refs`.
There has been some discussion around whether we want to refactor the
refname checking interfaces so that we do not have to introduce the two
new helper functions `is_pseudoref()` and `is_headref()`. But that would
result in a lot of churn, and we thus agreed that it is fine to do that
in a follow up patch series.
I then forgot to have a look at the remaining patches. I can do that
today.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 5/5] for-each-ref: add new option to include root refs
From: Patrick Steinhardt @ 2024-02-22 8:46 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git, gitster, phillip.wood123
In-Reply-To: <20240211183923.131278-6-karthik.188@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 9044 bytes --]
On Sun, Feb 11, 2024 at 07:39:23PM +0100, Karthik Nayak wrote:
> The git-for-each-ref(1) command doesn't provide a way to print root refs
> i.e pseudorefs and HEAD with the regular "refs/" prefixed refs.
>
> This commit adds a new option "--include-root-refs" to
> git-for-each-ref(1). When used this would also print pseudorefs and HEAD
> for the current worktree.
>
> Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
> ---
> Documentation/git-for-each-ref.txt | 5 ++++-
> builtin/for-each-ref.c | 11 ++++++++---
> ref-filter.c | 27 +++++++++++++++++++++++++-
> ref-filter.h | 5 ++++-
> refs/reftable-backend.c | 11 +++++++----
> t/t6302-for-each-ref-filter.sh | 31 ++++++++++++++++++++++++++++++
> 6 files changed, 80 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
> index 3a9ad91b7a..c1dd12b93c 100644
> --- a/Documentation/git-for-each-ref.txt
> +++ b/Documentation/git-for-each-ref.txt
> @@ -10,7 +10,7 @@ SYNOPSIS
> [verse]
> 'git for-each-ref' [--count=<count>] [--shell|--perl|--python|--tcl]
> [(--sort=<key>)...] [--format=<format>]
> - [ --stdin | <pattern>... ]
> + [--include-root-refs] [ --stdin | <pattern>... ]
> [--points-at=<object>]
> [--merged[=<object>]] [--no-merged[=<object>]]
> [--contains[=<object>]] [--no-contains[=<object>]]
> @@ -105,6 +105,9 @@ TAB %(refname)`.
> any excluded pattern(s) are shown. Matching is done using the
> same rules as `<pattern>` above.
>
> +--include-root-refs::
> + List root refs (HEAD and pseudorefs) apart from regular refs.
> +
> FIELD NAMES
> -----------
>
> diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
> index 23d352e371..9ed146dad3 100644
> --- a/builtin/for-each-ref.c
> +++ b/builtin/for-each-ref.c
> @@ -20,10 +20,10 @@ int cmd_for_each_ref(int argc, const char **argv, const char *prefix)
> {
> struct ref_sorting *sorting;
> struct string_list sorting_options = STRING_LIST_INIT_DUP;
> - int icase = 0;
> + int icase = 0, include_root_refs = 0, from_stdin = 0;
> struct ref_filter filter = REF_FILTER_INIT;
> struct ref_format format = REF_FORMAT_INIT;
> - int from_stdin = 0;
> + unsigned int flags = FILTER_REFS_REGULAR;
> struct strvec vec = STRVEC_INIT;
>
> struct option opts[] = {
> @@ -53,6 +53,7 @@ int cmd_for_each_ref(int argc, const char **argv, const char *prefix)
> OPT_NO_CONTAINS(&filter.no_commit, N_("print only refs which don't contain the commit")),
> OPT_BOOL(0, "ignore-case", &icase, N_("sorting and filtering are case insensitive")),
> OPT_BOOL(0, "stdin", &from_stdin, N_("read reference patterns from stdin")),
> + OPT_BOOL(0, "include-root-refs", &include_root_refs, N_("also include HEAD ref and pseudorefs")),
> OPT_END(),
> };
>
> @@ -96,8 +97,12 @@ int cmd_for_each_ref(int argc, const char **argv, const char *prefix)
> filter.name_patterns = argv;
> }
>
> + if (include_root_refs) {
> + flags |= FILTER_REFS_ROOT_REFS;
> + }
Nit: we don't use braces for single-line blocks.
> +
> filter.match_as_path = 1;
> - filter_and_format_refs(&filter, FILTER_REFS_REGULAR, sorting, &format);
> + filter_and_format_refs(&filter, flags, sorting, &format);
>
> ref_filter_clear(&filter);
> ref_sorting_release(sorting);
> diff --git a/ref-filter.c b/ref-filter.c
> index acb960e35c..0e83e29390 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -2628,6 +2628,12 @@ static int for_each_fullref_in_pattern(struct ref_filter *filter,
> each_ref_fn cb,
> void *cb_data)
> {
> + if (filter->kind == FILTER_REFS_KIND_MASK) {
> + /* in this case, we want to print all refs including root refs. */
Nit: s/in/In, as this is a full sentence.
> + return refs_for_each_include_root_refs(get_main_ref_store(the_repository),
> + cb, cb_data);
> + }
> +
> if (!filter->match_as_path) {
> /*
> * in this case, the patterns are applied after
> @@ -2750,6 +2756,9 @@ static int ref_kind_from_refname(const char *refname)
> return ref_kind[i].kind;
> }
>
> + if (is_pseudoref(get_main_ref_store(the_repository), refname))
> + return FILTER_REFS_PSEUDOREFS;
> +
> return FILTER_REFS_OTHERS;
> }
>
> @@ -2781,6 +2790,16 @@ static struct ref_array_item *apply_ref_filter(const char *refname, const struct
>
> /* Obtain the current ref kind from filter_ref_kind() and ignore unwanted refs. */
> kind = filter_ref_kind(filter, refname);
> +
> + /*
> + * When printing HEAD with all other refs, we want to apply the same formatting
> + * rules as the other refs, so we simply ask it to be treated as a pseudoref.
> + */
> + if (filter->kind == FILTER_REFS_KIND_MASK && kind == FILTER_REFS_DETACHED_HEAD)
> + kind = FILTER_REFS_PSEUDOREFS;
I'm not sure why exactly we need to munge the kind here. Would be great
if the comment explained what the actual difference would be.
> + else if (!(kind & filter->kind))
> + return NULL;
> +
> if (!(kind & filter->kind))
> return NULL;
This condition here is duplicated now, isn't it?
Patrick
> @@ -3049,7 +3068,13 @@ static int do_filter_refs(struct ref_filter *filter, unsigned int type, each_ref
> ret = for_each_fullref_in("refs/tags/", fn, cb_data);
> else if (filter->kind & FILTER_REFS_REGULAR)
> ret = for_each_fullref_in_pattern(filter, fn, cb_data);
> - if (!ret && (filter->kind & FILTER_REFS_DETACHED_HEAD))
> +
> + /*
> + * When printing all ref types, HEAD is already included,
> + * so we don't want to print HEAD again.
> + */
> + if (!ret && (filter->kind != FILTER_REFS_KIND_MASK) &&
> + (filter->kind & FILTER_REFS_DETACHED_HEAD))
> head_ref(fn, cb_data);
> }
>
> diff --git a/ref-filter.h b/ref-filter.h
> index 5416936800..0ca28d2bba 100644
> --- a/ref-filter.h
> +++ b/ref-filter.h
> @@ -22,7 +22,10 @@
> #define FILTER_REFS_REGULAR (FILTER_REFS_TAGS | FILTER_REFS_BRANCHES | \
> FILTER_REFS_REMOTES | FILTER_REFS_OTHERS)
> #define FILTER_REFS_DETACHED_HEAD 0x0020
> -#define FILTER_REFS_KIND_MASK (FILTER_REFS_REGULAR | FILTER_REFS_DETACHED_HEAD)
> +#define FILTER_REFS_PSEUDOREFS 0x0040
> +#define FILTER_REFS_ROOT_REFS (FILTER_REFS_DETACHED_HEAD | FILTER_REFS_PSEUDOREFS)
> +#define FILTER_REFS_KIND_MASK (FILTER_REFS_REGULAR | FILTER_REFS_DETACHED_HEAD | \
> + FILTER_REFS_PSEUDOREFS)
>
> struct atom_value;
> struct ref_sorting;
> diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c
> index a14f2ad7f4..c23a516ac2 100644
> --- a/refs/reftable-backend.c
> +++ b/refs/reftable-backend.c
> @@ -364,12 +364,15 @@ static int reftable_ref_iterator_advance(struct ref_iterator *ref_iterator)
> break;
>
> /*
> - * The files backend only lists references contained in
> - * "refs/". We emulate the same behaviour here and thus skip
> - * all references that don't start with this prefix.
> + * The files backend only lists references contained in "refs/" unless
> + * the root refs are to be included. We emulate the same behaviour here.
> */
> - if (!starts_with(iter->ref.refname, "refs/"))
> + if (!starts_with(iter->ref.refname, "refs/") &&
> + !(iter->flags & DO_FOR_EACH_INCLUDE_ROOT_REFS &&
> + (is_pseudoref(&iter->refs->base, iter->ref.refname) ||
> + is_headref(&iter->refs->base, iter->ref.refname)))) {
> continue;
> + }
>
> if (iter->prefix &&
> strncmp(iter->prefix, iter->ref.refname, strlen(iter->prefix))) {
> diff --git a/t/t6302-for-each-ref-filter.sh b/t/t6302-for-each-ref-filter.sh
> index 82f3d1ea0f..948f1bb5f4 100755
> --- a/t/t6302-for-each-ref-filter.sh
> +++ b/t/t6302-for-each-ref-filter.sh
> @@ -31,6 +31,37 @@ test_expect_success 'setup some history and refs' '
> git update-ref refs/odd/spot main
> '
>
> +test_expect_success '--include-root-refs pattern prints pseudorefs' '
> + cat >expect <<-\EOF &&
> + HEAD
> + ORIG_HEAD
> + refs/heads/main
> + refs/heads/side
> + refs/odd/spot
> + refs/tags/annotated-tag
> + refs/tags/doubly-annotated-tag
> + refs/tags/doubly-signed-tag
> + refs/tags/four
> + refs/tags/one
> + refs/tags/signed-tag
> + refs/tags/three
> + refs/tags/two
> + EOF
> + git update-ref ORIG_HEAD main &&
> + git for-each-ref --format="%(refname)" --include-root-refs >actual &&
> + test_cmp expect actual
> +'
> +
> +test_expect_success '--include-root-refs with other patterns' '
> + cat >expect <<-\EOF &&
> + HEAD
> + ORIG_HEAD
> + EOF
> + git update-ref ORIG_HEAD main &&
> + git for-each-ref --format="%(refname)" --include-root-refs "*HEAD" >actual &&
> + test_cmp expect actual
> +'
> +
> test_expect_success 'filtering with --points-at' '
> cat >expect <<-\EOF &&
> refs/heads/main
> --
> 2.43.GIT
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: Git in GSoC 2024
From: Karthik Nayak @ 2024-02-22 8:57 UTC (permalink / raw)
To: Patrick Steinhardt
Cc: Kaartic Sivaraam, Christian Couder, git, Taylor Blau,
Junio C Hamano, Victoria Dye
In-Reply-To: <Zdb8lnUSurutauRa@tanuki>
On Thu, Feb 22, 2024 at 8:49 AM Patrick Steinhardt <ps@pks.im> wrote:
>
> On Thu, Feb 22, 2024 at 10:01:54AM +0530, Kaartic Sivaraam wrote:
> > [1]:
> > https://summerofcode.withgoogle.com/organizations/git/programs/2024/timeline
> >
> > [2]: https://summerofcode.withgoogle.com/programs/2024/organizations/git
>
> I can access the second link, but the first one is broken for me. First
> it claimed that my Google account wasn't connected to GSoC, and after a
> reload it stays blank now.
>
Both links seem to be working now for me.
^ permalink raw reply
* Re: Segfault: git show-branch --reflog refs/pullreqs/1
From: Patrick Steinhardt @ 2024-02-22 9:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Yasushi SHOJI, Denton Liu, Git Mailing List
In-Reply-To: <xmqqv86hogpi.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 2889 bytes --]
On Wed, Feb 21, 2024 at 09:44:09AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > with an empty reflog file (added by that same commit). The code in
> > get_oid_basic() to parse reflogs doesn't suffer from the same bugs: it
> > checks up front that the reflog file exists, it preloads the output oid
> > with the current ref value, and it doesn't look at other fields (like
> > the reflog message).
>
> It is a usability hack to allow foo@{0} to resolve successfully,
> instead of causing a failure, when there is no reflog entries for
> foo, I would think. As to the "show-branch -g", the intent is to
> see the recent evolution of the branch, so I am fine if we do not
> give any output when no reflog entries exist (i.e. "no evolution
> behind the current state---it just is"), or just one entry output
> for "foo@{0}" to say "there is only one recent state".
>
> Even though it may feel wrong to successfully resolve foo@{0} when
> reflog for foo does not exist at the mechanical level (read: the
> implementors of reflog mechanism may find the usability hack a bad
> idea), I suspect at the end-user level it may be closer to what
> people expect out of foo@{0} (i.e. "give me the latest").
Hum, I dunno. I don't really understand what the benefit of this
fallback is. If a user wants to know the latest object ID of the ref
they shouldn't ask for `foo@{0}`, they should ask for `foo`. On the
other hand, if I want to know "What is the latest entry in the ref's
log", I want to ask for `foo@{0}`.
For one, I think that this is adding complexity to the user interface.
If you were to explain this feature to a user who has never encountered
it, you need to now also explain special cases: "It gives you the latest
reflog entry, except when the reflog doesn't exist or is missing, then
we return the object ID of the corresponding ref." This is a lot more
mental overhead than "It gives you the latest reflog entry."
We also have to consider a potential future where we stop deleting
reflogs together with their ref in the "reftable" backend. What do we
return when the reflog is empty and the ref is missing? "It gives you
the latest reflog entry, except when the reflog doesn't exist or is
missing, then we give you the ref except if that is missing, too". It's
getting even harder to explain now.
Another angle to me is scripting. If I really want to get the latest
reflog entry, then I now have to execute two commands. First I have to
check whether the reflog is non-empty, and only then can I ask for the
latest reflog entry. Otherwise, I might not get a reflog entry but the
resolved ref instead. And I wouldn't even know how to check whether the
reflog is non-empty.
So overall, I think the interface is a lot easier to understand and use
correctly if we didn't have this fallback.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] doc: git-rev-parse: enforce command-line description syntax
From: Jean-Noël AVILA @ 2024-02-22 9:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jean-Noël Avila via GitGitGadget, git
In-Reply-To: <xmqqbk89molz.fsf@gitster.g>
On Wednesday, 21 February 2024 23:36:24 CET Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> >> Backticks and single quotes are used indistinctively (by the way,
> >> asciidoctor does not process single quotes as markup) ...
>
> Hmph, it sounds like a bug of asciidoctor we'd need to work around?
>
> In any case, I practiced your "_<placeholder>_" rule on git-add.txt
> and here is how my local HTML rendition of the updated line in the
> first hunk in the attached patch looks like with "AsciiDoc 10.2.0".
>
> https://pasteboard.co/6koO0h0KJAjW.png
>
> The actual HTML for the above part looks like this:
>
> <div class="paragraph"><p>For more details about the
> <em><pathspec></em> syntax, see the <em>pathspec</em> entry
> in <a href="gitglossary.html">gitglossary(7)</a>.</p></div>
>
> In the first hunk, the updated "_<pathspec>_" is enclosed inside an
> <em>..</em> pair, which is made into "font-style: italic" via css,
> while 'pathspec' that remains is already inside <em>..</em>.
>
> By the way, I am getting some typesetting effect from the pair of
> single quotes with AsciiDoctor. Here is the rendition of the same
> part:
>
> https://pasteboard.co/LbDi95G8BNGv.png
>
> The <meta name="generator"> element in the generated HTML claims it
> is "Asciidoctor 2.0.20". The actual HTML for that piece looks like
> this:
>
> <p>For more details about the <em><pathspec></em> syntax,
> see the <em>pathspec</em> entry
> in <a href="gitglossary.html">gitglossary(7)</a>.</p>
>
> So, perhaps we do not have to do a lot of 'word' -> _word_
> replacements, hopefully?
>
Asciidoctor tries to "normify" the asciidoc format (https://asciidoc-wg.eclipse.org/projects/) and pushes for deprecating the 'word' markup which
is a asciidoc.py legacy.
See https://docs.asciidoctor.org/asciidoctor/latest/migrate/asciidoc-py/
#updated-and-deprecated-asciidoc-syntax
In the transition period (which is lasting), they introduce a compatibility
mode with the compat-mode flag in order to support legacy content.
For all I know, asciidoc.py has entered a maintenance stage where it will not
support the evolutions of the standard. Should the Git documentation migrate
to asciidoctor and drop the compat mode is an open question. At least, we
should try to stick as much as possible to the common markup _ for emphasis.
This would have the added benefit of differentiating single quotes from
backticks, because single quotes would completely disappear in the end, except
when a real single quote is needed.
For the migration to "standard" asciidoc, I would also recommend using "="
prefix for titles instead of underlines which require changing two lines when
modifying a title and are a pain for translators in languages with variable
width characters.
> ----- >8 --------- >8 --------- >8 --------- >8 ----
>
> Subject: [PATCH] doc: apply the new placeholder rules to git-add
documentation
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
> index ed44c1cb31..b73071ba47 100644
> --- a/Documentation/git-add.txt
> +++ b/Documentation/git-add.txt
> @@ -63,7 +63,7 @@ OPTIONS
> to ignore removed files; use `--no-all` option if you want
> to add modified or new files but ignore removed ones.
> +
> -For more details about the <pathspec> syntax, see the 'pathspec' entry
> +For more details about the _<pathspec>_ syntax, see the 'pathspec' entry
> in linkgit:gitglossary[7].
>
> -n::
> @@ -119,10 +119,10 @@ apply to the index. See EDITING PATCHES below.
> -u::
> --update::
> Update the index just where it already has an entry matching
> - <pathspec>. This removes as well as modifies index entries to
> + _<pathspec>_. This removes as well as modifies index entries to
> match the working tree, but adds no new files.
> +
> -If no <pathspec> is given when `-u` option is used, all
> +If no _<pathspec>_ is given when `-u` option is used, all
> tracked files in the entire working tree are updated (old versions
> of Git used to limit the update to the current directory and its
> subdirectories).
> @@ -131,11 +131,11 @@ subdirectories).
> --all::
> --no-ignore-removal::
> Update the index not only where the working tree has a file
> - matching <pathspec> but also where the index already has an
> + matching _<pathspec>_ but also where the index already has an
> entry. This adds, modifies, and removes index entries to
> match the working tree.
> +
> -If no <pathspec> is given when `-A` option is used, all
> +If no _<pathspec>_ is given when `-A` option is used, all
> files in the entire working tree are updated (old versions
> of Git used to limit the update to the current directory and its
> subdirectories).
> @@ -145,11 +145,11 @@ subdirectories).
> Update the index by adding new files that are unknown to the
> index and files modified in the working tree, but ignore
> files that have been removed from the working tree. This
> - option is a no-op when no <pathspec> is used.
> + option is a no-op when no _<pathspec>_ is used.
> +
> This option is primarily to help users who are used to older
> -versions of Git, whose "git add <pathspec>..." was a synonym
> -for "git add --no-all <pathspec>...", i.e. ignored removed files.
> +versions of Git, whose "git add _<pathspec>_..." was a synonym
> +for "git add --no-all _<pathspec>_...", i.e. ignored removed files.
>
> -N::
> --intent-to-add::
> @@ -198,8 +198,8 @@ for "git add --no-all <pathspec>...", i.e. ignored
removed files.
> unchanged.
>
> --pathspec-from-file=<file>::
> - Pathspec is passed in `<file>` instead of commandline args. If
> - `<file>` is exactly `-` then standard input is used. Pathspec
> + Pathspec is passed in _<file>_ instead of commandline args. If
> + _<file>_ is exactly `-` then standard input is used. Pathspec
> elements are separated by LF or CR/LF. Pathspec elements can be
> quoted as explained for the configuration variable `core.quotePath`
> (see linkgit:git-config[1]). See also `--pathspec-file-nul` and
>
>
This looks good to me.
^ permalink raw reply
* Re: [PATCH] rebase: make warning less passive aggressive
From: Jean-Noël AVILA @ 2024-02-22 10:01 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michal Suchánek, Harmen Stoppels via GitGitGadget, git,
Harmen Stoppels
In-Reply-To: <xmqq4je1mo5p.fsf@gitster.g>
On Wednesday, 21 February 2024 23:46:10 CET Junio C Hamano wrote:
> Jean-Noël AVILA <jn.avila@free.fr> writes:
>
> > As a translator, I'm less bothered by editing a sentence to remove a
question
> > mark (maybe enforcing a language style and reformulating the sentence by
the
> > way), than by translating again and again similar sentences.
>
> Sure, but if the original in C locale used to be "FOO BAR?" and you
> translated it to "foo bar?" in your language, and then a patch
> updates the string in the source to "FOO BAR", doesn't msgmerge
> notice that the original as a "fuzzy" matching and offer you
> something like
>
> # fuzzy
> msgid "FOO BAR"
> msgstr "foo bar?"
>
> so that all you have to do is to remove '?' anyway?
Yes, it works as expected.
> So I do not
> think you'd need to translate the "FOO BAR" part again and again.
Sorry for not being clear: I don't consider changing a question to an
assertion is translating "again and again". This change is completely entitled
to end up on translators desk, because it involves possibly changing the whole
structure of the sentence.
About "again and again", I was more refering to strings such as "could not
stat '%s'" and then "could not stat file '%s'".
>
> But the above assumes that for your language, the ONLY thing to turn
> such a rhetorical "passive aggressive" question into grammatically
> correct statement of a fact is to remove the question mark. It may
> not be universally true for all languages, and for some language,
> even after msgmerge did its job correctly, you may need to do more
> than just removing the question mark to adjust the remaining "foo
> bar" part.
>
I perfectly agree with you.
Thanks
^ permalink raw reply
* Re: [PATCH v2] rebase: make warning less passive aggressive
From: Kristoffer Haugsbakk @ 2024-02-22 10:53 UTC (permalink / raw)
To: Josh Soref; +Cc: Harmen Stoppels, git
In-Reply-To: <pull.1669.v2.git.1708537097448.gitgitgadget@gmail.com>
On Wed, Feb 21, 2024, at 18:38, Harmen Stoppels via GitGitGadget wrote:
> From: Harmen Stoppels <me@harmenstoppels.nl>
>
> When you run `git rebase --continue` when no rebase is in progress, git
> outputs `fatal: No rebase in progress?` which is not a question but a
> statement. Make it appear as a statement, and use lowercase to align
> with error message style.
>
> Signed-off-by: Harmen Stoppels <me@harmenstoppels.nl>
> ---
I’ve interpreted this error as: I’m not quite sure but it looks like you
are not in the middle of a rebase? Like it can’t be completely
sure. Maybe from a more “primitive” time, implementation-wise?[1] :)
(I waited to make this reply in order to see what others would say. And
apparently there is no need for a hedging/passive aggressive question
mark.)
† 1: 031321c654d (Add --continue and --abort options to git-rebase.,
2006-04-26)
--
Kristoffer Haugsbakk
^ permalink raw reply
* Re: [PATCH] rebase: make warning less passive aggressive
From: Michal Suchánek @ 2024-02-22 11:04 UTC (permalink / raw)
To: Jean-Noël AVILA
Cc: Junio C Hamano, Harmen Stoppels via GitGitGadget, git,
Harmen Stoppels
In-Reply-To: <7633780.EvYhyI6sBW@cayenne>
Hello,
On Thu, Feb 22, 2024 at 11:01:59AM +0100, Jean-Noël AVILA wrote:
> On Wednesday, 21 February 2024 23:46:10 CET Junio C Hamano wrote:
> > Jean-Noël AVILA <jn.avila@free.fr> writes:
> >
> > > As a translator, I'm less bothered by editing a sentence to remove a
> question
> > > mark (maybe enforcing a language style and reformulating the sentence by
> the
> > > way), than by translating again and again similar sentences.
Indeed, the style part is the key here.
The message that is changed here was quite stylistically poorly written
which is why only removing the question mark is correct, and it's why
it's changed in the first place, too.
While this is faithfully reflected in multiple language translations
there is no saying that's the case for all languages, at least basic
understanding of the grammar of the language in question is needed to
verify that.
> > But the above assumes that for your language, the ONLY thing to turn
> > such a rhetorical "passive aggressive" question into grammatically
> > correct statement of a fact is to remove the question mark. It may
> > not be universally true for all languages, and for some language,
> > even after msgmerge did its job correctly, you may need to do more
> > than just removing the question mark to adjust the remaining "foo
> > bar" part.
> >
>
> I perfectly agree with you.
Indeed, and that's why per-language review for such change is needed.
Thanks
Michal
^ 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