worktree add: improve message for ambiguous remote branch name

'git worktree add ../foo-dir bar-topic' fails to dwim when there are
multiple remote branches with name `bar-topic'. But it doesn't display
meaningful message as 'git checkout bar-topic' does under the same
situation.

We improve this by adding advice and modify the error message for worktree
add.

By Junio's suggestion, we include matched remote names in the advice. It is
applied to checkout, too.

Changes from the previous patch:

 * fix grammatical errors in hints
 * narrow the scope of local variable oid

Yoichi NAKAYAMA (3):
  checkout: extract function to display advice for ambiguous remotes
  checkout: improve message for ambiguous remote branch name
  worktree add: improve message for ambiguous remote branch name

 builtin/checkout.c      | 76 +++++++++++++++++++++++++----------------
 builtin/worktree.c      | 39 ++++++++++++++++++---
 checkout.c              | 14 ++++++--
 checkout.h              |  5 ++-
 t/t2400-worktree-add.sh |  4 +--
 5 files changed, 99 insertions(+), 39 deletions(-)

base-commit: dea0ea3

Submitted-As: https://lore.kernel.org/git/pull.2197.v7.git.1787368962.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2197.git.1786177301832.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2197.v2.git.1786374470383.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2197.v3.git.1786395305884.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2197.v4.git.1786430155244.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2197.v5.git.1787143859.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2197.v6.git.1787259838.gitgitgadget@gmail.com

treewide: migrate from legacy utime.h to utimensat

utime() function for setting access/modification time for files (and a
corresponding <utime.h> header) have been officially removed from POSIX
starting from POSIX.1-2024. While existing system library implementations
still provide this function for compatibility reasons, its implementation
may be removed in the future, or otherwise degrade over time. Some newer
libc implementations (e.g. LLVM-libc, currently under development) don't
provide utime() function at all.

This PR switches the git codebase to recommended alternative: utimensat()
POSIX function (which supports nanosecond-level precision) from <fcntl.h>,
and, as a possible fallback for older systems compatibility, utimes()
function from <sys/stat.h>. It also provides the corresponding MinGW
wrapper.

The alternative is to unconditionally use utimes() where possible, but given
that utimensat is available in glibc starting from 2007, and on BSD systems
since 2012 or so, it makes sense to use the newer variant by default.

No behavior changes is intended or expected (except for Git explicitly
passing nanosecond-precision timestamps to kernel, where previously only
second-level precision was used).

This change is generated by Gemini Flash from Antigravity, but all the code
has been manually verified by me, and, where applicable, adjusted to match
the existing behavior as closely as possible.

Signed-off-by: Alexey Samsonov vonosmas@gmail.com

Alexey Samsonov (3):
  compat/posix: introduce utimensat(2) wrapper
  treewide: use utimensat(2) instead of legacy utime(3p)
  compat/posix: drop legacy <utime.h> header and shims

 Makefile                            |  6 +++++
 builtin/pack-objects.c              | 12 +++++----
 commit-graph.c                      | 17 +++++--------
 compat/mingw-posix.h                |  4 +--
 compat/mingw.c                      | 36 ++++++++++++++++++++------
 compat/posix.h                      | 22 +++++++++++++++-
 compat/utimensat.c                  | 39 +++++++++++++++++++++++++++++
 compat/vcbuild/include/sys/utime.h  | 34 -------------------------
 compat/vcbuild/include/utime.h      |  1 -
 configure.ac                        |  6 +++++
 contrib/buildsystems/CMakeLists.txt |  8 ++++--
 copy.c                              | 10 +++++---
 meson.build                         |  2 ++
 object-file.c                       | 12 +++++----
 odb/source-loose.c                  | 10 ++++----
 odb/source-packed.c                 | 12 +++++----
 rerere.c                            |  4 +--
 t/helper/test-chmtime.c             | 20 +++++++++------
 t/t4051/includes.c                  |  1 -
 19 files changed, 163 insertions(+), 93 deletions(-)
 create mode 100644 compat/utimensat.c
 delete mode 100644 compat/vcbuild/include/sys/utime.h
 delete mode 100644 compat/vcbuild/include/utime.h

base-commit: dea0ea3

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

send-pack: avoid sending the whole tree when pushing from a shallow c…

…lone

From: Elijah Newren <newren@gmail.com>

When pushing from a shallow clone, even if we only have made a small
one-line change to a tiny file, we often push the entire toplevel tree
of files.  For large repositories, this could be gigabytes instead of
kilobytes.

The reason for this is that the push likely lacks the commits the
receiver has advertised, so it walks back to its shallow grafts.  Since
it doesn't know that the server has anything, it sends the entire tree
for the graft.  It would also send the parents of the shallow graft,
except the shallow clone doesn't have those by construction.  We thus
are forced to assume that the server has the parents of the shallow
graft -- if it doesn't, the server's receive-pack will reject the push.

But that raises the obvious question: if we're going to assume the
server has the parents of the shallow graft, why not just assume the
server has the shallow graft itself -- which this clone almost certainly
received from the server when the shallow clone was created?  As noted
above, receive-pack already has a builtin connectivity check that
predates pushing from a shallow clone by years[*], so even if a client
is pushing to a different server than it cloned from, the worst that
happens is a rejected push.  And by assuming the server has the shallow
graft commits, then for large repositories (those most likely to use
shallow clone) we can avoid transferring (and perhaps re-compressing)
gigabytes of file contents that the server already has.

[*] Compare 5dbd767 (receive/send-pack: support pushing from a
    shallow clone, 2013-12-05) and 52fed6e (receive-pack: check
    connectivity before concluding "git push", 2011-09-02)

Fix this by finding the shallow grafts behind the history we're pushing
and adding them to the pack boundary as uninteresting (negative) tips,
so the generated pack leaves out everything underneath them.  We only
use grafts that the pushed commits can actually reach; excluding every
graft in the repository would be simpler, but it could drop an object we
really do need to send -- for example, a new blob we're pushing that
also happens to sit under some unrelated shallow root pulled from a
different remote.

We can also stop early at any commit we and the server both have --
one the server advertised, or that push negotiation found in common.
Such a commit already marks the edge of what we need to send, so
there's no reason to keep walking down to a graft below it.  For
deeper clones the server usually has a commit close by, which keeps
this walk short; we only reach a graft when we and the server share no
history that we know about.

One very rare (and non-default) workflow genuinely needs the larger
push: seeding a receiver willing to adopt new shallow roots
(receive.shallowUpdate; see 5dbd767 (receive/send-pack: support
pushing from a shallow clone, 2013-12-05) and 0a1bc12
(receive-pack: allow pushes that update .git/shallow, 2013-12-05)).
When the server sets receive.shallowUpdate, it is willing to accept
pushes despite lacking ancestors of the pushed commits.  But it expects
us to send all tree objects so it can graft a new shallow root.  For
that case, add a sender-side config, push.shallowExcludeBoundary,
defaulting to true (the optimization), while allowing users to set it to
false to restore the previous behavior needed for that rare case.

Update the existing shallow-seeding tests in t5538 to set
push.shallowExcludeBoundary=false, since they exercise that
receive.shallowUpdate path.  Add tests for the optimized default and the
opt-out, that a rejected ref does not cause an accepted ref to be
over-excluded, and that a shallowUpdate receiver still rejects a
rootless snapshot by default.

Signed-off-by: Elijah Newren <newren@gmail.com>

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

worktree repair: detect relative path in .git file correctly

From: Yoichi NAKAYAMA <yoichi.nakayama@gmail.com>

Given a state in which the cross-references between the worktree and
the repository (specifically worktree/id/gitdir in the main repository
and the .git file in the worktree) are recorded using absolute paths,
setting 'worktree.useRelativePaths=true' and running 'git worktree
repair' within the main worktree converts them to relative paths.

Conversely, given a state in which the cross-references are recorded
using relative paths, one would expect that setting
'worktree.useRelativePaths=false' and running 'git worktree repair'
would convert them to absolute paths. However, they remain as relative
paths.

This is because we incorrectly use read_gitfile_gently(), which always
returns an absolute path. To fix this, introduce read_gitfile_raw(),
which is almost identical to read_gitfile_gently(), but skips checking
the existence of the referenced repository and returns the path as-is
from the .git file.

Signed-off-by: Yoichi NAKAYAMA <yoichi.nakayama@gmail.com>

Submitted-As: https://lore.kernel.org/git/pull.2205.v3.git.1787344586470.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2205.git.1786799480344.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2205.v2.git.1787240760069.gitgitgadget@gmail.com

history: add squash subcommand to fold a range

Adds git history squash <revision-range> to fold a range of commits.

Changes in v14:

 * Update commit message trailers.
 * Simplify rev-parse and tr complexity in the tests.

Changes in v13:

 * Split the squash implementation into five patches covering parsing, range
   validation, branch protection, commit creation, and message editing.
 * Print the sorted names of local branches that prevent a squash, with
   clearer advice for --update-refs=head.
 * Isolate --no-edit behavior from the final patch that enables default
   editor-based message combining.

Changes in v12:

 * Incorporated fixups from Phillip:
   * Reworks range validation into a single walk that rejects roots and
     multiple tips while preserving every parent when squashing into a
     merge.
   * Resolves fixup!, squash! and amend! targets directly, preserving
     message intent and safely consolidating related markers.
   * Builds the editor template from the exact selected revisions, including
     exclusions, while retaining --no-edit behavior.
   * Protects descendant local branches while leaving tags and
     remote-tracking refs unchanged.

Changes in v11:

 * Make message editing the default with the autosquash-style template, add
   --no-edit instead of squash-specific --reedit-message.
 * Validate one actual boundary and tip, rejecting root-reaching and
   multi-tip ranges.
 * Protect only interior local branches, leaving tags and remote-tracking
   refs unchanged.
 * Move sequencer preparation before squash and fold the later
   message-editing patch into the feature commit.

Changes in v10:

 * Record the full revision expression in squash reflog.
 * Preserve the boundary-walk invariant when sanitizing rev-list options.
 * Clarify amend! and --reedit-message documentation.

Changes in v9:

 * Use the last amend! targeting the oldest folded commit as the default
   squashed message. Ignore amend! markers targeting later commits while
   selecting that replacement message.
 * Improve tests.

Changes in v8:

 * --reedit-message now builds the same editor template as git rebase -i
   --autosquash: fixup!, squash! and amend! commits are grouped under the
   commit they target instead of shown in commit order, and an amend!
   replaces its target's message.
 * A fixup!, squash! or amend! is refused only when its target is outside
   the range, so several fixups for an in-range commit fold together. A
   range that is entirely markers for one below-range target is combined
   into a single commit, keeping the last amend! message.
 * Merges inside the range are folded when the range has a single base, with
   no dedicated opt-in flag, --ancestry-path ensures only commits descended
   from the base are folded, and a range reaching more than one base is
   rejected.
 * Rev-list options are accepted and sanitized the way git replay does,
   forcing the walk order back with a warning, which also fixes git history
   squash -- --reverse slipping past the previous option check.
 * Kept this as an explicit squash subcommand rather than making
   --reedit-message the default or renaming the command.

Changes in v7:

 * --reedit-message now builds the same editor template git rebase -i shows
   for a squash (a combination of N commits banner with each folded message
   under its own header) and follows autosquash for markers: a fixup!
   message falls out (commented under a will be skipped header), while a
   squash! or amend! keeps its body with only the marker subject commented
   so its remark can be reworded in. Only the message text is affected,
   every commit's changes are always folded in.
 * Reuse git rebase -i's squash-message code: a preparatory sequencer:
   commit extracts the banner, header and marker-comment helpers so both
   rebase and git history squash build the identical template from one
   source.
 * Refuse a range whose oldest commit is a fixup!, squash! or amend!, since
   the marker's target cannot be inside the range.
 * Reorder the squash usage so dashed options come before <revision-range>,
   and spell out HEAD instead of @ in the documentation and examples.
 * Expand the squash commit message and documentation with this overview,
   and scope the merge limitation so it no longer contradicts squash folding
   a single-base interior merge.

Changes in v6:

 * git history squash now accepts multiple revision arguments, read like the
   arguments to git-rev-list, so a compound range such as @~3.. ^topic
   works.
 * The base to reparent onto is now the oldest in-range commit's parent; a
   boundary other than that base means the range has more than one base and
   is rejected. This also fixes the earlier overly-restrictive handling of
   merges and side branches.
 * A single-commit range (e.g. @^!) is rejected with "nothing to squash"
   (this also covers the @^!-style example that previously succeeded
   silently).
 * Commit messages reworded: the squash commit now gives an overview of
   fixup!/squash!/amend! handling, rewording, merge-parent and ref behavior.

Changes in v5:

 * The range walk now uses --ancestry-path, so only commits descended from
   the base are folded; a single revision such as HEAD or HEAD~1 is now
   rejected as "not a <base>..<tip> range" rather than treated as a squash
   down to the root.
 * This adopts the --ancestry-path suggestion; the multi-base rejection is
   unchanged, so a side branch that forked before the base and merged in is
   still refused.
 * Added tests covering more merge topologies: two interior merges, a nested
   merge, an octopus merge, an octopus arm forked before the base, a merge
   among the descendants replayed above the range, and a ref pointing at an
   interior merge commit.

Changes in v4:

 * git history squash now detects when another ref points at a commit inside
   the range being folded and refuses, with an advice.historyUpdateRefs hint
   to use --update-refs=head.
 * A merge inside the range is folded fine as long as the range has a single
   base; a range with merge commit at the tip or base also folds correctly.
   Only a range with more than one base is rejected.

Changes in v3:

 * Moved the feature out of git rebase and into a new git history squash
   <revision-range> subcommand, per the list discussion. git rebase --squash
   is dropped.
 * Takes an arbitrary range (git history squash @~3.., git history squash
   @~5..@~2), folding it into the oldest commit and replaying any
   descendants on top.
 * Implemented as a single tree operation rather than picking each commit,
   so there are no repeated conflict stops (addresses Phillip's efficiency
   point).
 * A merge inside the range is folded fine, only a range with more than one
   base is rejected.
 * --reedit-message seeds the editor with every folded-in message, not just
   the oldest.

Harald Nordgren (8):
  history: extract helper for a commit's parent tree
  history: give commit_tree_ext a message template
  sequencer: share the squash message marker helpers and flags
  history: add skeleton for squash subcommand
  history: validate squash revision ranges
  history: protect branches when squashing a range
  history: create squashed commits without editing
  history: support editing squashed commit messages

 Documentation/config/advice.adoc |   4 +
 Documentation/git-history.adoc   |  59 +-
 advice.c                         |   1 +
 advice.h                         |   1 +
 builtin/history.c                | 720 +++++++++++++++++++++++--
 object.h                         |   1 +
 sequencer.c                      |  70 +--
 sequencer.h                      |  30 ++
 t/meson.build                    |   1 +
 t/t3455-history-squash.sh        | 886 +++++++++++++++++++++++++++++++
 10 files changed, 1702 insertions(+), 71 deletions(-)
 create mode 100755 t/t3455-history-squash.sh

base-commit: 18e6685

Submitted-As: https://lore.kernel.org/git/pull.2337.v14.git.git.1787249432.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2337.git.git.1781465141.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2337.v2.git.git.1781512625.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2337.v3.git.git.1781810226.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2337.v4.git.git.1782021195.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2337.v5.git.git.1782338102.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2337.v6.git.git.1782635349.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2337.v7.git.git.1783327849.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2337.v8.git.git.1783674396.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2337.v9.git.git.1784128573.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2337.v10.git.git.1784536024.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2337.v11.git.git.1785567209.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2337.v12.git.git.1785832251.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2337.v13.git.git.1786088371.gitgitgadget@gmail.com

worktree repair: detect relative path in .git file correctly

From: Yoichi NAKAYAMA <yoichi.nakayama@gmail.com>

Given a state where the cross references between the worktree and the
repository (specifically worktree/id/gitdir in the main repository and
the .git file in the worktree) are recorded using absolute paths,
setting 'worktree.useRelativePaths=true' and running 'git worktree
repair' within the main worktree converts them to relative paths.

On the other hand, given a state where the cross references are
recorded using relative paths, one would expect (by symmetry) that
setting 'worktree.useRelativePath=false' and running 'git worktree
repair' would convert them to absolute paths. However, they remain as
relative paths.

This is because we wrongly use read_gitfile_gently() which always
returns an absolute path. To fix this, introduce read_gitfile_raw()
that is almost same as read_gitfile_gently(), but it skips existence
check of the referenced repository and returns the unmodified path
read from .git file.

Signed-off-by: Yoichi NAKAYAMA <yoichi.nakayama@gmail.com>

Submitted-As: https://lore.kernel.org/git/pull.2205.v2.git.1787240760069.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2205.git.1786799480344.gitgitgadget@gmail.com

t1401: check symbolic-ref exit codes and --quiet silence

From: Nikolaus Schuetz <nikolauspschuetz@gmail.com>

git-symbolic-ref(1) documents that reading a name that is not a
symbolic ref exits non-zero, and that --quiet does so silently.
Tests such as t2020 and t5621 already rely on "symbolic-ref -q HEAD"
failing on a detached HEAD, but none pins the exact exit codes or
checks that --quiet actually suppresses the diagnostic.

Assert that a non-symbolic ref exits 128 with the "is not a symbolic
ref" message, and that --quiet instead exits 1 with no output.

Signed-off-by: Nikolaus Schuetz <nikolauspschuetz@gmail.com>

Submitted-As: https://lore.kernel.org/git/pull.2204.v2.git.1787264402361.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2204.git.1786655554197.gitgitgadget@gmail.com

t1402: test forbidden characters in refnames

From: Nikolaus Schuetz <nikolauspschuetz@gmail.com>

git-check-ref-format(1) documents that a refname cannot contain a
space, tilde, caret, colon, question-mark, asterisk, open-bracket or
backslash, nor the sequence "..", and cannot be the single character
"@".  Of these, only "?", "\" and ".." were tested embedded in an
otherwise-valid refname; "*" was checked only as a lone character or
with --refspec-pattern.

Test all of them in that embedded form with a single loop, and check
that "@" alone is rejected even with --allow-onelevel -- where "@" is
otherwise a valid refname component, as "refs/@" confirms.

Signed-off-by: Nikolaus Schuetz <nikolauspschuetz@gmail.com>

Submitted-As: https://lore.kernel.org/git/pull.2203.v2.git.1787264417682.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2203.git.1786653837190.gitgitgadget@gmail.com

worktree add: improve message for ambiguous remote branch name

'git worktree add ../foo-dir bar-topic' fails to dwim when there are
multiple remote branches with name `bar-topic'. But it doesn't display
meaningful message as 'git checkout bar-topic' does under the same
situation.

We improve this by adding advice and modify the error message for worktree
add.

By Junio's suggestion, we include matched remote names in the advice. It is
applied to checkout, too.

The changes to 'checkout' are almost identical to what Junio proposed; I
have made minor adjustments to use the specified branch name. I'm not sure
how to handle the "Author" field in this case, so I've set it to myself for
now, but I'll correct it if that's not appropriate.

Yoichi NAKAYAMA (3):
  checkout: extract function to display advice for ambiguous remotes
  checkout: improve message for ambiguous remote branch name
  worktree add: improve message for ambiguous remote branch name

 builtin/checkout.c      | 76 +++++++++++++++++++++++++----------------
 builtin/worktree.c      | 37 ++++++++++++++++++--
 checkout.c              | 14 ++++++--
 checkout.h              |  5 ++-
 t/t2400-worktree-add.sh |  4 +--
 5 files changed, 98 insertions(+), 38 deletions(-)

base-commit: dea0ea3

Submitted-As: https://lore.kernel.org/git/pull.2197.v6.git.1787259838.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2197.git.1786177301832.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2197.v2.git.1786374470383.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2197.v3.git.1786395305884.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2197.v4.git.1786430155244.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2197.v5.git.1787143859.gitgitgadget@gmail.com

worktree add: shouldn't dwim if -b or -B is given

From: Yoichi NAKAYAMA <yoichi.nakayama@gmail.com>

'git worktree add <path> <branch>' DWIMs <branch> to a
remote-tracking branch when neither -b, -B, nor --detach
is given.

However, 'git worktree add -b <new-branch> <path> <branch>' can
still DWIM <branch>, causing <new-branch> to be ignored.  This is a
regression introduced by 128e549 (worktree add: extend DWIM to
infer --orphan, 2023-05-17), which appeared in Git 2.42.

Signed-off-by: Yoichi NAKAYAMA <yoichi.nakayama@gmail.com>

Submitted-As: https://lore.kernel.org/git/pull.2192.v4.git.1787221888406.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2192.git.1785852032626.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2192.v2.git.1785932208004.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2192.v3.git.1785934486496.gitgitgadget@gmail.com