Re: bug: `git pull` does not clean up after itself if it fails

From: Jeff King <peff@peff.net>
Date: Jul 17, 2024, 05:55 UTC
Message-ID: <20240717055549.GD547635@coredump.intra.peff.net>
In-Reply-To: <0cc13c53-1d8d-4501-89f2-e8329bc95485@charite.de>

On Mon, Jul 15, 2024 at 01:19:32PM +0200, Nikolai Zaki wrote:

Show 14 quoted lines

> What did you do before the bug happened? (Steps to reproduce your issue)
> In your local repo have a directory that you cannot write to.
> Pull from a remote that has changes/new files in that directory.
> 
> What did you expect to happen? (Expected behavior)
> The pull fails and the local repo in the same state as before.
> 
> What happened instead? (Actual behavior)
> All changes to writeable files are applied and all new files in writeable
> dirs are added.
> The local HEAD however remained the same.
> 
> What's different between what you expected and what actually happened?
> A failed `git pull` inadvertently creates changes and untracked files.

A pull is basically fetch followed by merge. So I'd expect us to fail in the merge step, at which point pull would generally leave the state as-is, because merge failures tend to be conflicts.

So I guess doing what you expect would require a merge which hits a non-conflict error (like an unwriteable directory) to clean up after itself. That's probably not impossible, but it may be rather tricky, especially if we are concerned about unrelated changes in the working tree.

-Peff