* Re: What's cooking in git.git (May 2026, #05)
From: Jeff King @ 2026-05-20 5:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqo6ia4q03.fsf@gitster.g>
On Wed, May 20, 2026 at 02:19:24PM +0900, Junio C Hamano wrote:
> * jk/commit-graph-lazy-load-fallback (2026-05-18) 1 commit
> - commit: fall back to full read when maybe_tree is NULL
>
> The logic to lazy-load trees from the commit-graph has been made
> more robust by falling back to reading the commit object when
> the commit-graph is no longer available.
>
> Will merge to 'next'?
> source: <20260519050513.GA1635924@coredump.intra.peff.net>
I posted an updated patch in response to your suggestion to use
parse_oid_hex_algop(), but it looks like the topic in your repo has the
original.
-Peff
^ permalink raw reply
* Re: [PATCH v3 1/2] builtin/maintenance: fix locking with "--detach"
From: Jeff King @ 2026-05-20 5:47 UTC (permalink / raw)
To: Taylor Blau
Cc: Junio C Hamano, Patrick Steinhardt, git, Jean-Christophe Manciot,
Mikael Magnusson, Derrick Stolee
In-Reply-To: <agz78jjYEAif4lZt@nand.local>
On Tue, May 19, 2026 at 08:10:26PM -0400, Taylor Blau wrote:
> Thanks, Patrick, for making the change. I think that this series is in a
> good spot, though I'd like to hear from Peff who had some comments on
> the second patch from the previous round.
What's in v3 of the series looks good to me (both patches).
-Peff
^ permalink raw reply
* Re: [PATCH v3 1/2] builtin/maintenance: fix locking with "--detach"
From: Patrick Steinhardt @ 2026-05-20 5:52 UTC (permalink / raw)
To: Jeff King
Cc: Taylor Blau, Junio C Hamano, git, Jean-Christophe Manciot,
Mikael Magnusson, Derrick Stolee
In-Reply-To: <20260520054716.GB3849892@coredump.intra.peff.net>
On Wed, May 20, 2026 at 01:47:16AM -0400, Jeff King wrote:
> On Tue, May 19, 2026 at 08:10:26PM -0400, Taylor Blau wrote:
>
> > Thanks, Patrick, for making the change. I think that this series is in a
> > good spot, though I'd like to hear from Peff who had some comments on
> > the second patch from the previous round.
>
> What's in v3 of the series looks good to me (both patches).
Thanks, both!
Patrick
^ permalink raw reply
* Re: [PATCH v8] revision.c: implement --max-count-oldest
From: Junio C Hamano @ 2026-05-20 6:02 UTC (permalink / raw)
To: Mirko Faina
Cc: git, Jeff King, Jean-Noël Avila, Patrick Steinhardt,
Tian Yuchen, Ben Knoble, Johannes Sixt, Chris Torek
In-Reply-To: <8210d60832b9a58aa4d71fc3790e44d8989564ce.1779152064.git.mroik@delayed.space>
Mirko Faina <mroik@delayed.space> writes:
> --max-count is a commit limiting option sets a maximum amount of commits
> to be shown. If a user wants to see only the first N commits of the
> history (the oldest commits) they'd have to do something like
>
> git log $(git rev-list HEAD | tail -n N | head -n 1)
>
> This is not very user-friendly.
>
> Teach get_revision() the --max-count-oldest option.
>
> Signed-off-by: Mirko Faina <mroik@delayed.space>
> ---
This breaks CI
https://github.com/git/git/actions/runs/26138986677/job/76880268854#step:4:2072
Squash something like this to fix.
--- >8 ---
Subject: [PATCH] SQUASH??? test portability and other fixes
* "test_when_finished" should use "rm -f", not an error-detecting
"rm", as the execution may not have reached to the point to create
the "actual" file it is removing.
* Do not hide exit status of "git log" by piping its output into
another process.
* Do not expect output of "wc -l" is portable. macOS puts extra
whitespaces in front, while GNU/Linux does not.
---
t/t4202-log.sh | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index c3c1b862d3..75edb0eb38 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -1916,11 +1916,10 @@ test_expect_success 'log --max-count-oldest=1000 --graph --boundary' '
'
test_expect_success 'log --oneline --graph --boundary --max-count-oldest=1' '
- test_when_finished rm actual &&
- echo 2 >expect &&
- git log --oneline --graph --boundary --max-count-oldest=1 HEAD~1..HEAD \
- | wc -l >actual &&
- test_cmp expect actual
+ test_when_finished rm -f actual &&
+ git log --oneline --graph --boundary --max-count-oldest=1 \
+ HEAD~1..HEAD >actual &&
+ test_line_count = 2 actual
'
cat >expect <<-\EOF
--
2.54.0-398-ga4b2d32071
^ permalink raw reply related
* [PATCH] apply: plug strbuf leak
From: Junio C Hamano @ 2026-05-20 6:28 UTC (permalink / raw)
To: git
Depending on how read_patch_file() fails, it may already have read
many bytes into the supplied strbuf. Either the caller or the callee
should release the strbuf.
Here we choose to make the sole caller of the function responsible
for releasing it, as it makes the error handling slightly simpler.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
apply.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/apply.c b/apply.c
index 4aa1694cfa..0167902325 100644
--- a/apply.c
+++ b/apply.c
@@ -4881,8 +4881,10 @@ static int apply_patch(struct apply_state *state,
state->patch_input_file = filename;
state->linenr = 1;
- if (read_patch_file(&buf, fd) < 0)
+ if (read_patch_file(&buf, fd) < 0) {
+ strbuf_release(&buf);
return -128;
+ }
offset = 0;
while (offset < buf.len) {
struct patch *patch;
--
2.54.0-398-ga4b2d32071
^ permalink raw reply related
* Re: What's cooking in git.git (May 2026, #05)
From: Junio C Hamano @ 2026-05-20 6:38 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20260520054436.GA3849892@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, May 20, 2026 at 02:19:24PM +0900, Junio C Hamano wrote:
>
>> * jk/commit-graph-lazy-load-fallback (2026-05-18) 1 commit
>> - commit: fall back to full read when maybe_tree is NULL
>>
>> The logic to lazy-load trees from the commit-graph has been made
>> more robust by falling back to reading the commit object when
>> the commit-graph is no longer available.
>>
>> Will merge to 'next'?
>> source: <20260519050513.GA1635924@coredump.intra.peff.net>
>
> I posted an updated patch in response to your suggestion to use
> parse_oid_hex_algop(), but it looks like the topic in your repo has the
> original.
Indeed, with sufficient amount of front matter before the scissors
line, I missed the patch X-<.
Applied. Thanks.
^ permalink raw reply
* Re: [PATCH] apply: plug strbuf leak
From: Junio C Hamano @ 2026-05-20 6:48 UTC (permalink / raw)
To: git
In-Reply-To: <xmqq33zm4msa.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> Depending on how read_patch_file() fails, it may already have read
> many bytes into the supplied strbuf. Either the caller or the callee
> should release the strbuf.
>
> Here we choose to make the sole caller of the function responsible
> for releasing it, as it makes the error handling slightly simpler.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> apply.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/apply.c b/apply.c
> index 4aa1694cfa..0167902325 100644
> --- a/apply.c
> +++ b/apply.c
> @@ -4881,8 +4881,10 @@ static int apply_patch(struct apply_state *state,
>
> state->patch_input_file = filename;
> state->linenr = 1;
> - if (read_patch_file(&buf, fd) < 0)
> + if (read_patch_file(&buf, fd) < 0) {
> + strbuf_release(&buf);
> return -128;
> + }
Ah, my mistake. This was one of the two "oh, we found longstanding
issues immediately after enabling EXPENSIVE tests on" fixes Peff
already fixed for us.
> offset = 0;
> while (offset < buf.len) {
> struct patch *patch;
^ permalink raw reply
* Re: [PATCH v2] remote: qualify "git pull" advice for non-upstream branches
From: Harald Nordgren @ 2026-05-20 6:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Harald Nordgren via GitGitGadget, git
In-Reply-To: <xmqqbjeb7qfv.fsf@gitster.g>
> Hmph, shouldn't this be done conditionally, though? Most new users
> follow the recommended pattern to set branch.<name>.merge so that
> "git pull" would do the right thing for them, I presume, even when
> they are using triangular workflow to push to a different remote
> than the remote they pull from, so the new and more verbose message
> would not help the users any more than the existing message, right?
>
> Can the code tell the situation where the extra part of the message
> would help and give it only then?
Yes, that's a good idea.
Harald
^ permalink raw reply
* Re: [PATCH 7/9] notes: support an external command to display notes
From: Siddh Raman Pant @ 2026-05-20 6:59 UTC (permalink / raw)
To: gitster@pobox.com
Cc: git@vger.kernel.org, calvinwan@google.com, newren@gmail.com,
ps@pks.im, code@khaugsbakk.name
In-Reply-To: <87fr3nq74l.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 3052 bytes --]
On Wed, May 20 2026 at 05:33:54 +0530, Junio C Hamano wrote:
> Siddh Raman Pant <siddh.raman.pant@oracle.com> writes:
>
> > This problem excaberates on scale.
> >
> > One solution to this is a realtime fetch or faster updation via
> > external means, but unfortunately we lose the coherence in the
> > display of information, and the user would end up reinventing
> > git log.
> >
> > So let's add support for an external command to display the notes.
>
> It is unclear how we would arrive at "So let's" from the previous
> paragraph. It is not limited to notes but multiple people updating
> the same thing racing against each other happens all the time in the
> main part of the history, no? Isn't a better solution for such
> racing situation usually based on a better merge support, I have to
> wonder?
Sorry, I should have been clear.
The issue I meant to describe is not primarily about two people
updating the same note object at the same time.
The workflow I have in mind is different. In kernel work, the same
logical upstream fix can appear as different commit objects across many
downstream branches, such as the stable branches and vendor-specific
branches (based on which the released kernel is actually built).
Different developers may be working on those branches in parallel, and
a review decision recorded for one backport is useful context for the
others.
Today, seeing that decision in ordinary history output requires first
synchronizing the local notes ref, and then interpreting those notes
for the branch being inspected. The latter step is workflow-specific
and can be cheap, but keeping the local notes state fresh enough can be
expensive in a large kernel repository with a large shared notes
history (and if we are to extrapolate, a slow git server conn/ops can
be a factor too).
That is the synchronization problem I was trying to describe: not that
Git should solve all concurrent note updates, but that users can be
looking at stale note-derived information simply because their local
notes state has not caught up yet and catching up is expensive.
The intended role of the external command is to move that freshness
policy out of Git's notes ref synchronization path. A site-specific
helper can decide how to obtain current note text for the commit being
displayed, such as consulting an external service, doing a targeted
lookup, or using its own cache/update policy. Git still owns the
coherent git log/show presentation; the helper only supplies the note
text to display.
> > We split the addition of documentation and tests from this commit for
> > easier review. The new help text added in Documentation/ in the next
> > commit should make the usage clear.
>
> It is unclear why a large body of code that is not documented or
> whose uses are not illustrated by examples found in the test scripts
> is easier to review, though.
Okay my bad. I'll squash them in v2 after this discussion, along with
rewording the commit.
Thanks,
Siddh
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/9] Documentation/git-range-diff: add missing notes options in synopsis
From: Siddh Raman Pant @ 2026-05-20 7:00 UTC (permalink / raw)
To: gitster@pobox.com
Cc: git@vger.kernel.org, newren@gmail.com, ps@pks.im,
code@khaugsbakk.name
In-Reply-To: <87v7cjq7vc.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 383 bytes --]
On Wed, May 20 2026 at 05:17:51 +0530, Junio C Hamano wrote:
> This has nothing to do with "external notes" topic, no?
Yeah, but since I added the command line flag I found it doesn't
mention the existing flags.
Fixing it in the "external notes" commit would be bad, so I put it
before that, since it also then provides a logical place to add new
flags.
Thanks,
Siddh
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 3/9] wrapper: add sleep_nanosec
From: Siddh Raman Pant @ 2026-05-20 7:07 UTC (permalink / raw)
To: gitster@pobox.com
Cc: git@vger.kernel.org, calvinwan@google.com, newren@gmail.com,
ps@pks.im, code@khaugsbakk.name
In-Reply-To: <87qzn7q7qj.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 496 bytes --]
On Wed, May 20 2026 at 05:20:44 +0530, Junio C Hamano wrote:
> The space above the signed-off-by line should be utilized to explain
> why we want this change. For the purpose of this series, why do we
> want to sleep at nanosecond precision?
The current time returned by getnanotime() is in nanoseconds which is
used for deadline, so to avoid re-casting in helper code path we try to
stay in nanosecond world. The caller can store in ns once and reuse it
everytime.
Thanks,
Siddh
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3] doc: add caveat about turning off commit-graph
From: Kristoffer Haugsbakk @ 2026-05-20 7:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Derrick Stolee, git, Oswald Buddenhagen
In-Reply-To: <xmqq8q9qwxrr.fsf@gitster.g>
On Mon, May 11, 2026, at 03:16, Junio C Hamano wrote:
>>>[snip]
>>
>> It’s certainly not necessary, yeah. :)
>>
>> I am basing this on a recollection of someone quoting this from
>> SubmittingPatches:
>>
>> Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and
>> `Tested-by:` lines as necessary to credit people who helped your
>> patch, and "cc:" them when sending such a final version for inclusion.
>>
>> They said that this was outdated since Junio does it himself. But then
>> Junio replied and said that it’s good/better if the contributor does it.
>
> I used to say "let me do this to skip one extra roundtrip" but I
> stopped saying so. Perhaps I should be a bit more explicit and stop
> being silently nice to contributors who do not follow the guidelines
> to the letter in order to unconfuse you and your friends. It
> actually is a tempting thought.
I am personally okay with adding these trailers and think it’s nice to
document such review/ack/etc. interactions.
Just considering this part in isolation, I imagine that you not filling
in missing acks etc. will lead to less such trailers because (1) most
contributors don’t seem to follow up with such updates if the only
change is the trailers section, and (2) most people here (culturally)
don’t add explicit trailer lines in their replies (e.g. an “LGTM” is
clearly an ack, but not explicit).
>> Well, this is another instance that I may be trying to be too
>> helpful and over extending myself, which does not make the process
>> scale well (the other one being the "one final resend after the
>> list reached a consensus").
>>
>> If the authors collect Acks and Reviewed-by's and resend after the
>> list reached the concensus, it may take one extra iteration, but I
>> no longer have to keep track of these trailers myself, which couldOn Mon, May 11, 2026, at 03:16, Junio C Hamano wrote:
>>>[snip]
>>
>> It’s certainly not necessary, yeah. :)
>>
>> I am basing this on a recollection of someone quoting this from
>> SubmittingPatches:
>>
>> Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and
>> `Tested-by:` lines as necessary to credit people who helped your
>> patch, and "cc:" them when sending such a final version for inclusion.
>>
>> They said that this was outdated since Junio does it himself. But then
>> Junio replied and said that it’s good/better if the contributor does it.
>
> I used to say "let me do this to skip one extra roundtrip" but I
> stopped saying so. Perhaps I should be a bit more explicit and stop
> being silently nice to contributors who do not follow the guidelines
> to the letter in order to unconfuse you and your friends. It
> actually is a tempting thought.
I am personally okay with adding these trailers and think it’s nice to
document such review/ack/etc. interactions.
Just considering this part in isolation, I imagine that you not filling
in missing acks etc. will lead to less such trailers because (1) most
contributors don’t seem to follow up with such updates if the only
change is the trailers section, and (2) most people here (culturally)
don’t add explicit trailer lines in their replies (e.g. an “LGTM” is
clearly an ack, but not explicit).
>> Well, this is another instance that I may be trying to be too
>> helpful and over extending myself, which does not make the process
>> scale well (the other one being the "one final resend after the
>> list reached a consensus").
>>
>> If the authors collect Acks and Reviewed-by's and resend after the
>> list reached the concensus, it may take one extra iteration, but I
>> no longer have to keep track of these trailers myself, which could
>> be a big win.
>>
>> So, I dunno.
>>
>> In conclusion for now: I dunno. :)
>
> I do not know either, but if we agree that everybody should do so
> themselves and I should refrain from applying the ones that lack
> Acks, I can adjust. There will be lot of unapplied patches left on
> the mailing list initially until the contributors adjust their
> behaviour, but in the long run it may be beneficial?
Okay, if the proposal is to *not* e.g. graduate series to `next` that
haven’t applied the acks etc. then I understand how it will likely lead
to some stalls until people adjust.
To be clear, I imagine this is how it would play out:
• The series in itself is ready for `next` and has no unapplied acks
etc.: it graduates to `next`
• The series in itself is ready for `next` but has unapplied acks etc.:
it does not graduate to `next` since the contributor should send a new
version with the trailer changes
***
There is also the paragraph previous to the trailer one:
After the list reached a consensus that it is a good idea to apply the
patch, re-send it with "To:" set to the maintainer{current-maintainer}
and "cc:" the list{git-ml} for inclusion. This is especially relevant
when the maintainer did not heavily participate in the discussion and
instead left the review to trusted others.
Do not forget to add trailers such as `Acked-by:`, [...]
And I have only managed to follow that part maybe, probably one single time.
>> be a big win.
>>
>> So, I dunno.
>>
>> In conclusion for now: I dunno. :)
>
> I do not know either, but if we agree that everybody should do so
> themselves and I should refrain from applying the ones that lack
> Acks, I can adjust. There will be lot of unapplied patches left on
> the mailing list initially until the contributors adjust their
> behaviour, but in the long run it may be beneficial?
Okay, if the proposal is to *not* e.g. graduate series to `next` that
haven’t applied the acks etc. then I understand how it will likely lead
to some stalls until people adjust.
To be clear, I imagine this is how it would play out:
• The series in itself is ready for `next` and has no unapplied acks
etc.: it graduates to `next`
• The series in itself is ready for `next` but has unapplied acks etc.:
it does not graduate to `next` since the contributor should send a new
version with the trailer changes
***
There is also the paragraph previous to the trailer one:
After the list reached a consensus that it is a good idea to apply the
patch, re-send it with "To:" set to the maintainer{current-maintainer}
and "cc:" the list{git-ml} for inclusion. This is especially relevant
when the maintainer did not heavily participate in the discussion and
instead left the review to trusted others.
Do not forget to add trailers such as `Acked-by:`, [...]
And I have only managed to follow that part maybe, probably one single time.
^ permalink raw reply
* [PATCH v2] git-jump: pick a mode automatically when invoked without arguments
From: Greg Hurrell via GitGitGadget @ 2026-05-20 12:31 UTC (permalink / raw)
To: git; +Cc: Jeff King, Greg Hurrell, Erik Cervin Edin, Greg Hurrell,
Greg Hurrell
In-Reply-To: <pull.2108.git.1778231254871.gitgitgadget@gmail.com>
From: Greg Hurrell <greg.hurrell@datadoghq.com>
When `git jump` is invoked with no positional arguments (and no
arguments after `--stdout`) it currently prints usage and exits with
status 1.
But there are several situations where we can usefully infer the most
valuable and likely mode that a user would want to use, and select it
automatically:
1. When there are unmerged paths in the index, the user likely
wants `git jump merge`.
2. When the working tree has unstaged changes, the user likely
wants `git jump diff`.
3. In the presence of conflict markers or whitespace errors (as reported
by `git diff --check`), the user likely wants `git jump ws`.
In this commit we teach `git jump` a new "auto" mode which detects these
cases and dispatches to the corresponding mode automatically. The user
can either explicitly spell out `git jump auto`, or just leave it at
`git jump` (because "auto" is the default).
If none of the interesting cases listed above applies, then auto mode
falls back to the existing usage-and-exit behavior.
Signed-off-by: Greg Hurrell <greg.hurrell@datadoghq.com>
---
git-jump: pick a mode automatically when invoked without arguments
Changes since v0:
* Added explicit "auto" keyword/mode.
* Updated additional detail to usage info and README.
* (Bonus) Added ws usage example to README.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2108%2Fwincent%2Fauto-jump-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2108/wincent/auto-jump-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/2108
Range-diff vs v1:
1: 87fa66d233 ! 1: 5fbc8480ef git-jump: pick a mode automatically when invoked without arguments
@@ Commit message
arguments after `--stdout`) it currently prints usage and exits with
status 1.
- But there are two situations where we can usefully infer the most
+ But there are several situations where we can usefully infer the most
valuable and likely mode that a user would want to use, and select it
- automatically when they run `git jump` without arguments:
+ automatically:
1. When there are unmerged paths in the index, the user likely
wants `git jump merge`.
@@ Commit message
2. When the working tree has unstaged changes, the user likely
wants `git jump diff`.
- Detect these two cases and dispatch to the corresponding mode
- automatically, falling back to the existing usage-and-exit behavior
- when neither holds.
+ 3. In the presence of conflict markers or whitespace errors (as reported
+ by `git diff --check`), the user likely wants `git jump ws`.
+
+ In this commit we teach `git jump` a new "auto" mode which detects these
+ cases and dispatches to the corresponding mode automatically. The user
+ can either explicitly spell out `git jump auto`, or just leave it at
+ `git jump` (because "auto" is the default).
+
+ If none of the interesting cases listed above applies, then auto mode
+ falls back to the existing usage-and-exit behavior.
Signed-off-by: Greg Hurrell <greg.hurrell@datadoghq.com>
## contrib/git-jump/README ##
-@@ contrib/git-jump/README: To use it, just drop git-jump in your PATH, and then invoke it like
- this:
+@@ contrib/git-jump/README: git jump grep foo_bar
+ # arbitrary grep options
+ git jump grep -i foo_bar
- --------------------------------------------------
++# jump to places with conflict markers or whitespace errors
++# (as reported by # `git diff --check`)
++git jump ws
++
+ # use the silver searcher for git jump grep
+ git config jump.grepCmd "ag --column"
++
+# pick a mode automatically: "merge" if there are unmerged paths,
-+# "diff" if the worktree has unstaged changes, otherwise show usage
-+git jump
++# "diff" if the worktree has unstaged changes, "ws" if there are
++# whitespace problems; otherwise show usage
++git jump auto
+
- # jump to changes not yet staged for commit
- git jump diff
++# with no explicit mode, same as "auto"
++git jump
+ --------------------------------------------------
+ You can use the optional argument '--stdout' to print the listing to
## contrib/git-jump/git-jump ##
@@
@@ contrib/git-jump/git-jump
+usage: git jump [--stdout] [<mode>] [<args>]
Jump to interesting elements in an editor.
- The <mode> parameter is one of:
-@@ contrib/git-jump/git-jump: while test $# -gt 0; do
- shift
- done
- if test $# -lt 1; then
-- usage >&2
-- exit 1
+-The <mode> parameter is one of:
++The <mode> parameter is one of the following,
++defaulting to "auto" if omitted:
+
+ diff: elements are diff hunks. Arguments are given to diff.
+
+@@ contrib/git-jump/git-jump: grep: elements are grep hits. Arguments are given to git grep or, if
+
+ ws: elements are whitespace errors. Arguments are given to diff --check.
+
++auto: select one of the other modes based on worktree state;
++ "merge" if there are unmerged paths, "diff" if there are
++ unstaged changes, "ws" if there are whitespace errors.
++
+ If the optional argument `--stdout` is given, print the quickfix
+ lines to standard output instead of feeding it to the editor.
+ EOF
+@@ contrib/git-jump/git-jump: mode_ws() {
+ git diff --check "$@"
+ }
+
++mode_auto() {
+ if test "$(git rev-parse --is-inside-work-tree 2>/dev/null)" != "true"; then
+ usage >&2
+ exit 1
+ fi
-+ if test -n "$(git ls-files -u)"; then
-+ set -- merge
-+ elif ! git diff --quiet; then
-+ set -- diff
++ if test -n "$(git ls-files -u "$@")"; then
++ mode_merge "$@"
++ elif ! git diff --quiet "$@"; then
++ mode_diff "$@"
++ elif ! git diff --check >/dev/null 2>&1; then
++ mode_ws "$@"
+ else
+ usage >&2
+ exit 1
+ fi
++}
++
+ use_stdout=
+ while test $# -gt 0; do
+ case "$1" in
+@@ contrib/git-jump/git-jump: while test $# -gt 0; do
+ shift
+ done
+ if test $# -lt 1; then
+- usage >&2
+- exit 1
++ set -- auto
fi
mode=$1; shift
type "mode_$mode" >/dev/null 2>&1 || { usage >&2; exit 1; }
contrib/git-jump/README | 12 ++++++++++++
contrib/git-jump/git-jump | 29 +++++++++++++++++++++++++----
2 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/contrib/git-jump/README b/contrib/git-jump/README
index 3211841305..ac35792e55 100644
--- a/contrib/git-jump/README
+++ b/contrib/git-jump/README
@@ -75,8 +75,20 @@ git jump grep foo_bar
# arbitrary grep options
git jump grep -i foo_bar
+# jump to places with conflict markers or whitespace errors
+# (as reported by # `git diff --check`)
+git jump ws
+
# use the silver searcher for git jump grep
git config jump.grepCmd "ag --column"
+
+# pick a mode automatically: "merge" if there are unmerged paths,
+# "diff" if the worktree has unstaged changes, "ws" if there are
+# whitespace problems; otherwise show usage
+git jump auto
+
+# with no explicit mode, same as "auto"
+git jump
--------------------------------------------------
You can use the optional argument '--stdout' to print the listing to
diff --git a/contrib/git-jump/git-jump b/contrib/git-jump/git-jump
index 8d1d5d79a6..43d3b42a41 100755
--- a/contrib/git-jump/git-jump
+++ b/contrib/git-jump/git-jump
@@ -2,10 +2,11 @@
usage() {
cat <<\EOF
-usage: git jump [--stdout] <mode> [<args>]
+usage: git jump [--stdout] [<mode>] [<args>]
Jump to interesting elements in an editor.
-The <mode> parameter is one of:
+The <mode> parameter is one of the following,
+defaulting to "auto" if omitted:
diff: elements are diff hunks. Arguments are given to diff.
@@ -16,6 +17,10 @@ grep: elements are grep hits. Arguments are given to git grep or, if
ws: elements are whitespace errors. Arguments are given to diff --check.
+auto: select one of the other modes based on worktree state;
+ "merge" if there are unmerged paths, "diff" if there are
+ unstaged changes, "ws" if there are whitespace errors.
+
If the optional argument `--stdout` is given, print the quickfix
lines to standard output instead of feeding it to the editor.
EOF
@@ -82,6 +87,23 @@ mode_ws() {
git diff --check "$@"
}
+mode_auto() {
+ if test "$(git rev-parse --is-inside-work-tree 2>/dev/null)" != "true"; then
+ usage >&2
+ exit 1
+ fi
+ if test -n "$(git ls-files -u "$@")"; then
+ mode_merge "$@"
+ elif ! git diff --quiet "$@"; then
+ mode_diff "$@"
+ elif ! git diff --check >/dev/null 2>&1; then
+ mode_ws "$@"
+ else
+ usage >&2
+ exit 1
+ fi
+}
+
use_stdout=
while test $# -gt 0; do
case "$1" in
@@ -99,8 +121,7 @@ while test $# -gt 0; do
shift
done
if test $# -lt 1; then
- usage >&2
- exit 1
+ set -- auto
fi
mode=$1; shift
type "mode_$mode" >/dev/null 2>&1 || { usage >&2; exit 1; }
base-commit: 1c00d2d8392f603a6263f11f1a50fde96ae5475e
--
gitgitgadget
^ permalink raw reply related
* [PATCH v3] remote: qualify "git pull" advice for non-upstream compareBranches
From: Harald Nordgren via GitGitGadget @ 2026-05-20 13:10 UTC (permalink / raw)
To: git; +Cc: Harald Nordgren, Harald Nordgren
In-Reply-To: <pull.2301.v2.git.git.1778665812261.gitgitgadget@gmail.com>
From: Harald Nordgren <haraldnordgren@gmail.com>
Enable ENABLE_ADVICE_PULL for push-branch comparisons too, not just
the upstream entry, so the "use git pull" hint prints when the local
branch is behind its push branch.
Spell out "git pull <remote> <branch>" so running the suggested
command actually pulls the ref the user was told about; plain
"git pull" would fetch the upstream instead.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
remote: qualify "git pull" advice for non-upstream branches
* Only suggest git pull <remote> <branch> when plain git pull wouldn't
do the right thing.
* Tests: when upstream and push are the same ref, the message stays
plain git pull.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2301%2FHaraldNordgren%2Fstatus-pull-advice-qualified-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2301/HaraldNordgren/status-pull-advice-qualified-v3
Pull-Request: https://github.com/git/git/pull/2301
Range-diff vs v2:
1: 1f06873f82 ! 1: 3703be9aac remote: qualify "git pull" advice for non-upstream branches
@@ Metadata
Author: Harald Nordgren <haraldnordgren@gmail.com>
## Commit message ##
- remote: qualify "git pull" advice for non-upstream branches
+ remote: qualify "git pull" advice for non-upstream compareBranches
- When "git status" reports the local branch is behind the push
- branch, the advice suggested a bare "git pull". That follows the
- upstream, which may live on a different remote, so emit
- "git pull <remote> <branch>" instead.
+ Enable ENABLE_ADVICE_PULL for push-branch comparisons too, not just
+ the upstream entry, so the "use git pull" hint prints when the local
+ branch is behind its push branch.
- Also enable the pull advice for push-branch comparisons; it was
- previously only set for the upstream.
+ Spell out "git pull <remote> <branch>" so running the suggested
+ command actually pulls the ref the user was told about; plain
+ "git pull" would fetch the upstream instead.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
@@ remote.c: int format_tracking_info(struct branch *branch, struct strbuf *sb,
flags |= ENABLE_ADVICE_DIVERGENCE;
+ if (is_push) {
+ flags |= ENABLE_ADVICE_PUSH;
-+ push_remote_name = pushremote_for_branch(branch, NULL);
-+ if (push_remote_name &&
-+ skip_prefix(full_ref, "refs/remotes/", &push_branch_name) &&
-+ skip_prefix(push_branch_name, push_remote_name, &push_branch_name) &&
-+ *push_branch_name == '/')
-+ push_branch_name++;
-+ else
-+ push_remote_name = NULL;
++ if (!upstream_ref || strcmp(upstream_ref, full_ref)) {
++ push_remote_name = pushremote_for_branch(branch, NULL);
++ if (push_remote_name &&
++ skip_prefix(full_ref, "refs/remotes/", &push_branch_name) &&
++ skip_prefix(push_branch_name, push_remote_name, &push_branch_name) &&
++ *push_branch_name == '/')
++ push_branch_name++;
++ else
++ push_remote_name = NULL;
++ }
+ }
format_branch_comparison(sb, !cmp, ours, theirs, short_ref,
+ push_remote_name, push_branch_name,
@@ t/t6040-tracking-info.sh: test_expect_success 'status.compareBranches with remap
test_cmp expect actual
'
-+test_expect_success 'status.compareBranches with behind push branch suggests qualified pull' '
++test_expect_success 'status.compareBranches behind both upstream and push' '
+ test_config -C test push.default current &&
+ test_config -C test remote.pushDefault origin &&
+ test_config -C test status.compareBranches "@{upstream} @{push}" &&
+ git -C test checkout -b feature13 upstream/main &&
+ (cd test && advance work13) &&
+ git -C test push origin &&
++ git -C test branch --set-upstream-to upstream/ahead &&
+ git -C test reset --hard HEAD^ &&
+ git -C test status >actual &&
+ cat >expect <<-EOF &&
+ On branch feature13
-+ Your branch is up to date with ${SQ}upstream/main${SQ}.
++ Your branch is behind ${SQ}upstream/ahead${SQ} by 1 commit, and can be fast-forwarded.
++ (use "git pull" to update your local branch)
+
+ Your branch is behind ${SQ}origin/feature13${SQ} by 1 commit, and can be fast-forwarded.
+ (use "git pull origin feature13" to update your local branch)
@@ t/t6040-tracking-info.sh: test_expect_success 'status.compareBranches with remap
+ EOF
+ test_cmp expect actual
+'
++
++test_expect_success 'status.compareBranches with behind push branch and no upstream' '
++ test_config -C test push.default current &&
++ test_config -C test remote.pushDefault origin &&
++ test_config -C test status.compareBranches "@{push}" &&
++ git -C test checkout --no-track -b feature15 upstream/main &&
++ (cd test && advance work15) &&
++ git -C test push origin &&
++ git -C test reset --hard HEAD^ &&
++ git -C test status >actual &&
++ cat >expect <<-EOF &&
++ On branch feature15
++ Your branch is behind ${SQ}origin/feature15${SQ} by 1 commit, and can be fast-forwarded.
++ (use "git pull origin feature15" to update your local branch)
++
++ nothing to commit, working tree clean
++ EOF
++ test_cmp expect actual
++'
++
++test_expect_success 'status.compareBranches behind upstream-equals-push suggests plain pull' '
++ test_config -C test status.compareBranches "@{upstream} @{push}" &&
++ git -C test checkout -b feature16 origin/main &&
++ (cd test && advance work16) &&
++ git -C test push origin HEAD:main &&
++ git -C test reset --hard HEAD^ &&
++ git -C test status >actual &&
++ cat >expect <<-EOF &&
++ On branch feature16
++ Your branch is behind ${SQ}origin/main${SQ} by 1 commit, and can be fast-forwarded.
++ (use "git pull" to update your local branch)
++
++ nothing to commit, working tree clean
++ EOF
++ test_cmp expect actual
++'
+
test_done
remote.c | 46 +++++++++++++++++++-----
t/t6040-tracking-info.sh | 78 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 115 insertions(+), 9 deletions(-)
diff --git a/remote.c b/remote.c
index a664cd166a..2b82f6b312 100644
--- a/remote.c
+++ b/remote.c
@@ -2267,6 +2267,8 @@ static void format_branch_comparison(struct strbuf *sb,
bool up_to_date,
int ours, int theirs,
const char *branch_name,
+ const char *push_remote_name,
+ const char *push_branch_name,
enum ahead_behind_flags abf,
unsigned flags)
{
@@ -2302,9 +2304,15 @@ static void format_branch_comparison(struct strbuf *sb,
"and can be fast-forwarded.\n",
theirs),
branch_name, theirs);
- if (use_pull_advice && advice_enabled(ADVICE_STATUS_HINTS))
- strbuf_addstr(sb,
- _(" (use \"git pull\" to update your local branch)\n"));
+ if (use_pull_advice && advice_enabled(ADVICE_STATUS_HINTS)) {
+ if (push_remote_name && push_branch_name)
+ strbuf_addf(sb,
+ _(" (use \"git pull %s %s\" to update your local branch)\n"),
+ push_remote_name, push_branch_name);
+ else
+ strbuf_addstr(sb,
+ _(" (use \"git pull\" to update your local branch)\n"));
+ }
} else {
strbuf_addf(sb,
Q_("Your branch and '%s' have diverged,\n"
@@ -2315,9 +2323,15 @@ static void format_branch_comparison(struct strbuf *sb,
"respectively.\n",
ours + theirs),
branch_name, ours, theirs);
- if (use_divergence_advice && advice_enabled(ADVICE_STATUS_HINTS))
- strbuf_addstr(sb,
- _(" (use \"git pull\" if you want to integrate the remote branch with yours)\n"));
+ if (use_divergence_advice && advice_enabled(ADVICE_STATUS_HINTS)) {
+ if (push_remote_name && push_branch_name)
+ strbuf_addf(sb,
+ _(" (use \"git pull %s %s\" if you want to integrate the remote branch with yours)\n"),
+ push_remote_name, push_branch_name);
+ else
+ strbuf_addstr(sb,
+ _(" (use \"git pull\" if you want to integrate the remote branch with yours)\n"));
+ }
}
}
@@ -2355,6 +2369,8 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb,
int ours, theirs, cmp;
int is_upstream, is_push;
unsigned flags = 0;
+ const char *push_remote_name = NULL;
+ const char *push_branch_name = NULL;
full_ref = resolve_compare_branch(branch,
branches.items[i].string);
@@ -2396,13 +2412,25 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb,
if (reported)
strbuf_addstr(sb, "\n");
- if (is_upstream)
+ if (is_upstream || is_push)
flags |= ENABLE_ADVICE_PULL;
- if (is_push)
- flags |= ENABLE_ADVICE_PUSH;
if (show_divergence_advice && is_upstream)
flags |= ENABLE_ADVICE_DIVERGENCE;
+ if (is_push) {
+ flags |= ENABLE_ADVICE_PUSH;
+ if (!upstream_ref || strcmp(upstream_ref, full_ref)) {
+ push_remote_name = pushremote_for_branch(branch, NULL);
+ if (push_remote_name &&
+ skip_prefix(full_ref, "refs/remotes/", &push_branch_name) &&
+ skip_prefix(push_branch_name, push_remote_name, &push_branch_name) &&
+ *push_branch_name == '/')
+ push_branch_name++;
+ else
+ push_remote_name = NULL;
+ }
+ }
format_branch_comparison(sb, !cmp, ours, theirs, short_ref,
+ push_remote_name, push_branch_name,
abf, flags);
reported = 1;
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
index 0242b5bf7a..b613aba33a 100755
--- a/t/t6040-tracking-info.sh
+++ b/t/t6040-tracking-info.sh
@@ -646,4 +646,82 @@ test_expect_success 'status.compareBranches with remapped push and upstream remo
test_cmp expect actual
'
+test_expect_success 'status.compareBranches behind both upstream and push' '
+ test_config -C test push.default current &&
+ test_config -C test remote.pushDefault origin &&
+ test_config -C test status.compareBranches "@{upstream} @{push}" &&
+ git -C test checkout -b feature13 upstream/main &&
+ (cd test && advance work13) &&
+ git -C test push origin &&
+ git -C test branch --set-upstream-to upstream/ahead &&
+ git -C test reset --hard HEAD^ &&
+ git -C test status >actual &&
+ cat >expect <<-EOF &&
+ On branch feature13
+ Your branch is behind ${SQ}upstream/ahead${SQ} by 1 commit, and can be fast-forwarded.
+ (use "git pull" to update your local branch)
+
+ Your branch is behind ${SQ}origin/feature13${SQ} by 1 commit, and can be fast-forwarded.
+ (use "git pull origin feature13" to update your local branch)
+
+ nothing to commit, working tree clean
+ EOF
+ test_cmp expect actual
+'
+
+test_expect_success 'status.compareBranches with remapped push and behind push branch' '
+ test_config -C test remote.pushDefault origin &&
+ test_config -C test remote.origin.push refs/heads/feature14:refs/heads/remapped14 &&
+ test_config -C test status.compareBranches "@{push}" &&
+ git -C test checkout -b feature14 upstream/main &&
+ (cd test && advance work14) &&
+ git -C test push &&
+ git -C test reset --hard HEAD^ &&
+ git -C test status >actual &&
+ cat >expect <<-EOF &&
+ On branch feature14
+ Your branch is behind ${SQ}origin/remapped14${SQ} by 1 commit, and can be fast-forwarded.
+ (use "git pull origin remapped14" to update your local branch)
+
+ nothing to commit, working tree clean
+ EOF
+ test_cmp expect actual
+'
+
+test_expect_success 'status.compareBranches with behind push branch and no upstream' '
+ test_config -C test push.default current &&
+ test_config -C test remote.pushDefault origin &&
+ test_config -C test status.compareBranches "@{push}" &&
+ git -C test checkout --no-track -b feature15 upstream/main &&
+ (cd test && advance work15) &&
+ git -C test push origin &&
+ git -C test reset --hard HEAD^ &&
+ git -C test status >actual &&
+ cat >expect <<-EOF &&
+ On branch feature15
+ Your branch is behind ${SQ}origin/feature15${SQ} by 1 commit, and can be fast-forwarded.
+ (use "git pull origin feature15" to update your local branch)
+
+ nothing to commit, working tree clean
+ EOF
+ test_cmp expect actual
+'
+
+test_expect_success 'status.compareBranches behind upstream-equals-push suggests plain pull' '
+ test_config -C test status.compareBranches "@{upstream} @{push}" &&
+ git -C test checkout -b feature16 origin/main &&
+ (cd test && advance work16) &&
+ git -C test push origin HEAD:main &&
+ git -C test reset --hard HEAD^ &&
+ git -C test status >actual &&
+ cat >expect <<-EOF &&
+ On branch feature16
+ Your branch is behind ${SQ}origin/main${SQ} by 1 commit, and can be fast-forwarded.
+ (use "git pull" to update your local branch)
+
+ nothing to commit, working tree clean
+ EOF
+ test_cmp expect actual
+'
+
test_done
base-commit: 7bcaabddcf68bd0702697da5904c3b68c52f94cf
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH] log: let --follow follow renames in merge commits
From: Miklos Vajna @ 2026-05-20 13:28 UTC (permalink / raw)
To: Elijah Newren, Jeff King; +Cc: git
In-Reply-To: <xmqqo6ib7vlp.fsf@gitster.g>
Hi Elijah, Jeff,
On Tue, May 19, 2026 at 03:37:54PM +0900, Junio C Hamano <gitster@pobox.com> wrote:
> > :-) Should I just wait more or should I resend this?
>
> Rather, ask other reviewers
I did a small improvement to how 'git log --follow' works, as in if the
rename happens inside the merge commit itself, then the rename was
detected "vs the first parent", but it wasn't detected "vs other
parents", which is painful with a "subtree" merge commit.
I'm not sure if it adds value, but I can append a one-paragraph summary
of Junio's comment in this thread to the end the commit message, to be
more explicit that the inherent limitation of the current log follow
design (single path, once a rename is detected, we only care about the
new path) is not changed with the patch, this is just a fix patch so
'git log' works better, similar to how 'git blame' already does.
May I ask you to review the patch?
Thanks,
Miklos
^ permalink raw reply
* Re: [PATCH 4/8] pack-bitmap: consolidate `find_object_pos()` success path
From: SZEDER Gábor @ 2026-05-20 14:42 UTC (permalink / raw)
To: Taylor Blau; +Cc: git, Junio C Hamano, Jeff King, Elijah Newren, Derrick Stolee
In-Reply-To: <c9a560660949c53575a9b1e81160d25212a1f484.1779207127.git.me@ttaylorr.com>
On Tue, May 19, 2026 at 12:12:44PM -0400, Taylor Blau wrote:
> Both sides of `find_object_pos()` report success in the same way by
> setting the optional `found` out-parameter and return the resolved
> bitmap position.
>
> Prepare for adding more bookkeeping around object-position lookups by
> storing the result in a local `pos` variable and sharing the success
This 'pos' variable will only be declared in the next commit,
resulting in an error building this commit:
pack-bitmap-write.c: In function ‘find_object_pos’:
pack-bitmap-write.c:227:17: error: ‘pos’ undeclared (first use in this function)
227 | pos = oe_in_pack_pos(writer->to_pack, entry) + base_objects;
| ^~~
pack-bitmap-write.c:227:17: note: each undeclared identifier is reported only once for each function it appears in
make: *** [Makefile:2917: pack-bitmap-write.o] Error 1
> return path between the packlist and MIDX cases.
>
> Signed-off-by: Taylor Blau <me@ttaylorr.com>
> ---
> pack-bitmap-write.c | 17 ++++++++---------
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/pack-bitmap-write.c b/pack-bitmap-write.c
> index 651ad467469..6483fdc7daf 100644
> --- a/pack-bitmap-write.c
> +++ b/pack-bitmap-write.c
> @@ -224,23 +224,22 @@ static uint32_t find_object_pos(struct bitmap_writer *writer,
> if (writer->midx)
> base_objects = writer->midx->num_objects +
> writer->midx->num_objects_in_base;
> -
> - if (found)
> - *found = 1;
> - return oe_in_pack_pos(writer->to_pack, entry) + base_objects;
> + pos = oe_in_pack_pos(writer->to_pack, entry) + base_objects;
> } else if (writer->midx) {
> - uint32_t at, pos;
> + uint32_t at;
>
> if (!bsearch_midx(oid, writer->midx, &at))
> goto missing;
> if (midx_to_pack_pos(writer->midx, at, &pos) < 0)
> goto missing;
> -
> - if (found)
> - *found = 1;
> - return pos;
> + } else {
> + goto missing;
> }
>
> + if (found)
> + *found = 1;
> + return pos;
> +
> missing:
> if (found)
> *found = 0;
> --
> 2.54.0.rc1.84.g30ce254312c
>
^ permalink raw reply
* Re: [PATCH] commit: fall back to full read when maybe_tree is NULL
From: Derrick Stolee @ 2026-05-20 16:20 UTC (permalink / raw)
To: Jeff King, git; +Cc: Rasmus Villemoes, Daniel Mach
In-Reply-To: <20260519050513.GA1635924@coredump.intra.peff.net>
On 5/19/2026 1:05 AM, Jeff King wrote:
> When we load a commit object from the commit graph (rather than reading
> the object contents), we don't fill in its "maybe_tree" entry, but
> rather wait to lazy-load it. This goes back to 7b8a21dba1 (commit-graph:
> lazy-load trees for commits, 2018-04-06), and saves the work of
> instantiating tree objects that nobody cares about.
>
> But it creates a data dependency: now the commit struct depends on the
> graph file to do that lazy load. This is a problem if we close the graph
> file; now we have a commit struct that claims to be parsed but is
> missing some of its data.
> Reported twice recently:
>
> - https://lore.kernel.org/git/87h5onsi0f.fsf@prevas.dk/
>
> - https://lore.kernel.org/git/6ae85515-9373-4c9e-90d2-5e4176590c5b@suse.com/
>
> I don't why we suddenly got two reports. AFAICT the bug goes back to
> 2018, though it would become more prominent as use of commit graphs
> increased.
Likely, this may have changed with the switch to using geometric
maintenance instead of gc maintenance by default in Git 2.54.0. That
perhaps increased the amount of commit-graphs being present.
> +static void load_tree_from_commit_contents(struct repository *r, struct commit *commit)
> +{
> + enum object_type type;
> + unsigned long size;
> + char *buf;
> + const char *p;
> + struct object_id tree_oid;
> +
> + buf = odb_read_object(r->objects, &commit->object.oid, &type, &size);
> + if (!buf)
> + return;
> +
> + if (type == OBJ_COMMIT &&
> + skip_prefix(buf, "tree ", &p) &&
> + !parse_oid_hex(p, &tree_oid, &p) &&
> + *p == '\n')
> + set_commit_tree(commit, lookup_tree(r, &tree_oid));
> +
> + free(buf);
> +}
> +
I like this focused parsing of the commit contents. I also briefly
considered "unparsing" the commit, but you make a good point in your
message why a focused parse here is important, especially around
munging of the parent list.
> struct tree *repo_get_commit_tree(struct repository *r,
> const struct commit *commit)
> {
> @@ -443,7 +464,17 @@ struct tree *repo_get_commit_tree(struct repository *r,
> if (commit_graph_position(commit) != COMMIT_NOT_FROM_GRAPH)
> return get_commit_tree_in_graph(r, commit);
>
> - return NULL;
> + /*
> + * This is either a corrupt commit, or one which we partially loaded
> + * from a graph file but then subsequently threw away the graph data.
> + *
> + * Optimistically assume it's the latter and try to reload from
> + * scratch. This gives a performance penalty if it really is a corrupt
> + * commit, but presumably that happens rarely (and only once per
> + * process).
> + */
> + load_tree_from_commit_contents(r, (struct commit *)commit);
> + return commit->maybe_tree;
> }
I agree that this is the right place to insert this logic.
> +test_expect_success 'dissociate from repo with commit graph' '
> + git init orig &&
> + # We are trying to make sure the dissociated repo can
> + # find the tree of the tip commit, so the test could still
> + # serve its purpose with an empty tree. But having actual
> + # content future-proofs us against any kind of internal
> + # empty-tree optimizations.
> + echo content >orig/file &&
> + git -C orig add . &&
> + git -C orig commit -m foo &&
> +
> + # We will use graph.git as our "local" source to dissociate
> + # from.
> + git clone --bare orig graph.git &&
> + git -C graph.git commit-graph write --reachable &&
> +
> + # And then finally clone orig, using graph.git to get our objects. This
> + # must be non-bare so that we perform the checkout step, which will
> + # need to access the tree of HEAD, which we will have originally loaded
> + # via the commit graph.
> + git clone --no-local --reference graph.git --dissociate orig clone
> +'
> +
Thanks for the clear extra coverage here.
-Stolee
^ permalink raw reply
* Re: [PATCH] commit: fall back to full read when maybe_tree is NULL
From: Derrick Stolee @ 2026-05-20 16:22 UTC (permalink / raw)
To: Jeff King, Junio C Hamano; +Cc: git, Rasmus Villemoes, Daniel Mach
In-Reply-To: <20260519061534.GA1709881@coredump.intra.peff.net>
On 5/19/2026 2:15 AM, Jeff King wrote:
> On Tue, May 19, 2026 at 02:56:51PM +0900, Junio C Hamano wrote:
>> Looks quite straight-forward. Don't you need to pay attention to
>> r->hash_algo and call parse_oid_hex_algop() instead?
>>
>> Or are we pretty much sure that "r" is always "the_repository" here,
>> in which case parse_oid_hex() that uses "the_hash_algo" would be
>> sufficient?
>
> No, I didn't even think about it, since the use of the_hash_algo is
> hidden behind the function. We definitely should use the hash algo from
> "r", since we have access to it. I'm not even sure if you can have repos
> of two different hashes loaded in the same process at this point, but
> certainly it is the correct long-term direction.
>
> Here's a re-roll with the one-line fixup:
>
> diff --git a/commit.c b/commit.c
> index cfc87ad185..499a9602ad 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -448,7 +448,7 @@ static void load_tree_from_commit_contents(struct repository *r, struct commit *
>
> if (type == OBJ_COMMIT &&
> skip_prefix(buf, "tree ", &p) &&
> - !parse_oid_hex(p, &tree_oid, &p) &&
> + !parse_oid_hex_algop(p, &tree_oid, &p, r->hash_algo) &&
> *p == '\n')
> set_commit_tree(commit, lookup_tree(r, &tree_oid));
>
I figured that this was already tested via the test variable that
runs the test with SHA256, but the multi-repo case is an interesting
one that I'm sure would catch us at some point in the future.
I'm happy with the re-roll here.
Thanks,
-Stolee
^ permalink raw reply
* Re: [PATCH v8] revision.c: implement --max-count-oldest
From: Mirko Faina @ 2026-05-20 16:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jean-Noël Avila, Patrick Steinhardt,
Tian Yuchen, Ben Knoble, Johannes Sixt, Chris Torek, Mirko Faina
In-Reply-To: <xmqq7boy4o05.fsf@gitster.g>
On Wed, May 20, 2026 at 03:02:34PM +0900, Junio C Hamano wrote:
> Mirko Faina <mroik@delayed.space> writes:
>
> > --max-count is a commit limiting option sets a maximum amount of commits
> > to be shown. If a user wants to see only the first N commits of the
> > history (the oldest commits) they'd have to do something like
> >
> > git log $(git rev-list HEAD | tail -n N | head -n 1)
> >
> > This is not very user-friendly.
> >
> > Teach get_revision() the --max-count-oldest option.
> >
> > Signed-off-by: Mirko Faina <mroik@delayed.space>
> > ---
>
> This breaks CI
>
> https://github.com/git/git/actions/runs/26138986677/job/76880268854#step:4:2072
>
> Squash something like this to fix.
>
> --- >8 ---
> Subject: [PATCH] SQUASH??? test portability and other fixes
>
> * "test_when_finished" should use "rm -f", not an error-detecting
> "rm", as the execution may not have reached to the point to create
> the "actual" file it is removing.
>
> * Do not hide exit status of "git log" by piping its output into
> another process.
>
> * Do not expect output of "wc -l" is portable. macOS puts extra
> whitespaces in front, while GNU/Linux does not.
> ---
> t/t4202-log.sh | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
Sorry about that. And thank you for the fix.
^ permalink raw reply
* Re: [PATCH 4/8] pack-bitmap: consolidate `find_object_pos()` success path
From: Taylor Blau @ 2026-05-20 17:12 UTC (permalink / raw)
To: SZEDER Gábor
Cc: git, Junio C Hamano, Jeff King, Elijah Newren, Derrick Stolee
In-Reply-To: <ag3IXa3lKLmQC1tD@szeder.dev>
On Wed, May 20, 2026 at 04:42:37PM +0200, SZEDER Gábor wrote:
> On Tue, May 19, 2026 at 12:12:44PM -0400, Taylor Blau wrote:
> > Both sides of `find_object_pos()` report success in the same way by
> > setting the optional `found` out-parameter and return the resolved
> > bitmap position.
> >
> > Prepare for adding more bookkeeping around object-position lookups by
> > storing the result in a local `pos` variable and sharing the success
>
> This 'pos' variable will only be declared in the next commit,
> resulting in an error building this commit:
>
> pack-bitmap-write.c: In function ‘find_object_pos’:
> pack-bitmap-write.c:227:17: error: ‘pos’ undeclared (first use in this function)
> 227 | pos = oe_in_pack_pos(writer->to_pack, entry) + base_objects;
> | ^~~
> pack-bitmap-write.c:227:17: note: each undeclared identifier is reported only once for each function it appears in
> make: *** [Makefile:2917: pack-bitmap-write.o] Error 1
Thanks for spotting. I had split the patch that immediately follows this
one into two to make the latter easier to read, but have no idea how
this snuck through.
It's fixed by declaring `pos` in this commit:
--- 8< ---
diff --git a/pack-bitmap-write.c b/pack-bitmap-write.c
index 6483fdc7daf..42ed22feacc 100644
--- a/pack-bitmap-write.c
+++ b/pack-bitmap-write.c
@@ -217,6 +217,7 @@ static uint32_t find_object_pos(struct bitmap_writer *writer,
const struct object_id *oid, int *found)
{
struct object_entry *entry;
+ uint32_t pos;
entry = packlist_find(writer->to_pack, oid);
if (entry) {
--- >8 ---
, but I'll send a re-roll after the rest of the series has been
reviewed.
Thanks,
Taylor
^ permalink raw reply related
* Re: [BUG] "git diff --word-diff" gives a diff while they are only space changes
From: Michael Montalbo @ 2026-05-20 20:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Torek, Johannes Sixt, vincent, git
In-Reply-To: <xmqqo6ic8564.fsf@gitster.g>
On Mon, May 18, 2026 at 8:11 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Chris Torek <chris.torek@gmail.com> writes:
>
> > Call it an "implementation note" (or, if you like, a "practical
> > consideration"?).
> > Something along these lines might work...
> >
> > Implementation Note
> >
> > The --word-diff option currently operates by taking the same
> > line by line diff that you get without the option, then massaging
> > the result into a word-by-word difference. This may cause an
> > unnecessarily-larger diff than you would see with a more-clever
> > implementation. If and when Git acquires a more-clever
> > implementation, the output may change. Note that this is
> > similar to the --diff-algorithm option, which may change the
> > output.
> >
> > Regardless of which algorithm is used, _any_ diff simply shows
> > _a_ way to achieve some particular change. It's impossible for
> > any algorithm to tell whether someone deleted two lines and
> > then put one back exactly as it appeared earlier, saving the
> > resulting text, vs deleting a single line, for instance. Only a
> > keystroke-by-keystroke logger would be able to tell what the
> > human operator actually typed into some editor. Git does
> > not have that information, and having it is not desired.
> >
> > Chris
>
> I understand your frustration in the second paragraph ;-) but let's
> not go there. The first paragraph is excellent. It gives readers a
> clear enough explanation to understand what is happening and stop
> complaining where there is nothing to complain about (which is
> already hinted by the "Note that" at the end).
>
Thanks for the ideas, Chris. Here is my attempt at synthesizing Chris'
suggestions and Junio's feedback:
The `--word-diff` option operates by taking the same line-by-line
diff that is produced without the option and computing
word-by-word changes within each hunk. This may produce a
larger diff than a dedicated word-diff tool would. If Git
acquires a different implementation in the future, the output
may change. Note that this is similar to the `--diff-algorithm`
option, which may also change the output.
Does this work?
^ permalink raw reply
* [PATCH v2 00/11] Improve git gui operation without a worktree
From: Mark Levedahl @ 2026-05-20 20:23 UTC (permalink / raw)
To: git; +Cc: j6t, egg_mushroomcow, bootaina702, Mark Levedahl
In-Reply-To: <20260514143322.865587-1-mlevedahl@gmail.com>
git gui has a number of inter-related problems that result in problems
during startup from anything but a checked out worktree pointing at a
valid git repository. Some of the symptoms are:
- blame / browser subcommands, and launching gitk, are intended to be
useful without a worktree, but fail to work.
- unlike git, git-gui is supposed to use the parent directory as a
worktree if started from the .git subdirectory in the very common
single worktree + embedded git repository format. This does not
work.
- git-gui includes a repository picker allowing a user to select a
worktree from a list and/or start a new repo+worktree: this dialog can
appear at unexpected times, masking useful error feedback on
configuration problems.
This patch series addresses the above issues, substantially rewriting
the initial repository/worktree process to rely upon git rev-parse so
that git's knowledge of access rules, repository configuration, and use
of GIT_DIR / GIT_WORK_TREE (or git --gitdir / --work-tree) is used
throughout, replacing code largely based upon what git did in 2008. This
also means that git gui will naturally gain any new rules implmented in
git-core.
With this, git-gui only exports GIT_WORK_TREE when non-empty.
GIT_WORK_TREE is needed, and must be exported, if the user is overriding
core.worktree in the git repository. But, GIT_WORK_TREE cannot be used
to specify the lack of a worktree, so exporting an empty GIT_WORK_TREE
is one of the problems fixed by this series.
v2 of this series is a very substantial rewrite driven by j6t's review,
with patches reoranized and squashed, interfaces to the repository
chooser changed, a different code structure to allow user control of the
repository picker, a different approach to fixing the command line
parser for blame / browser, and other more minor changes. Patches
for fixing blame / browser are now after all discovery refactoring as
they cannot be tested without some of those fixes.
Many subtle things are fixed beyond the list at the top, including
better compatibility with git blame and repeatable browser / blame
operation for specific revs not in the worktree, regardless of the
worktree state. j6t indicated that in the git-gui project, the following
fails in the current release:
cd lib
GIT_DIR=$PWD/../.git GIT_WORK_TREE=$PWD/.. ../git-gui.sh browser origin/master .
This is due to a _prefix issue, and is fixed as of the patch
git-gui: use git rev-parse for worktree discovery
Mark Levedahl (11):
git-gui: guard set/unset of GIT_DIR and GIT_WORK_TREE
git-gui: return status from choose_repository::pick
git-gui: use --absolute-git-dir
git-gui: use rev-parse exclusively to find a repository
git-gui: simplify [is_bare] to report if a worktree is known
git-gui: use git rev-parse for worktree discovery
git-gui: try harder to find worktree from gitdir
git-gui: use HEAD as current branch when detached (bug fix)
git-gui: allow specifying path '.' to the browser
git-gui: adapt blame/browser parsing for bare operation
git-gui: add gui and pick as explicit subcommands
git-gui.sh | 412 +++++++++++++++++++++++---------------
lib/choose_repository.tcl | 21 +-
2 files changed, 257 insertions(+), 176 deletions(-)
Interdiff against v1:
diff --git a/git-gui.sh b/git-gui.sh
index c56aeeff88..299c1a0292 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -648,6 +648,9 @@ proc load_current_branch {} {
set current_branch [git branch --show-current]
set is_detached [expr [string length $current_branch] == 0]
+ if {$is_detached} {
+ set current_branch {HEAD}
+ }
}
auto_load tk_optionMenu
@@ -1021,7 +1024,8 @@ proc load_config {include_global} {
##
## feature option selection
-set run_picker_on_error 1
+enable_option picker
+enable_option gitdir_discovery
if {[regexp {^git-(.+)$} [file tail $argv0] _junk subcommand]} {
unset _junk
} else {
@@ -1031,9 +1035,11 @@ if {$subcommand eq {gui.sh}} {
set subcommand gui
}
if {$subcommand eq {gui} && [llength $argv] > 0} {
- set run_picker_on_error 0
set subcommand [lindex $argv 0]
set argv [lrange $argv 1 end]
+ if {$subcommand eq {gui}} {
+ disable_option picker
+ }
}
enable_option multicommit
@@ -1049,7 +1055,7 @@ blame {
disable_option multicommit
disable_option branch
disable_option transport
- set run_picker_on_error 0
+ disable_option picker
}
citool {
enable_option singlecommit
@@ -1058,7 +1064,7 @@ citool {
disable_option multicommit
disable_option branch
disable_option transport
- set run_picker_on_error 0
+ disable_option picker
while {[llength $argv] > 0} {
set a [lindex $argv 0]
@@ -1081,6 +1087,9 @@ citool {
set argv [lrange $argv 1 end]
}
}
+pick {
+ disable_option gitdir_discovery
+}
}
######################################################################
@@ -1104,21 +1113,39 @@ unset argv0dir
##
## repository setup
-proc is_parent_worktree {} {
- # Directory 'parent' of a repository named 'parent/.git' might be the worktree
- set ok 0
+proc find_worktree_from_gitdir {} {
+ # Directory 'parent' of a repository named 'parent/.git' might be the worktree.
+ # Assure parent is a worktree and using the git repository already discovered.
+ # Also, handle case of being in a worktree's gitdir, where file "gitdir" points to
+ # gitlink file .git in the real worktree.
+ set worktree {}
if {[file tail $::_gitdir] eq {.git}} {
- set gitdir_parent [file join $::_gitdir {..}]
- set expected_worktree [file normalize $gitdir_parent]
- catch {set git_worktree [git -C $gitdir_parent rev-parse --show-toplevel]}
- if {[string compare $expected_worktree $git_worktree] == 0} {
- set ::_prefix {}
- set ::_gitworktree $git_worktree
- cd $git_worktree
- set ok 1
+ if {[catch {
+ set gitdir_parent [file dirname $::_gitdir]
+ set worktree [git -C $gitdir_parent rev-parse --show-toplevel]
+ set parent_gitdir [git -C $worktree rev-parse --absolute-git-dir]
+ if {$::_gitdir ne $parent_gitdir} {
+ set worktree {}
+ }
+ }]} {
+ set worktree {}
+ }
+ } elseif [file exists {gitdir}] {
+ if {[catch {
+ set fd_gitdir [open {gitdir} {r}]
+ set gitlink_parent [file dirname [read $fd_gitdir]]
+ catch {close $fd_gitdir}
+ set worktree [git -C $gitlink_parent rev-parse --show-toplevel]
+ set parent_gitdir [git -C $worktree rev-parse --absolute-git-dir]
+ if {$::_gitdir ne $parent_gitdir} {
+ set worktree {}
+ }
+ }]} {
+ catch {close $fd_gitdir}
+ set worktree {}
}
}
- return $ok
+ return $worktree
}
proc is_gitvars_error {err} {
@@ -1155,62 +1182,76 @@ proc unset_gitdir_vars {} {
catch {unset env(GIT_WORK_TREE)}
}
+# find repository.
+set _gitdir {}
+if {[is_enabled gitdir_discovery]} {
+ if {[catch {
+ set _gitdir [git rev-parse --absolute-git-dir]
+ } err]} {
+ if {[is_gitvars_error $err]} {
+ exit 1
+ }
+ set _gitdir {}
+ }
+}
+
set picked 0
-proc pick_repo {} {
+if {$_gitdir eq {} && [is_enabled picker]} {
unset_gitdir_vars
load_config 1
apply_config
- choose_repository::pick
- set _gitdir [git rev-parse --absolute-git-dir]
- set _prefix {}
+ if {![choose_repository::pick]} {
+ exit 1
+ }
+ if {[catch {
+ set _gitdir [git rev-parse --absolute-git-dir]
+ } err]} {
+ catch {wm withdraw .}
+ error_popup [strcat [mc "Unusable repo/worktree:"] " [pwd] "\n\n$err"]
+ }
set picked 1
}
-# run repository picker if explicitly requested
-switch -- $subcommand {
- pick {
- pick_repo
- set subcommand gui
- set run_picker_on_error 0
- }
-}
-
-# find repository.
-if {[catch {
- set _gitdir [git rev-parse --absolute-git-dir]
-} err]} {
- if {[is_gitvars_error $err]} {
- exit 1
- }
- if {$run_picker_on_error} {
- pick_repo
- } else {
- catch {wm withdraw .}
- error_popup [strcat [mc "Git directory not found:"] "\n\n$err"]
- exit 1
- }
+if {$_gitdir eq {}} {
+ catch {wm withdraw .}
+ error_popup [strcat [mc "Git directory not found:"] "\n\n$err"]
+ exit 1
}
# find worktree, continue without if not required
if {[catch {
set _gitworktree [git rev-parse --show-toplevel]
set _prefix [git rev-parse --show-prefix]
- cd $_gitworktree
} err]} {
if {[is_gitvars_error $err]} {
exit 1
}
set _gitworktree {}
set _prefix {}
- if {[is_enabled bare]} {
- cd $_gitdir
- } elseif {![is_parent_worktree]} {
- catch {wm withdraw .}
- error_popup [strcat [mc "Cannot use bare repository:"] "\n\n" $_gitdir]
- exit 1
+}
+
+if {[is_bare]} {
+ # Maybe we are in an embedded or worktree specific gitdir
+ if {[set _gitworktree [find_worktree_from_gitdir]] ne {}} {
+ set _prefix {}
}
}
+if {![is_bare]} {
+ if {[catch {
+ cd $_gitworktree
+ } err]} {
+ catch {wm withdraw .}
+ error_popup [strcat [mc "Cannot change to discovered worktree: "] \
+ "$_gitworktree" "\n\n$err"]
+ exit 1;
+ }
+} elseif {![is_enabled bare]} {
+ catch {wm withdraw .}
+ error_popup [strcat [mc "Cannot use bare repository:"] "\n\n" $_gitdir]
+ exit 1
+}
+
# repository and worktree config are complete, export them
set_gitdir_vars
@@ -1229,8 +1270,6 @@ if {$hashalgorithm eq "sha1"} {
load_config 0
apply_config
-
-# Derive a human-readable repository name
set _reponame [file split [file normalize $_gitdir]]
if {[lindex $_reponame end] eq {.git}} {
set _reponame [lindex $_reponame end-1]
@@ -2035,7 +2074,7 @@ proc incr_font_size {font {amt 1}} {
proc do_gitk {revs {is_submodule false}} {
global current_diff_path file_states current_diff_side ui_index
- global _gitdir _gitworktree
+ global _gitworktree
# -- Always start gitk through whatever we were loaded with. This
# lets us bypass using shell process on Windows systems.
@@ -2045,8 +2084,6 @@ proc do_gitk {revs {is_submodule false}} {
if {$exe eq {}} {
error_popup [mc "Couldn't find gitk in PATH"]
} else {
- global env
-
set pwd [pwd]
if {!$is_submodule} {
@@ -2105,9 +2142,6 @@ proc do_git_gui {} {
if {$exe eq {}} {
error_popup [mc "Couldn't find git gui in PATH"]
} else {
- global env
- global _gitdir _gitworktree
-
# see note in do_gitk about unsetting these vars when
# running tools in a submodule
unset_gitdir_vars
@@ -2992,77 +3026,135 @@ proc normalize_relpath {path} {
if {$elements ne {}} {
return [eval file join $elements]
} else {
- return {}
+ return {./}
}
}
+proc find_path_type {head path} {
+ if {$path eq {./}} {
+ # the root-tree exists in every rev, ls-tree gives data on the contents,
+ # not the type of tree itself. So, if the rev exists, return {tree}
+ if {[catch {set objtype [git ls-tree $head]}]} {
+ set objtype {}
+ } else {
+ set objtype {tree}
+ }
+ } else {
+ # test that the path exists in head, ls-tree gives info on the path only
+ if {[catch {set objtype [git ls-tree {--format=%(objecttype)} $head $path]}]} {
+ set objtype {}
+ }
+ }
+ return $objtype
+}
+
# -- Not a normal commit type invocation? Do that instead!
#
switch -- $subcommand {
browser -
blame {
if {$subcommand eq "blame"} {
- set subcommand_args {[--line=<num>] rev? path}
+ set subcommand_args {[--line=<num>] <[rev] [--] filename | [--] filename rev>}
+ set required_objtype blob
} else {
- set subcommand_args {rev? path}
+ set subcommand_args {<[rev] [--] directory | [--] directory rev>}
+ set required_objtype tree
}
- if {$argv eq {}} usage
- set head {}
- set path {}
- set jump_spec {}
+ set maxargs [llength $subcommand_args]
set nargs [llength $argv]
- if {$nargs < 1} {
- usage
- }
- set argn 0
- foreach a $argv {
- set argn [expr {$argn + 1}]
+ if {$nargs < 1 || $nargs > $maxargs} usage
+ set head {}
+ set althead {}
+ set path {}
+ set altpath {}
+ set canswap 1
+ set jump_spec {}
- if {$argn < $nargs} {
- # revision or line number
- if {[regexp {^--line=(\d+)$} $a a lnum]} {
- set jump_spec [list $lnum]
+ # assume: [--line=num] [head] [--] path as the possible arguments, in order.
+ # head and path may need a swap later.
+ for {set iarg 0} {$iarg < $nargs} {incr iarg} {
+ set arg [lindex $argv $iarg]
+ if {$arg eq {--}} {
+ # next arg is the path, prevent or FORCE swap?
+ if {$iarg == $nargs - 2} {
+ set canswap 0
+ } elseif {$iarg == $nargs - 3} {
+ set canswap 2
} else {
- set head $a
+ usage
}
+ } elseif {[regexp {^--line=(\d+)$} $arg arg lnum]} {
+ # --line can only be the first arg
+ if {$iarg != 0 || $maxargs < 4} usage
+ set jump_spec [list $lnum]
+ } elseif {$iarg == $nargs - 1} {
+ # assume final argument is path
+ set path [normalize_relpath [file join $_prefix $arg]]
+ set althead $arg
+ } elseif {$head eq {}} {
+ # assume the other argument is head
+ set head $arg
+ set altpath [normalize_relpath [file join $_prefix $arg]]
} else {
- set path [normalize_relpath $a]
+ usage
}
}
+ # no swapping allowed if head not given, use current branch (HEAD)
if {$head eq {}} {
load_current_branch
set head $current_branch
- } else {
- if {[regexp [string map "@@ [expr $hashlength - 1]" {^[0-9a-f]{1,@@}$}] $head]} {
- if {[catch {
- set head [git rev-parse --verify $head]
- } err]} {
- if {[tk windowingsystem] eq "win32"} {
- tk_messageBox -icon error -title [mc Error] -message $err
- } else {
- puts stderr $err
- }
- exit 1
- }
+ set canswap 0
+ }
+
+ # -- before "rev" arg means we got -- path head
+ if {$canswap == 2} {
+ set head $althead
+ set path $altpath
+ set canswap 0
+ }
+
+ set objtype [find_path_type $head $path]
+ if {$objtype eq {} && $canswap} {
+ set objtype [find_path_type $althead $altpath]
+ if {$objtype ne {}} {
+ set head $althead
+ set path $altpath
}
- set current_branch $head
+ }
+ set current_branch $head
+
+ # check that path exists in head, and objtype matches need
+ if {$objtype ne $required_objtype} {
+ switch -- $required_objtype {
+ tree {set err [strcat \
+ [mc "'%s' is not a directory in rev '%s'" $path $head]]}
+ blob {set err [strcat \
+ [mc "'%s' is not a filename in rev '%s'" $path $head]]}
+ }
+ if {[tk windowingsystem] eq "win32"} {
+ catch {wm withdraw .}
+ error_popup $err
+ } else {
+ puts stderr $err
+ }
+ exit 1
}
wm deiconify .
switch -- $subcommand {
browser {
- if {$jump_spec ne {}} usage
browser::new $head $path
}
- blame {
+ blame {
blame::new $head $path $jump_spec
}
}
return
}
citool -
-gui {
+gui -
+pick {
if {[llength $argv] != 0} {
usage
}
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index 7e1462a20c..4b06afee93 100644
--- a/lib/choose_repository.tcl
+++ b/lib/choose_repository.tcl
@@ -15,7 +15,7 @@ field w_recentlist ; # Listbox containing recent repositories
field w_localpath ; # Entry widget bound to local_path
field done 0 ; # Finished picking the repository?
-field clone_ok false ; # clone succeeeded
+field pick_ok 0 ; # true if repo pick/clone succeeded
field local_path {} ; # Where this repository is locally
field origin_url {} ; # Where we are cloning from
field origin_name origin ; # What we shall call 'origin'
@@ -220,6 +220,8 @@ constructor pick {} {
if {$top eq {.}} {
eval destroy [winfo children $top]
}
+
+ return $pick_ok
}
method _center {} {
@@ -327,8 +329,7 @@ method _git_init {} {
}
_append_recentrepos [pwd]
- set ::_gitdir .git
- set ::_prefix {}
+ set pick_ok 1
return 1
}
@@ -409,6 +410,7 @@ method _do_new2 {} {
if {![_git_init $this]} {
return
}
+ set pick_ok 1
set done 1
}
@@ -621,7 +623,7 @@ method _do_clone2 {} {
}
tkwait variable @done
- if {!$clone_ok} {
+ if {!$pick_ok} {
error_popup [mc "Clone failed."]
return
}
@@ -632,18 +634,12 @@ method _do_clone2_done {ok} {
if {$ok} {
if {[catch {
cd $local_path
- set ::_gitdir .git
- set ::_prefix {}
_append_recentrepos [pwd]
} err]} {
set ok 0
}
}
- if {!$ok} {
- set ::_gitdir {}
- set ::_prefix {}
- }
- set clone_ok $ok
+ set pick_ok $ok
set done 1
}
@@ -721,8 +717,7 @@ method _do_open2 {} {
}
_append_recentrepos [pwd]
- set ::_gitdir $actualgit
- set ::_prefix {}
+ set pick_ok 1
set done 1
}
--
2.54.0.99.14
^ permalink raw reply related
* [PATCH v2 01/11] git-gui: guard set/unset of GIT_DIR and GIT_WORK_TREE
From: Mark Levedahl @ 2026-05-20 20:24 UTC (permalink / raw)
To: git; +Cc: j6t, egg_mushroomcow, bootaina702, Mark Levedahl
In-Reply-To: <20260520202411.108764-1-mlevedahl@gmail.com>
git-gui unconditionally exports _gitdir as GIT_DIR, and _gitworktree as
GIT_WORK_TREE, to the environment, and furthermore unconditionally
unsets these environment variables in many
git gui must have a repository, so _gitdir can never be empty and its
export is always valid if repository discovery completes successfully.
git gui might not find a worktree, so _gitworktree can be empty. While
having no worktree is valid for blame/browser subcommands, exporting
GIT_WORK_TREE=<empty> is not valid. Rather, an empty GIT_WORK_TREE
raises errors in git builtins, for instance 'git branch --show-current'
as used by git, and causes breakage. This is one cause of git blame /
git browser not working without a worktree.
A user may set GIT_DIR and/or GIT_WORK_TREE to override git's normal
discovery rules, including repository configuration of core.worktree
and/or worktree specific gitdirs. It is always safe to export the
absolute pathnames of the discovered values, even though they may not be
needed. However, the gitdir might not be found from the worktree without
GIT_DIR being set. Furthermore, the worktree defined by the discovered
gitdir might be overridden by GIT_WORK_TREE set before git-gui started.
So, it is also sometimes necessary that one or both of these variables
is set.
So, let's provide two procs, one to unset GIT_DIR / GIT_WORK_TREE if
they are set, one to set GIT_DIR and, if not empty, GIT_WORK_TREE, so
all call sites do the same thing, and problems with _gitworktree == {}
are avoided.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
git-gui.sh | 39 +++++++++++++++++++++++----------------
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 23fe76e498..4ba25da7b6 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1122,6 +1122,22 @@ unset argv0dir
##
## repository setup
+proc set_gitdir_vars {} {
+ global _gitdir _gitworktree env
+ if {$_gitdir ne {}} {
+ set env(GIT_DIR) $_gitdir
+ }
+ if {$_gitworktree ne {}} {
+ set env(GIT_WORK_TREE) $_gitworktree
+ }
+}
+
+proc unset_gitdir_vars {} {
+ global env
+ catch {unset env(GIT_DIR)}
+ catch {unset env(GIT_WORK_TREE)}
+}
+
set picked 0
if {[catch {
set _gitdir $env(GIT_DIR)
@@ -1207,8 +1223,8 @@ if {[lindex $_reponame end] eq {.git}} {
set _reponame [lindex $_reponame end]
}
-set env(GIT_DIR) $_gitdir
-set env(GIT_WORK_TREE) $_gitworktree
+# Export the final paths
+set_gitdir_vars
######################################################################
##
@@ -2007,7 +2023,7 @@ proc incr_font_size {font {amt 1}} {
proc do_gitk {revs {is_submodule false}} {
global current_diff_path file_states current_diff_side ui_index
- global _gitdir _gitworktree
+ global _gitworktree
# -- Always start gitk through whatever we were loaded with. This
# lets us bypass using shell process on Windows systems.
@@ -2017,8 +2033,6 @@ proc do_gitk {revs {is_submodule false}} {
if {$exe eq {}} {
error_popup [mc "Couldn't find gitk in PATH"]
} else {
- global env
-
set pwd [pwd]
if {!$is_submodule} {
@@ -2050,13 +2064,11 @@ proc do_gitk {revs {is_submodule false}} {
# TODO we could make life easier (start up faster?) for gitk
# by setting these to the appropriate values to allow gitk
# to skip the heuristics to find their proper value
- unset env(GIT_DIR)
- unset env(GIT_WORK_TREE)
+ unset_gitdir_vars
}
safe_exec_bg [concat $cmd $revs "--" "--"]
- set env(GIT_DIR) $_gitdir
- set env(GIT_WORK_TREE) $_gitworktree
+ set_gitdir_vars
cd $pwd
if {[info exists main_status]} {
@@ -2079,21 +2091,16 @@ proc do_git_gui {} {
if {$exe eq {}} {
error_popup [mc "Couldn't find git gui in PATH"]
} else {
- global env
- global _gitdir _gitworktree
-
# see note in do_gitk about unsetting these vars when
# running tools in a submodule
- unset env(GIT_DIR)
- unset env(GIT_WORK_TREE)
+ unset_gitdir_vars
set pwd [pwd]
cd $current_diff_path
safe_exec_bg [concat $exe gui]
- set env(GIT_DIR) $_gitdir
- set env(GIT_WORK_TREE) $_gitworktree
+ set_gitdir_vars
cd $pwd
set status_operation [$::main_status \
--
2.54.0.99.14
^ permalink raw reply related
* [PATCH v2 02/11] git-gui: return status from choose_repository::pick
From: Mark Levedahl @ 2026-05-20 20:24 UTC (permalink / raw)
To: git; +Cc: j6t, egg_mushroomcow, bootaina702, Mark Levedahl
In-Reply-To: <20260520202411.108764-1-mlevedahl@gmail.com>
The repository picker (choose_repository::pick) on success always
returns with the current directory at the root of the selected worktree,
and with the global variable _gitdir holding the name of the git
repository, possibly as a relative path. On failure, _gitdir = {}. If
the selection was from the "recent" list, no validation has occurred.
There are too many side effects in this interface. Note that the picker
only supports worktrees with a .git entry in the worktree root, so git
repository and worktree discovery will work starting in the current
directory on return. So, let's change pick to return a 0/1 value, 1
meaning a worktreee + repo was selected and the current directory is the
worktree root, and leave validation and setting of _gitdir,
_gitworktree, and _prefix to the caller. Note: pick actually does not
return if something was not selected, rather it terminates git-gui.
But, let's pretend at the call site that pick returns 0/false instead.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
git-gui.sh | 10 ++++++++--
lib/choose_repository.tcl | 21 ++++++++-------------
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 4ba25da7b6..4a736190a9 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1151,10 +1151,16 @@ if {[catch {
} err]} {
load_config 1
apply_config
- choose_repository::pick
- if {![file isdirectory $_gitdir]} {
+ if {![choose_repository::pick]} {
exit 1
}
+ if {[catch {
+ set _gitdir [git rev-parse --git-dir]
+ } err]} {
+ catch {wm withdraw .}
+ error_popup [strcat [mc "Unusable repo/worktree:"] " [pwd] "\n\n$err"]
+ }
+ set _prefix {}
set picked 1
}
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index 7e1462a20c..4b06afee93 100644
--- a/lib/choose_repository.tcl
+++ b/lib/choose_repository.tcl
@@ -15,7 +15,7 @@ field w_recentlist ; # Listbox containing recent repositories
field w_localpath ; # Entry widget bound to local_path
field done 0 ; # Finished picking the repository?
-field clone_ok false ; # clone succeeeded
+field pick_ok 0 ; # true if repo pick/clone succeeded
field local_path {} ; # Where this repository is locally
field origin_url {} ; # Where we are cloning from
field origin_name origin ; # What we shall call 'origin'
@@ -220,6 +220,8 @@ constructor pick {} {
if {$top eq {.}} {
eval destroy [winfo children $top]
}
+
+ return $pick_ok
}
method _center {} {
@@ -327,8 +329,7 @@ method _git_init {} {
}
_append_recentrepos [pwd]
- set ::_gitdir .git
- set ::_prefix {}
+ set pick_ok 1
return 1
}
@@ -409,6 +410,7 @@ method _do_new2 {} {
if {![_git_init $this]} {
return
}
+ set pick_ok 1
set done 1
}
@@ -621,7 +623,7 @@ method _do_clone2 {} {
}
tkwait variable @done
- if {!$clone_ok} {
+ if {!$pick_ok} {
error_popup [mc "Clone failed."]
return
}
@@ -632,18 +634,12 @@ method _do_clone2_done {ok} {
if {$ok} {
if {[catch {
cd $local_path
- set ::_gitdir .git
- set ::_prefix {}
_append_recentrepos [pwd]
} err]} {
set ok 0
}
}
- if {!$ok} {
- set ::_gitdir {}
- set ::_prefix {}
- }
- set clone_ok $ok
+ set pick_ok $ok
set done 1
}
@@ -721,8 +717,7 @@ method _do_open2 {} {
}
_append_recentrepos [pwd]
- set ::_gitdir $actualgit
- set ::_prefix {}
+ set pick_ok 1
set done 1
}
--
2.54.0.99.14
^ permalink raw reply related
* [PATCH v2 04/11] git-gui: use rev-parse exclusively to find a repository
From: Mark Levedahl @ 2026-05-20 20:24 UTC (permalink / raw)
To: git; +Cc: j6t, egg_mushroomcow, bootaina702, Mark Levedahl
In-Reply-To: <20260520202411.108764-1-mlevedahl@gmail.com>
git-gui attempts to use env(GIT_DIR) directly as the git repository,
accepting GIT_DIR if it is a directory. Only if that fails is git
rev-parse used to discover the repository. But, this avoids all of
git-core's validity checking on a repository, thus possibly deferring an
error to a later step, possibly unexpected. Repository validation should
be part of initial setup so that later processing does not need error
trapping for configuration errors.
Let's just invoke rev-parse so all error checking is done.
While here, let's cleanup the error handling.
Stop if an error occurs and the user set GIT_DIR or GIT_WORK_TREE.
Use of either or both of those variables is supported by git, but their
use also means the user has taken responsibility that they are correct,
so a failure is something the user must address.
Otherwise on error, continue the existing behavior and show the
repository picker. But, let's move the possible invocation of
repository_chooser::pick to a separate code block. This permits adding
separate conditions on using pick indepent of repository discovery, and
will be exploited later in the series. Note that the picker always
returns with the current directory in the root of a worktree with the
git repository is in the .git subdirectory. The variable "picked" is
used by git-gui to automatically execute the "Explore Working Copy" menu
item after the repository picker is run. This is controlled by config
variable gui.autoexplore, and happens after all discovery is complete.
Remove a later check on whether _gitdir is a directory: that code
cannot be reached without rev-parse already validating the repository.
_prefix should not be set before worktree discovery: the prefix is only
known after the worktree is found, and at this point we have only
discovered the repository. This is true even when running the repository
picker: that option provides a list of prior selections, and does no
validation on the list beyond checking that the directories exist. For
now, just initialize _prefix along with other global variables.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
git-gui.sh | 48 +++++++++++++++++++++++++++++++++---------------
1 file changed, 33 insertions(+), 15 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 233c975786..c61a6cbd8f 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -374,6 +374,7 @@ set _gitdir {}
set _gitworktree {}
set _isbare {}
set _githtmldir {}
+set _prefix {}
set _reponame {}
set _shellpath {@@SHELL_PATH@@}
@@ -1122,6 +1123,24 @@ unset argv0dir
##
## repository setup
+proc is_gitvars_error {err} {
+ set havevars 0
+ set GIT_DIR {}
+ set GIT_WORK_TREE {}
+ catch {set GIT_DIR $::env(GIT_DIR); set havevars 1}
+ catch {set GIT_WORK_TREE $::env(GIT_WORK_TREE) ; set havevars 1}
+
+ if {$havevars} {
+ catch {wm withdraw .}
+ error_popup [strcat [mc "Invalid configuration:"] \
+ "\n" "GIT_DIR: " $GIT_DIR \
+ "\n" "GIT_WORK_TREE: " $GIT_WORK_TREE \
+ "\n\n$err"]
+ return 1
+ }
+ return 0
+}
+
proc set_gitdir_vars {} {
global _gitdir _gitworktree env
if {$_gitdir ne {}} {
@@ -1138,17 +1157,22 @@ proc unset_gitdir_vars {} {
catch {unset env(GIT_WORK_TREE)}
}
-set picked 0
-if {[catch {
- set _gitdir $env(GIT_DIR)
- set _prefix {}
- }]
- && [catch {
- # beware that from the .git dir this sets _gitdir to .
- # and _prefix to the empty string
+# find repository.
+set _gitdir {}
+if {$_gitdir eq {}} {
+ if {[catch {
set _gitdir [git rev-parse --absolute-git-dir]
- set _prefix [git rev-parse --show-prefix]
} err]} {
+ if {[is_gitvars_error $err]} {
+ exit 1
+ }
+ set _gitdir {}
+ }
+}
+
+set picked 0
+if {$_gitdir eq {}} {
+ unset_gitdir_vars
load_config 1
apply_config
if {![choose_repository::pick]} {
@@ -1160,7 +1184,6 @@ if {[catch {
catch {wm withdraw .}
error_popup [strcat [mc "Unusable repo/worktree:"] " [pwd] "\n\n$err"]
}
- set _prefix {}
set picked 1
}
@@ -1175,11 +1198,6 @@ if {$hashalgorithm eq "sha1"} {
exit 1
}
-if {![file isdirectory $_gitdir]} {
- catch {wm withdraw .}
- error_popup [strcat [mc "Git directory not found:"] "\n\n$_gitdir"]
- exit 1
-}
# _gitdir exists, so try loading the config
load_config 0
apply_config
--
2.54.0.99.14
^ permalink raw reply related
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