From: Kristoffer Haugsbakk <code@khaugsbakk.name>
To: git@vger.kernel.org
Cc: phillip.wood123@gmail.com, code@khaugsbakk.name
Subject: [BUG] rebase: can write reflog with uninit. `action` string
Date: Mon, 28 Apr 2025 21:40:43 +0200 [thread overview]
Message-ID: <20250428194048.149348-1-code@khaugsbakk.name> (raw)
From: code@khaugsbakk.name
We did `git rebase --rebase-merges` on a branch with merge commits. Including
back merges. The reflog after that showed some weird symbols for
certain merge commits (only merges):
e9c962f2ea0 HEAD@{8}: <binary>�: Merged in <branch> (pull request #4441)
Some merge commits were normal.
No backmerges were affected.
We have a main branch. This other branch was created from the main
branch. It had been kept up to date with backmerges. Then someone did
a rebase on it once it was supposed to go into the main branch soonish.
It looks like the string is uninit. The values are different each time.
§ Bisection
Bisects to d188a60d722 (sequencer: stop exporting GIT_REFLOG_ACTION,
2022-11-09).
§ Reproduction on latest code
Reproduced on `master`, on f65182a99e5 (The ninth batch, 2025-04-24).
§ Gdb
This is the backtrace when I get the apparently uninit. string:
```
#0 run_git_commit (defmsg=0x555555babe70 "<repo path>/MERGE_MSG", opts=0x7fffffffc070, flags=0) at sequencer.c:1158
#1 0x00005555558740d9 in do_merge (r=0x555555a67020 <the_repo>, commit=0x555555b75cb0,
arg=0x555555b2164d "<branch stuff> # Merged in <branch> { (pull request #4464)\nlabel branch-point-9\npick 4026b5ced849724bd3857283b6ad50c8609b6d33 only sh"..., arg_len=125, flags=0, check_todo=0x7fffffffb1e0, opts=0x7fffffffc070) at sequencer.c:4380
#2 0x0000555555876629 in pick_commits (r=0x555555a67020 <the_repo>, todo_list=0x7fffffffbf50, opts=0x7fffffffc070) at sequencer.c:5048
#3 0x0000555555877eeb in sequencer_continue (r=0x555555a67020 <the_repo>, opts=0x7fffffffc070) at sequencer.c:5480
#4 0x000055555563a491 in run_sequencer_rebase (opts=0x7fffffffc330) at builtin/rebase.c:369
#5 0x000055555563bc74 in run_specific_rebase (opts=0x7fffffffc330) at builtin/rebase.c:746
#6 0x000055555563fe2a in cmd_rebase (argc=0, argv=0x555555a73890, prefix=0x0, repo=0x555555a67020 <the_repo>) at builtin/rebase.c:1878
#7 0x0000555555574c0d in run_builtin (p=0x555555a34908 <commands+2280>, argc=2, argv=0x555555a73890, repo=0x555555a67020 <the_repo>) at git.c:480
#8 0x00005555555750ca in handle_builtin (args=0x7fffffffd8a0) at git.c:743
#9 0x000055555557538c in run_argv (args=0x7fffffffd8a0) at git.c:810
#10 0x00005555555759e2 in cmd_main (argc=2, argv=0x7fffffffda30) at git.c:950
#11 0x000055555569b0c3 in main (argc=5, argv=0x7fffffffda18) at common-main.c:9
```
§ No reproduction script
I was unable to reproduce with a simple repo. setup. I tried:
1. Creating a side branch which had a merge
2. The side branch conflicted with the other branch
3. Rebased with `--rebase-merges`
-----
Normal bugreport questionaire follows.
-----
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 rebase --rebase-merges` on a branch with merge commits. Including
back merges.
What did you expect to happen? (Expected behavior)
Normal “action” string for the reflog like for example `continue`:
3f90f6ab14d (HEAD -> <branch>) HEAD@{1}: rebase (continue): Merged in <branch> (pull request #4507)
What happened instead? (Actual behavior)
The “action” (or whatever it is) string is arbitrary bytes. Like some
uninit. memory.
```
e9c962f2ea0 HEAD@{8}: <binary>�: Merged in <branch> (pull request #4441)
```
What's different between what you expected and what actually happened?
Apparently uninit. string.
Anything else you want to add:
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.49.0.459.gf65182a99e5
cpu: x86_64
built from commit: f65182a99e545d2f2bc22e6c1c2da192133b16a3
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
libcurl: 7.81.0
OpenSSL: OpenSSL 3.0.2 15 Mar 2022
zlib: 1.2.11
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
uname: Linux 6.8.0-58-generic #60~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 28 16:09:21 UTC 2 x86_64
compiler info: gnuc: 11.4
libc info: glibc: 2.35
$SHELL (typically, interactive shell): /bin/bash
[Enabled Hooks]
next reply other threads:[~2025-04-28 19:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-28 19:40 Kristoffer Haugsbakk [this message]
2025-04-29 9:22 ` [BUG] rebase: can write reflog with uninit. `action` string Phillip Wood
2025-04-29 19:40 ` Kristoffer Haugsbakk
2025-04-29 21:51 ` Jeff King
2025-04-30 15:17 ` Kristoffer Haugsbakk
2025-05-01 13:17 ` Jeff King
2025-05-01 14:36 ` phillip.wood123
2025-05-01 15:36 ` Jeff King
2025-05-01 16:07 ` Junio C Hamano
2025-05-01 16:38 ` Jeff King
2025-05-01 17:53 ` Junio C Hamano
2025-05-01 14:10 ` phillip.wood123
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250428194048.149348-1-code@khaugsbakk.name \
--to=code@khaugsbakk.name \
--cc=git@vger.kernel.org \
--cc=phillip.wood123@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.