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

From: Taylor Blau <me@ttaylorr.com>
Date: Sep 1, 2021, 02:55 UTC
Message-ID: <YS7rl8ynKD0fAerG@nand.local>
In-Reply-To: <CABPp-BFmU+RaAjq4_0-PSfRgH1Jc63nN0fMuDWk2+iDbdz7CCA@mail.gmail.com>

On Tue, Aug 31, 2021 at 01:14:55PM -0700, Elijah Newren wrote:

Show 13 quoted lines

> > 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