Tags: gitgitgadget/git
Tags
object-name: accept @{p} as short for @{push}
From: Harald Nordgren <haraldnordgren@gmail.com>
"git log @{p}" fails with "unknown revision", even though "@{u}"
works for "@{upstream}".
The "@{upstream}" notation came with its "@{u}" short form from the
very beginning in 28fb843 (Introduce <branch>@{upstream} notation,
2009-09-10). When "@{push}" was added in adfe5d0 (sha1_name:
implement @{push} shorthand, 2015-05-21), "@{p}" was held back to
avoid confusion with a proposed "@{publish}" and talk of an "@{pull}".
Neither of those was ever added.
Add the missing "@{p}" for symmetry with "@{u}".
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
Submitted-As: https://lore.kernel.org/git/pull.2431.v2.git.git.1790927399813.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2431.git.git.1790797186658.gitgitgadget@gmail.com
branch: let --delete-merged default to every upstream From: Harald Nordgren <haraldnordgren@gmail.com> Cleaning up every branch whose work has landed upstream required typing '*/*' as the pattern. Let a bare "git branch --delete-merged" consider every upstream. As with "--merged" without a commit, this applies only when the option comes last, so "git branch --dry-run --delete-merged" previews the cleanup. Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com> Submitted-As: https://lore.kernel.org/git/pull.2428.git.git.1790960147943.gitgitgadget@gmail.com
remote: allow a list of remotes in remote.pushDefault Let remote.pushDefault hold a space separated list of remote names and push to the first one configured in the repository, so a single global setting like fork origin works everywhere. Harald Nordgren (2): remote: factor out lookup of a remote by name remote: allow a list of remotes in remote.pushDefault Documentation/config/remote.adoc | 7 +++++ remote.c | 54 ++++++++++++++++++++++++-------- t/t5516-fetch-push.sh | 36 +++++++++++++++++++++ 3 files changed, 84 insertions(+), 13 deletions(-) base-commit: 0f8e75a Submitted-As: https://lore.kernel.org/git/pull.2423.git.git.1790925472.gitgitgadget@gmail.com
fetch: avoid fetching every branch of a new remote in a shallow repo Avoid fetching every branch of a new remote in a shallow repo. Changes in v5: * Renumber test file from t5585 to t5586. Changes in v4: * Removed the automatic default-branch fetch. A fresh remote fetches nothing until you track a branch explicitly. * Fixed fetch report showing "new ref HEAD" instead of "new branch " * Reworded remote..refmap docs and commit message. Changes in v3: * Replace the special ":"/"+:" fetch refspec with remote.<name>.refmap, reusing git's existing --refmap mechanism instead of inventing new refspec syntax. * Split the change into 4 commits. Changes in v2: * Replaced the opt-in fetch.shallow config entirely with a new special fetch refspec (+:) that git remote add now defaults new remotes to in a shallow repository. The new refspec fetches whichever branches any local branch tracks at that remote, plus the remote's default branch. Harald Nordgren (4): fetch: add remote.<name>.refmap fetch: infer branches to fetch from a refmap-only remote remote: add "git remote add --limited-fetch" remote: default to --limited-fetch in a shallow repository Documentation/config/remote.adoc | 8 +++ Documentation/fetch-options.adoc | 5 ++ Documentation/git-remote.adoc | 14 +++- builtin/fetch.c | 60 +++++++++++++--- builtin/remote.c | 31 ++++++-- remote.c | 41 ++++++++++- remote.h | 9 +++ t/meson.build | 1 + t/t5505-remote.sh | 76 ++++++++++++++++++++ t/t5510-fetch.sh | 17 +++++ t/t5586-fetch-refmap.sh | 119 +++++++++++++++++++++++++++++++ 11 files changed, 363 insertions(+), 18 deletions(-) create mode 100755 t/t5586-fetch-refmap.sh base-commit: a018953 Submitted-As: https://lore.kernel.org/git/pull.2412.v5.git.git.1790925198.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2412.git.git.1789829246437.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2412.v2.git.git.1790195720941.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2412.v3.git.git.1790333402.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2412.v4.git.git.1790673598.gitgitgadget@gmail.com
doc: don't require a SYNOPSIS in section 7 From: Julia Evans <julia@jvns.ca> Remove the SYNOPSIS section from the section 7 man pages where appropriate, to avoid having a section that contains no information. It's not the norm in section 7 to always require a SYNOPSIS. Update the perl script with a special case for section 7. Tested by running `make lint-docs`, and looked at the renaming synopses with this fish script snippet: for i in *.7 echo $i; grep SYNOPSIS -A 5 (string replace .7 .adoc $i) end Signed-off-by: Julia Evans <julia@jvns.ca> Submitted-As: https://lore.kernel.org/git/pull.2246.git.1790957227881.gitgitgadget@gmail.com
fetch: write commit-graph using updated refs only When fetch.writeCommitGraph is enabled, the commit-graph is currently rebuilt from all reachable refs after every fetch. This is unnecessarily expensive on repositories with many refs, since add_ref_to_set() validates each ref against the odb. This series optimizes the commit-graph write by using only the newly updated refs as seeds instead of scanning all refs. It introduces a three-mode enum (REACHABLE / TIPS / SKIP) to make the policy explicit: * No-op fetch: skip the commit-graph write entirely * Updated refs + existing graph: write incrementally from updated tips only * No existing graph or multi-remote fetch: fall back to full reachable scan Patch 1 adds a commit-info subcommand to test-tool read-graph for verifying graph contents in tests. Patch 2 implements the optimization in builtin/fetch.c with four tests covering the incremental, unrelated-commit, no-op, and fallback cases. Kristofer Karlsson (2): test-tool read-graph: add commit-info subcommand fetch: write commit-graph using updated refs only builtin/fetch.c | 65 ++++++++++++++++++++++++++++++++------ commit-graph.c | 2 +- commit-graph.h | 1 + t/helper/test-read-graph.c | 23 +++++++++++++- t/t5510-fetch.sh | 58 ++++++++++++++++++++++++++++++++++ 5 files changed, 138 insertions(+), 11 deletions(-) base-commit: 0f8e75a Submitted-As: https://lore.kernel.org/git/pull.2239.git.1790930019.gitgitgadget@gmail.com
rerere: wait for MERGE_RR.lock, and go on at a conflict A rebase dies at a conflict when a background "git rerere gc" holds MERGE_RR.lock at that moment. With the first patch, rerere waits for the lock instead of dying at once. With the second, the "git rerere gc" started by auto maintenance does nothing while the lock is held. With the third, a command that stops at a conflict goes on without rerere if the lock is still held after the wait. For v6 I took Patrick's suggestions for the second patch. Changes since v5: * Patch 2's option is "--skip-locked" instead of "--auto", since there is no heuristic behind it (Patrick). * The option is hidden and undocumented, like the "--skip-foreground-tasks" that maintenance passes to "git gc", and I no longer touch git-rerere(1) (Patrick). I kept the last sentence of the rerere.lockTimeout entry and named "git maintenance run --auto" and "git gc --auto" in it instead of the option. * I renamed patch 3's flag from RERERE_SKIP_LOCKED to RERERE_WARN_LOCKED, so that it does not look like the flag of "--skip-locked", which is still RERERE_NOWAIT. * I added a test to patch 3 for the merge that "git rebase -r" re-creates, the only call site without one. * I corrected and reworded the log messages of patches 2 and 3. Both implied that every rerere command takes the lock, but status, diff and remaining do not. Patch 2's also said that nobody waits for the gc of auto maintenance, but where maintenance does not detach, the command that starts it does. From patch 3's I dropped my explanation of why "git commit" and "git am --continue" still fail, which does not hold for "git commit": it has made its commit by the time it runs rerere. The message now gives the plain reason, that the rebase or am can still be continued when they fail. I kept the option rather than have maintenance call rerere_gc() directly. rerere_gc() dies when it cannot take the lock, so a manual or scheduled "git maintenance run" would die where it now reports the failed task (Patrick agreed). Thomas Bachem (3): rerere: wait for MERGE_RR.lock before giving up rerere: add "gc --skip-locked" for auto maintenance rerere: go on at a conflict when the lock stays busy Documentation/config/rerere.adoc | 14 +++ apply.c | 2 +- builtin/am.c | 3 +- builtin/gc.c | 4 +- builtin/merge.c | 2 +- builtin/rerere.c | 10 +- builtin/stash.c | 2 +- rerere.c | 56 +++++++-- rerere.h | 6 +- sequencer.c | 4 +- t/t4200-rerere.sh | 190 +++++++++++++++++++++++++++++++ t/t7900-maintenance.sh | 25 +++- 12 files changed, 300 insertions(+), 18 deletions(-) base-commit: 34f0685 Submitted-As: https://lore.kernel.org/git/pull.2214.v6.git.1790939492.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2214.git.1788337897490.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2214.v2.git.1788507876543.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2214.v3.git.1788537081930.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2214.v4.git.1789373061.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2214.v5.git.1790596702.gitgitgadget@gmail.com
ci: link failure and leak annotations to the test script Link failure and leak annotations in CI to the test script, so both can be found from the job summary. V4 CI Job where failures and leaks are reported: https://github.com/git/git/actions/runs/36760014277/job/110039964565?pr=2426 Changes in v4: * Clarify commit messages and simplify escaping logic. Changes in v3: * Fixed bug in the --immediate exit ordering: the --immediate && --invert-exit-code path called exit 0 before the test's annotation was written, now a single unconditional call covers both exit paths. * github_escape_message_ no longer relies on \r being a portable sed escape sequence (not POSIX-guaranteed and BSD sed implementations can differ), it splices in the literal carriage-return byte via printf instead. * Reverted unrelated test-tool line back to its original form. Changes in v2: * Split into two commits, each explaining its own reasoning. * Leak output is no longer capped or embedded in the message, it's now an uncapped fold, so multiple leaks in the same test both show in full. A second leak in a different test still won't show in the same run, --immediate stops the script at the first failure, but it no longer gets buried under every later test falsely reporting "not ok" either. * Drops the giant unfolded message that annotations used to carry, which is what probably caused the scrolling behavior. Harald Nordgren (2): ci: annotate leaks and stop a leak-sanitizer script at its first failure ci: point test failures and fixed known breakages at their file and line ci/lib.sh | 1 + t/test-lib-github-workflow-markup.sh | 54 ++++++++++++++++++++++++---- t/test-lib.sh | 6 +++- 3 files changed, 54 insertions(+), 7 deletions(-) base-commit: a018953 Submitted-As: https://lore.kernel.org/git/pull.2419.v4.git.git.1790880255.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2419.git.git.1790362443893.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2419.v2.git.git.1790621693.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2419.v3.git.git.1790748583.gitgitgadget@gmail.com
t5520: don't expire reflogs where it matters From: Thomas Bachem <mail@thomasbachem.com> "git merge" saves any uncommitted changes with "git stash" before it tries a merge strategy. When the strategy does not handle the merge, it restores them with "git stash apply --index". If some of the changes are staged, that runs "git reset", which writes an entry to the reflog of HEAD. The tests that pull with autostash disabled run eight such merges, each with a new file staged. An upcoming change makes "git stash apply --index" merge the index in-core, so it no longer runs "git reset" and those entries go away. Another makes the default "merge" backend of "git rebase" run auto maintenance when it finishes. Together, they change when auto maintenance expires the reflogs. This means that unfortunately the reflogs are expired at the end of "git pull --rebase" in the "--rebase with rebased upstream" test. The "git pull --rebase -f" in the next test looks for the fork point in the reflog of refs/remotes/me/copy, but as the test suite dates every reflog entry to 2005, the expiry has emptied that reflog. Pull then finds no fork point, so the rebase also replays copy-orig, the commit "copy" was rewound from, and it conflicts. Disable reflog expiration in this script, as ea7d894 (t34xx: don't expire reflogs where it matters, 2026-02-24) did for the rebase tests, so that the test no longer depends on where the expiry falls. Reported-by: Junio C Hamano <gitster@pobox.com> Helped-by: D. Ben Knoble <ben.knoble@gmail.com> Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk> Assisted-by: Claude Fable 5.1 Signed-off-by: Thomas Bachem <mail@thomasbachem.com> Submitted-As: https://lore.kernel.org/git/pull.2243.v3.git.1790843056949.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2243.git.1790606282769.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2243.v2.git.1790701691022.gitgitgadget@gmail.com
object-name: accept @{p} as short for @{push}
From: Harald Nordgren <haraldnordgren@gmail.com>
Typing "git log @{p}.." fails with "unknown revision", even though
"@{u}" works as the short form of "@{upstream}". Users who reach for
the one letter spelling of the push destination by analogy get an
error.
Accept "@{p}" wherever "@{push}" is accepted, in any case, just like
"@{u}".
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
Submitted-As: https://lore.kernel.org/git/pull.2431.git.git.1790797186658.gitgitgadget@gmail.com
PreviousNext