Marc Branchaud <marcnarc@xxxxxxxxxxx> writes:
> Signed-off-by: Marc Branchaud <marcnarc@xxxxxxxxxxx>
> ---
>
> Mostly just missing words and what I feel are clarifications.
>
> The biggest change is to the "git add -N" item. Not 100% sure
> I got it right.
>
> M.
> - * When new paths were added by "git add -N" to the index, it was
> - enough to circumvent the check by "git commit" to refrain from
> - making an empty commit without "--allow-empty". The same logic
> - prevented "git status" to show such a path as "new file" in the
> + * "git commit" created an empty commit when invoked with an index
> + consisting solely of intend-to-add paths (added with "git add -N").
> + It now requires the "--allow-empty" option to create such a commit.
> + The same logic prevented "git status" from showing such paths as "new files" in the
> "Changes not staged for commit" section.
Yes this is much easier to read. Greatly appreciated.
> * Codepaths that read from an on-disk loose object were too loose in
> - validating what they are reading is a proper object file and
> + validating that they are reading a proper object file and
> sometimes read past the data they read from the disk, which has
> been corrected. H/t to Gustavo Grieco for reporting.
> ...
> - * An author name, that spelled a backslash-quoted double quote in the
> - human readable part "My \"double quoted\" name", was not unquoted
> + * An author name that has a backslash-quoted double quote in the
> + human readable part ("My \"double quoted\" name"), was not unquoted
> correctly while applying a patch from a piece of e-mail.
> ...
> - * It is a common mistake to say "git blame --reverse OLD path",
> - expecting that the command line is dwimmed as if asking how lines
> + * "git blame --reverse OLD path" is now DWIMmed to show how lines
> in path in an old revision OLD have survived up to the current
> commit.
> (merge e1d09701a4 jc/blame-reverse later to maint).
> ...
> * The "submodule.<name>.path" stored in .gitmodules is never copied
> to .git/config and such a key in .git/config has no meaning, but
> - the documentation described it and submodule.<name>.url next to
> - each other as if both belong to .git/config. This has been fixed.
> + the documentation described it next to submodule.<name>.url
> + as if both belong to .git/config. This has been fixed.
These, too.
> - * In a worktree connected to a repository elsewhere, created via "git
> + * In a worktree created via "git
> worktree", "git checkout" attempts to protect users from confusion
> by refusing to check out a branch that is already checked out in
> another worktree. However, this also prevented checking out a
> - branch, which is designated as the primary branch of a bare
> + branch which is designated as the primary branch of a bare
> reopsitory, in a worktree that is connected to the bare
> repository. The check has been corrected to allow it.
This 'reopsitory' may already have been fixed ;-)
... goes and looks ...
Oops, no it hasn't. I'll patch it up while queuing this.
> - * A hot-fix for a test added by a recent topic that went to both
> + * Hot-fixed a test added by a recent topic that went to both
> 'master' and 'maint' already.
Oops; an entry like this shouldn't have been in the release notes in
the first place, because those who are seeing the released versions
would have never seen such breakages. Will try to remember removing
it.
Thanks, I missed this one completely even though you sent it out
last week and didn't have a chance to read it over before starting
today's integration cycle.