On Tue, Aug 31, 2021 at 01:14:55PM -0700, Elijah Newren wrote: > > Now I have spent zero time looking into actually coding this, so it may > > turn out to be much trickier than I am suggesting. But this seems like a > > much more fruitful direction, where we can protect users in cases where > > they benefit (and give them sensible and actionable error messages), > > without bothering people in the majority of cases where their cwd > > doesn't go away. > > Ooh, this sounds intriguing to me...but what if we changed that rule > slightly and just decided to never make the cwd go away? Currently, > the checkout code removes directories if they have no tracked or > untracked or ignored files left, i.e. if they're empty. What if we > decide to only have remove_scheduled_dirs() remove directories that > are empty AND they are not the current working directory? Hmm. My first thought after reading this is that it would cause surprising behavior for anybody who had 'git add --all' in their 'rebase -x' script. But would it? I.e., imagine somebody doing an in-place sed in a rebase and then `git add --all`-ing the result at each point in history. If the directory they were in ever went away, then the *next* revision would add that directory right back. That behavior seems somewhat surprising to me, or at least I could imagine it being surprising to users. Another thought is what should happen when the current directory goes away and then comes back as a file? We wouldn't be able to checkout that file, I don't think, so it might be a dead end. Thanks, Taylor
