summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
5 daysMerge branch 'ap/var-broken-down-idents' into seenseenJunio C Hamano1-10/+54
* ap/var-broken-down-idents: var: support broken-down idents, signing key, multiple args, and -z
5 daysMerge branch 'ps/ref-storage-format' into seenJunio C Hamano9-26/+54
The terminology regarding reference storage formats has been unified across command-line options, environment variables, configuration variables, and source code, standardizing on the phrase "ref storage format" (e.g., `--ref-storage-format`, `'GIT_REF_STORAGE_FORMAT'`). Additionally, the `--ref-storage-format` option has been updated to accept payloads in the form `<format>://<payload>`. * ps/ref-storage-format: setup: allow "--ref-storage-format=" to specify a payload setup: rename "init.defaultRefFormat" to "init.defaultRefStorageFormat" t: rename GIT_TEST_DEFAULT_REF_FORMAT setup: rename ref storage format environment variables setup: refactor how we configure the ref storage format refs: expose function to parse reference URIs help: rename "default-ref-format" to "default-ref-storage-format" builtin/rev-parse: rename "--show-ref-format" to "--show-ref-storage-format" builtin/submodule: rename "--ref-format=" to "--ref-storage-format=" builtin/refs: rename "--ref-format=" to "--ref-storage-format=" builtin/clone: rename "--ref-format=" to "--ref-storage-format=" builtin/init: rename "--ref-format=" to "--ref-storage-format=" parse-options: allow for hidden aliases
5 daysMerge branch 'tc/push-force-if-includes-fixes' into seenJunio C Hamano1-0/+4
The --force-if-includes protection for git push has been updated to consult the reflog of the local branch being pushed, rather than incorrectly checking the reflog of a local branch that shares the name of the remote destination branch. The push advice for detached HEAD scenarios has also been adjusted to indicate that the remote ref cannot be verified locally. * tc/push-force-if-includes-fixes: push: fix --force-if-includes detached HEAD advice push: check pushed ref for --force-if-includes
5 daysMerge branch 'mm/diff-process-hunks' into seenJunio C Hamano11-2/+491
A new 'diff.<driver>.process' configuration has been introduced to allow a long-running external process to act as a hunk provider, enabling external tools to control which lines Git considers changed while leaving all output formatting (word diff, color, blame, etc.) to Git's standard pipeline. * mm/diff-process-hunks: fixup! diff: consult oid-only hunk providers via diff.<driver>.process diff: consult oid-only hunk providers via diff.<driver>.process userdiff: add diff.<driver>.process config sub-process: add a gentle status read sub-process: separate process lifecycle from hashmap management blame: read precomputed hunks diff: read precomputed hunks for stat output diff: record precomputed hunks during stat output diff-hunks: add the store format, library, and command diff: introduce a hunk provider interface gitattributes: document how external diff drivers relate to diff features
5 daysMerge branch 'cc/early-scan-options' into seenJunio C Hamano1-6/+4
The process of parsing command-line options in commands that perform an early scan over their arguments (such as 'git bisect', 'git rev-parse', and 'git fast-import') has been unified using a new early-scan sub-API, which parses and skips known options taking separate values to prevent logic bugs. * cc/early-scan-options: fast-import: use early_scan_options() for --allow-unsafe-features parse-options: build early scan options from a struct option array parse-options: add parse_options_takes_argument() rev-parse: fix "--" detection when it is an option value bisect: fix "--" detection when a term name is "--" parse-options: add early_scan_options()
5 daysMerge branch 'll/doc-pushcert-if-asked' into seenJunio C Hamano1-1/+1
he remote helper documentation for the 'pushcert' option has been updated to mention that it can also take 'if-asked', reflecting the existing implementation in the code. * ll/doc-pushcert-if-asked: doc: remote-helpers: option pushcert if-asked
5 daysMerge branch 'fz/rebase-autosquash-empty' into seenJunio C Hamano1-0/+11
A commit that is emptied by melding a 'fixup!' or 'squash!' commit during 'git rebase --autosquash' is now handled according to the '--empty' option, allowing it to be dropped, kept, or to halt the rebase. * fz/rebase-autosquash-empty: sequencer: honor --empty when a fixup!/squash! empties its target
5 daysMerge branch 'hn/history-squash' into seenJunio C Hamano2-2/+61
The experimental 'git history' command has been taught a new 'squash' subcommand to fold a range of commits into a single commit, with any descendants replayed on top. * hn/history-squash: history: support editing squashed commit messages history: create squashed commits without editing history: protect branches when squashing a range history: validate squash revision ranges history: add skeleton for squash subcommand sequencer: share the squash message marker helpers and flags history: give commit_tree_ext a message template history: extract helper for a commit's parent tree
5 daysMerge branch 'kh/format-rev-more-options' into seenJunio C Hamano3-58/+97
The experimental 'git format-rev' has been taught a few more formatting options. * kh/format-rev-more-options: format-rev: learn --abbrev, --color, and --date doc: rev-list-options.adoc: factor out --date alts format-rev: factor option variables into a struct format-rev: place BUG calls first in callback format-rev: use lower case for opts description
5 daysMerge branch 'gg/http-ssl-verify-status' into seenJunio C Hamano1-0/+14
The HTTP transport has been taught to check the revocation status of the server certificate using the stapled OCSP response during the TLS handshake via a new 'http.sslVerifyStatus' configuration variable. * gg/http-ssl-verify-status: http: add http.sslVerifyStatus to check stapled OCSP responses
5 daysMerge branch 'cc/lazy-fetch-trusted-bit' into seenJunio C Hamano3-1/+57
A new 'uploadpack.lazyFetchTrusted' configuration variable has been introduced to allow 'upload-pack' to lazily fetch missing objects from configured promisor remotes when serving trusted repositories. * cc/lazy-fetch-trusted-bit: builtin/upload-pack: set GIT_NO_LAZY_FETCH to 0 on trusted repo promisor-remote: prevent infinite recursion when lazy fetching upload-pack: read uploadpack.lazyFetchTrusted setup: extract path_allowlist_apply() promisor-remote: factor out lazy_fetch_objects()
5 daysMerge branch 'bc/restrict-hex-to-lowercase' into seenJunio C Hamano1-0/+5
The parser for hex object names has been updated to reject uppercase hexadecimal characters when running in the breaking changes mode, in preparation for Git 3.0. * bc/restrict-hex-to-lowercase: hex: allow only lowercase object IDs in breaking changes mode t5324: adjust tests for corrupt commit-graph object-name: use hexval hex: label usages of hex parsing for object IDs hex: make hex_to_bytes accept kind of hex to use hex: allow specifying hex type with hex2chr hex: add functionality for lowercase-only hex
5 daysMerge branch 'pz/fetch-submodule-errors-config' into seenJunio C Hamano2-0/+22
The 'git fetch' command can now configure how submodule fetch errors are handled via 'fetch.submoduleErrors' and '--submodule-errors', making them non-fatal. A premature failure during recursive submodule fetches has been fixed by deferring the error until the OID-based retry phase fails. * pz/fetch-submodule-errors-config: fetch: add fetch.submoduleErrors to make submodule fetch errors non-fatal submodule: fix premature failure in recursive submodule fetch
5 daysMerge branch 'hs/rebase-continue-edit' into seenJunio C Hamano2-3/+20
Support for skipping the editor when continuing a rebase after conflict resolution has been added with the '--no-edit' option, and forcing it with '--edit'. A new configuration variable 'rebase.noEdit' can be used to set the default behavior. * hs/rebase-continue-edit: rebase: add --[no-]edit to --continue
5 daysMerge branch 'kj/repo-info-more-path-keys' into seenJunio C Hamano1-0/+62
The 'git repo info' command has been taught more keys to output paths of various repository components (such as the working tree root, superproject working tree, object database, etc.), supporting both absolute and relative path formats. * kj/repo-info-more-path-keys: repo: add path.cdup repo: add path.git-prefix repo: add path.grafts with absolute and relative suffixes repo: add path.index with absolute and relative suffixes repo: add path.hooks with absolute and relative suffixes repo: add path.superproject-root with absolute and relative suffixes repo: add path.toplevel with absolute and relative suffix formatting
5 daysMerge branch 'mm/line-log-limited-ops' into seenJunio C Hamano1-5/+10
The 'git log -L<range>:<path>' command has been taught to limit various 'diff' operations, such as '--stat', '--check', and '-G', to the specified range and path. * mm/line-log-limited-ops: diffcore-pickaxe: limit -G to the -L tracked range diff: support --check with -L line ranges diff: support stat formats with -L diff: extract a line-range diff helper for reuse diff: emit -L hunk headers via xdiff's formatter diff: simplify the line-range filter by classifying removals immediately diff: rename line-range filter struct and clarify fields
5 daysMerge branch 'ec/commit-fixup-options' into seenJunio C Hamano1-10/+12
Support for '-m', '-F', '-c', or '-C' options to supply a commit log message from outside the editor has been added for all 'git commit --fixup' variations. * ec/commit-fixup-options: commit: allow -c/-C for all kinds of --fixup commit: allow -m/-F for all kinds of --fixup
5 daysMerge branch 'bc/maintenance-doc-markup-fix-for-asciidoc' into seenJunio C Hamano1-0/+1
Mark-up fix for 'git maintenance' documentation pages. * bc/maintenance-doc-markup-fix-for-asciidoc: doc: fix conjoined maintenance strategies in git-config(1)
5 daysMerge branch 'ta/command-list-guides-sync-lint' into jchjchJunio C Hamano2-3/+8
A new linter test has been added to Documentation/lint-manpages.sh to ensure that all non-command manual pages (guides and developer interfaces) listed in Documentation/Makefile are present in command-list.txt, replacing an older comment that reminded developers to keep them in sync. * ta/command-list-guides-sync-lint: lint-docs: check the guide list in command-list.txt command-list: add gitformat-loose(5) and gitpacking(7)
5 daysMerge branch 'dk/use-nsec-runtime' into jchJunio C Hamano3-6/+19
The build-time knob 'USE_NSEC' for nanosecond stat precision has been converted to a runtime configuration 'core.useNanosec', allowing distributions to bundle one binary that adapts to filesystem capabilities dynamically. * dk/use-nsec-runtime: core: convert build-time USE_NSEC into runtime core.useNanosec environment: align repo_config_values_init with struct declaration meson: expose knob for xmlto relative links in manuals
5 daysMerge branch 'kn/receive-report-hook' into jchJunio C Hamano2-0/+78
A new hook 'report' is added to 'git receive-pack', which runs after reference updates and allows the server to filter or modify the packet-line status report sent back to the client. * kn/receive-report-hook: hook: introduce the receive-report hook receive-pack: move message generation to separate function receive-pack: drop static variables to track report status version doc: add proc-receive hook info in 'git-receive-pack.adoc'
5 daysMerge branch 'ta/lint-gitlink-older-perl-fix' into jchJunio C Hamano1-1/+1
The development helper script to lint gitlink references in the documentation has been updated to avoid a newer Perl regular expression syntax that breaks on older Perl versions. * ta/lint-gitlink-older-perl-fix: lint-gitlink: don't use empty lower bound in .{0,8}
5 daysMerge branch 'as/cherry-pick-no-commit-doc' into jchJunio C Hamano1-1/+7
The documentation for 'git cherry-pick' has been updated to clarify that the '--no-commit' option intentionally skips setting the 'CHERRY_PICK_HEAD' ref. A test has also been added to ensure this behavior holds even when the operation stops for conflicts. * as/cherry-pick-no-commit-doc: doc: cherry-pick: note --no-commit skips CHERRY_PICK_HEAD t3507: check no CHERRY_PICK_HEAD after conflicting --no-commit
5 daysMerge branch 'kh/doc-datamodel' into jchJunio C Hamano4-7/+23
The gitdatamodel documentation page has been linked from a handful of key documentaiton pages. * kh/doc-datamodel: doc: datamodel: link to the glossary doc: glossary: link four of the terms to gitdatamodel(7) doc: git: link to the gitdatamodel(7) tutorial doc: git: list gitdatamodel(7) as a concept guide
5 daysMerge branch 'sa/rev-list-missing-only' into jchJunio C Hamano1-0/+13
The git rev-list command has been augmented with a '--missing-only' option that filters the output to only show missing objects, stripping the leading '?' character and suppressing present objects, which is useful when used in combination with '--missing=print' or '--missing=print-info'. * sa/rev-list-missing-only: rev-list: add --missing-only option to filter output
5 daysMerge branch 'ps/tune-rerere-gc' into jchJunio C Hamano1-4/+4
"git maintenance" triggered "rerere gc" in unappropriate times and interfered with "git rebase" etc. too much. The conditions "rerere gc" gets triggered have been tweaked. * ps/tune-rerere-gc: builtin/maintenance: improve heuristic for "rerere gc" rerere: extract logic to determine whether entries are stale
5 daysMerge branch 'hn/checkout-m-autostash-refine' into jchJunio C Hamano1-0/+9
The autostash fallback in 'git checkout -m' has been refined to only retry when there are local changes. Additionally, a blank line now visually separates autostash conflict advice from the subsequent branch-switch message. * hn/checkout-m-autostash-refine: checkout: separate autostash conflict advice from branch-switch message stash: reserve exit status 1 for conflicts
5 daysMerge branch 'wf/imap-send-draft' into jchJunio C Hamano1-1/+8
The 'git imap-send' command has been taught to take the '--draft' option to mark uploaded messages as drafts, which helps some email clients render them properly for editing and sending. * wf/imap-send-draft: imap-send: add --draft to set IMAP \Draft flag
5 daysvar: support broken-down idents, signing key, multiple args, and -zAndrew Pleeter1-10/+54
While 'git var' exposes GIT_AUTHOR_IDENT and GIT_COMMITTER_IDENT, extracting individual components (name, email, or date) currently requires callers to manually parse the composite string. Furthermore, there is no way to query the resolved commit signing key through 'git var', and the command only accepts a single variable at a time. Teach 'git var' to expose individual identity components and commit signing configuration, and allow querying multiple variables with optional NUL-termination: - Add GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, and GIT_AUTHOR_DATE. - Add GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, and GIT_COMMITTER_DATE. - Add GIT_SIGNING_KEY to resolve the key that would be used to sign the resulting commit if you were to run 'git commit' right now. - Allow passing multiple variable arguments (e.g., 'git var GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL') to output each variable sequentially. - Support '-z' to terminate variable outputs with NUL bytes. - Format 'git var -l -z' using the same convention as 'git config list -z' (newline separating key and value, NUL separating entries). - Delimit values of multi-valued variables with NUL when '-z' is given, and output an extra delimiter after multi-valued variables when querying multiple variables to disambiguate the stream. - When querying multiple variables, print an empty record for any variable that has no value and continue processing remaining variables. - Use parse_options() to strictly require options before arguments. - Update Documentation/git-var.adoc and t/t0007-git-var.sh. Signed-off-by: Andrew Pleeter <andrewpleeter@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 daysdoc: fix conjoined maintenance strategies in git-config(1)Brigham Campbell1-0/+1
Fix conjoined bullet items for the maintenance strategies in git-config(1). Reportedly, asciidoctor renders this document correctly both before and after this patch. asciidoc renders it correctly only _after_ this patch. Signed-off-by: Brigham Campbell <me@brighamcampbell.com> Acked-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 daysGit 2.56-rc0HEADv2.56.0-rc0mastermainJunio C Hamano1-0/+26
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 daysMerge branch 'tc/replay-linearize'Junio C Hamano1-1/+16
The 'git replay' command has been taught the '--linearize' option to drop merge commits and linearize the replayed history, mimicking 'git rebase --no-rebase-merges'. * tc/replay-linearize: replay: offer an option to linearize the commit topology replay: resolve the replay base outside pick_regular_commit() replay: add helper to put entry into replayed_commits
6 dayslint-docs: check the guide list in command-list.txtTuomas Ahola2-3/+8
Since 2135e1ad70 (command-list.txt: add missing 'gitcredentials' and 'gitremote-helpers', 2020-08-05) there has been a comment in Documentation/Makefile reminding developers to add new guides also to command-list.txt. However, there is no linter script to enforce that. Adapt Documentation/lint-manpages.sh to fill that role. Extract MAN5_TXT and MAN7_TXT from the Makefile and check command-list.txt against them. Exempt gitweb.conf(5) from the new linter routine. Signed-off-by: Tuomas Ahola <taahol@utu.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 dayssetup: allow "--ref-storage-format=" to specify a payloadPatrick Steinhardt2-2/+8
Reference storage backends can be configured with a payload via the "extensions.refStorage" config key and the "GIT_REF_STORAGE_FORMAT" environment variable, both of which accept a URI in the format "<format>://<payload>". The payload may contain backend-specific information, for example an alternate refs directory or which database references should be stored in. The `--ref-storage-format=` option of git-init(1) and git-clone(1) does not know about payloads though: its value is parsed as a plain format name, so backends that require a payload cannot be conveniently set up at initialization time via the command line. Teach the option to accept the same URI syntax. Also, document the optional payloads for both the "files" and "reftable" backends. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 dayssetup: rename "init.defaultRefFormat" to "init.defaultRefStorageFormat"Patrick Steinhardt3-3/+5
With the same reasoning as for git-init(1), rename the "init.defaultRefFormat" config option to "init.defaultRefStorageFormat" and keep the old name as an alias. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 dayssetup: rename ref storage format environment variablesPatrick Steinhardt2-6/+12
With the same reasoning as for git-init(1), rename the environment variables GIT_REFERENCE_BACKEND and GIT_DEFAULT_REF_FORMAT to GIT_REF_STORAGE_FORMAT and GIT_DEFAULT_REF_STORAGE_FORMAT, respectively. The old names are kept as an alias to retain compatibility. While at it, fix indentation for `GIT_REF_STORAGE_FORMAT` docs to use tabs instead of spaces. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 daysbuiltin/rev-parse: rename "--show-ref-format" to "--show-ref-storage-format"Patrick Steinhardt1-1/+4
With the same reasoning as for git-init(1), rename "--show-ref-format" to "--show-ref-storage-format" and keep the old name as an alias. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 daysbuiltin/submodule: rename "--ref-format=" to "--ref-storage-format="Patrick Steinhardt1-6/+8
With the same reasoning as for git-init(1), rename "--ref-format=" to "--ref-storage-format=" and keep the old name as an alias. Note that this commit is a bit more complex compared to the others as we also need to adapt the submodule helper for consistency. But overall, the changes are straight-forward and in the same spirit. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 daysbuiltin/refs: rename "--ref-format=" to "--ref-storage-format="Patrick Steinhardt1-3/+6
With the same reasoning as for git-init(1), rename "--ref-format=" to "--ref-storage-format=" and keep the old name as an alias. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 daysbuiltin/clone: rename "--ref-format=" to "--ref-storage-format="Patrick Steinhardt1-1/+4
With the same reasoning as for git-init(1), rename "--ref-format=" to "--ref-storage-format=" and keep the old name as an alias. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 daysbuiltin/init: rename "--ref-format=" to "--ref-storage-format="Patrick Steinhardt3-4/+7
Back when we gained support for reftables we of course introduced the ability to control the reference storage format that is used by newly created repositories. This infrastructure has grown over time, and unfortunately without consistency: - The command line parameter to specify the ref storage format is called "--ref-format=", while the corresponding repository extension is called "refStorage". - In most cases we refer to the "ref storage format" in our docs, so calling it "--ref-format=" is being inconsistent with them. - It is possible to override the ref storage format via an environment variable that is called "GIT_REFERENCE_BACKEND", which is not even remotely consistent with anything else. - There is also an "object format", but that format does not control how we store objects but rather whether we use SHA1 or SHA256. So in summary, it's a huge mess. This problem is about to become even worse though, as we're soon going to introduce an object storage extension. This extension is the equivalent to the ref storage extension, and of course we also want users to be able to control which object storage format new repositories are using. But we cannot properly name that parameter without creating even more inconsistencies: - "--object-format=" would match "--ref-format=", but that parameter name is already taken to specify the hash function. - "--object-storage=" would be a good fit, but be inconsistent with "--ref-format=". Asking the user to execute `git init --ref-format= --object-storage=` just feels extremely awkward. Instead, this and subsequent patches will fix the mess by consistently referring to the ref storage format as such throughout all options, environment variables and config settings. This new name much more closely indicates that it is about how we store data and finally brings consistency into this area. We will keep the old names working of course for the sake of backwards compatibility. Start with git-init(1). Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 dayshook: introduce the receive-report hookKarthik Nayak2-0/+70
When running 'git-receive-pack(1)', there is no way for the server to intercept and modify the status report before it is sent back to the client. Servers with custom logic may need to transform or gate the report based on the outcome of external logic post reference updates. This is specially needed for our usecase at GitLab where we have custom MVCC logic on top of Git which creates a new version for each push operation. The new version is only committed when certain external operations post reference transaction succeed. So reporting the correct message based on the outcome of these operations is important. The outcome of these operations is only known after `execute_commands()` has returned and before the report is written. There is no point in receive-pack where the server can act on that. We cannot use any of the existing hooks as: - The pre-receive hook runs too early, as we haven't updated references at that point yet and we need to have the full view of all resulting updates (both objects and references). - The update hook is too inefficient as it runs once per reference, and we cannot trivially determine the last update. - The reference-transaction hook is not suited for this. It fires from within `ref_transaction_commit()`, which is before the outcome we need to report is known, so there is no phase at which it could give us the answer. It also does not contain any knowledge regarding the push and cannot communicate with the clients. - The proc-receive hook replaces execute_commands() for references matching 'receive.procReceiveRefs'. We need to gate the report for the push as a whole. - The post-receive and post-update hooks cannot be used as they run too late, at the point where we have already reported success to the client. Introduce a new 'receive-report' hook. The hook receives the complete pkt-line encoded status report on standard input, after all ref updates have been applied to the repository by execute_commands() but before the report is sent to the client. See linkgit:gitprotocol-pack[5] details on the protocol structure. The hook's stdout fully replaces the report sent to the client. receive-pack fully buffers the hook's stdout before acting on the exit status, so the exit code is known before the client receives anything. This gives two distinct behaviors depending on exit status: - Exit 0: the hook's stdout is used as the report. The hook can rewrite 'ok' lines to 'ng' lines to signal per-ref rejection to the client while receive-pack itself exits cleanly. The client marks rejected refs as '[remote rejected]' and exits with a non-zero status if any ref is 'ng'. - Non-zero exit: the hook's stdout is discarded, receive-pack modifies all references to be rejected with a 'receive-report hook failed' error. In both cases, any output the hook writes to standard error is forwarded to the client over the sideband channel and appears as 'remote:' lines on the client terminal. Writing to stderr alone does not affect the push outcome. Reference updates applied by execute_commands() are not rolled back in either failure mode. The hook can cause the client to perceive the push as failed, but cannot undo server-side changes. This creates a divergence that the server cannot resolve: the client leaves its remote-tracking reference at the old value while the update is in fact applied, and a later fetch may reveal the update that the push reported as rejected. The hook is therefore only appropriate for servers which can guarantee that a rejected update is not observable by any reader. In our case the transaction committed by execute_commands() produces a candidate version which is not visible to other readers and is only published once the subsequent operations succeed, so a report of 'ng' corresponds to a version that is discarded rather than published. On a repository where a committed reference update is immediately visible, rejecting a push from this hook would instead leave the pusher with a view that does not match the server. This hook does not use the config-based hook infrastructure, which supports running multiple scripts per hook event. This hook is a bidirectional filter: it receives the report on stdin and writes a modified version to stdout. Running multiple such scripts sequentially would require piping the output of one into the input of the next, which the current hook infrastructure does not support. A single-script design is therefore a natural fit, and is consistent with how 'proc-receive' is structured for the same reason. Helped-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 daysdoc: add proc-receive hook info in 'git-receive-pack.adoc'Karthik Nayak1-0/+8
The manpage of git-receive-pack(1) documents hooks invoked when receiving a push. The manpage does not mention the 'proc-receive' hook though, which is also invoked as part of that process. Add a paragraph about this hook to plug that gap. Helped-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 dayspush: fix --force-if-includes detached HEAD adviceTyler Cipriani1-0/+4
When a --force-if-includes push is rejected due to a detached HEAD state where there is no per-branch reflog to consult, the advice is misleading: ! [rejected] HEAD -> main (remote ref updated since checkout) error: failed to push some refs to '<remote>' hint: Updates were rejected because the tip of the remote-tracking hint: branch has been updated since the last checkout. If you want hint: to integrate the remote changes, use 'git pull' before hint: pushing again. See the 'Note about fast-forwards' in 'git hint: push --help' for details. But a `git pull` will not fix this rejection. What is required is either - Specify the expected remote tip with --force-with-lease=<ref>:<expect> - Ignore the error with --no-force-if-includes Add ref->unverifiable to differentiate between a detached HEAD rejection vs. a remote update rejection. Ensure tests check the rejection message. Reported-by: D. Ben Knoble <ben.knoble@gmail.com> Signed-off-by: Tyler Cipriani <tyler@tylercipriani.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
7 dayslint-gitlink: don't use empty lower bound in .{0,8}Tuomas Ahola1-1/+1
The regex quantifier {,n} was added in Perl 5.34.0 as a shorthand for {0,n}. That makes it too new an introduction for Git which targets Perl 5.26.0. Even though Documentation/lint-gitlink.perl is a development helper script, let's stick to the general Perl version requirement for consistency, and use an explicit zero in .{0,8}. Signed-off-by: Tuomas Ahola <taahol@utu.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
7 dayshistory: support editing squashed commit messagesHarald Nordgren1-2/+16
Open the editor by default when squashing and provide --no-edit as the opt-out. Record the exact commits selected by the revision walk, rearrange that todo list with the sequencer's autosquash machinery, and build the message template from the resulting order. Match interactive rebase's treatment of marker messages: comment out fixup! messages, retain squash! bodies, and let amend! replace its target unless a preceding squash! requires both bodies. This keeps message editing aligned with the marker validation used by the no-edit path. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
7 dayshistory: create squashed commits without editingHarald Nordgren1-2/+42
Create one replacement commit from the resolved range when --no-edit is selected. Preserve the authorship and all parents of the oldest commit, use the tip tree, and replay descendants through the existing history rewrite machinery. Record the complete revision expression in the reflog and retain dry-run and update-refs behavior. Resolve fixup!, squash! and amend! subjects while walking the range. Reject markers whose targets are not selected and refuse any no-edit fold that would discard a squash! or amend! message. A range made entirely from related markers can still be consolidated, with the last applicable amend! body supplying the message. Inspired-by: Sergey Chernov <serega.morph@gmail.com> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
7 dayshistory: protect branches when squashing a rangeHarald Nordgren1-0/+4
A local branch that descends from the selected graph without containing its tip cannot be replayed as a descendant of the squashed commit. Find those branches with ref-filter before creating any replacement objects and refuse the operation unless --update-refs=head was requested. Limit this protection to local branches, matching the refs that the default history rewrite mode updates; tags and remote-tracking refs remain untouched. Sort the blocking refs and print their short branch names so the user can decide whether to move them or leave them behind. Add advice.historyUpdateRefs for the hint that points to --update-refs=head. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
7 dayshistory: add skeleton for squash subcommandHarald Nordgren1-0/+1
Add the entry point and option parsing for "git history squash". Pass the remaining arguments through setup_revisions() so the command accepts revision ranges and rev-list options, while restoring the ordering and simplification settings required by the fold if an option changes them. Require at least one BOTTOM revision. The squashed commit needs a commit outside the selected range to serve as its base, so a single positive revision is not a sufficient range. Keep this step limited to defining the revision input contract so graph validation and the rewrite can be added independently. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
7 daysbuiltin/upload-pack: set GIT_NO_LAZY_FETCH to 0 on trusted repoChristian Couder3-1/+57
A previous commit added a new "uploadpack.lazyFetchTrusted" protected config variable that can contain an allowlist of repos, as well as functions to check if the current repo is in that list. But when the current repo is in that list, we currently do nothing. Let's instead set `GIT_NO_LAZY_FETCH` to `0`, which allows `upload-pack` and its `pack-objects` child process to lazily fetch the objects they need to serve a client, for example when the filter used by the client and the one used by the server don't match. This allows server operators to properly control lazy fetching. It is their responsibility, not the client's, to decide if the served repo is trusted, as the main security issue is that lazily fetching runs `git fetch`, which may execute arbitrary commands specified in the configuration and hooks of the served repo. As `GIT_NO_LAZY_FETCH` is passed down to child processes through the environment, this works for `pack-objects`, which performs the lazy fetch when serving a client, without any further plumbing. Now that "uploadpack.lazyFetchTrusted" is actually doing something, let's document it and reference it from GIT_NO_LAZY_FETCH's docs. Signed-off-by: Christian Couder <christian.couder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>