Re: [PATCH] rebase, cherry-pick, revert: only run from toplevel

[Taylor Blau <me@ttaylorr.com>]

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