* Re: [PATCH v2 0/5] Documentation: updates and a correction around 'ORIG_HEAD'
From: Junio C Hamano @ 2023-01-13 17:56 UTC (permalink / raw)
To: Phillip Wood
Cc: Philippe Blain via GitGitGadget, git, Erik Cervin Edin,
Philippe Blain
In-Reply-To: <ba20039c-19a3-96da-c938-89af67bca791@dunelm.org.uk>
Phillip Wood <phillip.wood123@gmail.com> writes:
> Hi Philippe
>
> On 10/01/2023 13:15, Philippe Blain via GitGitGadget wrote:
>> * added a link to the mailing list thread in the commit message of 5/5.
>> v1: Documentation: updates and a correction around 'ORIG_HEAD'
>> This series' initial motivation was to clear up a confusion that
>> arose in
>> [1] where it was noticed that 'ORIG_HEAD' is not guaranteed to point to the
>> original branch tip at the end of the rebase if 'git reset' is used during
>> the rebase.
>> Patch 5/5 adds a note to 'git rebase's documentation to make that
>> explicit.
>> When taking a look at the existing documentation mentioning 'ORIG_HEAD', I
>> also found an error in an example (patch 1/5), other small inconsistencies
>> (patch 2-3/5), and a potential improvement (patch 4/5).
>
> Thanks for doing this, I think the adding a note to the rebase
> documentation is a good idea given the confusion that's been
> reported. The patches all look great to me apart from patch 4 where I
> share Junio's concerns about the readability and maintenance burden of
> the list of commands. I was surprised to learn that merge also sets
> ORIG_HEAD, thanks for being so thorough.
Thanks for reviewing, and thanks for writing, the patch. Let's
queue and merge it to 'next'.
^ permalink raw reply
* Re: [PATCH] doc: fix non-existing config name
From: Junio C Hamano @ 2023-01-13 17:54 UTC (permalink / raw)
To: muzimuzhi Z; +Cc: Clemens Buchacher, git
In-Reply-To: <CAEg0tHQtf9G0N24Xfe-gvRM1AFaiS_ApcuQ8hZtsZAeMhhVWAQ@mail.gmail.com>
muzimuzhi Z <muzimuzhi@gmail.com> writes:
> Somehow My last mail failed to sent to Clemens Buchacher (drizzd@aon.at):
>
>> 550 5.7.1 <drizzd@aon.at>: Recipient address rejected: mailbox not found
>
> I found two lines about Clemens in `.mailmap` (see below) [1] and
> drizzd@gmx.net was used last time when Clemens mailed to the current
> mailing list in Feb 2019 [2].
>
> Clemens Buchacher <drizzd@gmx.net> <drizzd@aon.at>
> Clemens Buchacher <drizzd@gmx.net> <clemens.buchacher@intel.com>
>
> Thus I added drizzd@gmx.net to cc.
Thanks for the above explanation.
> yukai
Is that your name, or is it "muzimuzhi Z"? Please see and follow
Documentation/SubmittingPatches:[[sign-off]] and [[real-name]]
sections.
The patch, including the proposed log message, looks excellent.
Thanks.
>> Replace non-existent `branch.<name>.fetch` to `remote.<repository>.fetch`, in
>> the first example in `git-fetch` doc, which was introduced in
>> d504f69 (modernize fetch/merge/pull examples, 2009-10-21).
>>
>> Rename placeholder `<name>` to `<repository>`, to be consistent with all other
>> uses in git docs, except that `git-config.txt` uses `remote.<name>.fetch` in
>> its "Variables" section.
>>
>> Also add missing monospace markups.
>>
>> Signed-off-by: muzimuzhi <muzimuzhi@gmail.com>
>> ---
>> Documentation/git-fetch.txt | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
>> index 63d9569..fba66f1 100644
>> --- a/Documentation/git-fetch.txt
>> +++ b/Documentation/git-fetch.txt
>> @@ -251,10 +251,10 @@ EXAMPLES
>> $ git fetch origin
>> ------------------------------------------------
>> +
>> -The above command copies all branches from the remote refs/heads/
>> -namespace and stores them to the local refs/remotes/origin/ namespace,
>> -unless the branch.<name>.fetch option is used to specify a non-default
>> -refspec.
>> +The above command copies all branches from the remote `refs/heads/`
>> +namespace and stores them to the local `refs/remotes/origin/` namespace,
>> +unless the `remote.<repository>.fetch` option is used to specify a
>> +non-default refspec.
>>
>> * Using refspecs explicitly:
>> +
>> --
>> 2.39.0
^ permalink raw reply
* [PATCH] git-prompt: customizable symbols
From: Alessandro via GitGitGadget @ 2023-01-13 17:53 UTC (permalink / raw)
To: git; +Cc: Alessandro, Alessandro
From: Alessandro <alezini94@hotmail.it>
Add the possibility to customize git-prompt symbols by adding a bunch of
additional variables. The variables default to the original symbol.
Signed-off-by: Alessandro Zini <alezini94@hotmail.it>
---
git-prompt: customizable symbols
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1433%2Faleeraser%2Ffeat%2Fcustomize-git-prompt-symbols-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1433/aleeraser/feat/customize-git-prompt-symbols-v1
Pull-Request: https://github.com/git/git/pull/1433
contrib/completion/git-prompt.sh | 39 ++++++++++++++++++++------------
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 57972c2845c..d29209f0cef 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -39,25 +39,31 @@
# unstaged (*) and staged (+) changes will be shown next to the branch
# name. You can configure this per-repository with the
# bash.showDirtyState variable, which defaults to true once
-# GIT_PS1_SHOWDIRTYSTATE is enabled.
+# GIT_PS1_SHOWDIRTYSTATE is enabled. Variables GIT_PS1_UNSTAGED_SYMBOL
+# and GIT_PS1_STAGED_SYMBOL can be used to change the shown symbol.
#
# You can also see if currently something is stashed, by setting
# GIT_PS1_SHOWSTASHSTATE to a nonempty value. If something is stashed,
-# then a '$' will be shown next to the branch name.
+# then a '$' will be shown next to the branch name. Variable
+# GIT_PS1_STASH_SYMBOL can be used to change the shown symbol.
#
# If you would like to see if there're untracked files, then you can set
# GIT_PS1_SHOWUNTRACKEDFILES to a nonempty value. If there're untracked
# files, then a '%' will be shown next to the branch name. You can
# configure this per-repository with the bash.showUntrackedFiles
# variable, which defaults to true once GIT_PS1_SHOWUNTRACKEDFILES is
-# enabled.
+# enabled. Variable GIT_PS1_UNTRACKED_SYMBOL can be used to change the
+# shown symbol.
#
# If you would like to see the difference between HEAD and its upstream,
# set GIT_PS1_SHOWUPSTREAM="auto". A "<" indicates you are behind, ">"
# indicates you are ahead, "<>" indicates you have diverged and "="
-# indicates that there is no difference. You can further control
-# behaviour by setting GIT_PS1_SHOWUPSTREAM to a space-separated list
-# of values:
+# indicates that there is no difference. Symbols can be configured by
+# setting variables GIT_PS1_UPSTREAM_NOT_PRESENT_SYMBOL,
+# GIT_PS1_UPSTREAM_EQUAL_SYMBOL, GIT_PS1_UPSTREAM_AHEAD_SYMBOL,
+# GIT_PS1_UPSTREAM_BEHIND_SYMBOL, GIT_PS1_UPSTREAM_DIVERGED_SYMBOL
+# You can further control behaviour by setting GIT_PS1_SHOWUPSTREAM to a
+# space-separated list of values:
#
# verbose show number of commits ahead/behind (+/-) upstream
# name if verbose, then also show the upstream abbrev name
@@ -208,15 +214,15 @@ __git_ps1_show_upstream ()
if [[ -z "$verbose" ]]; then
case "$count" in
"") # no upstream
- p="" ;;
+ p="${GIT_PS1_UPSTREAM_NOT_PRESENT_SYMBOL-}" ;;
"0 0") # equal to upstream
- p="=" ;;
+ p="${GIT_PS1_UPSTREAM_EQUAL_SYMBOL-"="}" ;;
"0 "*) # ahead of upstream
- p=">" ;;
+ p="${GIT_PS1_UPSTREAM_AHEAD_SYMBOL-">"}" ;;
*" 0") # behind upstream
- p="<" ;;
+ p="${GIT_PS1_UPSTREAM_BEHIND_SYMBOL-"<"}" ;;
*) # diverged from upstream
- p="<>" ;;
+ p="${GIT_PS1_UPSTREAM_DIVERGED_SYMBOL-"<>"}" ;;
esac
else # verbose, set upstream instead of p
case "$count" in
@@ -537,8 +543,8 @@ __git_ps1 ()
if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ] &&
[ "$(git config --bool bash.showDirtyState)" != "false" ]
then
- git diff --no-ext-diff --quiet || w="*"
- git diff --no-ext-diff --cached --quiet || i="+"
+ git diff --no-ext-diff --quiet || w="${GIT_PS1_UNSTAGED_SYMBOL-"*"}"
+ git diff --no-ext-diff --cached --quiet || i="${GIT_PS1_STAGED_SYMBOL-"+"}"
if [ -z "$short_sha" ] && [ -z "$i" ]; then
i="#"
fi
@@ -546,14 +552,17 @@ __git_ps1 ()
if [ -n "${GIT_PS1_SHOWSTASHSTATE-}" ] &&
git rev-parse --verify --quiet refs/stash >/dev/null
then
- s="$"
+ s="${GIT_PS1_STASH_SYMBOL-"$"}"
fi
if [ -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" ] &&
[ "$(git config --bool bash.showUntrackedFiles)" != "false" ] &&
git ls-files --others --exclude-standard --directory --no-empty-directory --error-unmatch -- ':/*' >/dev/null 2>/dev/null
then
- u="%${ZSH_VERSION+%}"
+ u="${GIT_PS1_UNTRACKED_SYMBOL-"%"}"
+ if [ -n "$ZSH_VERSION" ] && [ "$u" = "%" ]; then
+ u="%%"
+ fi
fi
if [ -n "${GIT_PS1_COMPRESSSPARSESTATE-}" ] &&
base-commit: a38d39a4c50d1275833aba54c4dbdfce9e2e9ca1
--
gitgitgadget
^ permalink raw reply related
* Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1
From: Philip Oakley @ 2023-01-13 17:44 UTC (permalink / raw)
To: rsbecker, 'Hans Petter Selasky', git
In-Reply-To: <009701d9275a$678416b0$368c4410$@nexbridge.com>
On 13/01/2023 14:21, rsbecker@nexbridge.com wrote:
> On January 13, 2023 8:40 AM, Hans Petter Selasky wrote:
>> On 1/13/23 14:30, Konstantin Khomoutov wrote:
>>> On Fri, Jan 13, 2023 at 01:59:44PM +0100, Hans Petter Selasky wrote:
>>>
>>>> Currently GIT only supports cryptographic hashes for its commit tags.
>>> [...]
>>>
>>> https://github.com/git/git/blob/9bf691b78cf906751e65d65ba0c6ffdcd9a5a1
>>> 2c/Documentation/technical/hash-function-transition.txt
>>>
>>> It's not clear why are you referring to Gitorious in your mail's
>>> subject and then talk about Git.
>>>
>> Hi,
>>
>> I thought that Git was short for Gitorious? My bad.
>>
>> The document you refer to really highlights my concerns, that a strong
>> cryptographic hash algorithm is the highway to hell.
>>
>> Do _not_ use a cryptographic hash for Git. Use plain good old CRC hashes.
>>
>> Just imagine the consequences of finding child porn inside a 10-year old firmware
>> binary blob in the Linux kernel. Will you just ignore it, or will you fix it?
>>
>> That's why I say, that it must be possible to forge the hashes by default.
> I do not understand the goal of this request.
I'd agree about the core need for 'absolute' integrity checking.
However we have been here before, but without a way forward.
It was the "Subject: [TOPIC 3/17] Obliterate" at Git Contributor Summit,
Los Angeles (April 5, 2020).
https://lore.kernel.org/git/5B2FEA46-A12F-4DE7-A184-E8856EF66248@jramsay.com.au/
Discussion at
https://docs.google.com/document/d/15a_MPnKaEPbC92a4jhprlHvkyirDh2CtTtgOxNbnIbA/edit#heading=h.wljwyo3r1m6l
The core need I think HPS is referring to is that need to 'obliterate'
some blob (which contains the en-mass data), and perhaps some trees,
commits and tags, which may also hold objectionable meta data, at least
from reference repositories, and at the same time authenticate (if
that's the right term) the list of such obliterated objects.
It will be a difficult task to carefully cut the fog of misdirection and
scares in this arena.
It's one of those problem statements whose answer is "42".
> If it is possible to forge hashes, then nothing in a git repository can ever be trusted. Signed content will no longer be verifiable. The whole Merkel Tree representing the commit history becomes easily corruptible by hackers and no upstream remote repository can ever be trusted - or someone's own if someone targets a repo with malware that rewrites hashes. Imagine a scenario when malware replaces a blob in a repo and then forges the hash to pretend that the replacement never occurred. Using git as a supply chain audit trail becomes impossible. This is a potential vector for ransomware invading the git ecosystem. This seems like a really fatal path to take for the product.
The supply chain audit is (would be) a real problem if the presence of a
specific hash is a punishable criminal offence. I suspect it already is
in some jurisdictions.
>
> The advantage of how git functions is that it is possible to mirror or clone repositories, protecting from hardware errors. Repositories exist in distributed form, so there may be hundreds or thousands of copies in case someone's copy is corrupted by a disk or memory write error - so that takes hash reconstruction out of the requirement set. If the git architecture was based on a central repository model only, then this might be a reasonable request, but that is not how git works.
The law works in mysterious ways it's wonderful ways to demonstrate ;-)
Possession of certain artefacts can be a problem, so it is something
that is worth careful consideration. We shouldn't let the 'distribution
of criminal artefacts' be something 'guaranteed' by Git, despite careful
users.
> If, for instance, a main GitHub repo is somehow corrupted, it can be repaired by a push --force or a clone from a different instance.
>
> Unless I am missing your point.
> --Randall
>
The forced replacement of 'redacted' material is already a problem in
other domains. We should be able to manage a redaction list for a
repository that needs it.
All that said, CRC isn't any sort of solution!
--
Philip
^ permalink raw reply
* Re: [PATCH] object-file: fix indent-with-space
From: Junio C Hamano @ 2023-01-13 17:40 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Jeff King, git, Jonathan Tan
In-Reply-To: <230112.864jsv20r2.gmgdl@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> diff --git a/object-file.c b/object-file.c
>> index 80b08fc389..ce9efae994 100644
>> --- a/object-file.c
>> +++ b/object-file.c
>> @@ -1708,7 +1708,7 @@ void *repo_read_object_file(struct repository *r,
>> oi.sizep = size;
>> oi.contentp = &data;
>> if (oid_object_info_extended(r, oid, &oi, flags))
>> - return NULL;
>> + return NULL;
>>
>> return data;
>> }
Thanks, both, for being extra careful.
> Thanks, I didn't notice (assuming it was too soon, it being less than a
> week) that it was in "next" already. This change LGTM, thanks!
It would be surprising if an ordinary topic goes to 'master' without
spending a week in 'next', but it is something I aim to merge a
reasonably well-done topic down to 'next' from 'seen' with minimum
amount of time. Here minimum usually means 1 wallclock day, just to
catch silly typos, if the patches are reviewed adequately on list by
folks (or possibly by me).
Thanks.
^ permalink raw reply
* Re: [PATCH v8 0/4] worktree: Support `--orphan` when creating new worktrees
From: Junio C Hamano @ 2023-01-13 17:34 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Jacob Abel, git, Eric Sunshine, Phillip Wood, Rubén Justo,
Taylor Blau, rsbecker
In-Reply-To: <230109.86eds31plo.gmgdl@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> I've looked this & previous iterations over carefully, and this now
> looks good to me. Thanks for sticking with this so long.
>
> For what it's worth (if Junio would like to add it):
>
> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Thanks, but Phillip's point of -B/-b deserves consideration, I would
say. It seems that the required change is just a syntax sugar
without having to change anything deeper?
^ permalink raw reply
* Re: [PATCH v8 3/4] worktree add: add --orphan flag
From: Junio C Hamano @ 2023-01-13 17:32 UTC (permalink / raw)
To: Phillip Wood
Cc: Jacob Abel, git, Ævar Arnfjörð Bjarmason,
Eric Sunshine, Rubén Justo, Taylor Blau, rsbecker
In-Reply-To: <e5aadd5d-9b85-4dc9-e9f7-117892b4b283@dunelm.org.uk>
Phillip Wood <phillip.wood123@gmail.com> writes:
>> % git -C bar.git worktree add --orphan main main/
>
> 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
Good point. I am not sure if it is too late, though.
Thanks.
^ permalink raw reply
* Re: BUG: git grep behave oddly with alternatives
From: René Scharfe @ 2023-01-13 17:24 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason, Jeff King
Cc: Marco Nenciarini, git, Junio C Hamano
In-Reply-To: <230113.86ilhazved.gmgdl@evledraar.gmail.com>
Am 13.01.23 um 09:28 schrieb Ævar Arnfjörð Bjarmason:
>
> There's a couple of ways out of this that I don't see in this thread:
>
> - Declare it not a problem: We have -G, -E and -P to map to BRE, ERE and
> PCRE. One view is to say the first two must match POSIX, another is
> tha whatever the platform thinks they should do is how they should
> act.
I like that and it was my first reaction -- alternation is a
non-standard extension to BREs. But we supported it explicitly since
3632cfc248 (Use compatibility regex library for OSX/Darwin, 2008-09-07),
so not having it anymore is a regression that we should fix, I think.
> Of course that makes git regex invocations "unportable", but it might
> be acceptable. People can always use PCRE if they want "portability".
>
> - Just mandate PCRE for Mac OS, then map -E to -P. We could do this with
> the pcre2convert() API and PCRE2_CONVERT_POSIX_EXTENDED flag,
> i.e. PCRE's own "translate this to ERE".
>
> But Perl/PCRE syntax is already a superset of ERE syntax, minus things
> like (*VERB), (?: etc., which people are unlikely to write without
> intending to get the PCRE semantics.
PCRE2_CONVERT_POSIX_EXTENDED is a flag for pcre2_pattern_convert(),
which allows converting an ERE into a PCRE2 regex
(https://pcre.org/current/doc/html/pcre2convert.html). So this feature
allows using PCRE for every kind of regexes, right?
There may be feature differences for EREs between libc on macOS, glibc
and/or GAWK, but I'm not aware of any complaints so far. So I currently
don't see the need for that.
René
^ permalink raw reply
* Re: BUG: git grep behave oddly with alternatives
From: Junio C Hamano @ 2023-01-13 17:19 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Jeff King, René Scharfe, Marco Nenciarini, git
In-Reply-To: <230113.86ilhazved.gmgdl@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> On Thu, Jan 12 2023, Jeff King wrote:
>
>> So it does seem like all bets are off for what people can and should
>> expect here. Which isn't to say we should make things worse. I mostly
>> wondered if REG_ENHANCED might take us closer to what glibc was doing by
>> default, but it doesn't seem like it.
I thought that René's "Use enhanced only when doing BRE" was fairly
focused, but I am very tempted to accept ...
> There's a couple of ways out of this that I don't see in this thread:
>
> - Declare it not a problem: We have -G, -E and -P to map to BRE, ERE and
> PCRE. One view is to say the first two must match POSIX, another is
> tha whatever the platform thinks they should do is how they should
> act.
... this view. The story "BRE and ERE work via what system
libraries provide, and 'git grep' matches what system grep' does" is
an easy to understand view.
> - Just mandate PCRE for Mac OS, then map -E to -P. We could do this with
> the pcre2convert() API and PCRE2_CONVERT_POSIX_EXTENDED flag,
> i.e. PCRE's own "translate this to ERE".
Presumably this is to ensure -E works identically everywhere? If
so, then we should do that everywhere, not just on macOS. But again
it makes "git grep -E" slightly incompatible with "grep" on systems
(including macOS), so...
^ permalink raw reply
* Re: [PATCH] ls-files: add %(skipworktree) atom to format option
From: ZheNing Hu @ 2023-01-13 17:07 UTC (permalink / raw)
To: Elijah Newren
Cc: Junio C Hamano, ZheNing Hu via GitGitGadget, git,
Ævar Arnfjörð Bjarmason, Derrick Stolee,
Victoria Dye, Nguyễn Thái Ngọc Duy
In-Reply-To: <CABPp-BEvK7MFws9=XMfghjo8PgHL6nkiFKmYBiG+218809T2Pw@mail.gmail.com>
Elijah Newren <newren@gmail.com> 于2023年1月13日周五 12:44写道：
>
> On Thu, Jan 12, 2023 at 11:58 AM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > Elijah Newren <newren@gmail.com> writes:
> >
> > > Given my above comments, I personally don't buy this as justification
> > > for adding a new way of reporting on the skip-worktree bit. It may
> > > still make sense to add this feature or something like it, but I
> > > personally think it deserves separate justification from "`ls-files
> > > -t` is semi-deprecated".
> > > ...
> > > To be honest, I don't yet see any compelling reason to use this new
> > > option. Even if this patch is accepted, I'd just continue using "git
> > > ls-files -t" (both directly and in scripts) in preference to this.
> > > However, you have inspired me to try to fix up the ls-files
> > > documentation and remove the "semi-deprecated" label for the -t
> > > option.
> >
> > Thanks. I think that would be the better way forward between the
> > two (i.e. adding this one-shot new feature vs resurrecting -t).
>
> Submitted over here:
> https://lore.kernel.org/git/pull.1463.git.1673584914.gitgitgadget@gmail.com/
Thanks, I will check them later.
^ permalink raw reply
* Re: [PATCH] ls-files: add %(skipworktree) atom to format option
From: ZheNing Hu @ 2023-01-13 16:59 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: ZheNing Hu via GitGitGadget, git, Junio C Hamano, Derrick Stolee,
Victoria Dye, Elijah Newren,
Nguyễn Thái Ngọc Duy
In-Reply-To: <230112.86tu0w12kc.gmgdl@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> 于2023年1月12日周四 18:15写道：
>
>
> On Wed, Jan 11 2023, ZheNing Hu via GitGitGadget wrote:
>
> > From: ZheNing Hu <adlternative@gmail.com>
> >
> > Because sometimes we want to check if the files in the
> > index match the sparse specification by using
> > `git ls-files -t`, but `-t` option have semi-deprecated,
> >
> > So introduce "%(skipworktree)" atom to git ls-files
> > `--format` option. When we use this option, if the file
> > match the sparse specification and removed from working
> > tree, it will output "yes", othewise, output "no".
>
> Your code says "true" and "false", not "yes" or "no". Which is it ?:)
>
true/false. This is a typo.
> More generally it's unfortanute that we don't support the ref-filter.c
> formats more generally, then we could just make this 1 or the empty
> string, and you'd do:
>
> %(if)%(skipworktree)%(then)true%(else)false%(end)
>
> Now, I don't think your change needs to be blocked by generalizing that
> if/else stuff in ref-filter, that would probably be some thousand-line
> series if we're lucky, even though it's a good eventual goal.
>
Aha, if we were to introduce %(if) %(else) in the ref-filter I'm sure that
would be a very complicated situation.
> But I feel strongly that you should not pick "true", or "false", or
> "yes" or "no", but rather "1" or "", here, as doing so will be
> future-proof when it comes to this format being compatible with using
> the ref-filter.c conditional support.
> >
Good point.
> > Signed-off-by: ZheNing Hu <adlternative@gmail.com>
> > ---
> > ls-files: add %(skipworktree) atom to format option
> >
> > git ls-files -t is semi-deprecated, but in face we need to use -t option
> > to check if a file in the index match the sparse specification.
> >
> > So I think this feature can be migrated to git ls-files --format, add a
> > %(skipworktree) atom to indicate whether the file in the index match the
> > sparse specification and is removed from the working tree.
> >
> > v1: add %(skipworktree) atom to git ls-files format option.
> >
> > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1458%2Fadlternative%2Fzh%2Fls-file-format-skipworktree-v1
> > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1458/adlternative/zh/ls-file-format-skipworktree-v1
> > Pull-Request: https://github.com/gitgitgadget/git/pull/1458
> >
> > Documentation/git-ls-files.txt | 6 ++++++
> > builtin/ls-files.c | 3 +++
> > t/t3013-ls-files-format.sh | 22 ++++++++++++++++++++++
> > 3 files changed, 31 insertions(+)
> >
> > diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> > index 440043cdb8e..0e50307121d 100644
> > --- a/Documentation/git-ls-files.txt
> > +++ b/Documentation/git-ls-files.txt
> > @@ -260,6 +260,12 @@ eolattr::
> > that applies to the path.
> > path::
> > The pathname of the file which is recorded in the index.
> > +skipworktree::
> > + If the file in the index marked with SKIP_WORKTREE bit.
> > + It means the file do not match the sparse specification
> > + and removed from working tree.
> > + See link:technical/sparse-checkout.txt[sparse-checkout]
> > + for more information.
>
> I likewise think this won't need to be blocked, but this is a sign that
> we should probably move these to the main doc namespace. See 1e2320161d2
> (docs: move http-protocol docs to man section 5, 2022-08-04) (and
> commits before that) for prior art.
>
> But what we should fix here is that this ling is wrong, as you can see
> in that commit we need to link to the HTML docs for these (confusing as
> that is).
>
> Or (and I didn't check) if we never generate the *.html either for this
> particular one this link will always be broken. I.e. we won't install
> this, nor the HTML docs.
Yeah, you should be right: there may be a problem with the link here,
maybe this needs a patch to migrate technical/sparse-checkout.txt.
Thanks,
ZheNing Hu
^ permalink raw reply
* Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1
From: Hans Petter Selasky @ 2023-01-13 16:51 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: rsbecker, git
In-Reply-To: <20230113164953.o63hu5pgetci4sbb@meerkat.local>
On 1/13/23 17:49, Konstantin Ryabitsev wrote:
>> It's two different world views.
> Indeed, werenotalike.gif 😄
OK, I have no problem about that.
Thanks for the discussion.
--HPS
^ permalink raw reply
* Re: [PATCH] ls-files: add %(skipworktree) atom to format option
From: ZheNing Hu @ 2023-01-13 16:50 UTC (permalink / raw)
To: Elijah Newren
Cc: ZheNing Hu via GitGitGadget, git,
Ævar Arnfjörð Bjarmason, Junio C Hamano,
Derrick Stolee, Victoria Dye,
Nguyễn Thái Ngọc Duy
In-Reply-To: <CABPp-BGsD=6PiJtnsuYPsiZJ1rm2X8yTeu-YeP4q5uu5UDw2og@mail.gmail.com>
Elijah Newren <newren@gmail.com> 于2023年1月12日周四 18:00写道：
>
> On Wed, Jan 11, 2023 at 7:42 AM ZheNing Hu via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
> >
> > From: ZheNing Hu <adlternative@gmail.com>
> >
> > Because sometimes we want to check if the files in the
> > index match the sparse specification by using
> > `git ls-files -t`, but `-t` option have semi-deprecated,
>
> Where `semi-deprecated` was explicitly "suggest other functionality in
> preference, but do not ever remove"[1]. The "suggest other
> functionality in preference" for "ls-files -t" came about because
> people got confused about staged files which have (a) no unstaged
> changes, vs. (b) unstaged content changes, vs. (c) unstaged deletion
> of the file. Such users accidentally presumed that "H" (defined
> simply as "cached") should only refer to class (a) when it refers to
> the fact that the file is tracked (and not conflicted) and thus refers
> to any of (a), (b), and (c)[2]. (I wonder if changing the definition
> of "H" in the manual from "cached" to "tracked-and-not-conflicted"
> would fix this confusion.) In contrast, comparing tracked vs.
> not-tracked-because-skip-worktree files, the distinction between "H"
> and "S" makes lots of sense and naturally you want "H" to represent
> all 3 of (a), (b), and (c). So, for the skip-worktree bit usecase,
> "ls-files -t" doesn't cause the same confusion. (Perhaps the fact
> that we have a tri-state of "M" (unmerged) vs "S" (skip-worktree) vs.
> "H" (all other tracked files) could cause minor confusion, but in
> practice the possibility of "M" just hasn't seemed to have caused
> issues for sparse-checkout users or scripts.)
>
OK, I probably understand that the '-t' "semi-deprecated" was caused
by the confusion of the 'H' semantics.
> Further, since sparse-checkouts and monorepos really started taking
> off 4-5 years ago, "git ls-files -t" has been used *heavily* (but
> mostly by low-level script things rather than user-facing UI). If we
> wanted to come up with a better place to report on the skip-worktree
> bit and have scripts rely on that, we probably should have made such a
> change back then...if not another 8-9 years earlier. At this point,
> "ls-files -t" simply cannot be removed, even if we wanted to.
>
Ah, It seems we can't go back so far :)
> [1] As per this quote from 5bc0e247c4 ("Document ls-files -t as
> semi-obsolete.", 2010-07-28):
> "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.
> [2] https://lore.kernel.org/git/fcaeb9bf0908190204h31bc839ai39972a251040d449@mail.gmail.com/
> (a.k.a. gmane:126516 from the commit message referenced above)
>
It was good to discover that I had misunderstood the point:
"semi-obsolete" is not git want to remove `-t`.
> > So introduce "%(skipworktree)" atom to git ls-files
> > `--format` option.
>
> Given my above comments, I personally don't buy this as justification
> for adding a new way of reporting on the skip-worktree bit. It may
> still make sense to add this feature or something like it, but I
> personally think it deserves separate justification from "`ls-files
> -t` is semi-deprecated".
>
Agree now.
> (Others, of course, may disagree with me, but if this is the only
> justification for this change, then I'm more likely to want to fix the
> ls-files manual to remove the "semi-deprecated" notice and fix the
> definition of "H" to be less misleading than to make a change like
> this.)
>
> > When we use this option, if the file
> > match the sparse specification and removed from working
> > tree...
>
> The "and removed from working tree" portion of this sentence is
> superfluous. (And actually makes it harder to understand, I had to
> try to think through a bunch of cases to try to figure out why you
> might be trying to add some extra qualifier.)
>
I just quoted the definition of SKIP_WORKTREE from
Documentation/technical/sparse-checkout.txt:
SKIP_WORKTREE: When tracked files do not match the sparse specification and
are removed from the working tree, the file in the index is marked
with a SKIP_WORKTREE bit.
> > ...it will output "yes", othewise, output "no".
>
> typo in "otherwise".
>
> Also, your commit message claims output different from what your code
> below implements and what your testcase shows. ("yes"/"no" vs.
> "true"/"false")
>
Yeah, I would have said "true"/"false".
> > Signed-off-by: ZheNing Hu <adlternative@gmail.com>
> [...]
> > diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> > index 440043cdb8e..0e50307121d 100644
> > --- a/Documentation/git-ls-files.txt
> > +++ b/Documentation/git-ls-files.txt
> > @@ -260,6 +260,12 @@ eolattr::
> > that applies to the path.
> > path::
> > The pathname of the file which is recorded in the index.
> > +skipworktree::
> > + If the file in the index marked with SKIP_WORKTREE bit.
> > + It means the file do not match the sparse specification
> > + and removed from working tree.
> > + See link:technical/sparse-checkout.txt[sparse-checkout]
> > + for more information.
>
> Should the actual wording be included here? (i.e. "yes"/"no",
> "true"/"false", or whatever you end up using)?
>
Yes, it will be better to mention its output.
> > EXCLUDE PATTERNS
> > ----------------
> > diff --git a/builtin/ls-files.c b/builtin/ls-files.c
> > index a03b559ecaa..d1a27f28f01 100644
> > --- a/builtin/ls-files.c
> > +++ b/builtin/ls-files.c
> > @@ -280,6 +280,9 @@ static size_t expand_show_index(struct strbuf *sb, const char *start,
> > data->pathname));
> > else if (skip_prefix(start, "(path)", &p))
> > write_name_to_buf(sb, data->pathname);
> > + else if (skip_prefix(start, "(skipworktree)", &p))
> > + strbuf_addstr(sb, ce_skip_worktree(data->ce) ?
> > + "true" : "false");
> > else
> > die(_("bad ls-files format: %%%.*s"), (int)len, start);
> >
> > diff --git a/t/t3013-ls-files-format.sh b/t/t3013-ls-files-format.sh
> > index efb7450bf1e..ac8b865c275 100755
> > --- a/t/t3013-ls-files-format.sh
> > +++ b/t/t3013-ls-files-format.sh
> > @@ -92,4 +92,26 @@ test_expect_success 'git ls-files --format with --debug' '
> > test_cmp expect actual
> > '
> >
> > +test_expect_success 'git ls-files --format with skipworktree' '
>
> Should probably add a
> test_when_finished "git sparse-checkout disable" &&
> at the beginning of this test, otherwise you are potentially causing
> confusion to future developers who try to add additional testcases to
> this file.
>
Agree.
> > + mkdir dir1 dir2 &&
> > + echo "file1" >dir1/file1.txt &&
> > + echo "file2" >dir2/file2.txt &&
> > + git add dir1 dir2 &&
> > + git commit -m skipworktree &&
> > + git sparse-checkout set dir1 &&
> > + git ls-files --format="%(path) %(skipworktree)" >actual &&
> > + cat >expect <<-\EOF &&
> > + dir1/file1.txt false
> > + dir2/file2.txt true
> > + o1.txt false
> > + o2.txt false
> > + o3.txt false
> > + o4.txt false
> > + o5.txt false
> > + o6.txt false
> > + o7.txt false
> > + EOF
> > + test_cmp expect actual
> > +'
>
> To be honest, I don't yet see any compelling reason to use this new
> option. Even if this patch is accepted, I'd just continue using "git
> ls-files -t" (both directly and in scripts) in preference to this.
> However, you have inspired me to try to fix up the ls-files
> documentation and remove the "semi-deprecated" label for the -t
> option. Patches over here:
> https://github.com/gitgitgadget/git/pull/1463 ; I'll submit them in
> the next few days.
To be honest, right now I think %(skipworktree) just refines the
--format option's ability to read the index entry SKIP_WORKTREE
flag bits. It is probably still worth keeping.
Thanks,
ZheNing Hu
^ permalink raw reply
* Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1
From: Konstantin Ryabitsev @ 2023-01-13 16:49 UTC (permalink / raw)
To: Hans Petter Selasky; +Cc: rsbecker, git
In-Reply-To: <7a51b925-cb0a-4b48-fc14-171006f73298@selasky.org>
On Fri, Jan 13, 2023 at 05:44:03PM +0100, Hans Petter Selasky wrote:
> By using a cryptographic hash algorithm, the goal is to avoid tampering you
> say, like tampering on the internet, ISP, cache node and so on. To me that's
> clearly a zero-trust thought. You don't trust the guy(s) that put down the
> infrastructure, neither those that provide that local cache for the GIT
> repository, only the master repository. SHA-1 gives a certain confidence,
> that if you checkout XXXXXXX, then you get a likely expected result with
> reduced possibility of tampering.
>
> Anyone could intercept a CRC protected blob and re-compute the hash and send
> it on. But not a SHA-1 one.
>
> I on the other hand trust the guys that put down the internet and are
> providing the cache nodes for GIT.
I admit, I never trust the "guys who put down the internet," so that's a very
scary scenario to me (and I would say to pretty much everyone else on this
list).
> It's two different world views.
Indeed, werenotalike.gif :)
-K
^ permalink raw reply
* Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1
From: Hans Petter Selasky @ 2023-01-13 16:45 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: rsbecker, git
In-Reply-To: <20230113164131.swif4buln2py7tyl@meerkat.local>
On 1/13/23 17:41, Konstantin Ryabitsev wrote:
> It doesn't matter how it works behind the scenes as long as the produced hash
> is not unique (and CRC gives you no assurance of being unique). Git is built
> on the concept that every object has a unique hash. If this is no longer true,
> then it's literally no longer git, but is something else.
That's why I say you need a fixup field, in case of collisions. CRC is
used plenty all over the place and has good entropy.
--HPS
^ permalink raw reply
* Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1
From: Hans Petter Selasky @ 2023-01-13 16:44 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: rsbecker, git
In-Reply-To: <20230113163619.4ab5oyqyjrthxrwv@meerkat.local>
On 1/13/23 17:36, Konstantin Ryabitsev wrote:
> I'm not sure what you mean here, but git is certainly not zero-trust. When you
> clone linux.git from git.kernel.org, you're very much trusting that:
>
> - I (or members of my team) didn't mess with the repository
> - Linus (or someone who hacked his laptop) didn't mess with the repository
>
> Git is tamper-evident, not tamper-proof, so by definition it cannot be
> zero-trust.
Hi,
By using a cryptographic hash algorithm, the goal is to avoid tampering
you say, like tampering on the internet, ISP, cache node and so on. To
me that's clearly a zero-trust thought. You don't trust the guy(s) that
put down the infrastructure, neither those that provide that local cache
for the GIT repository, only the master repository. SHA-1 gives a
certain confidence, that if you checkout XXXXXXX, then you get a likely
expected result with reduced possibility of tampering.
Anyone could intercept a CRC protected blob and re-compute the hash and
send it on. But not a SHA-1 one.
I on the other hand trust the guys that put down the internet and are
providing the cache nodes for GIT.
It's two different world views.
--HPS
^ permalink raw reply
* Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1
From: Konstantin Ryabitsev @ 2023-01-13 16:41 UTC (permalink / raw)
To: Hans Petter Selasky; +Cc: rsbecker, git
In-Reply-To: <038b4ea4-2a10-9b5a-14e4-e987a68e93b0@selasky.org>
On Fri, Jan 13, 2023 at 05:35:57PM +0100, Hans Petter Selasky wrote:
> > Not to discourage you, but you seem to be making statements without a good
> > understanding of how git works. If there is a history rewrite (even one that
> > for some reason goes back millions of commits) all hash calculations will
> > happen exactly once -- on the system of the person who's rewriting the
> > history. After they push it, it's just a bunch of objects that everyone else
> > merely downloads.
>
> If you used CRC, you would not need that, because CRC calculations are
> "concatenatable", while SHA-1's are not. CRC would just need the first and
> the last hash, and then you would apply the "difference".
It doesn't matter how it works behind the scenes as long as the produced hash
is not unique (and CRC gives you no assurance of being unique). Git is built
on the concept that every object has a unique hash. If this is no longer true,
then it's literally no longer git, but is something else.
Since we're discussing this on the git list, it's not really a discussion
worth having here.
-K
^ permalink raw reply
* Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1
From: Konstantin Ryabitsev @ 2023-01-13 16:36 UTC (permalink / raw)
To: Hans Petter Selasky; +Cc: rsbecker, git
In-Reply-To: <5971b434-6409-8fd6-130f-f5b871a10f6d@selasky.org>
On Fri, Jan 13, 2023 at 05:18:40PM +0100, Hans Petter Selasky wrote:
> On 1/13/23 17:06, Hans Petter Selasky wrote:
> > What's the point? Only so that one party can stay in control?
>
> Let me phrase it like this:
>
> You clearly believe in the zero-trust principle. I don't.
I'm not sure what you mean here, but git is certainly not zero-trust. When you
clone linux.git from git.kernel.org, you're very much trusting that:
- I (or members of my team) didn't mess with the repository
- Linus (or someone who hacked his laptop) didn't mess with the repository
Git is tamper-evident, not tamper-proof, so by definition it cannot be
zero-trust.
> Why can't git support both beliefs, and it can be configurable somehow then?
Well, git is literally built on the concept of unique hashes. It's not
possible to make this bit configurable, as it would be a totally different
project with entirely different internals.
Not saying such framework doesn't have a reason to exist, but it's not
something that can be built on top of git.
-K
^ permalink raw reply
* Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1
From: Hans Petter Selasky @ 2023-01-13 16:35 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: rsbecker, git
In-Reply-To: <20230113162721.qwl2asjo542cxe3c@meerkat.local>
On 1/13/23 17:27, Konstantin Ryabitsev wrote:
> Not to discourage you, but you seem to be making statements without a good
> understanding of how git works. If there is a history rewrite (even one that
> for some reason goes back millions of commits) all hash calculations will
> happen exactly once -- on the system of the person who's rewriting the
> history. After they push it, it's just a bunch of objects that everyone else
> merely downloads.
If you used CRC, you would not need that, because CRC calculations are
"concatenatable", while SHA-1's are not. CRC would just need the first
and the last hash, and then you would apply the "difference".
--HPS
^ permalink raw reply
* Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1
From: Hans Petter Selasky @ 2023-01-13 16:30 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: rsbecker, git
In-Reply-To: <20230113162721.qwl2asjo542cxe3c@meerkat.local>
On 1/13/23 17:27, Konstantin Ryabitsev wrote:
> The answer is, unhelpfully, "because that's how git works." Every commit is a
> standalone object that references the previous commit, plus includes hashes of
> all trees, and those include hashes of all blobs. SHA-1 was picked because of
> its speed and the fact that it guarantees an extremely low potential for
> collisions (even better with SHA256). As a side-effect, it's easy to calculate
> the integrity of the entire tree, including its history, by verifying its
> hashes (this is what git fsck does).
Same thing can be said for CRC-XXX. Just some magic CPU instructions and
we're good. You don't even need a library.
--HPS
^ permalink raw reply
* Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1
From: Konstantin Ryabitsev @ 2023-01-13 16:27 UTC (permalink / raw)
To: Hans Petter Selasky; +Cc: rsbecker, git
In-Reply-To: <a2e6fdc3-fbb0-821c-078f-1ad4e55dc8e3@selasky.org>
On Fri, Jan 13, 2023 at 05:06:57PM +0100, Hans Petter Selasky wrote:
> OK, if you say so. Though in my mind 46K rebases of millions of commits seem
> a lot overhead.
Not to discourage you, but you seem to be making statements without a good
understanding of how git works. If there is a history rewrite (even one that
for some reason goes back millions of commits) all hash calculations will
happen exactly once -- on the system of the person who's rewriting the
history. After they push it, it's just a bunch of objects that everyone else
merely downloads.
> However, if history can be edited anyway, why do you need the cryptographic
> hash algorithm. Why not use a non-cryptographic one?
The answer is, unhelpfully, "because that's how git works." Every commit is a
standalone object that references the previous commit, plus includes hashes of
all trees, and those include hashes of all blobs. SHA-1 was picked because of
its speed and the fact that it guarantees an extremely low potential for
collisions (even better with SHA256). As a side-effect, it's easy to calculate
the integrity of the entire tree, including its history, by verifying its
hashes (this is what git fsck does).
Hashes aren't really "cryptographic" anyway (they just happen to be used all
over the place in cryptography). It's really just a one-way function to reduce
content of arbitrary size to a set of bytes of a determined size (and give a
relatively high assurance of it being collision-free).
-K
^ permalink raw reply
* Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1
From: Hans Petter Selasky @ 2023-01-13 16:18 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: rsbecker, git
In-Reply-To: <a2e6fdc3-fbb0-821c-078f-1ad4e55dc8e3@selasky.org>
On 1/13/23 17:06, Hans Petter Selasky wrote:
> What's the point? Only so that one party can stay in control?
Let me phrase it like this:
You clearly believe in the zero-trust principle. I don't.
Why can't git support both beliefs, and it can be configurable somehow then?
--HPS
^ permalink raw reply
* [PATCH v2] docs: link generating patch sections
From: John Cai via GitGitGadget @ 2023-01-13 16:15 UTC (permalink / raw)
To: git; +Cc: John Cai, John Cai
In-Reply-To: <pull.1392.git.git.1670614892380.gitgitgadget@gmail.com>
From: John Cai <johncai86@gmail.com>
Currently, in the git-log documentation, the reference to generating
patches does not match the section title. This can make the section
"Generating patch text with -p" hard to find, since typically readers of
the documentation will copy and paste to search the page.
Let's make this more convenient for readers by linking it directly to
the section.
Since git-log pulls in diff-generate-patch.txt, we can provide a direct
link to the section. Otherwise, change the verbiage to match exactly
what the section title is, to at least make searching for it an easier
task.
Signed-off-by: John Cai <johncai86@gmail.com>
---
docs: link generating patch sections
Currently, in the git-log documentation, the reference to generating
patches does not match the section title. This can make the section
"Generating patch text with -p" hard to find, since typically readers of
the documentation will copy and paste to search the page.
Let's make this more convenient for readers by linking it directly to
the section.
Since v1:
* added explicit anchor for generating patch text section
* adjusted verbiage to include quotations
Signed-off-by: John Cai johncai86@gmail.com
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1392%2Fjohn-cai%2Fjc%2Fdoc-generate-patch-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1392/john-cai/jc/doc-generate-patch-v2
Pull-Request: https://github.com/git/git/pull/1392
Range-diff vs v1:
1: 88e7e52fbc6 ! 1: 087f9b8d63a docs: link generating patch sections
@@ Commit message
Signed-off-by: John Cai <johncai86@gmail.com>
+ ## Documentation/diff-generate-patch.txt ##
+@@
++[[generate_patch_text_with_p]]
+ Generating patch text with -p
+ -----------------------------
+
+
## Documentation/diff-options.txt ##
@@ Documentation/diff-options.txt: ifndef::git-format-patch[]
-p::
-u::
--patch::
- Generate patch (see section on generating patches).
-+ Generate patch (see section on
++ Generate patch (see section titled
+ifdef::git-log[]
-+<<_generating_patch_text_with_p, generating patches>>).
++<<generate_patch_text_with_p, "Generating patch text with -p">>).
+endif::git-log[]
+ifndef::git-log[]
-+Generate patch text with -p).
++"Generating patch text with -p").
+endif::git-log[]
ifdef::git-diff[]
This is the default.
Documentation/diff-generate-patch.txt | 1 +
Documentation/diff-options.txt | 8 +++++++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt
index c78063d4f74..546adf79e5a 100644
--- a/Documentation/diff-generate-patch.txt
+++ b/Documentation/diff-generate-patch.txt
@@ -1,3 +1,4 @@
+[[generate_patch_text_with_p]]
Generating patch text with -p
-----------------------------
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 3674ac48e92..7d73e976d99 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -22,7 +22,13 @@ ifndef::git-format-patch[]
-p::
-u::
--patch::
- Generate patch (see section on generating patches).
+ Generate patch (see section titled
+ifdef::git-log[]
+<<generate_patch_text_with_p, "Generating patch text with -p">>).
+endif::git-log[]
+ifndef::git-log[]
+"Generating patch text with -p").
+endif::git-log[]
ifdef::git-diff[]
This is the default.
endif::git-diff[]
base-commit: a38d39a4c50d1275833aba54c4dbdfce9e2e9ca1
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH] docs: link generating patch sections
From: John Cai @ 2023-01-13 16:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Cai via GitGitGadget, git
In-Reply-To: <xmqqk030xfrd.fsf@gitster.g>
Hi Junio
On 9 Dec 2022, at 19:29, Junio C Hamano wrote:
> "John Cai via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
>> index 3674ac48e92..5acffdd129e 100644
>> --- a/Documentation/diff-options.txt
>> +++ b/Documentation/diff-options.txt
>> @@ -22,7 +22,13 @@ ifndef::git-format-patch[]
>> -p::
>> -u::
>> --patch::
>> - Generate patch (see section on generating patches).
>> + Generate patch (see section on
>> +ifdef::git-log[]
>> +<<_generating_patch_text_with_p, generating patches>>).
>
> Is this "prepend underscore, downcase, and replace each run of
> non-alnum with an underscore" ASCIIDoc magic? AsciiDoctor magic?
> All such backends prepare the anchor in the same format?
Yes, I believe this is asciidoc magic.
>
> I am mostly worried about relying on automatic magic that can
> silently be broken when say the title in diff-generate-patch.txt
> file is improved. Whoever is updating the file would not know
> it is being referenced from elsewhere (and it is hard to check).
>
> Or perhaps you forgot a single liner patch to diff-generate-patch.txt
> that adds [[_generating_patch_text_with_p]] anchor yourself?
Good point, adding an explicit anchor makes sense.
>
>> +endif::git-log[]
>> +ifndef::git-log[]
>> +Generate patch text with -p).
>
> The capitalization makes it look somewhat odd in the resulting
> text. Quoting, e.g.
>
> see the section titled "Generate patch text ..."
>
> may make it acceptable, though.
yeah I agree here--I can adjust this in the next version
thanks
John
>
>> +endif::git-log[]
>> ifdef::git-diff[]
>> This is the default.
>> endif::git-diff[]
>>
>> base-commit: 2e71cbbddd64695d43383c25c7a054ac4ff86882
^ permalink raw reply
* Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1
From: Konstantin Khomoutov @ 2023-01-13 15:30 UTC (permalink / raw)
To: git; +Cc: Hans Petter Selasky
In-Reply-To: <446984f6-0d2e-04da-11a3-8b1481fac953@selasky.org>
On Fri, Jan 13, 2023 at 02:39:37PM +0100, Hans Petter Selasky wrote:
[...]
> > It's not clear why are you referring to Gitorious in your mail's subject and
> > then talk about Git.
[...]
> I thought that Git was short for Gitorious? My bad.
No, unless you're late to the Git party ;-)
Old-timers do remember Gitorious as a software project [1] which is closely
related to Git but was a totally separate project.
1. https://en.wikipedia.org/wiki/Gitorious
^ 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