Re: git stash deletes/drops changes of

From: Stephen Bash <bash@genarts.com>
To: Thomas Rast <trast@inf.ethz.ch>
Cc: Jim Greenleaf <james.a.greenleaf@gmail.com>,
	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 10:26:02 -0400 (EDT)	[thread overview]
Message-ID: <360187633.973068.1369405562399.JavaMail.root@genarts.com> (raw)
In-Reply-To: <87obc15mq5.fsf@linux-k42r.v.cablecom.net>

----- Original Message -----
> From: "Thomas Rast" <trast@inf.ethz.ch>
> Sent: Thursday, May 23, 2013 6:56:50 PM
> Subject: Re: git stash deletes/drops changes of
> 
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Thomas Rast <trast@inf.ethz.ch> writes:
> >
> > > 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.
> >
> > It has always been a promise the user makes to Git that the working
> > tree files that are marked as such will be kept identical to what is
> > in the index (hence there is no need for Git to check if they were
> > modified). And by extension, Git is now free to choose reading from
> > the working tree file when asked to read from blob object recorded
> > in the index for that path, or vice versa, because of that promise.
> >
> > It is not --ignore-changes bit, and has never been.  What are the
> > workflows that are helped if we had such a bit?  If we need to
> > support them, I think you need a real --ignore-changes bit, not
> > an abuse of --assume-unchanged.
> 
> I gather -- from #git -- that it's mostly used for config files, which
> have an annoying habit of being different from the repository.

The web team at my $dayjob has the same problem, and I believe they are also using --assume-unchanged.

This may be slightly too tangential, but a different workflow we experimented with is marking the config file(s) merge=ours in gitattributes on each branch.  Ideally then devs can check in their local settings on their local branches.  Unfortunately, as is probably well known here, the merge attribute is only checked by the low level merge algorithm, so too often settings got bashed incorrectly (only one merge parent changed the file).  Perhaps there are some options in that direction?

Thanks,
Stephen