Re: When exactly should REBASE_HEAD exist?

[Stefan Haller <lists@haller-berlin.de>]

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

I see. That should be taken care of by not hard-coding ".git/...", but
using something like "git rev-parse --git-path ...". We are doing that
already, otherwise most of lazygit's other rebase commands wouldn't work
in worktrees.

>>> 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*. :-)

I see, thanks for the explanation. I agree. Trouble is, I don't have the
capacity to drive such an addition to git status, and I doubt anybody
else would be interested in doing it for me (are you? :-), so...

-Stefan