skip-worktree autostash on pull

skip-worktree autostash on pull

[Blake Campbell]

Hi all - I use update-index --skip-worktree on some config files that I change locally and don’t want to commit, but every time I pull from the remote I have to go through a process of no-skip-worktree, stash, pull, stash pop, then skip-worktree again, which is all a bit tedious! Ideally some switch like --autostash for git pull would be really useful. Does anyone know if something like that exists? 

Thanks!
Blake. 

Re: skip-worktree autostash on pull

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]

On 2023-09-14 at 09:54:30, Blake Campbell wrote:
> Hi all - I use update-index --skip-worktree on some config files that
> I change locally and don’t want to commit, but every time I pull from
> the remote I have to go through a process of no-skip-worktree, stash,
> pull, stash pop, then skip-worktree again, which is all a bit tedious!
> Ideally some switch like --autostash for git pull would be really
> useful. Does anyone know if something like that exists? 

The Git FAQ[0] outlines that, as you've noticed, skip-worktree doesn't
work for ignoring changes to tracked files:

  Git doesn’t provide a way to do this. The reason is that if Git needs
  to overwrite this file, such as during a checkout, it doesn’t know
  whether the changes to the file are precious and should be kept, or
  whether they are irrelevant and can safely be destroyed. Therefore, it
  has to take the safe route and always preserve them.

  It’s tempting to try to use certain features of git update-index,
  namely the assume-unchanged and skip-worktree bits, but these don’t
  work properly for this purpose and shouldn’t be used this way.

If you take the advice in the FAQ, then the config files won't be
tracked and you won't have this problem:

  If your goal is to modify a configuration file, it can often be
  helpful to have a file checked into the repository which is a template
  or set of defaults which can then be copied alongside and modified as
  appropriate. This second, modified file is usually ignored to prevent
  accidentally committing it.

Your particular case is one of many reasons we suggest this approach.
There is in fact an --autostash argument in git pull, as well as git
rebase, both of which work as you might expect, but in general they
still won't work properly with --skip-worktree and given the FAQ entry
above, we wouldn't add support for that in the option.

[0] https://git-scm.com/docs/gitfaq#ignore-tracked-files
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: skip-worktree autostash on pull

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> Your particular case is one of many reasons we suggest this approach.
> There is in fact an --autostash argument in git pull, as well as git
> rebase, both of which work as you might expect, but in general they
> still won't work properly with --skip-worktree and given the FAQ entry
> above, we wouldn't add support for that in the option.

As you mentioned, "--autostash" will move away the local change
while your otherwise clean working tree needs to be updated from the
upstream via "git pull" (or "git pull --rebase").  So the only thing
the user may want to be careful would be "git commit -a" (and "git
add -u"), I would think.  A pre-commit hook should be able to stop
you from committing with local changes to these selected paths you
want to keep following the upstream _with_ local changes (i.e. run
"diff --cached --name-only HEAD" and exit with non-zero when one of
these paths appear in its output).  Upon seeing such a failure, you
can "git stash" the changes, then "git commit" again.  And you do
not need to abuse assume-unchanged or skip-worktree for doing that.