threads / discuss / 50353

Extending `git pull` to deal with unindexed changes that would be overwritten

Subject: Extending `git pull` to deal with unindexed changes that would be overwritten

## tl;dr

One message between Jan 29, 2019 and Jan 29, 2019.

replies: 0people: 1as markdown or json

Mahmoud Al-Qudsi· Jan 29, 2019, 21:38 UTC · lore
Hello all,

A common point of friction when flipping back and forth between branches, especially when dealing with build configurations/artifacts that were sometimes included in the repository and sometimes not (e.g. the artifacts of an `autoreconf` run) is when a file not in the index at all would be overridden by the attempted checkout.

e.g. file `:/foo` is currently not in the index in any way, shape, or form (soft or hard) and executing `git checkout bar` would result in a copy of `bar:/foo` being checked out, which leads git to emit the following notice and abort the checkout:

> error: The following untracked working tree files would be overwritten by
> checkout:
>    foo

When it's a single file like in the example above, it's easy enough to add it to the index, stash your changes, then retry the checkout. But when there are multiple files involved -- perhaps especially in the presence of other untracked files you *don't* want to stash -- it's not as straightforward.

I would like to propose two changes extending current git actions to handle such a scenario:

1) `git pull --autostash` (both with and without `--rebase`, the latter of which
   is currently not a valid option), which would do the equivalent of calling
   `git add` on each of the files that would be overwritten followed by `git
   stash`, and
2) Either extending `git pull --force` or introducing something along the lines
   of `git pull --reset` or similar which would forcibly drop the changes that
   would be overwritten (e.g. equivalent to extension 1 above followed by `git
   stash drop`) as an alternative to running `git reset --hard` before
   attempting to repeat the checkout operation but dropping only changes that
   explicitly conflict with the requested checkout operation (so somewhat less
   destructive).

(I believe the first proposal should be fairly straightforward and free of controversy, the second might be a little too dramatic or dangerous to be accepted.)

With regards to the first extension: as mentioned, it is currently an error to run `git pull --autostash` without `--rebase` as well, but currently even the accepted `git pull --autostash --rebase` does *not* stash changes to files not in the index that would be overwritten by the checkout.

Of course there's an incredibly good chance that I'm missing a git action that already does what's requested that I just don't know about -- in which case, please do enlighten me!

Thank you for your consideration,

Mahmoud Al-Qudsi NeoSmart Technologies

← back to recent threads