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