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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html