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