* Re: [PATCH 06/12] fsmonitor: clarify handling of directory events in callback
From: Jeff Hostetler @ 2024-02-20 18:56 UTC (permalink / raw)
To: Junio C Hamano, Jeff Hostetler via GitGitGadget; +Cc: git, Jeff Hostetler
In-Reply-To: <xmqqil2rzdvo.fsf@gitster.g>
On 2/14/24 2:47 AM, Junio C Hamano wrote:
> "Jeff Hostetler via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> From: Jeff Hostetler <jeffhostetler@github.com>
>>
>> Signed-off-by: Jeff Hostetler <jeffhostetler@github.com>
>> ---
>> fsmonitor.c | 47 +++++++++++++++++++++++++++++++++--------------
>> 1 file changed, 33 insertions(+), 14 deletions(-)
>>
>> diff --git a/fsmonitor.c b/fsmonitor.c
>> index 614270fa5e8..754fe20cfd0 100644
>> --- a/fsmonitor.c
>> +++ b/fsmonitor.c
>> @@ -219,24 +219,40 @@ static void fsmonitor_refresh_callback_unqualified(
>> }
>> }
>>
>> -static void fsmonitor_refresh_callback_slash(
...
>> +static int fsmonitor_refresh_callback_slash(
>> struct index_state *istate, const char *name, int len, int pos)
>> {
>
> This was split out a few patches ago, and the caller of course
> ignored the return value (void), but now it turns an integer, and
> this change is without a corresponding update to the caller, which
> leaves readers puzzled.
>
> Perhaps a future patch either updates the existing caller or adds a
> new caller that utilize the returned value, but then at least the
> proposed commit message for this step should hint how it helps the
> caller(s) we will see in the future steps if this function returns
> the number of entries invalidated, iow, how the caller is expected
> to use the returned value from here, no?
>
> Alternatively, this step can limit itself to what the commit title
> claims to do---to clarify what the helper does with enhanced in-code
> comments. Then a future step that updates the caller to care about
> the return value can have both the changes to this callee as well as
> the caller---which may make it easier to see how the returned info
> helps the caller. I dunno which is more reasonable.
>
I'll split this into 2 commits. One for the refactor and one for
the new return value.
Jeff
^ permalink raw reply
* [ANNOUNCE] Git for Windows 2.44.0-rc2
From: Johannes Schindelin @ 2024-02-20 19:06 UTC (permalink / raw)
To: git-for-windows, git, git-packagers; +Cc: Johannes Schindelin
Dear Git users,
I hereby announce that Git for Windows 2.44.0-rc2 is available from:
https://github.com/git-for-windows/git/releases/tag/v2.44.0-rc2.windows.1
Changes since Git for Windows v2.43.0 (November 20th 2023)
Git for Windows for Windows v2.44 is the last version to support for
Windows 7 and for Windows 8, see MSYS2's corresponding deprecation
announcement (Git for Windows relies on MSYS2 for components such as
Bash and Perl).
Please also note that the 32-bit variant of Git for Windows is
deprecated; Its last official release is planned for 2025.
New Features
* Comes with Git v2.44.0-rc2.
* Comes with libfido2 v1.14.0.
* Comes with the MSYS2 runtime (Git for Windows flavor) based on
Cygwin v3.4.10.
* Comes with Perl v5.38.2.
* Git for Windows learned to detect and use native Windows support
for ANSI sequences, which allows using 24-bit colors in terminal
windows.
* Comes with Git LFS v3.4.1.
* The repository viewer Tig that is included in Git for Windows can
now be called also directly from PowerShell/CMD.
* Comes with OpenSSH v9.6.P1.
* Comes with Bash v5.2.26.
* Comes with GNU TLS v3.8.3.
* Comes with OpenSSL v3.2.1.
* Comes with cURL v8.6.0.
* Comes with GNU Privacy Guard v2.4.4.
Bug Fixes
* The 32-bit variant of Git for Windows was missing some MSYS2
runtime updates, which was addressed; Do note 32-bit support is
phased out.
* The Git for Windows installer showed cut-off text in some setups.
This has been fixed.
* The git credential-manager --help command previously would not find
a page to display in the web browser, which has been fixed.
* A couple of bugs that could cause Git Bash to hang in certain
scenarios were fixed.
Git-2.44.0-rc2-64-bit.exe | d188ba8cb0d36fda22fa12759de00c9e23cc45f57521f05184d3cf8c36a6fec3
Git-2.44.0-rc2-32-bit.exe | 12149c903330ccae8298a6890d3eed49939393c3a806775ef0ddb27674315556
PortableGit-2.44.0-rc2-64-bit.7z.exe | 4b753124cec6aa6635001c48716b249cc43a37db10aec3f0cccfc68d6d20ac7c
PortableGit-2.44.0-rc2-32-bit.7z.exe | b8cfa7ae7549a3c12a4e19fb9598e16161858075bba3df4110f0585e2476bb5a
MinGit-2.44.0-rc2-64-bit.zip | 6db61b0855f4dd67770a221debea944c7a69cb8fa37acb5b1c85c10ea914464e
MinGit-2.44.0-rc2-32-bit.zip | e92da5248e2165c1a25fcfce0469754cee218e8954bfe7711890d06803be1659
MinGit-2.44.0-rc2-busybox-64-bit.zip | 117839c34a0dba2323d46bf1c66172b4452c9323ab8f917266ef088aec1dc118
MinGit-2.44.0-rc2-busybox-32-bit.zip | d9820cccb91d80f46914c047f65424599cb29e87ff7a015e9fcd82b84e7b9abd
Git-2.44.0-rc2-64-bit.tar.bz2 | e6346c6ca380035642334d81480f24e74dfaed56f3b8d8313df6989c7b7cad11
Git-2.44.0-rc2-32-bit.tar.bz2 | d94aee3941b289f6b1ebf20cca84165628603cce71a067c44338b20e380deaa3
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH 06/12] fsmonitor: clarify handling of directory events in callback
From: Jeff Hostetler @ 2024-02-20 19:10 UTC (permalink / raw)
To: Patrick Steinhardt, Jeff Hostetler via GitGitGadget; +Cc: git, Jeff Hostetler
In-Reply-To: <Zc3aKSR53Ew4ImMP@tanuki>
On 2/15/24 4:32 AM, Patrick Steinhardt wrote:
> On Tue, Feb 13, 2024 at 08:52:15PM +0000, Jeff Hostetler via GitGitGadget wrote:
>> From: Jeff Hostetler <jeffhostetler@github.com>
>>
>> Signed-off-by: Jeff Hostetler <jeffhostetler@github.com>
>> ---
>> fsmonitor.c | 47 +++++++++++++++++++++++++++++++++--------------
>> 1 file changed, 33 insertions(+), 14 deletions(-)
>>
>> diff --git a/fsmonitor.c b/fsmonitor.c
>> index 614270fa5e8..754fe20cfd0 100644
>> --- a/fsmonitor.c
>> +++ b/fsmonitor.c
>> @@ -219,24 +219,40 @@ static void fsmonitor_refresh_callback_unqualified(
...
>> +static int fsmonitor_refresh_callback_slash(
>> struct index_state *istate, const char *name, int len, int pos)
>> {
>> int i;
>> + int nr_in_cone = 0;
>
> Should we return `size_t` instead of `int`?
>
> Patrick
yeah, I can fix all of the return values to be 'size_t' since
that is new functionality and not colliding with the existing
usages for 'i' and 'pos' that I mentioned in a response on a
previous thread.
Thanks
Jeff
^ permalink raw reply
* Re: [PATCH] branch: rework the descriptions of rename and copy operations
From: Rubén Justo @ 2024-02-20 19:12 UTC (permalink / raw)
To: Junio C Hamano, Dragan Simic; +Cc: git
In-Reply-To: <xmqqttm3ouxy.fsf@gitster.g>
On 20-feb-2024 10:24:25, Junio C Hamano wrote:
> I have slight aversion to non-words like "oldbranch" (not
> "old-branch"), but not that much.
I also have problems with <old...>. What's the reference in "old"?
Prior to the restructuring of the whole file, we should probably do:
---- >8 --------- >8 --------- >8 --------- >8 ------
Subject: [PATCH] branch: adjust documentation
Adjust the terms we use in Documentation/git-branch.txt to what
we say in CodingGuideLines:
If a placeholder has multiple words, they are separated by dashes:
<new-branch-name>
--template=<template-directory>
Best viewed with --word-diff.
Signed-off-by: Rubén Justo <rjusto@gmail.com>
---
Documentation/git-branch.txt | 57 +++++++++++++++++-------------------
1 file changed, 27 insertions(+), 30 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 0b08442932..d834d89a7f 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -17,13 +17,13 @@ SYNOPSIS
[(-r | --remotes) | (-a | --all)]
[--list] [<pattern>...]
'git branch' [--track[=(direct|inherit)] | --no-track] [-f]
- [--recurse-submodules] <branchname> [<start-point>]
-'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]
-'git branch' --unset-upstream [<branchname>]
-'git branch' (-m | -M) [<oldbranch>] <newbranch>
-'git branch' (-c | -C) [<oldbranch>] <newbranch>
-'git branch' (-d | -D) [-r] <branchname>...
-'git branch' --edit-description [<branchname>]
+ [--recurse-submodules] <new-branch> [<start-point>]
+'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branch>]
+'git branch' --unset-upstream [<branch>]
+'git branch' (-m | -M) [<branch>] <new-branch>
+'git branch' (-c | -C) [<branch>] <new-branch>
+'git branch' (-d | -D) [-r] <branch>...
+'git branch' --edit-description [<branch>]
DESCRIPTION
-----------
@@ -53,7 +53,7 @@ branches not merged into the named commit will be listed. If the <commit>
argument is missing it defaults to `HEAD` (i.e. the tip of the current
branch).
-The command's second form creates a new branch head named <branchname>
+The command's second form creates a new branch head named <branch>
which points to the current `HEAD`, or <start-point> if given. As a
special case, for <start-point>, you may use `"A...B"` as a shortcut for
the merge base of `A` and `B` if there is exactly one merge base. You
@@ -61,7 +61,7 @@ can leave out at most one of `A` and `B`, in which case it defaults to
`HEAD`.
Note that this will create the new branch, but it will not switch the
-working tree to it; use "git switch <newbranch>" to switch to the
+working tree to it; use "git switch" to switch to the
new branch.
When a local branch is started off a remote-tracking branch, Git sets up the
@@ -72,17 +72,17 @@ the remote-tracking branch. This behavior may be changed via the global
overridden by using the `--track` and `--no-track` options, and
changed later using `git branch --set-upstream-to`.
-With a `-m` or `-M` option, <oldbranch> will be renamed to <newbranch>.
-If <oldbranch> had a corresponding reflog, it is renamed to match
-<newbranch>, and a reflog entry is created to remember the branch
-renaming. If <newbranch> exists, -M must be used to force the rename
+With a `-m` or `-M` option, <branch> will be renamed to <new-branch>.
+If <branch> had a corresponding reflog, it is renamed to match
+<new-branch>, and a reflog entry is created to remember the branch
+renaming. If <new-branch> exists, -M must be used to force the rename
to happen.
The `-c` and `-C` options have the exact same semantics as `-m` and
`-M`, except instead of the branch being renamed, it will be copied to a
new name, along with its config and reflog.
-With a `-d` or `-D` option, `<branchname>` will be deleted. You may
+With a `-d` or `-D` option, `<branch>` will be deleted. You may
specify more than one branch for deletion. If the branch currently
has a reflog then the reflog will also be deleted.
@@ -107,7 +107,7 @@ OPTIONS
--create-reflog::
Create the branch's reflog. This activates recording of
all changes made to the branch ref, enabling use of date
- based sha1 expressions such as "<branchname>@\{yesterday}".
+ based sha1 expressions such as "<branch>@\{yesterday}".
Note that in non-bare repositories, reflogs are usually
enabled by default by the `core.logAllRefUpdates` config option.
The negated form `--no-create-reflog` only overrides an earlier
@@ -116,7 +116,7 @@ OPTIONS
-f::
--force::
- Reset <branchname> to <start-point>, even if <branchname> exists
+ Reset <branch> to <start-point>, even if <branch> exists
already. Without `-f`, 'git branch' refuses to change an existing branch.
In combination with `-d` (or `--delete`), allow deleting the
branch irrespective of its merged status, or whether it even
@@ -124,8 +124,8 @@ OPTIONS
`-m` (or `--move`), allow renaming the branch even if the new
branch name already exists, the same applies for `-c` (or `--copy`).
+
-Note that 'git branch -f <branchname> [<start-point>]', even with '-f',
-refuses to change an existing branch `<branchname>` that is checked out
+Note that 'git branch -f <branch> [<start-point>]', even with '-f',
+refuses to change an existing branch `<branch>` that is checked out
in another worktree linked to the same repository.
-m::
@@ -255,7 +255,7 @@ how the `branch.<name>.remote` and `branch.<name>.merge` options are used.
linkgit:git-config[1]. Currently, only branch creation is
supported.
+
-When used in branch creation, a new branch <branchname> will be created
+When used in branch creation, a new branch <branch> will be created
in the superproject and all of the submodules in the superproject's
<start-point>. In submodules, the branch will point to the submodule
commit in the superproject's <start-point> but the branch's tracking
@@ -270,12 +270,12 @@ superproject's "origin/main", but tracks the submodule's "origin/main".
-u <upstream>::
--set-upstream-to=<upstream>::
- Set up <branchname>'s tracking information so <upstream> is
- considered <branchname>'s upstream branch. If no <branchname>
+ Set up <branch>'s tracking information so <upstream> is
+ considered <branch>'s upstream branch. If no <branch>
is specified, then it defaults to the current branch.
--unset-upstream::
- Remove the upstream information for <branchname>. If no branch
+ Remove the upstream information for <branch>. If no branch
is specified it defaults to the current branch.
--edit-description::
@@ -300,24 +300,21 @@ superproject's "origin/main", but tracks the submodule's "origin/main".
Only list branches whose tips are not reachable from the
specified commit (HEAD if not specified). Implies `--list`.
-<branchname>::
+<branch>::
The name of the branch to create or delete.
The new branch name must pass all checks defined by
linkgit:git-check-ref-format[1]. Some of these checks
may restrict the characters allowed in a branch name.
+ If ommited, the current branch will be used instead.
<start-point>::
The new branch head will point to this commit. It may be
given as a branch name, a commit-id, or a tag. If this
option is omitted, the current HEAD will be used instead.
-<oldbranch>::
- The name of an existing branch. If this option is omitted,
- the name of the current branch will be used instead.
-
-<newbranch>::
- The new name for an existing branch. The same restrictions as for
- <branchname> apply.
+<new-branch>::
+ The name for new branch. The same restrictions as for
+ <branch> apply.
--sort=<key>::
Sort based on the key given. Prefix `-` to sort in descending
--
2.44.0.rc2
^ permalink raw reply related
* Re: [PATCH] branch: rework the descriptions of rename and copy operations
From: Rubén Justo @ 2024-02-20 19:14 UTC (permalink / raw)
To: Dragan Simic; +Cc: Junio C Hamano, git
In-Reply-To: <be91f3ad9305366c1385c2da4881537e@manjaro.org>
On 18-feb-2024 21:38:54, Dragan Simic wrote:
> Regarding the branch copy and rename operations and their argument
> names, perhaps the following would be a good choice:
>
> --copy [<branch>] <destination>
> --move [<branch>] <destination>
>
> It would clearly reflect the nature of the performed operations, while
> still using "<branch>" consistently, this time to refer to the source
> branch. Using "<destination>" to select the destination name should
> be pretty much self-descriptive, if you agree.
Sorry, but I don't. Actually, I don't see the logic with <destination>.
I appreciate your efforts to provide consistency, but the current ones
seem better options to me: either <oldbranch> and <newbranch>, or the
shortened ones: <old> and <new>.
Thanks.
^ permalink raw reply
* Re: [PATCH 06/12] fsmonitor: clarify handling of directory events in callback
From: Junio C Hamano @ 2024-02-20 19:24 UTC (permalink / raw)
To: Jeff Hostetler; +Cc: Jeff Hostetler via GitGitGadget, git, Jeff Hostetler
In-Reply-To: <b379b92f-407a-c4b3-ee65-a7fa6e7dff74@jeffhostetler.com>
Jeff Hostetler <git@jeffhostetler.com> writes:
> I'll split this into 2 commits. One for the refactor and one for
> the new return value.
And the latter one that makes the return value richer contains the
caller that makes use of the returned value? That's great. It
would make it very much easier to read the resulting commit, as the
presence of the callers and how they use the returned value would
make it self evident why it makes sense to return the number of
entries invalidated.
Thanks.
^ permalink raw reply
* Re: [PATCH] builtin/stash: configs keepIndex, includeUntracked
From: Kristoffer Haugsbakk @ 2024-02-20 19:30 UTC (permalink / raw)
To: Ricardo C; +Cc: Phillip Wood, git, Junio C Hamano
In-Reply-To: <31135b8a-af7a-4d73-b3b3-d91ea8d3d5fd@gmail.com>
On Tue, Feb 20, 2024, at 04:59, Ricardo C wrote:
> That makes sense. Do you have any ideas on how to address this? It feels to me
> like providing this config option is fundamentally incompatible with requiring
> backwards-compatible behavior regardless of configuration.
If my armchair also had a time machine: one could have used an `-s`
option to `git` (`git -s stash`) that only reads a few configuration
variables, like `user.name` and `user.email`. It would read none of the
variables meant for making interactive/custom use convenient. This would
be meant for scripts. That way new user-convenience config variables
wouldn’t interfere with some `git -s` invocation deep in some script
somewhere.
As for the status quo though one seems stuck.
^ permalink raw reply
* Re: [PATCH] branch: rework the descriptions of rename and copy operations
From: Dragan Simic @ 2024-02-20 19:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Rubén Justo, git
In-Reply-To: <xmqqttm3ouxy.fsf@gitster.g>
On 2024-02-20 19:24, Junio C Hamano wrote:
> Dragan Simic <dsimic@manjaro.org> writes:
>
>>> My advice would be to stick to <old> vs <new> that contrasts well.
>>
>> I appreciate the directness and honesty. How about using
>> "<oldbranch>"
>> and "<newbranch>" instead, which, although more wordy, would be more
>> consistent with "<branch>" that's used in a number of other places?
>
> I have slight aversion to non-words like "oldbranch" (not
> "old-branch"), but not that much.
>
> Quite honestly, in a document whose primary topic is "branch", I
> doubt that repeating "branch" all over the place would be the
> consistency we should be aiming for in the first place, when it is
> clear from the context that we are talking about branches.
>
> The updates we are making to Documentation/git-branch.txt that (1)
> slims wordy description of different modes in the DESCRIPTION
> section, (2) make option description of "-m" mention what
> argument(s) the option takes, and (3) rmove standalone <newbranch>
> and <oldbranch> description are all about making the necessary piece
> of information easier to find in one place (namely, the option
> description where "-m [<one branch name>] [<the other branch name>]"
> is described) without having to jump around all over in the
> documentation, so in that sense, I would think the way to go is to
> aim for brevity that takes advantage of the local context.
It's hard not to agree with the way you laid this out. :)
In a nutshell, the way I see it, using "<old>" and "<new>" is also fine.
It's also fine with me to use "<name>" instead of "<branch>"; in fact,
if we go with "<old>" and "<new>", we should go with "<name>", too.
^ permalink raw reply
* Re: [PATCH 02/12] name-hash: add index_dir_exists2()
From: Junio C Hamano @ 2024-02-20 19:34 UTC (permalink / raw)
To: Jeff Hostetler; +Cc: Jeff Hostetler via GitGitGadget, git, Jeff Hostetler
In-Reply-To: <1913ed1b-a145-e641-6601-d8a55a2a8fec@jeffhostetler.com>
Jeff Hostetler <git@jeffhostetler.com> writes:
> I'm always a little hesitant to change the signature of an existing
> function and chasing all of the callers in the middle of another
> task. It can sometimes be distracting to reviewers.
Of course we all should be hesitant. In addition to reviewers,
there are topics in flight and topics people are cooking but not
posted that will be affected. So it is perfectly fine to introduce
an enhanced version as needed under different name (but let's not
give it a meaningless name like "foo2" where it is totally unclear
and unexplained what its difference from "foo" is from the name),
but if it is meant as an enhanced version, we should aim to share
the code and rewrite the original in terms of the enhanced one,
instead of simply duplicating to risk unnecessary divergence of the
two functions in the future.
Thanks.
^ permalink raw reply
* Re: [PATCH] documentation: send-email: use camel case consistently
From: Dragan Simic @ 2024-02-20 19:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq8r3foup4.fsf@gitster.g>
On 2024-02-20 19:29, Junio C Hamano wrote:
> Dragan Simic <dsimic@manjaro.org> writes:
>
>> If you insist on using "CC", I'd be fine with that, but frankly, I
>> think
>> that would actually be confusing to the users.
>
> I do not insist; my job is to just reject what is not correct.
>
> In this particular case, I do not think Cc is outright wrong; it
> is near the borderline, but I do not know which side of that line it
> sits.
>
> I gave you one possible rule to decide what to capitalize (namely,
> acronyms are spelled in all caps and that is how we capitalize
> http.proxySSLCert and imap.preformattedHTML) and if we adopt that
> rule, then sendemail.supressCc would be incorrect, simply because
> carbon-copy should be spelled CC.
Please, let me remind you that I already fully agreed with using
"SSL". The same applies to "HTML", for example, but "Cc" should be
an exception to that rule, IMHO.
> You need to give an alternative criteria that is easy to understand
> for future developers and follow, and explain your choice in the
> proposed commit log message: "We spell acronyms in all caps like
> HTML and SSL, but in the case of carbon-copy, we spell it as Cc
> because ...".
>
> You need to fill that "..." is in your proposed log message to
> explain the choice you made in your patch text. More importantly,
> it is to help future developers so that they can easily follow the
> same rule to spell the variable names they invented in a way
> consistent with the rule you followed in this patch.
Agreed, I'll provide a detailed rationale for using "Cc" vs. "SSL"
in the commit description for v3, with a few references.
^ permalink raw reply
* Re: [PATCH] branch: rework the descriptions of rename and copy operations
From: Dragan Simic @ 2024-02-20 19:49 UTC (permalink / raw)
To: Rubén Justo; +Cc: Junio C Hamano, git
In-Reply-To: <16c1f883-881f-4f8c-95b2-22fb4825b733@gmail.com>
On 2024-02-20 20:12, Rubén Justo wrote:
> On 20-feb-2024 10:24:25, Junio C Hamano wrote:
>
>> I have slight aversion to non-words like "oldbranch" (not
>> "old-branch"), but not that much.
>
> I also have problems with <old...>. What's the reference in "old"?
>
> Prior to the restructuring of the whole file, we should probably do:
FWIW, I'm perfectly fine with having your patch, available below,
applied right now. To me, it would provide a true improvement.
> ---- >8 --------- >8 --------- >8 --------- >8 ------
> Subject: [PATCH] branch: adjust documentation
>
> Adjust the terms we use in Documentation/git-branch.txt to what
> we say in CodingGuideLines:
>
> If a placeholder has multiple words, they are separated by dashes:
> <new-branch-name>
> --template=<template-directory>
>
> Best viewed with --word-diff.
>
> Signed-off-by: Rubén Justo <rjusto@gmail.com>
> ---
> Documentation/git-branch.txt | 57 +++++++++++++++++-------------------
> 1 file changed, 27 insertions(+), 30 deletions(-)
>
> diff --git a/Documentation/git-branch.txt
> b/Documentation/git-branch.txt
> index 0b08442932..d834d89a7f 100644
> --- a/Documentation/git-branch.txt
> +++ b/Documentation/git-branch.txt
> @@ -17,13 +17,13 @@ SYNOPSIS
> [(-r | --remotes) | (-a | --all)]
> [--list] [<pattern>...]
> 'git branch' [--track[=(direct|inherit)] | --no-track] [-f]
> - [--recurse-submodules] <branchname> [<start-point>]
> -'git branch' (--set-upstream-to=<upstream> | -u <upstream>)
> [<branchname>]
> -'git branch' --unset-upstream [<branchname>]
> -'git branch' (-m | -M) [<oldbranch>] <newbranch>
> -'git branch' (-c | -C) [<oldbranch>] <newbranch>
> -'git branch' (-d | -D) [-r] <branchname>...
> -'git branch' --edit-description [<branchname>]
> + [--recurse-submodules] <new-branch> [<start-point>]
> +'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branch>]
> +'git branch' --unset-upstream [<branch>]
> +'git branch' (-m | -M) [<branch>] <new-branch>
> +'git branch' (-c | -C) [<branch>] <new-branch>
> +'git branch' (-d | -D) [-r] <branch>...
> +'git branch' --edit-description [<branch>]
>
> DESCRIPTION
> -----------
> @@ -53,7 +53,7 @@ branches not merged into the named commit will be
> listed. If the <commit>
> argument is missing it defaults to `HEAD` (i.e. the tip of the current
> branch).
>
> -The command's second form creates a new branch head named <branchname>
> +The command's second form creates a new branch head named <branch>
> which points to the current `HEAD`, or <start-point> if given. As a
> special case, for <start-point>, you may use `"A...B"` as a shortcut
> for
> the merge base of `A` and `B` if there is exactly one merge base. You
> @@ -61,7 +61,7 @@ can leave out at most one of `A` and `B`, in which
> case it defaults to
> `HEAD`.
>
> Note that this will create the new branch, but it will not switch the
> -working tree to it; use "git switch <newbranch>" to switch to the
> +working tree to it; use "git switch" to switch to the
> new branch.
>
> When a local branch is started off a remote-tracking branch, Git sets
> up the
> @@ -72,17 +72,17 @@ the remote-tracking branch. This behavior may be
> changed via the global
> overridden by using the `--track` and `--no-track` options, and
> changed later using `git branch --set-upstream-to`.
>
> -With a `-m` or `-M` option, <oldbranch> will be renamed to
> <newbranch>.
> -If <oldbranch> had a corresponding reflog, it is renamed to match
> -<newbranch>, and a reflog entry is created to remember the branch
> -renaming. If <newbranch> exists, -M must be used to force the rename
> +With a `-m` or `-M` option, <branch> will be renamed to <new-branch>.
> +If <branch> had a corresponding reflog, it is renamed to match
> +<new-branch>, and a reflog entry is created to remember the branch
> +renaming. If <new-branch> exists, -M must be used to force the rename
> to happen.
>
> The `-c` and `-C` options have the exact same semantics as `-m` and
> `-M`, except instead of the branch being renamed, it will be copied to
> a
> new name, along with its config and reflog.
>
> -With a `-d` or `-D` option, `<branchname>` will be deleted. You may
> +With a `-d` or `-D` option, `<branch>` will be deleted. You may
> specify more than one branch for deletion. If the branch currently
> has a reflog then the reflog will also be deleted.
>
> @@ -107,7 +107,7 @@ OPTIONS
> --create-reflog::
> Create the branch's reflog. This activates recording of
> all changes made to the branch ref, enabling use of date
> - based sha1 expressions such as "<branchname>@\{yesterday}".
> + based sha1 expressions such as "<branch>@\{yesterday}".
> Note that in non-bare repositories, reflogs are usually
> enabled by default by the `core.logAllRefUpdates` config option.
> The negated form `--no-create-reflog` only overrides an earlier
> @@ -116,7 +116,7 @@ OPTIONS
>
> -f::
> --force::
> - Reset <branchname> to <start-point>, even if <branchname> exists
> + Reset <branch> to <start-point>, even if <branch> exists
> already. Without `-f`, 'git branch' refuses to change an existing
> branch.
> In combination with `-d` (or `--delete`), allow deleting the
> branch irrespective of its merged status, or whether it even
> @@ -124,8 +124,8 @@ OPTIONS
> `-m` (or `--move`), allow renaming the branch even if the new
> branch name already exists, the same applies for `-c` (or `--copy`).
> +
> -Note that 'git branch -f <branchname> [<start-point>]', even with
> '-f',
> -refuses to change an existing branch `<branchname>` that is checked
> out
> +Note that 'git branch -f <branch> [<start-point>]', even with '-f',
> +refuses to change an existing branch `<branch>` that is checked out
> in another worktree linked to the same repository.
>
> -m::
> @@ -255,7 +255,7 @@ how the `branch.<name>.remote` and
> `branch.<name>.merge` options are used.
> linkgit:git-config[1]. Currently, only branch creation is
> supported.
> +
> -When used in branch creation, a new branch <branchname> will be
> created
> +When used in branch creation, a new branch <branch> will be created
> in the superproject and all of the submodules in the superproject's
> <start-point>. In submodules, the branch will point to the submodule
> commit in the superproject's <start-point> but the branch's tracking
> @@ -270,12 +270,12 @@ superproject's "origin/main", but tracks the
> submodule's "origin/main".
>
> -u <upstream>::
> --set-upstream-to=<upstream>::
> - Set up <branchname>'s tracking information so <upstream> is
> - considered <branchname>'s upstream branch. If no <branchname>
> + Set up <branch>'s tracking information so <upstream> is
> + considered <branch>'s upstream branch. If no <branch>
> is specified, then it defaults to the current branch.
>
> --unset-upstream::
> - Remove the upstream information for <branchname>. If no branch
> + Remove the upstream information for <branch>. If no branch
> is specified it defaults to the current branch.
>
> --edit-description::
> @@ -300,24 +300,21 @@ superproject's "origin/main", but tracks the
> submodule's "origin/main".
> Only list branches whose tips are not reachable from the
> specified commit (HEAD if not specified). Implies `--list`.
>
> -<branchname>::
> +<branch>::
> The name of the branch to create or delete.
> The new branch name must pass all checks defined by
> linkgit:git-check-ref-format[1]. Some of these checks
> may restrict the characters allowed in a branch name.
> + If ommited, the current branch will be used instead.
>
> <start-point>::
> The new branch head will point to this commit. It may be
> given as a branch name, a commit-id, or a tag. If this
> option is omitted, the current HEAD will be used instead.
>
> -<oldbranch>::
> - The name of an existing branch. If this option is omitted,
> - the name of the current branch will be used instead.
> -
> -<newbranch>::
> - The new name for an existing branch. The same restrictions as for
> - <branchname> apply.
> +<new-branch>::
> + The name for new branch. The same restrictions as for
> + <branch> apply.
>
> --sort=<key>::
> Sort based on the key given. Prefix `-` to sort in descending
^ permalink raw reply
* Re: [PATCH] branch: rework the descriptions of rename and copy operations
From: Dragan Simic @ 2024-02-20 19:56 UTC (permalink / raw)
To: Rubén Justo; +Cc: Junio C Hamano, git
In-Reply-To: <ad20099a-918d-4c37-8d5c-20c3f491728a@gmail.com>
On 2024-02-20 20:14, Rubén Justo wrote:
> On 18-feb-2024 21:38:54, Dragan Simic wrote:
>
>> Regarding the branch copy and rename operations and their argument
>> names, perhaps the following would be a good choice:
>>
>> --copy [<branch>] <destination>
>> --move [<branch>] <destination>
>>
>> It would clearly reflect the nature of the performed operations, while
>> still using "<branch>" consistently, this time to refer to the source
>> branch. Using "<destination>" to select the destination name should
>> be pretty much self-descriptive, if you agree.
>
> Sorry, but I don't. Actually, I don't see the logic with
> <destination>.
No worries, I appreciate the directness.
> I appreciate your efforts to provide consistency, but the current ones
> seem better options to me: either <oldbranch> and <newbranch>, or the
> shortened ones: <old> and <new>.
As I wrote a bit earlier, while replying to Junio, using "<old>" and
"<new>" (together with "<name>") is fine with me.
Though, using "<branch>" and "<new-branch>" is also a very good option,
which would additionally avoid introducing "<name>" to replace
"<branch>",
which I find highly beneficial, because it would provide consistency
with the rest of the documentation.
^ permalink raw reply
* Re: [PATCH] Revert "Declare both git-switch and git-restore experimental"
From: Martin @ 2024-02-20 19:57 UTC (permalink / raw)
Cc: git
In-Reply-To: <xmqqzfvvovva.fsf@gitster.g>
On 20/02/2024 19:04, Junio C Hamano wrote:
> [References]
>
> *1* https://lore.kernel.org/git/211021.86wnm6l1ip.gmgdl@evledraar.gmail.com/
> *2* https://lore.kernel.org/git/xmqqzg6eocmi.fsf@gitster.g/
>
From 2
> I think the "switch" was written exactly for such a transition so that folks who
> wanted a different behaviour do not have to break existing users of "checkout".
Yet then the table in link 1 suggests to re-use -c and -m in the old
style, the way the currently are used in "git branch"
"Introducing a new behaviour" is exactly not having to copy old meanings
of options...
As I wrote
> The flaw here is in "git branch" which by default list branches, but if give a name (and no option to specify an action) "git branch foo" will change its action to "create".
If "git branche" actually had needed an option to change its action to
create, what would it have been? --create or -c ?
And -n (as suggested in the table) is strongly associated with dry-run.
(not only in git)
If I look at the suggestion to replace -m by --merge, just so that -m
can be "move", then I seriously ask, what happens more often:
- Someone switching to a branch while having modifications in their
worktree (needing to merge)
- Someone creating a new branch, wanting to copy reflog/options
Given not only that switching to a new branch happens more often than
creating one (and thereby makes it alt least plausible, that the -m as
"merge" is required more often)..., but also that "git switch" is more
about switching than creating branches..., I believe that -m as "merge"
is entirely the better choice.
For the "git branch" features, if "git switch" should support them, they
could easily be made available as
--cc create and copy
--mv move
They - by all likelihood - are used less often, and should be the long
options. And a 2 letter long option is still easy to use.
^ permalink raw reply
* Git rebasing attribute the change to the wrong file [bug]
From: John Gabo @ 2024-02-20 20:01 UTC (permalink / raw)
To: git
Hello,
I think I found a bug in git, where a change get attributed to the
wrong file when doing a rebasing.
# Short summary
Assume `master_branch`
```
.
└── parent_folder
├── project_a
│ └── file.txt
└── project_b
└── file.txt # the 2 file.txt have the same content on master
```
Assume `feature_branch` from master
```
.
└── parent_folder
├── project_a
│ └── file.txt
└── project_b
└── file.txt # this file got modified with a feature
```
Assume `refactor_branch` from master
```
.
└── refactored_parent_folder # got renamed
├── project_a
│ └── file.txt
└── project_b
└── file.txt
```
then rebase `feature_branch` on `refactor_branch`,
```
.
└── refactored_parent_folder
├── project_a
│ └── file.txt # the feature got moved here !
└── project_b
└── file.txt # instead of here, where it should be !
```
# Reproduction bash script
```
#!/usr/bin/env bash
# tested on linux, git version 2.34.1, 2.43.2.
set -ex
# create a master branch
mkdir -p git_repo
cd git_repo
git init
mkdir -p parent_folder/project_a
echo -e "1\n2\n3" > parent_folder/project_a/file.txt
cp -r parent_folder/project_a parent_folder/project_b
git add .
git commit -m "initial commit"
# we create a feature_branch from master
git branch "feature_branch"
# we create a refactoring_branch from master
git checkout -b "refactoring_branch"
git mv parent_folder refactored_parent_folder
git add .
git commit -m "refactor"
# we create a new feature in project_b
git checkout "feature_branch"
echo -e "1\n2_some_new_feature_in_project_b\n3" >
parent_folder/project_b/file.txt
git add .
git commit -m "new feature"
# we rebase
git rebase refactoring_branch
cat refactored_parent_folder/project_a/file.txt
# refactored_parent_folder/project_a/file.txt contains the line
2_some_new_feature_in_project_I think I found a bug in gitb, which is
WRONG !
# It should have ended up in refactored_parent_folder/project_b/file.txt
```
# ENV
tested on linux, git version 2.34.1, 2.43.2 are affected
[System Info]
git version:
git version 2.43.2
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.5.0-18-generic #18~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC
Wed Feb 7 11:40:03 UTC 2 x86_64
compiler info: gnuc: 11.4
libc info: glibc: 2.35
$SHELL (typically, interactive shell): /usr/bin/zsh
[Enabled Hooks]
^ permalink raw reply
* [PATCH] branch: adjust documentation
From: Rubén Justo @ 2024-02-20 20:25 UTC (permalink / raw)
To: Junio C Hamano, Dragan Simic; +Cc: git
In-Reply-To: <16c1f883-881f-4f8c-95b2-22fb4825b733@gmail.com>
Adjust the placeholders we use in Documentation/git-branch.txt to what
we say in CodingGuideLines:
If a placeholder has multiple words, they are separated by dashes:
<new-branch-name>
--template=<template-directory>
Best viewed with --word-diff.
Signed-off-by: Rubén Justo <rjusto@gmail.com>
---
Documentation/git-branch.txt | 54 +++++++++++++++++-------------------
1 file changed, 25 insertions(+), 29 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 0b08442932..489507e25f 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -17,13 +17,13 @@ SYNOPSIS
[(-r | --remotes) | (-a | --all)]
[--list] [<pattern>...]
'git branch' [--track[=(direct|inherit)] | --no-track] [-f]
- [--recurse-submodules] <branchname> [<start-point>]
-'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]
-'git branch' --unset-upstream [<branchname>]
-'git branch' (-m | -M) [<oldbranch>] <newbranch>
-'git branch' (-c | -C) [<oldbranch>] <newbranch>
-'git branch' (-d | -D) [-r] <branchname>...
-'git branch' --edit-description [<branchname>]
+ [--recurse-submodules] <new-branch> [<start-point>]
+'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branch>]
+'git branch' --unset-upstream [<branch>]
+'git branch' (-m | -M) [<branch>] <new-branch>
+'git branch' (-c | -C) [<branch>] <new-branch>
+'git branch' (-d | -D) [-r] <branch>...
+'git branch' --edit-description [<branch>]
DESCRIPTION
-----------
@@ -53,7 +53,7 @@ branches not merged into the named commit will be listed. If the <commit>
argument is missing it defaults to `HEAD` (i.e. the tip of the current
branch).
-The command's second form creates a new branch head named <branchname>
+The command's second form creates a new branch head named <new-branch>
which points to the current `HEAD`, or <start-point> if given. As a
special case, for <start-point>, you may use `"A...B"` as a shortcut for
the merge base of `A` and `B` if there is exactly one merge base. You
@@ -61,7 +61,7 @@ can leave out at most one of `A` and `B`, in which case it defaults to
`HEAD`.
Note that this will create the new branch, but it will not switch the
-working tree to it; use "git switch <newbranch>" to switch to the
+working tree to it; use "git switch <new-branch>" to switch to the
new branch.
When a local branch is started off a remote-tracking branch, Git sets up the
@@ -72,17 +72,17 @@ the remote-tracking branch. This behavior may be changed via the global
overridden by using the `--track` and `--no-track` options, and
changed later using `git branch --set-upstream-to`.
-With a `-m` or `-M` option, <oldbranch> will be renamed to <newbranch>.
-If <oldbranch> had a corresponding reflog, it is renamed to match
-<newbranch>, and a reflog entry is created to remember the branch
-renaming. If <newbranch> exists, -M must be used to force the rename
+With a `-m` or `-M` option, <branch> will be renamed to <new-branch>.
+If <branch> had a corresponding reflog, it is renamed to match
+<new-branch>, and a reflog entry is created to remember the branch
+renaming. If <new-branch> exists, -M must be used to force the rename
to happen.
The `-c` and `-C` options have the exact same semantics as `-m` and
`-M`, except instead of the branch being renamed, it will be copied to a
new name, along with its config and reflog.
-With a `-d` or `-D` option, `<branchname>` will be deleted. You may
+With a `-d` or `-D` option, `<branch>` will be deleted. You may
specify more than one branch for deletion. If the branch currently
has a reflog then the reflog will also be deleted.
@@ -107,7 +107,7 @@ OPTIONS
--create-reflog::
Create the branch's reflog. This activates recording of
all changes made to the branch ref, enabling use of date
- based sha1 expressions such as "<branchname>@\{yesterday}".
+ based sha1 expressions such as "<branch>@\{yesterday}".
Note that in non-bare repositories, reflogs are usually
enabled by default by the `core.logAllRefUpdates` config option.
The negated form `--no-create-reflog` only overrides an earlier
@@ -116,7 +116,7 @@ OPTIONS
-f::
--force::
- Reset <branchname> to <start-point>, even if <branchname> exists
+ Reset <new-branch> to <start-point>, even if <new-branch> exists
already. Without `-f`, 'git branch' refuses to change an existing branch.
In combination with `-d` (or `--delete`), allow deleting the
branch irrespective of its merged status, or whether it even
@@ -124,8 +124,8 @@ OPTIONS
`-m` (or `--move`), allow renaming the branch even if the new
branch name already exists, the same applies for `-c` (or `--copy`).
+
-Note that 'git branch -f <branchname> [<start-point>]', even with '-f',
-refuses to change an existing branch `<branchname>` that is checked out
+Note that 'git branch -f <new-branch> [<start-point>]', even with '-f',
+refuses to change an existing branch `<new-branch>` that is checked out
in another worktree linked to the same repository.
-m::
@@ -255,7 +255,7 @@ how the `branch.<name>.remote` and `branch.<name>.merge` options are used.
linkgit:git-config[1]. Currently, only branch creation is
supported.
+
-When used in branch creation, a new branch <branchname> will be created
+When used in branch creation, a new branch <new-branch> will be created
in the superproject and all of the submodules in the superproject's
<start-point>. In submodules, the branch will point to the submodule
commit in the superproject's <start-point> but the branch's tracking
@@ -270,12 +270,12 @@ superproject's "origin/main", but tracks the submodule's "origin/main".
-u <upstream>::
--set-upstream-to=<upstream>::
- Set up <branchname>'s tracking information so <upstream> is
- considered <branchname>'s upstream branch. If no <branchname>
+ Set up <branch>'s tracking information so <upstream> is
+ considered <branch>'s upstream branch. If no <branch>
is specified, then it defaults to the current branch.
--unset-upstream::
- Remove the upstream information for <branchname>. If no branch
+ Remove the upstream information for <branch>. If no branch
is specified it defaults to the current branch.
--edit-description::
@@ -300,8 +300,8 @@ superproject's "origin/main", but tracks the submodule's "origin/main".
Only list branches whose tips are not reachable from the
specified commit (HEAD if not specified). Implies `--list`.
-<branchname>::
- The name of the branch to create or delete.
+<new-branch>::
+ The name of the branch to create.
The new branch name must pass all checks defined by
linkgit:git-check-ref-format[1]. Some of these checks
may restrict the characters allowed in a branch name.
@@ -311,14 +311,10 @@ superproject's "origin/main", but tracks the submodule's "origin/main".
given as a branch name, a commit-id, or a tag. If this
option is omitted, the current HEAD will be used instead.
-<oldbranch>::
+<branch>::
The name of an existing branch. If this option is omitted,
the name of the current branch will be used instead.
-<newbranch>::
- The new name for an existing branch. The same restrictions as for
- <branchname> apply.
-
--sort=<key>::
Sort based on the key given. Prefix `-` to sort in descending
order of the value. You may use the --sort=<key> option
--
2.44.0.rc2
^ permalink raw reply related
* Re: [PATCH] branch: adjust documentation
From: Dragan Simic @ 2024-02-20 20:34 UTC (permalink / raw)
To: Rubén Justo; +Cc: Junio C Hamano, git
In-Reply-To: <96f1afa6-f4ac-4593-9bf4-72dafe3cab85@gmail.com>
On 2024-02-20 21:25, Rubén Justo wrote:
> Adjust the placeholders we use in Documentation/git-branch.txt to what
> we say in CodingGuideLines:
>
> If a placeholder has multiple words, they are separated by dashes:
> <new-branch-name>
> --template=<template-directory>
>
> Best viewed with --word-diff.
>
> Signed-off-by: Rubén Justo <rjusto@gmail.com>
Looking good to me!
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
> ---
>
> Documentation/git-branch.txt | 54 +++++++++++++++++-------------------
> 1 file changed, 25 insertions(+), 29 deletions(-)
>
> diff --git a/Documentation/git-branch.txt
> b/Documentation/git-branch.txt
> index 0b08442932..489507e25f 100644
> --- a/Documentation/git-branch.txt
> +++ b/Documentation/git-branch.txt
> @@ -17,13 +17,13 @@ SYNOPSIS
> [(-r | --remotes) | (-a | --all)]
> [--list] [<pattern>...]
> 'git branch' [--track[=(direct|inherit)] | --no-track] [-f]
> - [--recurse-submodules] <branchname> [<start-point>]
> -'git branch' (--set-upstream-to=<upstream> | -u <upstream>)
> [<branchname>]
> -'git branch' --unset-upstream [<branchname>]
> -'git branch' (-m | -M) [<oldbranch>] <newbranch>
> -'git branch' (-c | -C) [<oldbranch>] <newbranch>
> -'git branch' (-d | -D) [-r] <branchname>...
> -'git branch' --edit-description [<branchname>]
> + [--recurse-submodules] <new-branch> [<start-point>]
> +'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branch>]
> +'git branch' --unset-upstream [<branch>]
> +'git branch' (-m | -M) [<branch>] <new-branch>
> +'git branch' (-c | -C) [<branch>] <new-branch>
> +'git branch' (-d | -D) [-r] <branch>...
> +'git branch' --edit-description [<branch>]
>
> DESCRIPTION
> -----------
> @@ -53,7 +53,7 @@ branches not merged into the named commit will be
> listed. If the <commit>
> argument is missing it defaults to `HEAD` (i.e. the tip of the current
> branch).
>
> -The command's second form creates a new branch head named <branchname>
> +The command's second form creates a new branch head named <new-branch>
> which points to the current `HEAD`, or <start-point> if given. As a
> special case, for <start-point>, you may use `"A...B"` as a shortcut
> for
> the merge base of `A` and `B` if there is exactly one merge base. You
> @@ -61,7 +61,7 @@ can leave out at most one of `A` and `B`, in which
> case it defaults to
> `HEAD`.
>
> Note that this will create the new branch, but it will not switch the
> -working tree to it; use "git switch <newbranch>" to switch to the
> +working tree to it; use "git switch <new-branch>" to switch to the
> new branch.
>
> When a local branch is started off a remote-tracking branch, Git sets
> up the
> @@ -72,17 +72,17 @@ the remote-tracking branch. This behavior may be
> changed via the global
> overridden by using the `--track` and `--no-track` options, and
> changed later using `git branch --set-upstream-to`.
>
> -With a `-m` or `-M` option, <oldbranch> will be renamed to
> <newbranch>.
> -If <oldbranch> had a corresponding reflog, it is renamed to match
> -<newbranch>, and a reflog entry is created to remember the branch
> -renaming. If <newbranch> exists, -M must be used to force the rename
> +With a `-m` or `-M` option, <branch> will be renamed to <new-branch>.
> +If <branch> had a corresponding reflog, it is renamed to match
> +<new-branch>, and a reflog entry is created to remember the branch
> +renaming. If <new-branch> exists, -M must be used to force the rename
> to happen.
>
> The `-c` and `-C` options have the exact same semantics as `-m` and
> `-M`, except instead of the branch being renamed, it will be copied to
> a
> new name, along with its config and reflog.
>
> -With a `-d` or `-D` option, `<branchname>` will be deleted. You may
> +With a `-d` or `-D` option, `<branch>` will be deleted. You may
> specify more than one branch for deletion. If the branch currently
> has a reflog then the reflog will also be deleted.
>
> @@ -107,7 +107,7 @@ OPTIONS
> --create-reflog::
> Create the branch's reflog. This activates recording of
> all changes made to the branch ref, enabling use of date
> - based sha1 expressions such as "<branchname>@\{yesterday}".
> + based sha1 expressions such as "<branch>@\{yesterday}".
> Note that in non-bare repositories, reflogs are usually
> enabled by default by the `core.logAllRefUpdates` config option.
> The negated form `--no-create-reflog` only overrides an earlier
> @@ -116,7 +116,7 @@ OPTIONS
>
> -f::
> --force::
> - Reset <branchname> to <start-point>, even if <branchname> exists
> + Reset <new-branch> to <start-point>, even if <new-branch> exists
> already. Without `-f`, 'git branch' refuses to change an existing
> branch.
> In combination with `-d` (or `--delete`), allow deleting the
> branch irrespective of its merged status, or whether it even
> @@ -124,8 +124,8 @@ OPTIONS
> `-m` (or `--move`), allow renaming the branch even if the new
> branch name already exists, the same applies for `-c` (or `--copy`).
> +
> -Note that 'git branch -f <branchname> [<start-point>]', even with
> '-f',
> -refuses to change an existing branch `<branchname>` that is checked
> out
> +Note that 'git branch -f <new-branch> [<start-point>]', even with
> '-f',
> +refuses to change an existing branch `<new-branch>` that is checked
> out
> in another worktree linked to the same repository.
>
> -m::
> @@ -255,7 +255,7 @@ how the `branch.<name>.remote` and
> `branch.<name>.merge` options are used.
> linkgit:git-config[1]. Currently, only branch creation is
> supported.
> +
> -When used in branch creation, a new branch <branchname> will be
> created
> +When used in branch creation, a new branch <new-branch> will be
> created
> in the superproject and all of the submodules in the superproject's
> <start-point>. In submodules, the branch will point to the submodule
> commit in the superproject's <start-point> but the branch's tracking
> @@ -270,12 +270,12 @@ superproject's "origin/main", but tracks the
> submodule's "origin/main".
>
> -u <upstream>::
> --set-upstream-to=<upstream>::
> - Set up <branchname>'s tracking information so <upstream> is
> - considered <branchname>'s upstream branch. If no <branchname>
> + Set up <branch>'s tracking information so <upstream> is
> + considered <branch>'s upstream branch. If no <branch>
> is specified, then it defaults to the current branch.
>
> --unset-upstream::
> - Remove the upstream information for <branchname>. If no branch
> + Remove the upstream information for <branch>. If no branch
> is specified it defaults to the current branch.
>
> --edit-description::
> @@ -300,8 +300,8 @@ superproject's "origin/main", but tracks the
> submodule's "origin/main".
> Only list branches whose tips are not reachable from the
> specified commit (HEAD if not specified). Implies `--list`.
>
> -<branchname>::
> - The name of the branch to create or delete.
> +<new-branch>::
> + The name of the branch to create.
> The new branch name must pass all checks defined by
> linkgit:git-check-ref-format[1]. Some of these checks
> may restrict the characters allowed in a branch name.
> @@ -311,14 +311,10 @@ superproject's "origin/main", but tracks the
> submodule's "origin/main".
> given as a branch name, a commit-id, or a tag. If this
> option is omitted, the current HEAD will be used instead.
>
> -<oldbranch>::
> +<branch>::
> The name of an existing branch. If this option is omitted,
> the name of the current branch will be used instead.
>
> -<newbranch>::
> - The new name for an existing branch. The same restrictions as for
> - <branchname> apply.
> -
> --sort=<key>::
> Sort based on the key given. Prefix `-` to sort in descending
> order of the value. You may use the --sort=<key> option
^ permalink raw reply
* Bug: impure renames may be reported as pure renames
From: Mário Guimarães @ 2024-02-20 20:58 UTC (permalink / raw)
To: git
Hello Git community,
please see the report below of what may be a bug.
Yours sincerely
Mário Guimarães
======================================================
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
In the rust-lang/rust repository (I cloned today from GitHub), if we
run the command
git diff-tree -r -M a04e649^2 a04e649 --
tests/ui/issues/issue-83190.rs
tests/ui/type-alias-impl-trait/nested-rpit-with-lifetimes.rs
we get this result
:100644 100644 da931c3edaf6f9de6805e771f2b3b28edd27001f
11b659eec97323ea5190dac1771c7ca3241861e7 R100
tests/ui/issues/issue-83190.rs
tests/ui/type-alias-impl-trait/nested-rpit-with-lifetimes.rs
However, the source and destination files of the rename are not 100%
equal. If we run this other command
git diff -M a04e649^2 a04e649 -- tests/ui/issues/issue-83190.rs
tests/ui/type-alias-impl-trait/nested-rpit-with-lifetimes.rs
we get the following result
diff --git a/tests/ui/issues/issue-83190.rs
b/tests/ui/type-alias-impl-trait/nested-rpit-with-lifetimes.rs
similarity index 100%
rename from tests/ui/issues/issue-83190.rs
rename to tests/ui/type-alias-impl-trait/nested-rpit-with-lifetimes.rs
index da931c3edaf..11b659eec97 100644
--- a/tests/ui/issues/issue-83190.rs
+++ b/tests/ui/type-alias-impl-trait/nested-rpit-with-lifetimes.rs
@@ -1,7 +1,7 @@
-// check-pass
-
// Regression test for issue #83190, triggering an ICE in borrowck.
+// check-pass
+
pub trait Any {}
impl<T> Any for T {}
What did you expect to happen? (Expected behavior)
I was expecting to get from the `git diff-tree ...` command above a
status of `R099`, but never `R100` which should be reserved for pure
renames (i.e., renames with no content modifications).
In fact, if we search for pure renames only, by using the `-M100%`
option, such as running this command
git diff-tree -r -M100% a04e649^2 a04e649 --
tests/ui/issues/issue-83190.rs
tests/ui/type-alias-impl-trait/nested-rpit-with-lifetimes.rs
we get this output
:100644 000000 da931c3edaf6f9de6805e771f2b3b28edd27001f
0000000000000000000000000000000000000000 D
tests/ui/issues/issue-83190.rs
:000000 100644 0000000000000000000000000000000000000000
11b659eec97323ea5190dac1771c7ca3241861e7 A
tests/ui/type-alias-impl-trait/nested-rpit-with-lifetimes.rs
This suggests that the initial command in this report cannot return an
`R100` status, as doing so it contradicts this last command.
Note that we only get a rename in case we lower the similarity
percentage, as demonstrated by this other command using the `-M99%`
option
git diff-tree -r -M99% a04e649^2 a04e649 --
tests/ui/issues/issue-83190.rs
tests/ui/type-alias-impl-trait/nested-rpit-with-lifetimes.rs
which outputs
:100644 100644 da931c3edaf6f9de6805e771f2b3b28edd27001f
11b659eec97323ea5190dac1771c7ca3241861e7 R100
tests/ui/issues/issue-83190.rs
tests/ui/type-alias-impl-trait/nested-rpit-with-lifetimes.rs
in which we see again `R100`, whereas the correct status should be `R099`.
What happened instead? (Actual behavior)
What's different between what you expected and what actually happened?
Anything else you want to add:
The rename detection machinery should be fixed to report pure renames
(`R100`) only when the source and destination files have exactly the
same contents.
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[Info de sistema]
versão git:
git version 2.42.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Thu Jul 6 22:12:47
PDT 2023; root:xnu-7195.141.49.702.12~1/RELEASE_X86_64 x86_64
info de compilador: clang: 13.0.0 (clang-1300.0.29.30)
info de libc: informação libc indisponível
^ permalink raw reply
* [PATCH v3] documentation: send-email: use camel case consistently
From: Dragan Simic @ 2024-02-20 22:01 UTC (permalink / raw)
To: git; +Cc: gitster
Correct a few random "sendemail.*" configuration parameter names in the
documentation that, for some unknown reason and contrary to the expected,
didn't use camel case format.
The majority of the corrections are straightforward, by using camel case
to denote boundaries of the individual words that, stringed together, make
up configuration parameter names. A couple of abbreviations found in some
of the corrected configuration parameter names present some exceptions,
which are described in detail below.
First, there's "SSL" as the abbreviation for "Secure Sockets Layer". [1]
As such, it's written using all uppercase letters, which is pretty much the
general rule for making abbreviations, with some exceptions. For example,
one rather well-known exception to this general rule is "SoC", which is the
abbreviation for "system-on-chip". [2]
Second, there's "Cc" as the abbreviation for "carbon copy", which is another
exception. As the acronym for "carbon copy", "cc" (mind the all lowercase
letters) stems from the rather old times when, literally, carbon copies were
made. [3] Therefore, using "CC" (mind the all uppercase letters) or "cc"
(mind the all lowercase letters) would be technically correct in the email
domain, as the abbreviation or as mentioned in RFC2076, [4] respectively, but
the age of email has established "Cc" (mind the mixed uppercase and lowercase
letters) as some kind of de facto standard. [1][5][6] Moreover, some of the
git utilities, primarily git-send-email(1), already refer to making email
carbon copies as specifying "Cc:" email headers. As a result, "Cc" becomes
one of the exceptions to the general rule for making abbreviations.
[1] https://en.wikipedia.org/wiki/Transport_Layer_Security
[2] https://en.wikipedia.org/wiki/System_on_a_chip
[3] https://en.wikipedia.org/wiki/Carbon_copy
[4] https://datatracker.ietf.org/doc/html/rfc2076
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=212059
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=50826
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
---
Notes:
The version 3 includes further feedback from Junio, by adding a detailed
rationale for using "Cc" instead of "CC", while also using "SSL", to the
commit description. No code changes were introduced.
The version 2 includes feedback from Junio, by changing "Ssl" to "SSL"
in a couple of places where "sendemail.smtpSSLCertPath" is mentioned.
There are already instances of "SSL" being used, for example in various
"http.proxySSL*" configuration parameter names.
Documentation/config/sendemail.txt | 12 ++++++------
Documentation/git-send-email.txt | 18 +++++++++---------
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/Documentation/config/sendemail.txt b/Documentation/config/sendemail.txt
index 7fc770ee9e69..6a869d67eb90 100644
--- a/Documentation/config/sendemail.txt
+++ b/Documentation/config/sendemail.txt
@@ -8,7 +8,7 @@ sendemail.smtpEncryption::
See linkgit:git-send-email[1] for description. Note that this
setting is not subject to the 'identity' mechanism.
-sendemail.smtpsslcertpath::
+sendemail.smtpSSLCertPath::
Path to ca-certificates (either a directory or a single file).
Set it to an empty string to disable certificate verification.
@@ -62,27 +62,27 @@ sendemail.chainReplyTo::
sendemail.envelopeSender::
sendemail.from::
sendemail.headerCmd::
-sendemail.signedoffbycc::
+sendemail.signedOffByCc::
sendemail.smtpPass::
-sendemail.suppresscc::
+sendemail.suppressCc::
sendemail.suppressFrom::
sendemail.to::
-sendemail.tocmd::
+sendemail.toCmd::
sendemail.smtpDomain::
sendemail.smtpServer::
sendemail.smtpServerPort::
sendemail.smtpServerOption::
sendemail.smtpUser::
sendemail.thread::
sendemail.transferEncoding::
sendemail.validate::
sendemail.xmailer::
These configuration variables all provide a default for
linkgit:git-send-email[1] command-line options. See its
documentation for details.
-sendemail.signedoffcc (deprecated)::
- Deprecated alias for `sendemail.signedoffbycc`.
+sendemail.signedOffCc (deprecated)::
+ Deprecated alias for `sendemail.signedOffByCc`.
sendemail.smtpBatchSize::
Number of messages to be sent per connection, after that a relogin
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index d1ef6a204e68..8264f8738093 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -138,7 +138,7 @@ Note that no attempts whatsoever are made to validate the encoding.
--compose-encoding=<encoding>::
Specify encoding of compose message. Default is the value of the
- 'sendemail.composeencoding'; if that is unspecified, UTF-8 is assumed.
+ 'sendemail.composeEncoding'; if that is unspecified, UTF-8 is assumed.
--transfer-encoding=(7bit|8bit|quoted-printable|base64|auto)::
Specify the transfer encoding to be used to send the message over SMTP.
@@ -174,7 +174,7 @@ Sending
Specify a command to run to send the email. The command should
be sendmail-like; specifically, it must support the `-i` option.
The command will be executed in the shell if necessary. Default
- is the value of `sendemail.sendmailcmd`. If unspecified, and if
+ is the value of `sendemail.sendmailCmd`. If unspecified, and if
--smtp-server is also unspecified, git-send-email will search
for `sendmail` in `/usr/sbin`, `/usr/lib` and $PATH.
@@ -269,7 +269,7 @@ must be used for each option.
certificates concatenated together: see verify(1) -CAfile and
-CApath for more information on these). Set it to an empty string
to disable certificate verification. Defaults to the value of the
- `sendemail.smtpsslcertpath` configuration variable, if set, or the
+ `sendemail.smtpSSLCertPath` configuration variable, if set, or the
backing SSL library's compiled-in default otherwise (which should
be the best choice on most platforms).
@@ -313,7 +313,7 @@ Automating
Specify a command to execute once per patch file which
should generate patch file specific "To:" entries.
Output of this command must be single email address per line.
- Default is the value of 'sendemail.tocmd' configuration value.
+ Default is the value of 'sendemail.toCmd' configuration value.
--cc-cmd=<command>::
Specify a command to execute once per patch file which
@@ -348,19 +348,19 @@ Automating
--[no-]signed-off-by-cc::
If this is set, add emails found in the `Signed-off-by` trailer or Cc: lines to the
- cc list. Default is the value of `sendemail.signedoffbycc` configuration
+ cc list. Default is the value of `sendemail.signedOffByCc` configuration
value; if that is unspecified, default to --signed-off-by-cc.
--[no-]cc-cover::
If this is set, emails found in Cc: headers in the first patch of
the series (typically the cover letter) are added to the cc list
- for each email set. Default is the value of 'sendemail.cccover'
+ for each email set. Default is the value of 'sendemail.ccCover'
configuration value; if that is unspecified, default to --no-cc-cover.
--[no-]to-cover::
If this is set, emails found in To: headers in the first patch of
the series (typically the cover letter) are added to the to list
- for each email set. Default is the value of 'sendemail.tocover'
+ for each email set. Default is the value of 'sendemail.toCover'
configuration value; if that is unspecified, default to --no-to-cover.
--suppress-cc=<category>::
@@ -384,7 +384,7 @@ Automating
- 'all' will suppress all auto cc values.
--
+
-Default is the value of `sendemail.suppresscc` configuration value; if
+Default is the value of `sendemail.suppressCc` configuration value; if
that is unspecified, default to 'self' if --suppress-from is
specified, as well as 'body' if --no-signed-off-cc is specified.
@@ -471,7 +471,7 @@ Information
Instead of the normal operation, dump the shorthand alias names from
the configured alias file(s), one per line in alphabetical order. Note
that this only includes the alias name and not its expanded email addresses.
- See 'sendemail.aliasesfile' for more information about aliases.
+ See 'sendemail.aliasesFile' for more information about aliases.
CONFIGURATION
^ permalink raw reply related
* Re: [PATCH v3] documentation: send-email: use camel case consistently
From: Junio C Hamano @ 2024-02-20 22:08 UTC (permalink / raw)
To: Dragan Simic; +Cc: git
In-Reply-To: <877b5bec11caa8a328ee0d4f226fe0666fd35a10.1708466383.git.dsimic@manjaro.org>
Dragan Simic <dsimic@manjaro.org> writes:
> general rule for making abbreviations, with some exceptions. For example,
> one rather well-known exception to this general rule is "SoC", which is the
> abbreviation for "system-on-chip". [2]
I am not opposed to say "we allow spelling 'carbon copy' as 'Cc'
because too many people mistakenly use that capitalization pattern",
which is what you earlier said, though. As I said, I do not insist
one or the other capitalization, as long as it is backed by solid
reasoning that would not confuse future developers.
It is very common to omit upcasing prepositions, articles, etc. when
spelling acronyms in all capital, so "SoC" would not count as a good
example of an exception. That's the kind of bogus justification of
giving an exception to "Cc" I would rather want to avoid. It really
is only "Cc" that needs to justify exception in your patch.
^ permalink raw reply
* Re: [PATCH v3] documentation: send-email: use camel case consistently
From: Dragan Simic @ 2024-02-20 22:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq1q96okkb.fsf@gitster.g>
On 2024-02-20 23:08, Junio C Hamano wrote:
> Dragan Simic <dsimic@manjaro.org> writes:
>
>> general rule for making abbreviations, with some exceptions. For
>> example,
>> one rather well-known exception to this general rule is "SoC", which
>> is the
>> abbreviation for "system-on-chip". [2]
>
> I am not opposed to say "we allow spelling 'carbon copy' as 'Cc'
> because too many people mistakenly use that capitalization pattern",
> which is what you earlier said, though. As I said, I do not insist
> one or the other capitalization, as long as it is backed by solid
> reasoning that would not confuse future developers.
>
> It is very common to omit upcasing prepositions, articles, etc. when
> spelling acronyms in all capital, so "SoC" would not count as a good
> example of an exception. That's the kind of bogus justification of
> giving an exception to "Cc" I would rather want to avoid. It really
> is only "Cc" that needs to justify exception in your patch.
Alright, let's try v4 with no such examples.
^ permalink raw reply
* Re: [PATCH v3] documentation: send-email: use camel case consistently
From: Kristoffer Haugsbakk @ 2024-02-20 22:17 UTC (permalink / raw)
To: Dragan Simic; +Cc: Junio C Hamano, git
In-Reply-To: <877b5bec11caa8a328ee0d4f226fe0666fd35a10.1708466383.git.dsimic@manjaro.org>
On Tue, Feb 20, 2024, at 23:01, Dragan Simic wrote:
> Correct a few random "sendemail.*" configuration parameter names in the
> documentation that, for some unknown reason and contrary to the expected,
> didn't use camel case format.
Interesting. Consistency is good. Nice work.
PS: Please keep me on CC. I’m not subscribed to the list.
PPS: 😉
--
Kristoffer Haugsbakk
^ permalink raw reply
* Re: [PATCH v3] documentation: send-email: use camel case consistently
From: Dragan Simic @ 2024-02-20 22:21 UTC (permalink / raw)
To: Kristoffer Haugsbakk; +Cc: Junio C Hamano, git
In-Reply-To: <37c0c025-7120-49f3-bc2f-f35249339f3a@app.fastmail.com>
On 2024-02-20 23:17, Kristoffer Haugsbakk wrote:
> On Tue, Feb 20, 2024, at 23:01, Dragan Simic wrote:
>> Correct a few random "sendemail.*" configuration parameter names in
>> the
>> documentation that, for some unknown reason and contrary to the
>> expected,
>> didn't use camel case format.
>
> Interesting. Consistency is good. Nice work.
>
> PS: Please keep me on CC. I’m not subscribed to the list.
Sure, here comes the v4 to you as a virtual carbon copy. :)
^ permalink raw reply
* [PATCH v4] documentation: send-email: use camel case consistently
From: Dragan Simic @ 2024-02-20 22:22 UTC (permalink / raw)
To: git; +Cc: gitster, code
Correct a few random "sendemail.*" configuration parameter names in the
documentation that, for some unknown reason and contrary to the expected,
didn't use camel case format.
The majority of the corrections are straightforward, by using camel case
to denote boundaries of the individual words that, stringed together, make
up configuration parameter names. A couple of abbreviations found in some
of the corrected configuration parameter names present some exceptions,
which are described in detail below.
First, there's "SSL" as the abbreviation for "Secure Sockets Layer". [1]
As such, it's written using all uppercase letters, which is pretty much the
general rule for making abbreviations, although with certain exceptions.
Second, there's "Cc" as the abbreviation for "carbon copy", which is another
exception. As the acronym for "carbon copy", "cc" (mind the all lowercase
letters) stems from the rather old times when, literally, carbon copies were
made. [2] Therefore, using "CC" (mind the all uppercase letters) or "cc"
(mind the all lowercase letters) would be technically correct in the email
domain, as the abbreviation or as mentioned in RFC2076, [3] respectively, but
the age of email has established "Cc" (mind the mixed uppercase and lowercase
letters) as some kind of de facto standard. [1][4][5] Moreover, some of the
git utilities, primarily git-send-email(1), already refer to making email
carbon copies as specifying "Cc:" email headers. As a result, "Cc" becomes
one of the exceptions to the general rule for making abbreviations.
[1] https://en.wikipedia.org/wiki/Transport_Layer_Security
[2] https://en.wikipedia.org/wiki/Carbon_copy
[3] https://datatracker.ietf.org/doc/html/rfc2076
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=212059
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=50826
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
---
Notes:
The versions 3 and 4 include further feedback from Junio, by adding a
detailed rationale for using "Cc" instead of "CC", while also using "SSL",
to the commit description. No code changes were introduced.
The version 2 includes feedback from Junio, by changing "Ssl" to "SSL"
in a couple of places where "sendemail.smtpSSLCertPath" is mentioned.
There are already instances of "SSL" being used, for example in various
"http.proxySSL*" configuration parameter names.
Documentation/config/sendemail.txt | 12 ++++++------
Documentation/git-send-email.txt | 18 +++++++++---------
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/Documentation/config/sendemail.txt b/Documentation/config/sendemail.txt
index 7fc770ee9e69..6a869d67eb90 100644
--- a/Documentation/config/sendemail.txt
+++ b/Documentation/config/sendemail.txt
@@ -8,7 +8,7 @@ sendemail.smtpEncryption::
See linkgit:git-send-email[1] for description. Note that this
setting is not subject to the 'identity' mechanism.
-sendemail.smtpsslcertpath::
+sendemail.smtpSSLCertPath::
Path to ca-certificates (either a directory or a single file).
Set it to an empty string to disable certificate verification.
@@ -62,27 +62,27 @@ sendemail.chainReplyTo::
sendemail.envelopeSender::
sendemail.from::
sendemail.headerCmd::
-sendemail.signedoffbycc::
+sendemail.signedOffByCc::
sendemail.smtpPass::
-sendemail.suppresscc::
+sendemail.suppressCc::
sendemail.suppressFrom::
sendemail.to::
-sendemail.tocmd::
+sendemail.toCmd::
sendemail.smtpDomain::
sendemail.smtpServer::
sendemail.smtpServerPort::
sendemail.smtpServerOption::
sendemail.smtpUser::
sendemail.thread::
sendemail.transferEncoding::
sendemail.validate::
sendemail.xmailer::
These configuration variables all provide a default for
linkgit:git-send-email[1] command-line options. See its
documentation for details.
-sendemail.signedoffcc (deprecated)::
- Deprecated alias for `sendemail.signedoffbycc`.
+sendemail.signedOffCc (deprecated)::
+ Deprecated alias for `sendemail.signedOffByCc`.
sendemail.smtpBatchSize::
Number of messages to be sent per connection, after that a relogin
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index d1ef6a204e68..8264f8738093 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -138,7 +138,7 @@ Note that no attempts whatsoever are made to validate the encoding.
--compose-encoding=<encoding>::
Specify encoding of compose message. Default is the value of the
- 'sendemail.composeencoding'; if that is unspecified, UTF-8 is assumed.
+ 'sendemail.composeEncoding'; if that is unspecified, UTF-8 is assumed.
--transfer-encoding=(7bit|8bit|quoted-printable|base64|auto)::
Specify the transfer encoding to be used to send the message over SMTP.
@@ -174,7 +174,7 @@ Sending
Specify a command to run to send the email. The command should
be sendmail-like; specifically, it must support the `-i` option.
The command will be executed in the shell if necessary. Default
- is the value of `sendemail.sendmailcmd`. If unspecified, and if
+ is the value of `sendemail.sendmailCmd`. If unspecified, and if
--smtp-server is also unspecified, git-send-email will search
for `sendmail` in `/usr/sbin`, `/usr/lib` and $PATH.
@@ -269,7 +269,7 @@ must be used for each option.
certificates concatenated together: see verify(1) -CAfile and
-CApath for more information on these). Set it to an empty string
to disable certificate verification. Defaults to the value of the
- `sendemail.smtpsslcertpath` configuration variable, if set, or the
+ `sendemail.smtpSSLCertPath` configuration variable, if set, or the
backing SSL library's compiled-in default otherwise (which should
be the best choice on most platforms).
@@ -313,7 +313,7 @@ Automating
Specify a command to execute once per patch file which
should generate patch file specific "To:" entries.
Output of this command must be single email address per line.
- Default is the value of 'sendemail.tocmd' configuration value.
+ Default is the value of 'sendemail.toCmd' configuration value.
--cc-cmd=<command>::
Specify a command to execute once per patch file which
@@ -348,19 +348,19 @@ Automating
--[no-]signed-off-by-cc::
If this is set, add emails found in the `Signed-off-by` trailer or Cc: lines to the
- cc list. Default is the value of `sendemail.signedoffbycc` configuration
+ cc list. Default is the value of `sendemail.signedOffByCc` configuration
value; if that is unspecified, default to --signed-off-by-cc.
--[no-]cc-cover::
If this is set, emails found in Cc: headers in the first patch of
the series (typically the cover letter) are added to the cc list
- for each email set. Default is the value of 'sendemail.cccover'
+ for each email set. Default is the value of 'sendemail.ccCover'
configuration value; if that is unspecified, default to --no-cc-cover.
--[no-]to-cover::
If this is set, emails found in To: headers in the first patch of
the series (typically the cover letter) are added to the to list
- for each email set. Default is the value of 'sendemail.tocover'
+ for each email set. Default is the value of 'sendemail.toCover'
configuration value; if that is unspecified, default to --no-to-cover.
--suppress-cc=<category>::
@@ -384,7 +384,7 @@ Automating
- 'all' will suppress all auto cc values.
--
+
-Default is the value of `sendemail.suppresscc` configuration value; if
+Default is the value of `sendemail.suppressCc` configuration value; if
that is unspecified, default to 'self' if --suppress-from is
specified, as well as 'body' if --no-signed-off-cc is specified.
@@ -471,7 +471,7 @@ Information
Instead of the normal operation, dump the shorthand alias names from
the configured alias file(s), one per line in alphabetical order. Note
that this only includes the alias name and not its expanded email addresses.
- See 'sendemail.aliasesfile' for more information about aliases.
+ See 'sendemail.aliasesFile' for more information about aliases.
CONFIGURATION
^ permalink raw reply related
* [PATCH 0/3] Doc placeholders
From: Jean-Noël Avila via GitGitGadget @ 2024-02-20 22:32 UTC (permalink / raw)
To: git; +Cc: Jean-Noël Avila
Here a few commits of some typos/mistakes found while translating the
manpages.
Jean-Noël Avila (3):
doc: git-rev-parse: enforce command-line description syntax
doc: git-clone fix missing placeholder end carret
doc: add some missing sentence dots.
Documentation/config/diff.txt | 4 ++--
Documentation/git-clone.txt | 2 +-
Documentation/git-fast-export.txt | 2 +-
Documentation/git-rev-parse.txt | 24 ++++++++++++------------
4 files changed, 16 insertions(+), 16 deletions(-)
base-commit: 5fdd5b989cbe5096d44e89861a92b2dd47c279d9
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1670%2Fjnavila%2Fdoc_placeholders-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1670/jnavila/doc_placeholders-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1670
--
gitgitgadget
^ permalink raw reply
* [PATCH 1/3] doc: git-rev-parse: enforce command-line description syntax
From: Jean-Noël Avila via GitGitGadget @ 2024-02-20 22:32 UTC (permalink / raw)
To: git; +Cc: Jean-Noël Avila, Jean-Noël Avila
In-Reply-To: <pull.1670.git.1708468374.gitgitgadget@gmail.com>
From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
git-rev-parse(1) manpage is completely off with respect to the
command-line description syntax with badly formatted placeholders and
malformed alternatives.
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
---
Documentation/git-rev-parse.txt | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 546faf90177..5d83dd36da1 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -9,7 +9,7 @@ git-rev-parse - Pick out and massage parameters
SYNOPSIS
--------
[verse]
-'git rev-parse' [<options>] <args>...
+'git rev-parse' [<options>] <arg>...
DESCRIPTION
-----------
@@ -130,7 +130,7 @@ for another option.
'git diff-{asterisk}'). In contrast to the `--sq-quote` option,
the command input is still interpreted as usual.
---short[=length]::
+--short[=<length>]::
Same as `--verify` but shortens the object name to a unique
prefix with at least `length` characters. The minimum length
is 4, the default is the effective value of the `core.abbrev`
@@ -165,9 +165,9 @@ Options for Objects
--all::
Show all refs found in `refs/`.
---branches[=pattern]::
---tags[=pattern]::
---remotes[=pattern]::
+--branches[=<pattern>]::
+--tags[=<pattern>]::
+--remotes[=<pattern>]::
Show all branches, tags, or remote-tracking branches,
respectively (i.e., refs found in `refs/heads`,
`refs/tags`, or `refs/remotes`, respectively).
@@ -176,7 +176,7 @@ If a `pattern` is given, only refs matching the given shell glob are
shown. If the pattern does not contain a globbing character (`?`,
`*`, or `[`), it is turned into a prefix match by appending `/*`.
---glob=pattern::
+--glob=<pattern>::
Show all refs matching the shell glob pattern `pattern`. If
the pattern does not start with `refs/`, this is automatically
prepended. If the pattern does not contain a globbing
@@ -197,7 +197,7 @@ respectively, and they must begin with `refs/` when applied to `--glob`
or `--all`. If a trailing '/{asterisk}' is intended, it must be given
explicitly.
---exclude-hidden=[fetch|receive|uploadpack]::
+--exclude-hidden=(fetch|receive|uploadpack)::
Do not include refs that would be hidden by `git-fetch`,
`git-receive-pack` or `git-upload-pack` by consulting the appropriate
`fetch.hideRefs`, `receive.hideRefs` or `uploadpack.hideRefs`
@@ -314,17 +314,17 @@ The following options are unaffected by `--path-format`:
Other Options
~~~~~~~~~~~~~
---since=datestring::
---after=datestring::
+--since=<datestring>::
+--after=<datestring>::
Parse the date string, and output the corresponding
--max-age= parameter for 'git rev-list'.
---until=datestring::
---before=datestring::
+--until=<datestring>::
+--before=<datestring>::
Parse the date string, and output the corresponding
--min-age= parameter for 'git rev-list'.
-<args>...::
+<arg>...::
Flags and parameters to be parsed.
--
gitgitgadget
^ permalink raw reply related
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