On Sat, Mar 4, 2023 at 12:36 AM Stefan Haller [off-list ref] wrote:
From what I can see, the current behavior of the .git/rebase-merge/amend
file was done in 2.12, that would be more than good enough for me. Did I
miss any changes to the behavior since then?
Probably not - but `git status` remains the right place to decode the
information, since it will be updated appropriately whenever this changes.
I'm surprised to hear that worktrees play a role in this. Do you have
more details about this?
$ git worktree add foo
$ cd ../foo
$ git rebase -i HEAD~2
puts the rebase-todo file into
`.git/worktrees/foo/rebase-merge/git-rebase-todo`;
all the status files will likewise be in the `.git/worktrees/foo/`
directory.
quoted
It would be best if `git status`
reported all of this information directly ...
Yes, that would be nice, but based on what state would it provide this
information? Are you suggesting that some new file should be added to
.git/rebase-merge/ to keep track of it (more reliably than the amend
file does today), or could the information be derived somehow from what
exists already?
I don't know which parts are reliably derive-able today, but to
the extent that `git status` *can't* provide the necessary information,
I'd call that a bug in `gitt status`, to be fixed by saving that information
somewhere. Until it exists, there's nothing you can do, but if and when
(a) it does exist and (b) `git status` provides it, it won't matter
whether it's in some added worktree, or moves around or changes
form: you'll get it in a reliable fashion.
In other words, this is not helpful *yet*. :-)
Chris