All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Rast <trast@inf.ethz.ch>
To: Jim Greenleaf <james.a.greenleaf@gmail.com>
Cc: <git@vger.kernel.org>, Petr Baudis <pasky@ucw.cz>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: git stash deletes/drops changes of
Date: Fri, 24 May 2013 00:10:51 +0200	[thread overview]
Message-ID: <87sj1d5ous.fsf@linux-k42r.v.cablecom.net> (raw)
In-Reply-To: <loom.20130523T185301-635@post.gmane.org> (Jim Greenleaf's message of "Thu, 23 May 2013 16:57:23 +0000 (UTC)")

Jim Greenleaf <james.a.greenleaf@gmail.com> writes:

> Adeodato Simó <dato <at> net.com.org.es> writes:
>
>> I was unpleasantly surprised to discover yesterday that doing `git
>> stash` on a repository where I had previously run `git update-index
>> --assume-unchanged FOO` completely lost all changes I had in file FOO.
>
> I just ran into this today.
>
> Was a decision about this behavior reached in the intervening time?

When you mark a file assume-unchanged, git internally sets a flag that
this file should not be considered when doing cache refreshes -- the
file is always assumed to be up-to-date.

So while I haven't actually looked into all of the code, I imagine it
goes something like this:

* git-stash uses git update-index --all on all modified files.  But it
  doesn't show up as modified, because you promised it isn't.

* Later it calls git reset --hard, which blows away the existing state.
  This would seem to ignore the assume-unchanged flag in this case, as
  otherwise it wouldn't overwrite it.

Whether the last behavior is a bug is in the eye of the beholder.  In
your case you apparently lost work.  However, 'git reset --hard' in
itself should discard all uncommitted work without asking any further
questions (because it's --hard).  So the bug is then in the sequence

  ask about uncommitted work
  save it elsewhere
  git reset --hard

assuming that this actually makes sure nothing gets lost.  But the only
thing that was lost was *files that you promised would not be changed*.


What's really unfortunate is that we caused this in the first place by
Pasky's 6259ac6 (Documentation: How to ignore local changes in tracked
files, 2008-07-18).  It recommends exactly the --assume-unchanged
strategy to ignore changes to tracked files.

And it's hard to disagree with its commit message:

    This is currently probably one of the top FAQs at #git and the
    --assume-unchanged switch is not widely known

Except that now the corresponding FAQ is that we have to actively
dissuade people from using --assume-unchanged precisely because it keeps
biting people.

So maybe it would be time to first make up our minds as to what
--assume-unchanged should actually mean:

* Ignore changes to a tracked file, but treat them as valuable.  In
  this case we'd have to make sure that failures like git-stash's are
  handled properly.

* Ignore changes to a tracked file, as in "who cares if it was changed".

* A very specific optimization for users who know what they are doing.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

  reply	other threads:[~2013-05-23 22:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-04 16:24 git stash deletes/drops changes of "assume-unchanged" files Adeodato Simó
2013-05-23 16:57 ` git stash deletes/drops changes of Jim Greenleaf
2013-05-23 22:10   ` Thomas Rast [this message]
2013-05-23 22:49     ` Junio C Hamano
2013-05-23 22:56       ` Thomas Rast
2013-05-23 23:20         ` Junio C Hamano
2013-05-24 15:25           ` Phil Hord
2013-05-24 15:34             ` Jim Greenleaf
2013-05-24 15:38               ` John Keeping
2013-05-24 15:42                 ` Jim Greenleaf
2013-05-24 16:01                   ` John Keeping
2013-05-23 23:57         ` Petr Baudis
2013-05-24  8:22           ` John Keeping
2013-05-24  9:40             ` Petr Baudis
2013-05-24 10:06               ` John Keeping
2013-05-24 10:14                 ` Petr Baudis
2013-05-24 10:40                   ` John Keeping
2013-05-24 11:03                     ` Petr Baudis
2013-05-24 12:42                       ` John Keeping
2013-05-24 14:26         ` Stephen Bash

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sj1d5ous.fsf@linux-k42r.v.cablecom.net \
    --to=trast@inf.ethz.ch \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=james.a.greenleaf@gmail.com \
    --cc=pasky@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.