Skip to content

Tags: gitgitgadget/git

Tags

pr-1864/dscho/fix-renaming-symlinks-on-windows-v1

compat/mingw: rename the symlink, not the target

From: Eliah Kagan <eliah.kagan@gmail.com>

Since 183ea3e [1], a new technique is used on Windows to rename files,
where supported. The first step of this technique is to open the file
with `CreateFileW`. At that time, `FILE_ATTRIBUTE_NORMAL` was passed as
the value of the `dwFlagsAndAttributes` argument. In b30404d [2], this
was improved by passing `FILE_FLAG_BACKUP_SEMANTICS`, to support
directories as well as regular files.

However, neither value of `dwFlagsAndAttributes` is sufficient to open
a symbolic link with the correct semantics to rename it. Symlinks on
Windows are reparse points. Attempting to open a reparse point with
`CreateFileW` dereferences the reparse point and opens the target
instead, unless `FILE_FLAG_OPEN_REPARSE_POINT` is included in
`dwFlagsAndAttributes`. This is documented for that flag and in the
"Symbolic Link Behavior" section of the `CreateFileW` docs [3].

This produces a regression where attempting to rename a symlink on
Windows renames its target to the intended new name and location of the
symlink. For example, if `symlink` points to `file`, then running

    git mv symlink symlink-renamed

leaves `symlink` in place and unchanged, but renames `file` to
`symlink-renamed` [4].

This regression is detectable by existing tests in `t7001-mv.sh`, but
the tests must be run by a Windows user with the ability to create
symlinks, and the `ln -s` command used to create the initial symlink
must also be able to create a real symlink (such as by setting the
`MSYS` environment variable to `winsymlinks:nativestrict`). Then
these two tests fail if the regression is present, and pass otherwise:

    38 - git mv should overwrite file with a symlink
    39 - check moved symlink

Let's fix this, so that renaming a symlink again renames the symlink
itself and leaves the target unchanged, by passing

    FILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_OPEN_REPARSE_POINT

as the `dwFlagsAndAttributes` argument. This is sufficient (and safe)
because including `FILE_FLAG_OPEN_REPARSE_POINT` causes no harm even
when used to open a file or directory that is not a reparse point. In
that case, as noted in [3], this flag is simply ignored.

[1]: git-for-windows@183ea3e
[2]: git-for-windows@b30404d
[3]: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew
[4]: git-for-windows#5436

Signed-off-by: Eliah Kagan <eliah.kagan@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Submitted-As: https://lore.kernel.org/git/pull.1864.git.1740139296483.gitgitgadget@gmail.com

pr-1863/phillipwood/add-p-split-hunks-are-undecided-v1

add -p: a couple of hunk splitting fixes

This series fixes a couple of infelicities when splitting hunks that have
already been selected or edited which I noticed a while ago when preparing
the test for 'pw/add-patch-with-suppress-blank-empty'.

Phillip Wood (2):
  add -p: mark split hunks as undecided
  add-patch: update hunk splitability after editing

 add-patch.c                | 15 +++++++++++++--
 t/t3701-add-interactive.sh | 31 +++++++++++++++++++++++++++++++
 2 files changed, 44 insertions(+), 2 deletions(-)

base-commit: 0394451

Submitted-As: https://lore.kernel.org/git/pull.1863.git.1740149837.gitgitgadget@gmail.com

pr-git-1886/kkato233/fix_filename_encoding-v1

gitk: Fixing file name encoding issues.

fix: file name encoding issues. fix: when resolving merge conflicts,
japanese file names become garbled.

Kazuhiro Kato (2):
  Fixing file name encoding issues.
  fix: when resolving merge conflicts, japanese file names become
    garbled.

 gitk-git/gitk | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

base-commit: bc204b7

Submitted-As: https://lore.kernel.org/git/pull.1886.git.git.1739918546.gitgitgadget@gmail.com

pr-1862/phillipwood/merge-tree-flush-v2

merge-tree --stdin: flush stdout

Thanks to Elijah for his comments on V1. I've updated the commit message of
patch 2 as he suggested. The rest of the patches are unchanged.

V1 Cover Letter:

I tried to squash some fixup commits with "git merge-tree --stdin" and found
that my script deadlocked because the output of "git merge-tree" is not
flushed after each merge. The first patch fixes that and the rest are
cleanups I noticed while reading the code and documentation. This series is
based on maint.

Phillip Wood (5):
  merge-tree --stdin: flush stdout to avoid deadlock
  merge-tree: remove redundant code
  merge-tree: only use basic merge config
  merge-tree: improve docs for --stdin
  merge-tree: fix link formatting in html docs

 Documentation/git-merge-tree.txt | 11 ++++++++---
 builtin/merge-tree.c             | 11 +++++------
 2 files changed, 13 insertions(+), 9 deletions(-)

base-commit: f93ff17

Submitted-As: https://lore.kernel.org/git/pull.1862.v2.git.1739895879.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.1862.git.1739723829.gitgitgadget@gmail.com

pr-1852/asilano/autocorrect-allow-prompt-default-yes-v2

help: add prompt-yes setting for autocorrect

From: Chris Howlett <chowlett09@gmail.com>

The help.autocorrect functionality is really useful, saving frustration
when a dev fat-fingers a command, and git has a pretty good idea what
was originally intended. The config settings are a nice selection, with
"prompt" asking the user to confirm that they want to run the assumed
command.

However, with "prompt", the choice defaults to "No" - that is, hitting
return will _not_ run the command. For me at least, if git is confident
it knows which command I wanted, it's usually right, and the golden path
would be to run the command.

Therefore this patch adds "prompt-yes" as a counterpart config setting
for help.autocorrect, which does the same as "prompt", but defaults to
"Yes" - hitting return will run the assumed command.

I have not added any tests because the test suite doesn't have any tests
(that I could find) for the "prompt" behaviour - I'm assuming this is
because it's hard/impossible to simulate the interactive terminal prompt

Signed-off-by: Chris Howlett <chowlett09@gmail.com>

Submitted-As: https://lore.kernel.org/git/pull.1852.v2.git.1739801960334.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.1852.git.1736933815236.gitgitgadget@gmail.com

pr-git-1893/hickford/title-v2

doc: use 'title' consistently

From: M Hickford <mirth.hickford@gmail.com>

The first line of a commit message is variously called 'title' or
'subject'.

Prefer 'title' unless discussing email.

Signed-off-by: M Hickford <mirth.hickford@gmail.com>

Submitted-As: https://lore.kernel.org/git/pull.1893.v2.git.git.1739739761445.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.1893.git.git.1739477118350.gitgitgadget@gmail.com

pr-1862/phillipwood/merge-tree-flush-v1

merge-tree --stdin: flush stdout

I tried to squash some fixup commits with "git merge-tree --stdin" and found
that my script deadlocked because the output of "git merge-tree" is not
flushed after each merge. The first patch fixes that and the rest are
cleanups I noticed while reading the code and documentation. This series is
based on maint.

Phillip Wood (5):
  merge-tree --stdin: flush stdout to avoid deadlock
  merge-tree: remove redundant code
  merge-tree: only use basic merge config
  merge-tree: improve docs for --stdin
  merge-tree: fix link formatting in html docs

 Documentation/git-merge-tree.txt | 11 ++++++++---
 builtin/merge-tree.c             | 11 +++++------
 2 files changed, 13 insertions(+), 9 deletions(-)

base-commit: f93ff17

Submitted-As: https://lore.kernel.org/git/pull.1862.git.1739723829.gitgitgadget@gmail.com

pr-git-1894/phil-blain/follow-remote-head-doc-v1

Documentation: fixups following followRemoteHEAD

A small fixup and a wording improvement for the documentation of
remote.<name>.followRemoteHEAD.

Bence, thanks a lot for this new option, it is something I've been wanting
for a long time!

Philippe Blain (2):
  config/remote.txt: reunite 'severOption' description paragraphs
  config/remote.txt: improve wording for
    'remote.<name>.followRemoteHEAD'

 Documentation/config/remote.txt | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

base-commit: e2067b4

Submitted-As: https://lore.kernel.org/git/pull.1894.git.git.1739554578.gitgitgadget@gmail.com

pr-git-1893/hickford/title-v1

doc: use 'title' consistently

From: M Hickford <mirth.hickford@gmail.com>

The first line of a commit message is variously called 'title' or
'subject'.

Prefer 'title' unless discussing email.

Signed-off-by: M Hickford <mirth.hickford@gmail.com>

Submitted-As: https://lore.kernel.org/git/pull.1893.git.git.1739477118350.gitgitgadget@gmail.com

pr-1859/hickford/meson-credential-v1

meson: wire up contrib/credential

It would be neat to also run test t0303-credential-external with
GIT_TEST_CREDENTIAL_HELPER=wincred but I couldn't figure out how to do this.

M Hickford (2):
  meson: wire up credential-wincred
  meson: wire up credential-libsecret

 contrib/credential/libsecret/meson.build            | 3 +++
 contrib/credential/meson.build                      | 6 ++++++
 contrib/credential/wincred/git-credential-wincred.c | 2 ++
 contrib/credential/wincred/meson.build              | 1 +
 contrib/meson.build                                 | 1 +
 meson_options.txt                                   | 4 ++++
 6 files changed, 17 insertions(+)
 create mode 100644 contrib/credential/libsecret/meson.build
 create mode 100644 contrib/credential/meson.build
 create mode 100644 contrib/credential/wincred/meson.build

base-commit: e2067b4

Submitted-As: https://lore.kernel.org/git/pull.1859.git.1739471859.gitgitgadget@gmail.com