From: Petr Baudis <pasky@ucw•cz>
To: Thomas Rast <trast@inf•ethz.ch>
Cc: Junio C Hamano <gitster@pobox•com>,
Jim Greenleaf <james.a.greenleaf@gmail•com>,
git@vger•kernel.org
Subject: Re: git stash deletes/drops changes of
Date: Fri, 24 May 2013 01:57:12 +0200 [thread overview]
Message-ID: <20130523235711.GJ12252@machine.or.cz> (raw)
In-Reply-To: <87obc15mq5.fsf@linux-k42r.v.cablecom.net>
Hi!
On Fri, May 24, 2013 at 12:56:50AM +0200, Thomas Rast wrote:
> > It is not --ignore-changes bit, and has never been.
Indeed, it has been my lack of imagination regarding what can go
wrong. I am fine with the changes not being shown in `git diff` and even
not so worried about them being overwritten by a merge/checkout
(touching that file for other purposes), but `git stash` dropping the
changes is rather vicious. ;-)
An emergency fix would be to add a warning to the documentation that
under various circumstances, your changes may get overwritten and keep a
backup copy. It's a bit silly, I'm not sure how long it may take to
flesh out a proper solution; if we just stop recommending anything (or
recommend something unhelpful like "you don't want that"), people will
just refer to the old advice and I think it's better to warn them.
> > 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.
>
> Which is wrong, really. But we still claim that --assume-unchanged is
> a solution to it in git-update-index(1).
The main workflow for me is when you don't get to pick the workflow.
Most recently, I found myself tackling this scenario:
(i) https://github.com/huceke/omxplayer carries file Makefile.include
(ii) I'm paid to make some modifications to the omxplayer software
on short notice.
(iii) Makefile.include hardcodes some crosscompiling tool paths and
other things (like CFLAGS) that are different in my setup.
For the first few commits, I have avoided using -a, then I went ahead
and marked Makefile.include with --assume-unchanged. It felt like
something dangerous, so I also made a backup of the file for good
measure; that turned out to be a good idea after the first `git stash`
issued. (Unfortunately, I forgot about the problem before I would have
time to think about fixing that.)
Yeah, omxplayer's setup is not ideal. But in this scenario, I'm not
really in the position to easily start poking into other people's
toolchain setup, I'd like git just to help me get my work done and move
on and ideally keep my pull requests clean of unrelated commits.
Just to clear up on what the best practice is, I'd imagine the setup
to be something like:
(a) Makefile contains inclusion of Makefile.include.
(b) There is a file like Makefile.include.template containing
a template to be copied over and filled by the user.
(c) Makefile contains code that makes sure all variables that
are supposed to be set are set and obsolete variables are not,
since there is no mechanism to cause e.g. a merge conflict
on change of Makefile.include.template.
Is there a better way to solve this?
There are a couple of things to notice here:
(i) The solution is highly specific for the particular file format
and usage, universal recommendations are difficult especially if we
are to cover (c).
(ii) The solution is certainly not the simplest one to occur to
the original author, who will probably initially just commit
Makefile.include with the values suitable for them.
(iii) A corrolary to (ii), the person who will find tackling this
problem first will probably be a newcoming developer to the project
who is likely not to be familiar with it and its toolchain / config
mechanisms, and this will be a huge hassle.
Therefore the demand for Git to just solve their problem on its level.
Of course Git would be simpler and more elegant if it didn't have to do
this and cover all the annoying corner cases. But is this simplification
worth the extra workflow hassle for its users?
--
Petr "Pasky" Baudis
For every complex problem there is an answer that is clear,
simple, and wrong. -- H. L. Mencken
next prev parent reply other threads:[~2013-05-24 0:06 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
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 [this message]
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=20130523235711.GJ12252@machine.or.cz \
--to=pasky@ucw$(echo .)cz \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=james.a.greenleaf@gmail$(echo .)com \
--cc=trast@inf$(echo .)ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox