Re: When exactly should REBASE_HEAD exist?

[Chris Torek <chris.torek@gmail.com>]

On Sat, Mar 4, 2023 at 12:36 AM Stefan Haller <lists@haller-berlin.de> 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.

>> 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