* Re: [PATCH v3] rebase: clarify --reschedule-failed-exec default
From: Taylor Blau @ 2024-01-05 17:11 UTC (permalink / raw)
To: Illia Bobyr; +Cc: git
In-Reply-To: <20240105011424.1443732-2-illia.bobyr@gmail.com>
On Thu, Jan 04, 2024 at 05:14:26PM -0800, Illia Bobyr wrote:
> ---
> Documentation/git-rebase.txt | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
LGTM.
Thanks,
Taylor
^ permalink raw reply
* [BUG] mv: can trigger assertion failure with three parameters (builtin/mv.c:481)
From: Kristoffer Haugsbakk @ 2024-01-05 17:41 UTC (permalink / raw)
To: git
You can trigger an assertion by giving these arguments to `git mv`:
<dir>/file <dir> <other dir>
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
```
git config --global --add safe.directory /tmp
dir=$(mktemp -d)
cd $dir
git init
mkdir a
touch a/a.txt
git add a/a.txt
git commit -m 'init'
mkdir b
# Assertion triggered
git mv a/a.txt a b
# `.git/index.lock` still lingers after this; commands like `git add
# <file>` will fail
```
The output:
```
git: builtin/mv.c:481: cmd_mv: Assertion `pos >= 0' failed.
Aborted (core dumped)
```
Also `.git/index.lock` is still there.
> What did you expect to happen? (Expected behavior)
A normal error message if the command is nonsensical (I don’t know; that’s
not the point). Also `.git/index.lock` to be cleaned up.
> What happened instead? (Actual behavior)
An assertion failed. `.git/index.lock` is not cleaned up.
> What's different between what you expected and what actually happened?
See above.
> Anything else you want to add:
Same behavior on `master` (a26002b628 (The fifth batch, 2024-01-02)).
```
./bin-wrappers/git config --global --add safe.directory /tmp
dir=$(mktemp -d)
./bin-wrappers/git -C $dir init
mkdir $dir/a
touch $dir/a/a.txt
./bin-wrappers/git -C $dir add $dir/a/a.txt
./bin-wrappers/git -C $dir commit -m 'init'
mkdir $dir/b
# Assertion triggered
./bin-wrappers/git -C $dir mv $dir/a/a.txt $dir/a $dir/b
```
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.43.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.2.0-39-generic #40~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov 16 10:53:04 UTC 2 x86_64
compiler info: gnuc: 11.4
libc info: glibc: 2.35
$SHELL (typically, interactive shell): /bin/bash
[Enabled Hooks]
--
Kristoffer Haugsbakk
^ permalink raw reply
* Re: [BUG] mv: can trigger assertion failure with three parameters (builtin/mv.c:481)
From: Junio C Hamano @ 2024-01-05 18:52 UTC (permalink / raw)
To: Kristoffer Haugsbakk; +Cc: git
In-Reply-To: <d1f739fe-b28e-451f-9e01-3d2e24a0fe0d@app.fastmail.com>
"Kristoffer Haugsbakk" <code@khaugsbakk.name> writes:
> You can trigger an assertion by giving these arguments to `git mv`:
>
> <dir>/file <dir> <other dir>
> ...
>> What did you expect to happen? (Expected behavior)
>
> A normal error message if the command is nonsensical (I don’t know; that’s
> not the point). Also `.git/index.lock` to be cleaned up.
Good find.
Not just that, but when the command fails in the middle like this,
it leaves the working tree in a half-updated state, i.e.
> ./bin-wrappers/git -C $dir mv $dir/a/a.txt $dir/a $dir/b
will first move a/a.txt to b/a.txt, then try to move a (actually,
all contents of it, including a/a.txt) to b/a and finds that "the
command is nonsensical" and aborts, and by that time, there is no
a/a.txt (i.e. the working tree has been modified). The failure
should be made atomic, just like "git switch" to another branch may
stop _without_ touching anything in the working tree when it may
have to fail (e.g., due to a file being dirty).
Thanks for reporting, Kristoffer.
Any takers?
$ git shortlog --since=3.years -s -n -e --no-merges v2.43.0 builtin/mv.c
15 Shaoxuan Yuan <shaoxuan.yuan02@gmail.com>
10 Elijah Newren <newren@gmail.com>
5 Ævar Arnfjörð Bjarmason <avarab@gmail.com>
2 Junio C Hamano <gitster@pobox.com>
1 Andrzej Hunt <ajrhunt@google.com>
1 Calvin Wan <calvinwan@google.com>
1 Derrick Stolee <stolee@gmail.com>
1 Sebastian Thiel <sebastian.thiel@icloud.com>
1 Torsten Bögershausen <tboegi@web.de>
^ permalink raw reply
* Re: [BUG] mv: can trigger assertion failure with three parameters (builtin/mv.c:481)
From: Dragan Simic @ 2024-01-05 19:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kristoffer Haugsbakk, git
In-Reply-To: <xmqqil47obnw.fsf@gitster.g>
On 2024-01-05 19:52, Junio C Hamano wrote:
> "Kristoffer Haugsbakk" <code@khaugsbakk.name> writes:
>
>> You can trigger an assertion by giving these arguments to `git mv`:
>>
>> <dir>/file <dir> <other dir>
>> ...
>>> What did you expect to happen? (Expected behavior)
>>
>> A normal error message if the command is nonsensical (I don’t know;
>> that’s
>> not the point). Also `.git/index.lock` to be cleaned up.
>
> Good find.
Yes, thanks to Kristoffer for reporting this issue.
> Not just that, but when the command fails in the middle like this,
> it leaves the working tree in a half-updated state, i.e.
>
>> ./bin-wrappers/git -C $dir mv $dir/a/a.txt $dir/a $dir/b
>
> will first move a/a.txt to b/a.txt, then try to move a (actually,
> all contents of it, including a/a.txt) to b/a and finds that "the
> command is nonsensical" and aborts, and by that time, there is no
> a/a.txt (i.e. the working tree has been modified). The failure
> should be made atomic, just like "git switch" to another branch may
> stop _without_ touching anything in the working tree when it may
> have to fail (e.g., due to a file being dirty).
>
> Thanks for reporting, Kristoffer.
>
> Any takers?
This looks like a rather interesting bugfix to me. :) Though, I've
unfortunately contracted some _nasty_ flu, so I'm still simply unable to
work on pretty much anything in the next 5-6 days or so, at which point
I hope to be operational again.
Thus, unless someone else can get it done faster, I should be able to
start working on it in about a week or so. Hopefully, that is.
> $ git shortlog --since=3.years -s -n -e --no-merges v2.43.0
> builtin/mv.c
> 15 Shaoxuan Yuan <shaoxuan.yuan02@gmail.com>
> 10 Elijah Newren <newren@gmail.com>
> 5 Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> 2 Junio C Hamano <gitster@pobox.com>
> 1 Andrzej Hunt <ajrhunt@google.com>
> 1 Calvin Wan <calvinwan@google.com>
> 1 Derrick Stolee <stolee@gmail.com>
> 1 Sebastian Thiel <sebastian.thiel@icloud.com>
> 1 Torsten Bögershausen <tboegi@web.de>
^ permalink raw reply
* Re: [PATCH] commit-graph: fix memory leak when not writing graph
From: Taylor Blau @ 2024-01-05 19:11 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
In-Reply-To: <0feab5e7d5bc6275e2c7671cd8f6786ea86fd610.1702891190.git.ps@pks.im>
On Mon, Dec 18, 2023 at 11:02:28AM +0100, Patrick Steinhardt wrote:
> When `write_commit_graph()` bails out writing a split commit-graph early
> then it may happen that we have already gathered the set of existing
> commit-graph file names without yet determining the new merged set of
> files. This can result in a memory leak though because we only clear the
> preimage of files when we have collected the postimage.
>
> Fix this issue by dropping the condition altogether so that we always
> try to free both preimage and postimage filenames. As the context
> structure is zero-initialized this simplification is safe to do.
Looks obviously good to me, thanks for finding and fixing.
Thanks,
Taylor
^ permalink raw reply
* Re: [RFC PATCH 0/5] Introduce -t, --table for status/add commands
From: Dragan Simic @ 2024-01-05 19:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jacob Stopak, Oswald Buddenhagen, git
In-Reply-To: <8d45763bb4fa4c7d1e1f69dfaf93e647@manjaro.org>
On 2023-10-24 04:21, Dragan Simic wrote:
> On 2023-10-24 04:03, Junio C Hamano wrote:
>> I think the "use more verbose report format to help relatively
>> inexperienced folks, in exchange for spending more screen real
>> estate" is a good direction to think about this thing.
>>
>> I am not personally interested in adding such support all that much
>> myself, but one piece of advice I can offer those who are interested
>> is not to be too deeply attached to the word "table".
>>
>> ... snip ...
>>
>> So be very careful when choosing what to call this new thing, and
>> avoid naming it after the implementation details (e.g., in what
>> particular shape the data gets presented) that may turn out not to
>> be the most important part of the concept.
>
> Totally agreed, "table" simply sneaked in and remained here as the
> term. Perhaps "<command>.verbose = extra" or something similar would
> be a good choice.
Just a brief update... Some of the associated patches are already ready
to go, and some more are still pending to be implemented. It took me a
while, which I apologize for, and now I've also unfortunately contracted
some really bad flu. I'll be back to the patches as soon as the flu
decides to go away.
>> [Footnote]
>>
>> * FWIW, "git status -s" is a tabular presentation. Maybe we can
>> add a more verbose form of "-s" and be done with it for the
>> command?
>
> That's also an option.
^ permalink raw reply
* Re: [PATCH] commit-graph: retain commit slab when closing NULL commit_graph
From: Junio C Hamano @ 2024-01-05 19:56 UTC (permalink / raw)
To: Jeff King; +Cc: git, Scott Leggett, Taylor Blau
In-Reply-To: <20240105054142.GA2035092@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> This fixes a regression introduced in ac6d45d11f (commit-graph: move
> slab-clearing to close_commit_graph(), 2023-10-03), in which running:
> ...
> So it happens to work out. But it still seems questionable to me that we
> would clear a global slab (which might still be in use) when closing the
> commit graph. This clearing comes from 957ba814bf (commit-graph: when
> closing the graph, also release the slab, 2021-09-08), and was fixing a
> case where we really did need it to be closed (and in that case we
> presumably call close_object_store() more directly).
Wow, that is nasty.
But anyway, thanks for your usual "3 pages of explanation for 2
lines of change". The patch does look the best fix in the meantime.
^ permalink raw reply
* What's cooking in git.git (Jan 2024, #02; Fri, 5)
From: Junio C Hamano @ 2024-01-06 1:13 UTC (permalink / raw)
To: git
Here are the topics that have been cooking in my tree. Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and are candidate to be in a
future release). Commits prefixed with '-' are only in 'seen', and
aren't considered "accepted" at all and may be annotated with an URL
to a message that raises issues but they are no means exhaustive. A
topic without enough support may be discarded after a long period of
no activity (of course they can be resubmit when new interests
arise).
Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors. Some
repositories have only a subset of branches.
With maint, master, next, seen, todo:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://kernel.googlesource.com/pub/scm/git/git/
https://github.com/git/git/
https://gitlab.com/git-vcs/git/
With all the integration branches and topics broken out:
https://github.com/gitster/git/
Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):
git://git.kernel.org/pub/scm/git/git-htmldocs.git/
https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
https://www.kernel.org/pub/software/scm/git/
--------------------------------------------------
[New Topics]
* ms/rebase-insnformat-doc-fix (2024-01-03) 1 commit
(merged to 'next' on 2024-01-04 at d68f2be39b)
+ Documentation: fix statement about rebase.instructionFormat
Docfix.
Will merge to 'master'.
source: <pull.1629.git.git.1704305663254.gitgitgadget@gmail.com>
* cp/git-flush-is-an-env-bool (2024-01-04) 1 commit
(merged to 'next' on 2024-01-04 at b435a96ce8)
+ write-or-die: make GIT_FLUSH a Boolean environment variable
Unlike other environment variables that took the usual
true/false/yes/no as well as 0/1, GIT_FLUSH only understood 0/1,
which has been corrected.
Will merge to 'master'.
source: <pull.1628.v3.git.1704363617842.gitgitgadget@gmail.com>
* sd/negotiate-trace-fix (2024-01-03) 1 commit
- push: region_leave trace for negotiate_using_fetch
Tracing fix.
Waiting for a review response.
cf. <xmqqbka27zu9.fsf@gitster.g>
source: <20240103224054.1940209-1-delmerico@google.com>
* sk/mingw-owner-check-error-message-improvement (2024-01-04) 1 commit
- mingw: give more details about unsafe directory's ownership
In addition to (rather cryptic) Security Identifiers, show username
and domain in the error message when we barf on mismatch between
the Git directory and the current user.
Waiting for a review by the area maintainer.
cf. <xmqqbka07te6.fsf@gitster.g>
source: <20240104192202.2124-2-soekkle@freenet.de>
* ib/rebase-reschedule-doc (2024-01-05) 1 commit
- rebase: clarify --reschedule-failed-exec default
Doc update.
Will merge to 'next'.
source: <20240105011424.1443732-2-illia.bobyr@gmail.com>
* jk/commit-graph-slab-clear-fix (2024-01-05) 1 commit
- commit-graph: retain commit slab when closing NULL commit_graph
Clearing in-core repository (happens during e.g., "git fetch
--recurse-submodules" with commit graph enabled) made in-core
commit object in an inconsistent state by discarding the necessary
data from commit-graph too early, which has been corrected.
Will merge to 'next'.
source: <20240105054142.GA2035092@coredump.intra.peff.net>
* jk/index-pack-lsan-false-positive-fix (2024-01-05) 1 commit
- index-pack: spawn threads atomically
Fix false positive reported by leak sanitizer.
Will merge to 'next'.
source: <20240105085034.GA3078476@coredump.intra.peff.net>
--------------------------------------------------
[Cooking]
* cp/sideband-array-index-comment-fix (2023-12-28) 1 commit
- sideband.c: remove redundant 'NEEDSWORK' tag
In-code comment fix.
Will merge to 'next'.
source: <pull.1625.v4.git.1703750460527.gitgitgadget@gmail.com>
* ps/worktree-refdb-initialization (2023-12-28) 6 commits
- builtin/worktree: create refdb via ref backend
- worktree: expose interface to look up worktree by name
- builtin/worktree: move setup of commondir file earlier
- refs/files: skip creation of "refs/{heads,tags}" for worktrees
- setup: move creation of "refs/" into the files backend
- refs: prepare `refs_init_db()` for initializing worktree refs
Instead of manually creating refs/ hierarchy on disk upon a
creation of a secondary worktree, which is only usable via the
files backend, use the refs API to populate it.
May want to wait until other topics solidify a bit more.
cf. <xmqqedf6gpt8.fsf@gitster.g>
source: <cover.1703754513.git.ps@pks.im>
* ml/doc-merge-updates (2023-12-20) 2 commits
(merged to 'next' on 2023-12-28 at 7a6329a219)
+ Documentation/git-merge.txt: use backticks for command wrapping
+ Documentation/git-merge.txt: fix reference to synopsis
Doc update.
Will merge to 'master'.
source: <20231220195342.17590-1-mi.al.lohmann@gmail.com>
* cp/apply-core-filemode (2023-12-26) 3 commits
- apply: code simplification
- apply: correctly reverse patch's pre- and post-image mode bits
- apply: ignore working tree filemode when !core.filemode
"git apply" on a filesystem without filemode support have learned
to take a hint from what is in the index for the path, even when
not working with the "--index" or "--cached" option, when checking
the executable bit match what is required by the preimage in the
patch.
Needs review.
source: <20231226233218.472054-1-gitster@pobox.com>
* jc/archive-list-with-extra-args (2023-12-21) 1 commit
(merged to 'next' on 2023-12-28 at 2d5c20e67f)
+ archive: "--list" does not take further options
"git archive --list extra garbage" silently ignored excess command
line parameters, which has been corrected.
Will merge to 'master'.
source: <xmqqmsu3mnix.fsf@gitster.g>
* jk/t1006-cat-file-objectsize-disk (2024-01-03) 2 commits
(merged to 'next' on 2024-01-03 at a492c6355c)
+ t1006: prefer shell loop to awk for packed object sizes
(merged to 'next' on 2023-12-28 at d82812e636)
+ t1006: add tests for %(objectsize:disk)
Test update.
Will merge to 'master'.
source: <20231221094722.GA570888@coredump.intra.peff.net>
source: <20240103090152.GB1866508@coredump.intra.peff.net>
* js/contributor-docs-updates (2023-12-27) 9 commits
(merged to 'next' on 2024-01-02 at 0e072117cd)
+ SubmittingPatches: hyphenate non-ASCII
+ SubmittingPatches: clarify GitHub artifact format
+ SubmittingPatches: clarify GitHub visual
+ SubmittingPatches: provide tag naming advice
+ SubmittingPatches: update extra tags list
+ SubmittingPatches: discourage new trailers
+ SubmittingPatches: drop ref to "What's in git.git"
+ CodingGuidelines: write punctuation marks
+ CodingGuidelines: move period inside parentheses
Doc update.
Will merge to 'master'.
source: <pull.1623.v3.git.1703739324.gitgitgadget@gmail.com>
* al/unit-test-ctype (2024-01-05) 1 commit
- unit-tests: rewrite t/helper/test-ctype.c as a unit test
Move test-ctype helper to the unit-test framework.
Will merge to 'next'.
source: <20240105161413.10422-1-ach.lumap@gmail.com>
* bk/bisect-doc-fix (2023-12-27) 1 commit
- doc: use singular form of repeatable path arg
Synopsis fix.
Expecting a reroll.
source: <3d46bca1-96d4-43ba-a912-1f7c76942287@smtp-relay.sendinblue.com>
* en/sparse-checkout-eoo (2023-12-26) 2 commits
(merged to 'next' on 2023-12-28 at 3ddf2ebab6)
+ sparse-checkout: be consistent with end of options markers
+ Merge branch 'jk/end-of-options' into jc/sparse-checkout-set-add-end-of-options
"git sparse-checkout (add|set) --[no-]cone --end-of-options" did
not handle "--end-of-options" correctly after a recent update.
Will merge to 'master'.
source: <pull.1625.v2.git.git.1703619562639.gitgitgadget@gmail.com>
* ja/doc-placeholders-fix (2023-12-26) 2 commits
- doc: enforce placeholders in documentation
- doc: enforce dashes in placeholders
Docfix.
Needs review.
source: <pull.1626.git.1703539287.gitgitgadget@gmail.com>
* jc/sparse-checkout-set-default-fix (2023-12-26) 1 commit
(merged to 'next' on 2023-12-28 at a558eccf8e)
+ sparse-checkout: use default patterns for 'set' only !stdin
"git sparse-checkout set" added default patterns even when the
patterns are being fed from the standard input, which has been
corrected.
Will merge to 'master'.
source: <20231221065925.3234048-3-gitster@pobox.com>
* rs/fast-import-simplify-mempool-allocation (2023-12-26) 1 commit
(merged to 'next' on 2023-12-28 at 16e6dd2a69)
+ fast-import: use mem_pool_calloc()
Code simplification.
Will merge to 'master'.
source: <50c1f410-ca37-4c1c-a28b-3e9fad49f2b4@web.de>
* rs/mem-pool-improvements (2023-12-28) 2 commits
(merged to 'next' on 2023-12-28 at aa03d9441c)
+ mem-pool: simplify alignment calculation
+ mem-pool: fix big allocations
MemPool allocator fixes.
Will merge to 'master'.
source: <fa89d269-1a23-4ed6-bebc-30c0b629f444@web.de>
* ps/refstorage-extension (2024-01-02) 13 commits
- t9500: write "extensions.refstorage" into config
- builtin/clone: introduce `--ref-format=` value flag
- builtin/init: introduce `--ref-format=` value flag
- builtin/rev-parse: introduce `--show-ref-format` flag
- t: introduce GIT_TEST_DEFAULT_REF_FORMAT envvar
- setup: introduce GIT_DEFAULT_REF_FORMAT envvar
- setup: introduce "extensions.refStorage" extension
- setup: set repository's formats on init
- setup: start tracking ref storage format
- refs: refactor logic to look up storage backends
- worktree: skip reading HEAD when repairing worktrees
- t: introduce DEFAULT_REPO_FORMAT prereq
- Merge branch 'ps/clone-into-reftable-repository' into ps/refstorage-extension
Introduce a new extension "refstorage" so that we can mark a
repository that uses a non-default ref backend, like reftable.
Will merge to 'next'.
source: <cover.1703833818.git.ps@pks.im>
* ps/reftable-fixes-and-optims (2024-01-03) 9 commits
- reftable/merged: transfer ownership of records when iterating
- reftable/merged: really reuse buffers to compute record keys
- reftable/record: store "val2" hashes as static arrays
- reftable/record: store "val1" hashes as static arrays
- reftable/record: constify some parts of the interface
- reftable/writer: fix index corruption when writing multiple indices
- reftable/stack: do not auto-compact twice in `reftable_stack_add()`
- reftable/stack: do not overwrite errors when compacting
- Merge branch 'ps/reftable-fixes' into ps/reftable-fixes-and-optims
More fixes and optimizations to the reftable backend.
Will merge to 'next'.
source: <cover.1704262787.git.ps@pks.im>
* tb/multi-pack-verbatim-reuse (2023-12-14) 26 commits
(merged to 'next' on 2024-01-04 at 891ac0fa2c)
+ t/perf: add performance tests for multi-pack reuse
+ pack-bitmap: enable reuse from all bitmapped packs
+ pack-objects: allow setting `pack.allowPackReuse` to "single"
+ t/test-lib-functions.sh: implement `test_trace2_data` helper
+ pack-objects: add tracing for various packfile metrics
+ pack-bitmap: prepare to mark objects from multiple packs for reuse
+ pack-revindex: implement `midx_pair_to_pack_pos()`
+ pack-revindex: factor out `midx_key_to_pack_pos()` helper
+ midx: implement `midx_preferred_pack()`
+ git-compat-util.h: implement checked size_t to uint32_t conversion
+ pack-objects: include number of packs reused in output
+ pack-objects: prepare `write_reused_pack_verbatim()` for multi-pack reuse
+ pack-objects: prepare `write_reused_pack()` for multi-pack reuse
+ pack-objects: pass `bitmapped_pack`'s to pack-reuse functions
+ pack-objects: keep track of `pack_start` for each reuse pack
+ pack-objects: parameterize pack-reuse routines over a single pack
+ pack-bitmap: return multiple packs via `reuse_partial_packfile_from_bitmap()`
+ pack-bitmap: simplify `reuse_partial_packfile_from_bitmap()` signature
+ ewah: implement `bitmap_is_empty()`
+ pack-bitmap: pass `bitmapped_pack` struct to pack-reuse functions
+ midx: implement `midx_locate_pack()`
+ midx: implement `BTMP` chunk
+ midx: factor out `fill_pack_info()`
+ pack-bitmap: plug leak in find_objects()
+ pack-bitmap-write: deep-clear the `bb_commit` slab
+ pack-objects: free packing_data in more places
Streaming spans of packfile data used to be done only from a
single, primary, pack in a repository with multiple packfiles. It
has been extended to allow reuse from other packfiles, too.
Will merge to 'master'.
cf. <ZXurD1NTZ4TAs7WZ@nand.local>
source: <cover.1702592603.git.me@ttaylorr.com>
* jc/bisect-doc (2023-12-09) 1 commit
- bisect: document "terms" subcommand more fully
Doc update.
Needs review.
source: <xmqqzfyjmk02.fsf@gitster.g>
* en/header-cleanup (2023-12-26) 12 commits
(merged to 'next' on 2023-12-28 at 1ccddc2a10)
+ treewide: remove unnecessary includes in source files
+ treewide: add direct includes currently only pulled in transitively
+ trace2/tr2_tls.h: remove unnecessary include
+ submodule-config.h: remove unnecessary include
+ pkt-line.h: remove unnecessary include
+ line-log.h: remove unnecessary include
+ http.h: remove unnecessary include
+ fsmonitor--daemon.h: remove unnecessary includes
+ blame.h: remove unnecessary includes
+ archive.h: remove unnecessary include
+ treewide: remove unnecessary includes in source files
+ treewide: remove unnecessary includes from header files
Remove unused header "#include".
Will merge to 'master'.
source: <pull.1617.v2.git.1703351700.gitgitgadget@gmail.com>
* jw/builtin-objectmode-attr (2023-12-28) 1 commit
(merged to 'next' on 2024-01-02 at 4c3784b3a1)
+ attr: add builtin objectmode values support
The builtin_objectmode attribute is populated for each path
without adding anything in .gitattributes files, which would be
useful in magic pathspec, e.g., ":(attr:builtin_objectmode=100755)"
to limit to executables.
Will merge to 'master'.
cf. <xmqq5y0ssknj.fsf@gitster.g>
source: <20231116054437.2343549-1-jojwang@google.com>
* tb/pair-chunk-expect (2023-11-10) 8 commits
- midx: read `OOFF` chunk with `pair_chunk_expect()`
- midx: read `OIDL` chunk with `pair_chunk_expect()`
- commit-graph: read `BIDX` chunk with `pair_chunk_expect()`
- commit-graph: read `GDAT` chunk with `pair_chunk_expect()`
- commit-graph: read `CDAT` chunk with `pair_chunk_expect()`
- commit-graph: read `OIDL` chunk with `pair_chunk_expect()`
- chunk-format: introduce `pair_chunk_expect()` helper
- Merge branch 'jk/chunk-bounds-more' into HEAD
Further code clean-up.
Needs review.
source: <cover.1699569246.git.me@ttaylorr.com>
* tb/path-filter-fix (2023-10-18) 17 commits
- bloom: introduce `deinit_bloom_filters()`
- commit-graph: reuse existing Bloom filters where possible
- object.h: fix mis-aligned flag bits table
- commit-graph: drop unnecessary `graph_read_bloom_data_context`
- commit-graph.c: unconditionally load Bloom filters
- bloom: prepare to discard incompatible Bloom filters
- bloom: annotate filters with hash version
- commit-graph: new filter ver. that fixes murmur3
- repo-settings: introduce commitgraph.changedPathsVersion
- t4216: test changed path filters with high bit paths
- t/helper/test-read-graph: implement `bloom-filters` mode
- bloom.h: make `load_bloom_filter_from_graph()` public
- t/helper/test-read-graph.c: extract `dump_graph_info()`
- gitformat-commit-graph: describe version 2 of BDAT
- commit-graph: ensure Bloom filters are read with consistent settings
- revision.c: consult Bloom filters for root commits
- t/t4216-log-bloom.sh: harden `test_bloom_filters_not_used()`
The Bloom filter used for path limited history traversal was broken
on systems whose "char" is unsigned; update the implementation and
bump the format version to 2.
Expecting a reroll?
cf. <20231023202212.GA5470@szeder.dev>
source: <cover.1697653929.git.me@ttaylorr.com>
* ak/color-decorate-symbols (2023-10-23) 7 commits
- log: add color.decorate.pseudoref config variable
- refs: exempt pseudorefs from pattern prefixing
- refs: add pseudorefs array and iteration functions
- log: add color.decorate.ref config variable
- log: add color.decorate.symbol config variable
- log: use designated inits for decoration_colors
- config: restructure color.decorate documentation
A new config for coloring.
Needs review.
source: <20231023221143.72489-1-andy.koppe@gmail.com>
* eb/hash-transition (2023-10-02) 30 commits
- t1016-compatObjectFormat: add tests to verify the conversion between objects
- t1006: test oid compatibility with cat-file
- t1006: rename sha1 to oid
- test-lib: compute the compatibility hash so tests may use it
- builtin/ls-tree: let the oid determine the output algorithm
- object-file: handle compat objects in check_object_signature
- tree-walk: init_tree_desc take an oid to get the hash algorithm
- builtin/cat-file: let the oid determine the output algorithm
- rev-parse: add an --output-object-format parameter
- repository: implement extensions.compatObjectFormat
- object-file: update object_info_extended to reencode objects
- object-file-convert: convert commits that embed signed tags
- object-file-convert: convert commit objects when writing
- object-file-convert: don't leak when converting tag objects
- object-file-convert: convert tag objects when writing
- object-file-convert: add a function to convert trees between algorithms
- object: factor out parse_mode out of fast-import and tree-walk into in object.h
- cache: add a function to read an OID of a specific algorithm
- tag: sign both hashes
- commit: export add_header_signature to support handling signatures on tags
- commit: convert mergetag before computing the signature of a commit
- commit: write commits for both hashes
- object-file: add a compat_oid_in parameter to write_object_file_flags
- object-file: update the loose object map when writing loose objects
- loose: compatibilty short name support
- loose: add a mapping between SHA-1 and SHA-256 for loose objects
- repository: add a compatibility hash algorithm
- object-names: support input of oids in any supported hash
- oid-array: teach oid-array to handle multiple kinds of oids
- object-file-convert: stubs for converting from one object format to another
Teach a repository to work with both SHA-1 and SHA-256 hash algorithms.
Needs review.
source: <878r8l929e.fsf@gmail.froward.int.ebiederm.org>
* jx/remote-archive-over-smart-http (2023-12-14) 4 commits
- archive: support remote archive from stateless transport
- transport-helper: call do_take_over() in connect_helper
- transport-helper: call do_take_over() in process_connect
- transport-helper: no connection restriction in connect_helper
"git archive --remote=<remote>" learned to talk over the smart
http (aka stateless) transport.
Needs review.
source: <cover.1702562879.git.zhiyou.jx@alibaba-inc.com>
* jx/sideband-chomp-newline-fix (2023-12-18) 3 commits
(merged to 'next' on 2024-01-04 at 1237898a22)
+ pkt-line: do not chomp newlines for sideband messages
+ pkt-line: memorize sideband fragment in reader
+ test-pkt-line: add option parser for unpack-sideband
Sideband demultiplexer fixes.
Will merge to 'master'.
source: <cover.1702823801.git.zhiyou.jx@alibaba-inc.com>
* jc/rerere-cleanup (2023-08-25) 4 commits
- rerere: modernize use of empty strbuf
- rerere: try_merge() should use LL_MERGE_ERROR when it means an error
- rerere: fix comment on handle_file() helper
- rerere: simplify check_one_conflict() helper function
Code clean-up.
Not ready to be reviewed yet.
source: <20230824205456.1231371-1-gitster@pobox.com>
--------------------------------------------------
[Discarded]
* jc/sparse-checkout-eoo (2023-12-21) 5 commits
. sparse-checkout: tighten add_patterns_from_input()
. sparse-checkout: use default patterns for 'set' only !stdin
. SQUASH??? end-of-options test
. sparse-checkout: take care of "--end-of-options" in set/add/check-rules
+ Merge branch 'jk/end-of-options' into jc/sparse-checkout-set-add-end-of-options
"git sparse-checkout (add|set) --[no-]cone --end-of-options" did
not handle "--end-of-options" correctly after a recent update.
Superseded by the en/sparse-checkout-eoo topic.
source: <20231221065925.3234048-1-gitster@pobox.com>
* tb/merge-tree-write-pack (2023-10-23) 5 commits
. builtin/merge-tree.c: implement support for `--write-pack`
. bulk-checkin: introduce `index_tree_bulk_checkin_incore()`
. bulk-checkin: introduce `index_blob_bulk_checkin_incore()`
. bulk-checkin: generify `stream_blob_to_pack()` for arbitrary types
. bulk-checkin: extract abstract `bulk_checkin_source`
"git merge-tree" learned "--write-pack" to record its result
without creating loose objects.
Broken when an object created during a merge is needed to continue merge
cf. <CABPp-BEfy9VOvimP9==ry_rZXu=metOQ8s=_-XiG_Pdx9c06Ww@mail.gmail.com>
cf. <ZZWOtnP2IHNldcy6@nand.local>
source: <cover.1698101088.git.me@ttaylorr.com>
^ permalink raw reply
* Re: [RFC PATCH 0/5] Introduce -t, --table for status/add commands
From: Jacob Stopak @ 2024-01-06 4:44 UTC (permalink / raw)
To: Dragan Simic; +Cc: Junio C Hamano, Oswald Buddenhagen, git
In-Reply-To: <778c4540924ad076269ac72097cf3789@manjaro.org>
On Fri, Jan 05, 2024 at 08:14:34PM +0100, Dragan Simic wrote:
>
> Just a brief update... Some of the associated patches are already ready to
> go, and some more are still pending to be implemented. It took me a while,
> which I apologize for, and now I've also unfortunately contracted some
> really bad flu. I'll be back to the patches as soon as the flu decides to
> go away.
Hey! No worries - thanks for letting me know. I have been thinking about this
and am looking forward to getting back to it.
Hope you recover quickly. Please include me when those patches are ready. Then
I will try to align my previous patches with them and also I have a bunch of
restructuring/refactoring to do based on the previous feedback from Junio.
Oh and happy new year.
^ permalink raw reply
* Re: [PATCH v3 1/1] bugreport: include +i in outfile suffix as needed
From: Jacob Stopak @ 2024-01-06 4:54 UTC (permalink / raw)
To: Emily Shaffer; +Cc: git
In-Reply-To: <ZTtZ5CbIGETy1ucV.jacob@initialcommit.io>
Hey Emily!
Hope you had a great holiday!
I think this thread might have gotten lost in the shuffle.
I had replied to your feedback a couple months ago with a few questions.
It would be great to get your further input before I continue working on
this one.
Best,
Jack
^ permalink raw reply
* Re: [RFC PATCH 0/5] Introduce -t, --table for status/add commands
From: Dragan Simic @ 2024-01-06 7:06 UTC (permalink / raw)
To: Jacob Stopak; +Cc: Junio C Hamano, Oswald Buddenhagen, git
In-Reply-To: <ZZjar4li8R7Uo0c3.jacob@initialcommit.io>
On 2024-01-06 05:44, Jacob Stopak wrote:
> On Fri, Jan 05, 2024 at 08:14:34PM +0100, Dragan Simic wrote:
>>
>> Just a brief update... Some of the associated patches are already
>> ready to
>> go, and some more are still pending to be implemented. It took me a
>> while,
>> which I apologize for, and now I've also unfortunately contracted some
>> really bad flu. I'll be back to the patches as soon as the flu
>> decides to
>> go away.
>
> Hey! No worries - thanks for letting me know. I have been thinking
> about this
> and am looking forward to getting back to it.
>
> Hope you recover quickly. Please include me when those patches are
> ready. Then
> I will try to align my previous patches with them and also I have a
> bunch of
> restructuring/refactoring to do based on the previous feedback from
> Junio.
I hope to recover soon. It's been already about two miserable weeks
since the flu symptoms started, and it has since moved into my lungs,
making things much worse than usual.
Sure, I'll also include a brief summary of our earlier discussions into
the cover letter, with the links to the mailing list archives, to
provide context for the patches for everyone reviewing them later.
Looking forward to these new git features!
> Oh and happy new year.
Happy New Year to you too, and to everybody on the mailing list! :)
^ permalink raw reply
* [PATCH v6 0/1] mingw: give more details about unsafe directory's ownership
From: Sören Krecker @ 2024-01-06 11:29 UTC (permalink / raw)
To: git; +Cc: sunshine, Sören Krecker
In-Reply-To: <xmqqbka07te6.fsf@gitster.g>
So I change the commit message and the title of this commit.
Thanks for your feedback.
Sören Krecker (1):
mingw: give more details about unsafe directory's ownership
compat/mingw.c | 64 ++++++++++++++++++++++++++++++++++++++++----------
1 file changed, 51 insertions(+), 13 deletions(-)
base-commit: e79552d19784ee7f4bbce278fe25f93fbda196fa
--
2.39.2
^ permalink raw reply
* [PATCH v6 1/1] mingw: give more details about unsafe directory's ownership
From: Sören Krecker @ 2024-01-06 11:29 UTC (permalink / raw)
To: git; +Cc: sunshine, Sören Krecker
In-Reply-To: <20240106112917.1870-1-soekkle@freenet.de>
Add domain/username in error message, if owner sid of repository and
user sid are not equal on windows systems.
Old error message:
'''
fatal: detected dubious ownership in repository at 'C:/Users/test/source/repos/git'
'C:/Users/test/source/repos/git' is owned by:
'S-1-5-21-571067702-4104414259-3379520149-500'
but the current user is:
'S-1-5-21-571067702-4104414259-3379520149-1001'
To add an exception for this directory, call:
git config --global --add safe.directory C:/Users/test/source/repos/git
'''
New error message:
'''
fatal: detected dubious ownership in repository at 'C:/Users/test/source/repos/git'
'C:/Users/test/source/repos/git' is owned by:
'DESKTOP-L78JVA6/Administrator' (S-1-5-21-571067702-4104414259-3379520149-500)
but the current user is:
'DESKTOP-L78JVA6/test' (S-1-5-21-571067702-4104414259-3379520149-1001)
To add an exception for this directory, call:
git config --global --add safe.directory C:/Users/test/source/repos/git
'''
Signed-off-by: Sören Krecker <soekkle@freenet.de>
---
compat/mingw.c | 64 ++++++++++++++++++++++++++++++++++++++++----------
1 file changed, 51 insertions(+), 13 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 42053c1f65..6240387205 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -2684,6 +2684,26 @@ static PSID get_current_user_sid(void)
return result;
}
+static BOOL user_sid_to_user_name(PSID sid, LPSTR *str)
+{
+ SID_NAME_USE pe_use;
+ DWORD len_user = 0, len_domain = 0;
+ BOOL translate_sid_to_user;
+
+ /* returns only FALSE, because the string pointers are NULL*/
+ LookupAccountSidA(NULL, sid, NULL, &len_user, NULL, &len_domain,
+ &pe_use);
+ /*Alloc needed space of the strings*/
+ ALLOC_ARRAY((*str), (size_t)len_domain + (size_t)len_user);
+ translate_sid_to_user = LookupAccountSidA(NULL, sid, (*str) + len_domain, &len_user,
+ *str, &len_domain, &pe_use);
+ if (translate_sid_to_user == FALSE)
+ FREE_AND_NULL(*str);
+ else
+ (*str)[len_domain] = '/';
+ return translate_sid_to_user;
+}
+
static int acls_supported(const char *path)
{
size_t offset = offset_1st_component(path);
@@ -2765,27 +2785,45 @@ int is_path_owned_by_current_sid(const char *path, struct strbuf *report)
strbuf_addf(report, "'%s' is on a file system that does "
"not record ownership\n", path);
} else if (report) {
- LPSTR str1, str2, to_free1 = NULL, to_free2 = NULL;
+ LPSTR str1, str2, str3, str4, to_free1 = NULL, to_free3 = NULL, to_local_free2=NULL, to_local_free4=NULL;
- if (ConvertSidToStringSidA(sid, &str1))
+ if (user_sid_to_user_name(sid, &str1))
to_free1 = str1;
else
str1 = "(inconvertible)";
-
- if (!current_user_sid)
- str2 = "(none)";
- else if (!IsValidSid(current_user_sid))
- str2 = "(invalid)";
- else if (ConvertSidToStringSidA(current_user_sid, &str2))
- to_free2 = str2;
+ if (ConvertSidToStringSidA(sid, &str2))
+ to_local_free2 = str2;
else
str2 = "(inconvertible)";
+
+ if (!current_user_sid) {
+ str3 = "(none)";
+ str4 = "(none)";
+ }
+ else if (!IsValidSid(current_user_sid)) {
+ str3 = "(invalid)";
+ str4 = "(invalid)";
+ } else {
+ if (user_sid_to_user_name(current_user_sid,
+ &str3))
+ to_free3 = str3;
+ else
+ str3 = "(inconvertible)";
+ if (ConvertSidToStringSidA(current_user_sid,
+ &str4))
+ to_local_free4 = str4;
+ else
+ str4 = "(inconvertible)";
+ }
strbuf_addf(report,
"'%s' is owned by:\n"
- "\t'%s'\nbut the current user is:\n"
- "\t'%s'\n", path, str1, str2);
- LocalFree(to_free1);
- LocalFree(to_free2);
+ "\t'%s' (%s)\nbut the current user is:\n"
+ "\t'%s' (%s)\n",
+ path, str1, str2, str3, str4);
+ free(to_free1);
+ LocalFree(to_local_free2);
+ free(to_free3);
+ LocalFree(to_local_free4);
}
}
--
2.39.2
^ permalink raw reply related
* Re: [GSOC][RFC] Heed core.bare from template config file when no command line override given, as a microproject.
From: Ghanshyam Thakkar @ 2024-01-06 12:07 UTC (permalink / raw)
To: Junio C Hamano, Elijah Newren; +Cc: Christian Couder, git, johannes.schindelin
In-Reply-To: <xmqqjzonpy9l.fsf@gitster.g>
On Fri Jan 5, 2024 at 9:29 PM IST, Junio C Hamano wrote:
> Elijah Newren <newren@gmail.com> writes:
>
> > If you look back at the mailing list discussion on the series that
> > introduced this TODO comment you are trying to address, you'll note
> > that both Glen and I dug into the code and attempted to explain it to
> > each other, and we both got it wrong on our first try.
>
> I think you meant 0f7443bd (init-db: document existing bug with
> core.bare in template config, 2023-05-16), where it says:
>
> The comments in create_default_files() talks about reading config from
> the config file in the specified `--templates` directory, which leads to
> the question of whether core.bare could be set in such a config file and
> thus whether the code is doing the right thing.
>
> But I suspect the all of the above comes from a misunderstanding.
> The comment the above commit log message talks about is:
>
> /*
> * First copy the templates -- we might have the default
> * config file there, in which case we would want to read
> * from it after installing.
> *
> * Before reading that config, we also need to clear out any cached
> * values (since we've just potentially changed what's available on
> * disk).
> */
>
> This primarily comes from my 4f629539 (init-db: check template and
> repository format., 2005-11-25), whose focus was to control the way
> HEAD symref is created, but care was taken to avoid propagating
> values from the configuration variables in the template that do not
> make sense for the repository being initialized. The most important
> thing being the repository format version, but the intent to avoid
> nonsense combination between the characteristic the new repository
> has and the configuration values copied from the template was not
> limited to the format version.
>
> Specifically, the commit that introduced the comment never wanted to
> honor core.bare in the template. I do not think I has core.bare in
> mind when I wrote the comment, but I would have described it as the
> same category as the repository format version, i.e. something you
> would not want to copy, if I were pressed to clarify back then.
Then I suppose this warrants updating the TODO comment in
create_default_files(), which currently can be interpreted as this
being a unwanted behavior. And also amending the testcases which
currently display this as knwon breakage.
> Besides, create_default_files() is way too late, even if we wanted
> to create a bare repository when the template config file says
> core.bare = true, as the caller would already have created before
> passing $DIR (when "git --bare init $DIR" was run) or $DIR/.git
> (when "git init $DIR" was run) to the function.
>
> If somebody wants to always create a bare repository by having
> core.bare=true in their template and if we wanted to honor it (which
> I am dubious of the value of, by the way), I would think the right
> place to do so would be way before create_default_files() is called.
> When running "git init [$DIR]", long before calling init_db(), we
> decide if we are about to create a bare repository and either create
> $DIR or $DIR/.git. What is in the template, if we really wanted to
> do so, should be read before that happens, no?
That is what I proposed in my original email, after which I had a
working solution which passed all the tests. That solution was indeed to
check for core.bare in the template before we set GIT_DIR_ENVIRONMENT,
which subsequently creates either $DIR or $DIR/.git as you described
above.
Regardless, I can send the patch with updated comments to clarify
that ignoring core.bare from template files is the intended behavior and
amend the test_expect_failure testcases, with Elijah's consensus.
Thanks.
^ permalink raw reply
* [PATCH] branch: clarify <oldbranch> term
From: Rubén Justo @ 2024-01-06 14:38 UTC (permalink / raw)
To: Git List
Since 52d59cc645 (branch: add a --copy (-c) option to go with --move
(-m), 2017-06-18) <oldbranch> is used in more operations than just -m.
Let's also clarify what we do if <oldbranch> is omitted.
Signed-off-by: Rubén Justo <rjusto@gmail.com>
---
Documentation/git-branch.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 4395aa9354..233264549c 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -312,7 +312,8 @@ superproject's "origin/main", but tracks the submodule's "origin/main".
option is omitted, the current HEAD will be used instead.
<oldbranch>::
- The name of an existing branch to rename.
+ The name of an existing branch. If this option is omitted,
+ the name of the current branch will be used instead.
<newbranch>::
The new name for an existing branch. The same restrictions as for
--
2.42.0
^ permalink raw reply related
* Bug: git log with log.showSignature enabled
From: Maxim Iorsh @ 2024-01-06 16:56 UTC (permalink / raw)
To: git
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
iorsh-linux:~/devel/fontforge/build> git log -n 1 --oneline
2aa98f6a5 (HEAD -> master) Dummy signed commit
iorsh-linux:~/devel/fontforge/build> git config log.showSignature true
iorsh-linux:~/devel/fontforge/build> git log -n 1 --oneline
2aa98f6a5 (HEAD -> master) gpg: Signature made 17:47:50 2024 ינו 06 ש' IST
gpg: using RSA key XXXXXXXXXX
gpg: issuer "iorsh@users.sourceforge.net"
gpg: Good signature from "Maxim Iorsh <iorsh@users.sourceforge.net>" [ultimate]
Dummy signed commit
What did you expect to happen? (Expected behavior)
When asked for oneliner or any specific format, `git log` shouldn't
show signature event when configured.
What happened instead? (Actual behavior)
`git log` always show signatures with log.showSignature enabled, even
for explicit formatting requests.
What's different between what you expected and what actually happened?
Anything else you want to add:
This behavior obviously breaks any script which relies on git log to
produce preformatted info about commits. It's also quite rare, becaus
e probably very few users set log.showSignature config option.
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.34.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC
2023 x86_64
compiler info: gnuc: 11.4
libc info: glibc: 2.35
$SHELL (typically, interactive shell): /bin/tcsh
[Enabled Hooks]
^ permalink raw reply
* Re: Bug: git log with log.showSignature enabled
From: brian m. carlson @ 2024-01-06 18:21 UTC (permalink / raw)
To: Maxim Iorsh; +Cc: git
In-Reply-To: <CADQ_TR56X_iMitPEiaOyR_h=1dp9ThUQMu_Vqjest1i8xbh9Tw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2506 bytes --]
On 2024-01-06 at 16:56:29, Maxim Iorsh wrote:
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
>
> iorsh-linux:~/devel/fontforge/build> git log -n 1 --oneline
> 2aa98f6a5 (HEAD -> master) Dummy signed commit
> iorsh-linux:~/devel/fontforge/build> git config log.showSignature true
> iorsh-linux:~/devel/fontforge/build> git log -n 1 --oneline
> 2aa98f6a5 (HEAD -> master) gpg: Signature made 17:47:50 2024 ינו 06 ש' IST
> gpg: using RSA key XXXXXXXXXX
> gpg: issuer "iorsh@users.sourceforge.net"
> gpg: Good signature from "Maxim Iorsh <iorsh@users.sourceforge.net>" [ultimate]
> Dummy signed commit
>
> What did you expect to happen? (Expected behavior)
>
> When asked for oneliner or any specific format, `git log` shouldn't
> show signature event when configured.
>
> What happened instead? (Actual behavior)
>
> `git log` always show signatures with log.showSignature enabled, even
> for explicit formatting requests.
>
> What's different between what you expected and what actually happened?
>
> Anything else you want to add:
>
> This behavior obviously breaks any script which relies on git log to
> produce preformatted info about commits. It's also quite rare, becaus
> e probably very few users set log.showSignature config option.
I think this is behaving as designed. git log is a porcelain command,
which means it's designed for the user to use, but is not intended for
scripting. The documentation for `log.showSignature` says this:
If true, makes git-log(1), git-show(1), and git-whatchanged(1) assume --show-signature.
As long as the output is what you would have gotten if you manually
added --show-signature, the result is correct.
However, if you want to script things, you can use git rev-list, which
is a plumbing command that's specifically designed to allow scripting.
It works very similarly to git log, but doesn't have configuration
options that change its behaviour, so it doesn't suffer from this
problem.
For example, on one of my branches, I get this:
$ git rev-list -n 1 --oneline HEAD
404bf1f83a credential: add an argument to keep state
Note that the implicit HEAD of git log doesn't work with git rev-list,
so you need to specify HEAD explicitly.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Leveraging --rebase-merges --update-refs mechanism to rebase several branches in one run
From: Yann Dirson @ 2024-01-06 19:05 UTC (permalink / raw)
To: git
In-Reply-To: <763603689.1820092086.1704566524953.JavaMail.root@zimbra39-e7>
This idea comes from a repo[1] where I am experimenting with code variants:
on one side I have a branch where I add to the core mechanisms, and on the
other(s) I have several branches where I experiment with different rendering
options.
There are indeed 2 different workflows here:
- improving the variants themselves, where occasionally some fixup or new
commit for the core branch gets introduced
- adding feature to the core branch, then merging that into each variant,
where fixups already appear quite regularly
That produces a set closely-related branches with lots of merges, and applying
the fixups is a bit tricky.
The "core + 1 variant" case pretty much works out of the box, with --rebase-merges
and --update-refs generating a perfect instructions sheet.
But if I was to rebase just one variant while rewriting the core branch, obviously
all other variants would still fork off the pre-rewrite core branch, and we'd loose
all chances of automating the same work on the other variants.
OTOH, if I get `git-rebase` to generate the instruction sheets for those other
variants first, strip them (manually) from the common part, and insert them in the
instruction sheet of my "core + 1 variant" case ... I do get the whole of my branches
rebased together, and sharing the updated core.
So the question is, would there be any obstacles to let git-rebase automate this
completely? By chance it could even be a trivial change?
I guess we'd only want this feature to be enabled under certain conditions, like
--update-refs being specified so the many heads of the rebase would be reachable.
[1] https://github.com/ydirson/test-yew-tutorial/tree/opr is the "core" branch,
and branches opr-* are the variants
^ permalink raw reply
* [PATCH v3] fetch: add new config option fetch.all
From: Tamino Bauknecht @ 2024-01-06 20:17 UTC (permalink / raw)
To: git; +Cc: Tamino Bauknecht
In-Reply-To: <xmqqa5pjpxm6.fsf@gitster.g>
This commit introduces the new boolean configuration option fetch.all
which allows to fetch all available remotes by default. The config
option can be overridden by explicitly specifying a remote or by using
--no-all.
The behavior for --all is unchanged and calling git-fetch with --all and
a remote will still result in an error.
The config option was also added to the config documentation and new
tests cover the expected behavior.
Additionally, --no-all was added to the command-line documentation of
git-fetch.
Signed-off-by: Tamino Bauknecht <dev@tb6.eu>
---
Thank you for your detailed explanation. I misunderstood your suggestion
and didn't know that the concept of negated options ("no-...") already
exists for most options in git and utilizing it definitely makes sense.
I also agree with you that "default" would be ambiguous.
I reworked the patch to respect --no-all and added the flag to the
documentation.
The previous tests also had an issue that the check could be true even
if no fetch was executed for those that tested for the "default" fetch
behavior (since all the branches from origin already existed anyway).
If someone can think of a more elegant solution, I'll gladly improve it
further.
Documentation/config/fetch.txt | 6 ++
Documentation/fetch-options.txt | 5 +-
builtin/fetch.c | 20 +++-
t/t5514-fetch-multiple.sh | 161 ++++++++++++++++++++++++++++++++
4 files changed, 187 insertions(+), 5 deletions(-)
diff --git a/Documentation/config/fetch.txt b/Documentation/config/fetch.txt
index aea5b97477..d7dc461bd1 100644
--- a/Documentation/config/fetch.txt
+++ b/Documentation/config/fetch.txt
@@ -50,6 +50,12 @@ fetch.pruneTags::
refs. See also `remote.<name>.pruneTags` and the PRUNING
section of linkgit:git-fetch[1].
+fetch.all::
+ If true, fetch will attempt to update all available remotes.
+ This behavior can be overridden by passing `--no-all` or by
+ explicitly specifying one or more remote(s) to fetch from.
+ Defaults to false.
+
fetch.output::
Control how ref update status is printed. Valid values are
`full` and `compact`. Default value is `full`. See the
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index a1d6633a4f..5e70f6d2e4 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -1,5 +1,6 @@
---all::
- Fetch all remotes.
+--[no-]all::
+ Fetch all remotes. This overrides the configuration option
+ `fetch.all`.
-a::
--append::
diff --git a/builtin/fetch.c b/builtin/fetch.c
index a284b970ef..5a0b249c07 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -102,6 +102,7 @@ static struct string_list negotiation_tip = STRING_LIST_INIT_NODUP;
struct fetch_config {
enum display_format display_format;
+ int all;
int prune;
int prune_tags;
int show_forced_updates;
@@ -115,6 +116,11 @@ static int git_fetch_config(const char *k, const char *v,
{
struct fetch_config *fetch_config = cb;
+ if (!strcmp(k, "fetch.all")) {
+ fetch_config->all = git_config_bool(k, v);
+ return 0;
+ }
+
if (!strcmp(k, "fetch.prune")) {
fetch_config->prune = git_config_bool(k, v);
return 0;
@@ -2121,6 +2127,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
{
struct fetch_config config = {
.display_format = DISPLAY_FORMAT_FULL,
+ .all = -1,
.prune = -1,
.prune_tags = -1,
.show_forced_updates = 1,
@@ -2132,7 +2139,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
const char *bundle_uri;
struct string_list list = STRING_LIST_INIT_DUP;
struct remote *remote = NULL;
- int all = 0, multiple = 0;
+ int all = -1, multiple = 0;
int result = 0;
int prune_tags_ok = 1;
int enable_auto_gc = 1;
@@ -2148,7 +2155,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
struct option builtin_fetch_options[] = {
OPT__VERBOSITY(&verbosity),
- OPT_BOOL(0, "all", &all,
+ OPT_COUNTUP(0, "all", &all,
N_("fetch from all remotes")),
OPT_BOOL(0, "set-upstream", &set_upstream,
N_("set upstream for git pull/fetch")),
@@ -2337,11 +2344,18 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
fetch_bundle_uri(the_repository, bundle_uri, NULL))
warning(_("failed to fetch bundles from '%s'"), bundle_uri);
- if (all) {
+ if (all > 0) {
if (argc == 1)
die(_("fetch --all does not take a repository argument"));
else if (argc > 1)
die(_("fetch --all does not make sense with refspecs"));
+ }
+
+ if (all > 0 || (config.all > 0 && !argc && all < 0)) {
+ /*
+ * Only use fetch.all config option if no remotes were
+ * explicitly given and if no --no-all was passed
+ */
(void) for_each_remote(get_one_remote_for_fetch, &list);
/* do not do fetch_multiple() of one */
diff --git a/t/t5514-fetch-multiple.sh b/t/t5514-fetch-multiple.sh
index a95841dc36..63cd730718 100755
--- a/t/t5514-fetch-multiple.sh
+++ b/t/t5514-fetch-multiple.sh
@@ -24,6 +24,15 @@ setup_repository () {
)
}
+setup_test_clone () {
+ test_dir="$1" &&
+ git clone one "$test_dir" &&
+ for r in one two three
+ do
+ git -C "$test_dir" remote add "$r" "../$r" || return 1
+ done
+}
+
test_expect_success setup '
setup_repository one &&
setup_repository two &&
@@ -209,4 +218,156 @@ test_expect_success 'git fetch --multiple --jobs=0 picks a default' '
git fetch --multiple --jobs=0)
'
+create_fetch_all_expect () {
+ cat >expect <<-\EOF || return 1
+ one/main
+ one/side
+ origin/HEAD -> origin/main
+ origin/main
+ origin/side
+ three/another
+ three/main
+ three/side
+ two/another
+ two/main
+ two/side
+ EOF
+}
+
+for fetch_all in true false
+do
+ test_expect_success "git fetch --all (works with fetch.all = $fetch_all)" '
+ test_dir="test_fetch_all_$fetch_all" &&
+ setup_test_clone "$test_dir" &&
+ (
+ cd "$test_dir" &&
+ git config fetch.all $fetch_all &&
+ git fetch --all &&
+ create_fetch_all_expect &&
+ git branch -r >actual &&
+ test_cmp expect actual
+ )
+ '
+done
+
+test_expect_success 'git fetch (fetch all remotes with fetch.all = true)' '
+ setup_test_clone test9 &&
+ (
+ cd test9 &&
+ git config fetch.all true &&
+ git fetch &&
+ git branch -r >actual &&
+ create_fetch_all_expect &&
+ test_cmp expect actual
+ )
+'
+
+create_fetch_one_expect () {
+ cat >expect <<-\EOF || return 1
+ one/main
+ one/side
+ origin/HEAD -> origin/main
+ origin/main
+ origin/side
+ EOF
+}
+
+test_expect_success 'git fetch one (explicit remote overrides fetch.all)' '
+ setup_test_clone test10 &&
+ (
+ cd test10 &&
+ git config fetch.all true &&
+ git fetch one &&
+ create_fetch_one_expect &&
+ git branch -r >actual &&
+ test_cmp expect actual
+ )
+'
+
+create_fetch_two_as_origin_expect () {
+ cat >expect <<-\EOF || return 1
+ origin/HEAD -> origin/main
+ origin/another
+ origin/main
+ origin/side
+ EOF
+}
+
+test_expect_success 'git config fetch.all false (fetch only default remote)' '
+ setup_test_clone test11 &&
+ (
+ cd test11 &&
+ git config fetch.all false &&
+ git remote set-url origin ../two &&
+ git fetch &&
+ create_fetch_two_as_origin_expect &&
+ git branch -r >actual &&
+ test_cmp expect actual
+ )
+'
+
+for fetch_all in true false
+do
+ test_expect_success "git fetch --no-all (fetch only default remote with fetch.all = $fetch_all)" '
+ test_dir="test_no_all_fetch_all_$fetch_all" &&
+ setup_test_clone "$test_dir" &&
+ (
+ cd "$test_dir" &&
+ git config fetch.all $fetch_all &&
+ git remote set-url origin ../two &&
+ git fetch --no-all &&
+ create_fetch_two_as_origin_expect &&
+ git branch -r >actual &&
+ test_cmp expect actual
+ )
+ '
+done
+
+test_expect_success 'git fetch --no-all (fetch only default remote without fetch.all)' '
+ setup_test_clone test12 &&
+ (
+ cd test12 &&
+ git config --unset-all fetch.all || true &&
+ git remote set-url origin ../two &&
+ git fetch --no-all &&
+ create_fetch_two_as_origin_expect &&
+ git branch -r >actual &&
+ test_cmp expect actual
+ )
+'
+
+test_expect_success 'git fetch --all --no-all (fetch only default remote)' '
+ setup_test_clone test13 &&
+ (
+ cd test13 &&
+ git remote set-url origin ../two &&
+ git fetch --all --no-all &&
+ create_fetch_two_as_origin_expect &&
+ git branch -r >actual &&
+ test_cmp expect actual
+ )
+'
+
+test_expect_success 'git fetch --no-all one (fetch only explicit remote)' '
+ setup_test_clone test14 &&
+ (
+ cd test14 &&
+ git fetch --no-all one &&
+ create_fetch_one_expect &&
+ git branch -r >actual &&
+ test_cmp expect actual
+ )
+'
+
+test_expect_success 'git fetch --no-all --all (fetch all remotes)' '
+ setup_test_clone test15 &&
+ (
+ cd test15 &&
+ git fetch --no-all --all &&
+ create_fetch_all_expect &&
+ git branch -r >actual &&
+ test_cmp expect actual
+ )
+'
+
test_done
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3] fetch: add new config option fetch.all
From: Eric Sunshine @ 2024-01-06 23:32 UTC (permalink / raw)
To: Tamino Bauknecht; +Cc: git
In-Reply-To: <20240106202352.7253-2-dev@tb6.eu>
On Sat, Jan 6, 2024 at 3:25 PM Tamino Bauknecht <dev@tb6.eu> wrote:
> This commit introduces the new boolean configuration option fetch.all
> which allows to fetch all available remotes by default. The config
> option can be overridden by explicitly specifying a remote or by using
> --no-all.
> The behavior for --all is unchanged and calling git-fetch with --all and
> a remote will still result in an error.
>
> The config option was also added to the config documentation and new
> tests cover the expected behavior.
> Additionally, --no-all was added to the command-line documentation of
> git-fetch.
>
> Signed-off-by: Tamino Bauknecht <dev@tb6.eu>
> ---
> diff --git a/t/t5514-fetch-multiple.sh b/t/t5514-fetch-multiple.sh
> @@ -209,4 +218,156 @@ test_expect_success 'git fetch --multiple --jobs=0 picks a default' '
> +create_fetch_all_expect () {
> + cat >expect <<-\EOF || return 1
> + ...
> + EOF
> +}
This is really minor, but the `|| return 1` is superfluous. The `cat`
command itself will exit with success or failure, and since it's the
last command in the function, its return value will be the value
returned by the function. Thus, there is no need to use `|| return 1`
to signal failure when the `cat` command itself will do so anyhow.
For such a minor issue, I would typically say "not worth a reroll",
however, this sort of unnecessary code may confuse future readers into
thinking that something unusual and non-obvious is going on. As such,
it might be worth a reroll after all, but if you do choose to reroll,
wait until others have chimed in since they might have more to add
(either about this or other parts of the patch).
^ permalink raw reply
* Re: [PATCH v3] fetch: add new config option fetch.all
From: Eric Sunshine @ 2024-01-06 23:37 UTC (permalink / raw)
To: Tamino Bauknecht; +Cc: git
In-Reply-To: <CAPig+cQ3y7rGbrNjMZB_HpMAWYOhDg8qKSoR5EF=T5+jc6rgvA@mail.gmail.com>
On Sat, Jan 6, 2024 at 6:32 PM Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Sat, Jan 6, 2024 at 3:25 PM Tamino Bauknecht <dev@tb6.eu> wrote:
> > +create_fetch_all_expect () {
> > + cat >expect <<-\EOF || return 1
> > + ...
> > + EOF
> > +}
>
> This is really minor, but the `|| return 1` is superfluous. The `cat`
> command itself will exit with success or failure, and since it's the
> last command in the function, its return value will be the value
> returned by the function. Thus, there is no need to use `|| return 1`
> to signal failure when the `cat` command itself will do so anyhow.
Just for completeness, the other `|| return 1` in your patch...
> > + for r in one two three
> > + do
> > + git -C "$test_dir" remote add "$r" "../$r" || return 1
> > + done
... is necessary, thus correct, since shell for-loops don't terminate
automatically when a command in the loop body fails; the loop
continues regardless. Thus, this `|| return 1` ensures that we
correctly abort (signalling a failure) as soon as the error is
discovered.
^ permalink raw reply
* git config --global needs to be run in a git directory
From: Trix Knotts @ 2024-01-07 5:56 UTC (permalink / raw)
To: Git
Hi! This is a minor issue, but I noticed when I ran `git config --global` from my home directory it gave me this error: `fatal: not in a git directory`. I was able to resolve this simply by moving to a git directory on my machine and rerunning it, so it is not really a big issue. However, I think for convenience it would be nice to be able to run global things like this anywhere. What do y'all think? Would this be easy to change?
BTW this is my first time emailing the git mailing list, so sorry if I did something wrong. Please let me know if so!
--
Trix Knotts (she/they)
^ permalink raw reply
* Re: git config --global needs to be run in a git directory
From: Trix Knotts @ 2024-01-07 7:14 UTC (permalink / raw)
To: Git
In-Reply-To: <NnXUPNo--3-9@tuta.io>
My bad, I had `--global` after the item to be configured.
--
Trix Knotts (she/they)
Jan 6, 2024, 11:56 PM by enderk@tuta.io:
> Hi! This is a minor issue, but I noticed when I ran `git config --global` from my home directory it gave me this error: `fatal: not in a git directory`. I was able to resolve this simply by moving to a git directory on my machine and rerunning it, so it is not really a big issue. However, I think for convenience it would be nice to be able to run global things like this anywhere. What do y'all think? Would this be easy to change?
>
> BTW this is my first time emailing the git mailing list, so sorry if I did something wrong. Please let me know if so!
>
> --
> Trix Knotts (she/they)
>
^ permalink raw reply
* Re: Leveraging --rebase-merges --update-refs mechanism to rebase several branches in one run
From: Johannes Sixt @ 2024-01-07 8:57 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <133456672.1820149400.1704567932308.JavaMail.root@zimbra39-e7>
Am 06.01.24 um 20:05 schrieb Yann Dirson:
> The "core + 1 variant" case pretty much works out of the box, with --rebase-merges
> and --update-refs generating a perfect instructions sheet.
>
> But if I was to rebase just one variant while rewriting the core branch, obviously
> all other variants would still fork off the pre-rewrite core branch, and we'd loose
> all chances of automating the same work on the other variants.
>
> OTOH, if I get `git-rebase` to generate the instruction sheets for those other
> variants first, strip them (manually) from the common part, and insert them in the
> instruction sheet of my "core + 1 variant" case ... I do get the whole of my branches
> rebased together, and sharing the updated core.
Not a complete automation, but... You can merge all variant branches
into a temporary branch (or detached HEAD), even if that are merely -s
ours merges, and then rebase the temporary branch with --rebase-merges
--update-refs. This will generate the instruction sheet that you want.
You can remove the final merge instructions (the temporary ones) from
the instruction sheet if you do not want them to be executed.
-- Hannes
^ permalink raw reply
* Re: Leveraging --rebase-merges --update-refs mechanism to rebase several branches in one run
From: Yann Dirson @ 2024-01-07 11:37 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <ed9f9fc5-c398-4424-9b5b-dbe618cca2ed@kdbg.org>
Johannes Sixt wrote:
> Am 06.01.24 um 20:05 schrieb Yann Dirson:
> > The "core + 1 variant" case pretty much works out of the box, with
> > --rebase-merges
> > and --update-refs generating a perfect instructions sheet.
> >
> > But if I was to rebase just one variant while rewriting the core
> > branch, obviously
> > all other variants would still fork off the pre-rewrite core
> > branch, and we'd loose
> > all chances of automating the same work on the other variants.
> >
> > OTOH, if I get `git-rebase` to generate the instruction sheets for
> > those other
> > variants first, strip them (manually) from the common part, and
> > insert them in the
> > instruction sheet of my "core + 1 variant" case ... I do get the
> > whole of my branches
> > rebased together, and sharing the updated core.
>
> Not a complete automation, but... You can merge all variant branches
> into a temporary branch (or detached HEAD), even if that are merely
> -s
> ours merges, and then rebase the temporary branch with
> --rebase-merges
> --update-refs. This will generate the instruction sheet that you
> want.
> You can remove the final merge instructions (the temporary ones) from
> the instruction sheet if you do not want them to be executed.
Nice idea, and this is indeed automatable for the most part, Q&D PoC below.
There are a few things I can see missing in this PoC:
- removal of the final merge from instruction sheet
Could be done by wrapping $EDITOR - I'm not particularly fond doing things
behind the user's back, but I lack better ideas.
- restoration of HEAD
In the general case it cannot be done from the script, so we would naturally
want to do that from the instruction sheet?
While I was at manually removing the final merge, I experimented with changing
the "reset onto" to "reset <a branch name>", but that resulted in moving HEAD
to the pre-rebase version of the requested branch.
- When aborting the rebase HEAD still points to the extra merge
This is indeed a special case of the above, where instruction sheet cannot
be used, and where the script could help since we won't be in the middle of
a rebase when git-rebase stops.
There does not seem to be any documented exit-code protocol to tell the
git-rebase caller the user aborted. I guess "HEAD pointing to this commit"
could be used to identify the abort.
---- 8< ---- git-rebase-batch
#!/bin/bash
set -e
die() {
echo >&2 "ERROR: $0: $*"
exit 1
}
REBASE_OPTS=(--interactive --rebase-merges --update-refs)
# all args before "--" are passed to git-rebase
while [ $# -ge 1 ]; do
case "$1" in
--) shift; break;;
*) REBASE_OPTS+=("$1"); shift;;
esac
done
[ $# -ge 3 ] || die "need cutting-point and at least 2 refs to rebase"
CUT="$1"
shift
git checkout --detach "$CUT"
git merge -s ours "$@" -m "temporary handle for all rebased branches"
git rebase "${REBASE_OPTS[@]}" "$CUT" HEAD
# here we can be in the middle of interactive rebase, cannot perform
# any kind of cleanup (which would include restoring HEAD ref to its
# original destination)
---- 8< ----
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox