{"thread":{"id":"24008","subject":"git stash deletes/drops changes of \"assume-unchanged\" files","startedAt":"2010-06-04T16:24:41Z","lastAt":"2013-05-24T16:01:43Z","messageCount":20,"participants":["Adeodato Simó","Jim Greenleaf","Thomas Rast","Junio C Hamano","Petr Baudis","John Keeping","Stephen Bash","Phil Hord"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"142991","messageId":"AANLkTin-BIxgQE5CO2cLhCYJAGHFxiXPquyozKc308DS@mail.gmail.com","threadId":"24008","inReplyTo":null,"subject":"git stash deletes/drops changes of \"assume-unchanged\" files","fromName":"Adeodato Simó","fromEmail":"dato@net.com.org.es","sentAt":"2010-06-04T16:24:41Z","receivedAt":"2010-06-04T16:24:41Z","isPatch":false,"sender":{"key":"dato@net.com.org.es","avatar":"https://gravatar.com/avatar/952ec7d5d5663eb8baf631b5c37f9c58480a881920dd5f8a2d3a71f969b72b53?d=mp&s=160"},"body":"Hello (and please CC me on replies).\n\nI was unpleasantly surprised to discover yesterday that doing `git\nstash` on a repository where I had previously run `git update-index\n--assume-unchanged FOO` completely lost all changes I had in file FOO.\n\nI understand the behavior is logical from the way git-stash is\nimplemented, but it strikes as very undesirable behavior to me. Does\nsomebody think something could be done to change it? In my opinion, both\nincluding in the stash changes in FOO, or just leaving them in the\nworking tree, would be better alternatives.\n\nThoughts?\n\n-8<-\n\n% git init\n% echo file1 contents >file1; echo file2 contents >file2\n% git add file1 file2; git commit -m Initial.\n\n% echo changes for file2 >>file2\n% echo some other changes to file 1 >>file1\n% git update-index --assume-unchanged file1\n\n% git stash\n% cat file1\nfile1 contents\n% git stash show -p\n--- a/file2\n+++ b/file2\n@@ -1 +1,2 @@\n file2 contents\n+changes for file2\n\n-8<-\n\n-- \n- Are you sure we're good?\n- Always.\n -- Rory and Lorelai\n"},{"id":"218282","messageId":"loom.20130523T185301-635@post.gmane.org","threadId":"24008","inReplyTo":"AANLkTin-BIxgQE5CO2cLhCYJAGHFxiXPquyozKc308DS@mail.gmail.com","subject":"Re: git stash deletes/drops changes of","fromName":"Jim Greenleaf","fromEmail":"james.a.greenleaf@gmail.com","sentAt":"2013-05-23T16:57:23Z","receivedAt":"2013-05-23T16:57:23Z","isPatch":false,"sender":{"key":"james.a.greenleaf@gmail.com","avatar":"https://gravatar.com/avatar/dc4e7f3bbb0eefe1e3daa76a87d355c1e4260d9b5a6614cbe773a14f7b3c2805?d=mp&s=160"},"body":"Adeodato Simó net.com.org.es> writes:\n\n> I was unpleasantly surprised to discover yesterday that doing `git\n> stash` on a repository where I had previously run `git update-index\n> --assume-unchanged FOO` completely lost all changes I had in file FOO.\n\nI just ran into this today.\n\nWas a decision about this behavior reached in the intervening time?\n"},{"id":"218323","messageId":"87sj1d5ous.fsf@linux-k42r.v.cablecom.net","threadId":"24008","inReplyTo":"loom.20130523T185301-635@post.gmane.org","subject":"Re: git stash deletes/drops changes of","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-05-23T22:10:51Z","receivedAt":"2013-05-23T22:10:51Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jim Greenleaf writes:\n\n> Adeodato Simó net.com.org.es> writes:\n>\n>> I was unpleasantly surprised to discover yesterday that doing `git\n>> stash` on a repository where I had previously run `git update-index\n>> --assume-unchanged FOO` completely lost all changes I had in file FOO.\n>\n> I just ran into this today.\n>\n> Was a decision about this behavior reached in the intervening time?\n\nWhen you mark a file assume-unchanged, git internally sets a flag that\nthis file should not be considered when doing cache refreshes -- the\nfile is always assumed to be up-to-date.\n\nSo while I haven't actually looked into all of the code, I imagine it\ngoes something like this:\n\n* git-stash uses git update-index --all on all modified files. But it\n doesn't show up as modified, because you promised it isn't.\n\n* Later it calls git reset --hard, which blows away the existing state.\n This would seem to ignore the assume-unchanged flag in this case, as\n otherwise it wouldn't overwrite it.\n\nWhether the last behavior is a bug is in the eye of the beholder. In\nyour case you apparently lost work. However, 'git reset --hard' in\nitself should discard all uncommitted work without asking any further\nquestions (because it's --hard). So the bug is then in the sequence\n\n ask about uncommitted work\n save it elsewhere\n git reset --hard\n\nassuming that this actually makes sure nothing gets lost. But the only\nthing that was lost was *files that you promised would not be changed*.\n\n\nWhat's really unfortunate is that we caused this in the first place by\nPasky's 6259ac6 (Documentation: How to ignore local changes in tracked\nfiles, 2008-07-18). It recommends exactly the --assume-unchanged\nstrategy to ignore changes to tracked files.\n\nAnd it's hard to disagree with its commit message:\n\n This is currently probably one of the top FAQs at #git and the\n --assume-unchanged switch is not widely known\n\nExcept that now the corresponding FAQ is that we have to actively\ndissuade people from using --assume-unchanged precisely because it keeps\nbiting people.\n\nSo maybe it would be time to first make up our minds as to what\n--assume-unchanged should actually mean:\n\n* Ignore changes to a tracked file, but treat them as valuable. In\n this case we'd have to make sure that failures like git-stash's are\n handled properly.\n\n* Ignore changes to a tracked file, as in \"who cares if it was changed\".\n\n* A very specific optimization for users who know what they are doing.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"218327","messageId":"7vd2shcnx7.fsf@alter.siamese.dyndns.org","threadId":"24008","inReplyTo":"87sj1d5ous.fsf@linux-k42r.v.cablecom.net","subject":"Re: git stash deletes/drops changes of","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-23T22:49:08Z","receivedAt":"2013-05-23T22:49:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> So maybe it would be time to first make up our minds as to what\n> --assume-unchanged should actually mean:\n>\n> * Ignore changes to a tracked file, but treat them as valuable. In\n> this case we'd have to make sure that failures like git-stash's are\n> handled properly.\n>\n> * Ignore changes to a tracked file, as in \"who cares if it was changed\".\n>\n> * A very specific optimization for users who know what they are doing.\n\nIt has always been a promise the user makes to Git that the working\ntree files that are marked as such will be kept identical to what is\nin the index (hence there is no need for Git to check if they were\nmodified). And by extension, Git is now free to choose reading from\nthe working tree file when asked to read from blob object recorded\nin the index for that path, or vice versa, because of that promise.\n\nIt is not --ignore-changes bit, and has never been. What are the\nworkflows that are helped if we had such a bit? If we need to\nsupport them, I think you need a real --ignore-changes bit, not\nan abuse of --assume-unchanged.\n"},{"id":"218329","messageId":"87obc15mq5.fsf@linux-k42r.v.cablecom.net","threadId":"24008","inReplyTo":"7vd2shcnx7.fsf@alter.siamese.dyndns.org","subject":"Re: git stash deletes/drops changes of","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-05-23T22:56:50Z","receivedAt":"2013-05-23T22:56:50Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano writes:\n\n> Thomas Rast writes:\n>\n>> So maybe it would be time to first make up our minds as to what\n>> --assume-unchanged should actually mean:\n>>\n>> * Ignore changes to a tracked file, but treat them as valuable. In\n>> this case we'd have to make sure that failures like git-stash's are\n>> handled properly.\n>>\n>> * Ignore changes to a tracked file, as in \"who cares if it was changed\".\n>>\n>> * A very specific optimization for users who know what they are doing.\n>\n> It has always been a promise the user makes to Git that the working\n> tree files that are marked as such will be kept identical to what is\n> in the index (hence there is no need for Git to check if they were\n> modified). And by extension, Git is now free to choose reading from\n> the working tree file when asked to read from blob object recorded\n> in the index for that path, or vice versa, because of that promise.\n>\n> It is not --ignore-changes bit, and has never been. What are the\n> workflows that are helped if we had such a bit? If we need to\n> support them, I think you need a real --ignore-changes bit, not\n> an abuse of --assume-unchanged.\n\nI gather -- from #git -- that it's mostly used for config files, which\nhave an annoying habit of being different from the repository.\n\nWhich is wrong, really. But we still claim that --assume-unchanged is a\nsolution to it in git-update-index(1).\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"218332","messageId":"7v4ndtcmh0.fsf@alter.siamese.dyndns.org","threadId":"24008","inReplyTo":"87obc15mq5.fsf@linux-k42r.v.cablecom.net","subject":"Re: git stash deletes/drops changes of","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-23T23:20:27Z","receivedAt":"2013-05-23T23:20:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n>> What are the workflows that are helped if we had such a bit? If\n>> we need to support them, I think you need a real --ignore-changes\n>> bit, not an abuse of --assume-unchanged.\n>\n> I gather -- from #git -- that it's mostly used for config files, which\n> have an annoying habit of being different from the repository.\n>\n> Which is wrong, really. But we still claim that --assume-unchanged is a\n> solution to it in git-update-index(1).\n\nThat is doubly wrong, then ;-)\n\nHow would we want to proceed from here? The obvious first step\nwould be to fix the documentation, but then what is next?\n\nThinking aloud, ignoring that \"Which is wrong, really\" part in your\nmessage and assuming that we do want to support --ignore-changes....\n\nCan the way we handle \"--ignore-changes\" files be a strict superset\n(or is it subset?) of what we currently do for \"--assume-unchanged\"?\nThat is, if we \"fix\"^Wchange the behaviour of \"--assume-unchanged\"\nto be less aggressive in assuming that the user kept his promise,\ncan we get \"--ignore-changes\" without losing much of the performance\nbenefit of \"--assume-unchanged\" the people who originally wanted to\nhave that feature have enjoyed for all these years?\n\nIf you are working on a project with a large working tree, by\nmarking paths in one directory you do not care about (and do not\nuse) with the --assume-unchanged bit, checking out another branch\ncan be done without inspecting if there are uncommitted changes in\nthe part of the working tree that may be clobbered with the\ndifferent version of the file in the other branch. That has to go\nfor \"--ignore-changes\", for example. Are there others that need to\nsuffer?\n\nIf so, these two have to be done as totally independent options, but\nif -ignore-changes can be just a slightly less agressive\n-assume-unchanged, we could \"fix\" \"--assume-unchanged\", introduce\n\"--ignore-changes\" as a synonym and be done with it. I highly doubt\nthat is doable.\n\nThe only sensible way forward, it seems to me, is introduce a proper\n\"--ignore-changes\" that is independent from \"--assume-unchanged\".\nWhat does \"--ignore-changes\" really mean?\n\nThe end user does not want to see changes to a config file when he\nruns \"git status\" and \"git diff\". I think \"git commit -a\" would\nignore the local changes to the configuration file as a natural\nconsequence if we teach \"git status\" to ignore paths marked with the\n\"--ignore-changes\" bit. But the same \"git diff\" (between the index\nand the working tree) logic is internally used to decide if a path\nhas local changes when running \"git checkout\" to check out another\nbranch, \"git rebase\" to see if there are local changes, etc. and the\nuser do want to view the paths as modified.\n\nI am not so sure if there is a clear semantics other than\nan unactionable blanket statement \"ignore local changes\".\n"},{"id":"218338","messageId":"20130523235711.GJ12252@machine.or.cz","threadId":"24008","inReplyTo":"87obc15mq5.fsf@linux-k42r.v.cablecom.net","subject":"Re: git stash deletes/drops changes of","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2013-05-23T23:57:12Z","receivedAt":"2013-05-23T23:57:12Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi!\n\nOn Fri, May 24, 2013 at 12:56:50AM +0200, Thomas Rast wrote:\n> > It is not --ignore-changes bit, and has never been.\n\n Indeed, it has been my lack of imagination regarding what can go\nwrong. I am fine with the changes not being shown in `git diff` and even\nnot so worried about them being overwritten by a merge/checkout\n(touching that file for other purposes), but `git stash` dropping the\nchanges is rather vicious. ;-)\n\n An emergency fix would be to add a warning to the documentation that\nunder various circumstances, your changes may get overwritten and keep a\nbackup copy. It's a bit silly, I'm not sure how long it may take to\nflesh out a proper solution; if we just stop recommending anything (or\nrecommend something unhelpful like \"you don't want that\"), people will\njust refer to the old advice and I think it's better to warn them.\n\n> > What are the workflows that are helped if we had such a bit? If we\n> > need to support them, I think you need a real --ignore-changes bit,\n> > not an abuse of --assume-unchanged.\n> \n> I gather -- from #git -- that it's mostly used for config files, which\n> have an annoying habit of being different from the repository.\n> \n> Which is wrong, really. But we still claim that --assume-unchanged is\n> a solution to it in git-update-index(1).\n\n The main workflow for me is when you don't get to pick the workflow.\nMost recently, I found myself tackling this scenario:\n\n (i) https://github.com/huceke/omxplayer carries file Makefile.include\n\n (ii) I'm paid to make some modifications to the omxplayer software\non short notice.\n\n (iii) Makefile.include hardcodes some crosscompiling tool paths and\nother things (like CFLAGS) that are different in my setup.\n\n For the first few commits, I have avoided using -a, then I went ahead\nand marked Makefile.include with --assume-unchanged. It felt like\nsomething dangerous, so I also made a backup of the file for good\nmeasure; that turned out to be a good idea after the first `git stash`\nissued. (Unfortunately, I forgot about the problem before I would have\ntime to think about fixing that.)\n\n Yeah, omxplayer's setup is not ideal. But in this scenario, I'm not\nreally in the position to easily start poking into other people's\ntoolchain setup, I'd like git just to help me get my work done and move\non and ideally keep my pull requests clean of unrelated commits.\n\n\n Just to clear up on what the best practice is, I'd imagine the setup\nto be something like:\n\n\t(a) Makefile contains inclusion of Makefile.include.\n\n\t(b) There is a file like Makefile.include.template containing\n\ta template to be copied over and filled by the user.\n\n\t(c) Makefile contains code that makes sure all variables that\n\tare supposed to be set are set and obsolete variables are not,\n\tsince there is no mechanism to cause e.g. a merge conflict\n\ton change of Makefile.include.template.\n\nIs there a better way to solve this?\n\n There are a couple of things to notice here:\n\n (i) The solution is highly specific for the particular file format\nand usage, universal recommendations are difficult especially if we\nare to cover (c).\n\n (ii) The solution is certainly not the simplest one to occur to\nthe original author, who will probably initially just commit\nMakefile.include with the values suitable for them.\n\n (iii) A corrolary to (ii), the person who will find tackling this\nproblem first will probably be a newcoming developer to the project\nwho is likely not to be familiar with it and its toolchain / config\nmechanisms, and this will be a huge hassle.\n\n Therefore the demand for Git to just solve their problem on its level.\nOf course Git would be simpler and more elegant if it didn't have to do\nthis and cover all the annoying corner cases. But is this simplification\nworth the extra workflow hassle for its users?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\n\tFor every complex problem there is an answer that is clear,\n\tsimple, and wrong. -- H. L. Mencken\n"},{"id":"218348","messageId":"20130524082253.GY27005@serenity.lan","threadId":"24008","inReplyTo":"20130523235711.GJ12252@machine.or.cz","subject":"Re: git stash deletes/drops changes of","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-24T08:22:53Z","receivedAt":"2013-05-24T08:22:53Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Fri, May 24, 2013 at 01:57:12AM +0200, Petr Baudis wrote:\n> Just to clear up on what the best practice is, I'd imagine the setup\n> to be something like:\n> \n> \t(a) Makefile contains inclusion of Makefile.include.\n> \n> \t(b) There is a file like Makefile.include.template containing\n> \ta template to be copied over and filled by the user.\n> \n> \t(c) Makefile contains code that makes sure all variables that\n> \tare supposed to be set are set and obsolete variables are not,\n> \tsince there is no mechanism to cause e.g. a merge conflict\n> \ton change of Makefile.include.template.\n> \n> Is there a better way to solve this?\n\nI think the best practice would be what Git itself does ;-)\n\nThe Makefile sets default values for all parameters, some of which are\ninferred based on the system. It then includes config.mak, which allows\nthe user to override any of these values.\n"},{"id":"218353","messageId":"20130524094006.GM12252@machine.or.cz","threadId":"24008","inReplyTo":"20130524082253.GY27005@serenity.lan","subject":"Re: git stash deletes/drops changes of","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2013-05-24T09:40:07Z","receivedAt":"2013-05-24T09:40:07Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, May 24, 2013 at 09:22:53AM +0100, John Keeping wrote:\n> On Fri, May 24, 2013 at 01:57:12AM +0200, Petr Baudis wrote:\n> > Just to clear up on what the best practice is, I'd imagine the setup\n> > to be something like:\n> > \n> > \t(a) Makefile contains inclusion of Makefile.include.\n> > \n> > \t(b) There is a file like Makefile.include.template containing\n> > \ta template to be copied over and filled by the user.\n> > \n> > \t(c) Makefile contains code that makes sure all variables that\n> > \tare supposed to be set are set and obsolete variables are not,\n> > \tsince there is no mechanism to cause e.g. a merge conflict\n> > \ton change of Makefile.include.template.\n> > \n> > Is there a better way to solve this?\n> \n> I think the best practice would be what Git itself does ;-)\n> \n> The Makefile sets default values for all parameters, some of which are\n> inferred based on the system. It then includes config.mak, which allows\n> the user to override any of these values.\n\nSo that's pretty similar to what I described, modulo the filenames.\nI'd say it's more friendly if you don't need to tweak any of the\ndefaults in the common case, but less friendly if you always need to\ntweak something/everything (you really want a template file then\nand not covering (c) is a problem).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\n\tFor every complex problem there is an answer that is clear,\n\tsimple, and wrong. -- H. L. Mencken\n"},{"id":"218354","messageId":"20130524100612.GA27005@serenity.lan","threadId":"24008","inReplyTo":"20130524094006.GM12252@machine.or.cz","subject":"Re: git stash deletes/drops changes of","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-24T10:06:12Z","receivedAt":"2013-05-24T10:06:12Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Fri, May 24, 2013 at 11:40:07AM +0200, Petr Baudis wrote:\n> On Fri, May 24, 2013 at 09:22:53AM +0100, John Keeping wrote:\n> > On Fri, May 24, 2013 at 01:57:12AM +0200, Petr Baudis wrote:\n> > > Just to clear up on what the best practice is, I'd imagine the setup\n> > > to be something like:\n> > > \n> > > \t(a) Makefile contains inclusion of Makefile.include.\n> > > \n> > > \t(b) There is a file like Makefile.include.template containing\n> > > \ta template to be copied over and filled by the user.\n> > > \n> > > \t(c) Makefile contains code that makes sure all variables that\n> > > \tare supposed to be set are set and obsolete variables are not,\n> > > \tsince there is no mechanism to cause e.g. a merge conflict\n> > > \ton change of Makefile.include.template.\n> > > \n> > > Is there a better way to solve this?\n> > \n> > I think the best practice would be what Git itself does ;-)\n> > \n> > The Makefile sets default values for all parameters, some of which are\n> > inferred based on the system. It then includes config.mak, which allows\n> > the user to override any of these values.\n> \n> So that's pretty similar to what I described, modulo the filenames.\n> I'd say it's more friendly if you don't need to tweak any of the\n> defaults in the common case, but less friendly if you always need to\n> tweak something/everything (you really want a template file then\n> and not covering (c) is a problem).\n\nI don't see anything wrong with having a template file documenting the\nparameters, but I think it's important that there are sensible defaults\nin place when the user's configuration file does not specify a value for\na parameter. It wasn't clear to me from your definition that there were\ndefaults to be overridden by the user's configuration file, as opposed\nto forcing the user to define certain values and causing an error if\nthose are not defined.\n"},{"id":"218355","messageId":"20130524101416.GO12252@machine.or.cz","threadId":"24008","inReplyTo":"20130524100612.GA27005@serenity.lan","subject":"Re: git stash deletes/drops changes of","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2013-05-24T10:14:16Z","receivedAt":"2013-05-24T10:14:16Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, May 24, 2013 at 11:06:12AM +0100, John Keeping wrote:\n> I don't see anything wrong with having a template file documenting the\n> parameters, but I think it's important that there are sensible defaults\n> in place when the user's configuration file does not specify a value for\n> a parameter. It wasn't clear to me from your definition that there were\n> defaults to be overridden by the user's configuration file, as opposed\n> to forcing the user to define certain values and causing an error if\n> those are not defined.\n\nThat's the case in plenty of situations - when specifying usernames and\npasswords and server hostnames, paths to cross-compiling environments\nthat pretty much everyone has at a different place, and so on.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\n\tFor every complex problem there is an answer that is clear,\n\tsimple, and wrong. -- H. L. Mencken\n"},{"id":"218359","messageId":"20130524104018.GB27005@serenity.lan","threadId":"24008","inReplyTo":"20130524101416.GO12252@machine.or.cz","subject":"Re: git stash deletes/drops changes of","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-24T10:40:18Z","receivedAt":"2013-05-24T10:40:18Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Fri, May 24, 2013 at 12:14:16PM +0200, Petr Baudis wrote:\n> On Fri, May 24, 2013 at 11:06:12AM +0100, John Keeping wrote:\n> > I don't see anything wrong with having a template file documenting the\n> > parameters, but I think it's important that there are sensible defaults\n> > in place when the user's configuration file does not specify a value for\n> > a parameter. It wasn't clear to me from your definition that there were\n> > defaults to be overridden by the user's configuration file, as opposed\n> > to forcing the user to define certain values and causing an error if\n> > those are not defined.\n> \n> That's the case in plenty of situations - when specifying usernames and\n> passwords and server hostnames, paths to cross-compiling environments\n> that pretty much everyone has at a different place, and so on.\n\nYeah, I didn't mean to say that everything can have a sensible default.\n\nGoing back to where this started, in the omxplayer Makefile, I would map\nmy suggestion to a change like this:\n\n * Change most of the \":=\" in Makefile.include to \"=\" so that the\n order of variable definition matters less\n * Move Makefile.include to Makefile.defaults\n * Change the \"include Makefile.include\" at the top of Makefile to:\n\n include Makefile.defaults\n -include Makefile.config\n \n * Add Makefile.config to .gitignore\n\nSo that it continues to Just Work for people using buildroot but you can\ncreate Makefile.config to override those defaults.\n\nI agree that this isn't possible in all cases, and your template\napproach is certainly useful for configuration files - particularly\nbecause those templates can be included in end-user documentation or the\ninstallation as they are likely to be needed in the installed\napplication and not just development.\n"},{"id":"218361","messageId":"20130524110322.GP12252@machine.or.cz","threadId":"24008","inReplyTo":"20130524104018.GB27005@serenity.lan","subject":"Re: git stash deletes/drops changes of","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2013-05-24T11:03:22Z","receivedAt":"2013-05-24T11:03:22Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, May 24, 2013 at 11:40:18AM +0100, John Keeping wrote:\n> So that it continues to Just Work for people using buildroot but you can\n> create Makefile.config to override those defaults.\n\n Indeed, that doesn't cover some corner cases of (c), but that's not a\nbig deal in practice I guess.\n\n My point still stands - this is extra hassle, done just for the sake\nof the tool; I think the tool should not get in the way. Moreover, it's\nnot the default solution for your typical original author and therefore\nyou will still often find yourself in a situation where you have to deal\nwith a setup that's broken already.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\n\tFor every complex problem there is an answer that is clear,\n\tsimple, and wrong. -- H. L. Mencken\n"},{"id":"218364","messageId":"20130524124242.GD27005@serenity.lan","threadId":"24008","inReplyTo":"20130524110322.GP12252@machine.or.cz","subject":"Re: git stash deletes/drops changes of","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-24T12:42:42Z","receivedAt":"2013-05-24T12:42:42Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Fri, May 24, 2013 at 01:03:22PM +0200, Petr Baudis wrote:\n> On Fri, May 24, 2013 at 11:40:18AM +0100, John Keeping wrote:\n> > So that it continues to Just Work for people using buildroot but you can\n> > create Makefile.config to override those defaults.\n> \n> Indeed, that doesn't cover some corner cases of (c), but that's not a\n> big deal in practice I guess.\n> \n> My point still stands - this is extra hassle, done just for the sake\n> of the tool; I think the tool should not get in the way. Moreover, it's\n> not the default solution for your typical original author and therefore\n> you will still often find yourself in a situation where you have to deal\n> with a setup that's broken already.\n\nI think we're in violent agreement here.\n\nI can see that there are cases where an --ignore-changes option that\nbehaves like --assume-unchanged but without ever overwriting the local\nfile is a useful feature. I was simply trying to point at what I\nconsider best practices for makefiles, which was relevant for the\nexample you gave. Sorry if that was unclear.\n"},{"id":"218373","messageId":"360187633.973068.1369405562399.JavaMail.root@genarts.com","threadId":"24008","inReplyTo":"87obc15mq5.fsf@linux-k42r.v.cablecom.net","subject":"Re: git stash deletes/drops changes of","fromName":"Stephen Bash","fromEmail":"bash@genarts.com","sentAt":"2013-05-24T14:26:02Z","receivedAt":"2013-05-24T14:26:02Z","isPatch":false,"sender":{"key":"bash@genarts.com","avatar":null},"body":"----- Original Message -----\n> From: \"Thomas Rast\" \n> Sent: Thursday, May 23, 2013 6:56:50 PM\n> Subject: Re: git stash deletes/drops changes of\n> \n> Junio C Hamano writes:\n> \n> > Thomas Rast writes:\n> >\n> > > So maybe it would be time to first make up our minds as to what\n> > > --assume-unchanged should actually mean:\n> > >\n> > > * Ignore changes to a tracked file, but treat them as valuable.\n> > > In this case we'd have to make sure that failures like\n> > > git-stash's are handled properly.\n> > >\n> > > * Ignore changes to a tracked file, as in \"who cares if it was\n> > > changed\".\n> > >\n> > > * A very specific optimization for users who know what they are\n> > > doing.\n> >\n> > It has always been a promise the user makes to Git that the working\n> > tree files that are marked as such will be kept identical to what is\n> > in the index (hence there is no need for Git to check if they were\n> > modified). And by extension, Git is now free to choose reading from\n> > the working tree file when asked to read from blob object recorded\n> > in the index for that path, or vice versa, because of that promise.\n> >\n> > It is not --ignore-changes bit, and has never been. What are the\n> > workflows that are helped if we had such a bit? If we need to\n> > support them, I think you need a real --ignore-changes bit, not\n> > an abuse of --assume-unchanged.\n> \n> I gather -- from #git -- that it's mostly used for config files, which\n> have an annoying habit of being different from the repository.\n\nThe web team at my $dayjob has the same problem, and I believe they are also using --assume-unchanged.\n\nThis 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?\n\nThanks,\nStephen\n"},{"id":"218376","messageId":"CABURp0rBzH9=VdW0Y4Bv1tfbSzZ3dwismwgZ7zCwrXC6nDRSJQ@mail.gmail.com","threadId":"24008","inReplyTo":"7v4ndtcmh0.fsf@alter.siamese.dyndns.org","subject":"Re: git stash deletes/drops changes of","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-05-24T15:25:23Z","receivedAt":"2013-05-24T15:25:23Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Thu, May 23, 2013 at 7:20 PM, Junio C Hamano wrote:\n> Thomas Rast writes:\n>\n>>> What are the workflows that are helped if we had such a bit? If\n>>> we need to support them, I think you need a real --ignore-changes\n>>> bit, not an abuse of --assume-unchanged.\n>>\n>> I gather -- from #git -- that it's mostly used for config files, which\n>> have an annoying habit of being different from the repository.\n>>\n>> Which is wrong, really. But we still claim that --assume-unchanged is a\n>> solution to it in git-update-index(1).\n>\n> That is doubly wrong, then ;-)\n>\n> How would we want to proceed from here? The obvious first step\n> would be to fix the documentation, but then what is next?\n>\n> Thinking aloud, ignoring that \"Which is wrong, really\" part in your\n> message and assuming that we do want to support --ignore-changes....\n\n\nThe wording of --ignore-changes suffers the same lack of clarity that\n--assume-unchanged does.\n\n --assume-unchanged : These changes are ephemeral\n\n --ignore-changes : These changes are precious but not to be committed\n\nWhat's better? --sequester is probably too obscure. Maybe --hold.\nOr --silence. Or --shut-up.\n\nDoes this mean a new class of files for git-status? Added, changed,\nuntracked, ignored and held?\n\nI wonder if there is a use case for such a switch to be applied to\ncontent rather than files. Suppose I want to --hold these changes,\nbut further changes to the same files should be fair game? That's\nprobably an insane situation for some future itch and not this one.\nAnyway, it sounds like it would involve the index or maybe a 2nd\nindex.\n\nPhil\n"},{"id":"218378","messageId":"loom.20130524T173321-264@post.gmane.org","threadId":"24008","inReplyTo":"CABURp0rBzH9=VdW0Y4Bv1tfbSzZ3dwismwgZ7zCwrXC6nDRSJQ@mail.gmail.com","subject":"Re: git stash deletes/drops changes of","fromName":"Jim Greenleaf","fromEmail":"james.a.greenleaf@gmail.com","sentAt":"2013-05-24T15:34:26Z","receivedAt":"2013-05-24T15:34:26Z","isPatch":false,"sender":{"key":"james.a.greenleaf@gmail.com","avatar":"https://gravatar.com/avatar/dc4e7f3bbb0eefe1e3daa76a87d355c1e4260d9b5a6614cbe773a14f7b3c2805?d=mp&s=160"},"body":"Phil Hord gmail.com> writes:\n\n> The wording of --ignore-changes suffers the same lack of clarity that\n> --assume-unchanged does.\n> What's better? --sequester is probably too obscure. Maybe --hold.\n> Or --silence. Or --shut-up.\n\nHow about --freeze?\n"},{"id":"218379","messageId":"20130524153853.GE27005@serenity.lan","threadId":"24008","inReplyTo":"loom.20130524T173321-264@post.gmane.org","subject":"Re: git stash deletes/drops changes of","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-24T15:38:53Z","receivedAt":"2013-05-24T15:38:53Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Fri, May 24, 2013 at 03:34:26PM +0000, Jim Greenleaf wrote:\n> Phil Hord gmail.com> writes:\n> \n> > The wording of --ignore-changes suffers the same lack of clarity that\n> > --assume-unchanged does.\n> > What's better? --sequester is probably too obscure. Maybe --hold.\n> > Or --silence. Or --shut-up.\n> \n> How about --freeze?\n\nI wonder if this would be better as a file rather than another option to\ngit-update-index. We already have .git/info/exclude so we could add\n.git/info/freeze or .git/info/local with the same syntax as the normal\n.gitignore file.\n"},{"id":"218380","messageId":"loom.20130524T174015-773@post.gmane.org","threadId":"24008","inReplyTo":"20130524153853.GE27005@serenity.lan","subject":"Re: git stash deletes/drops changes of","fromName":"Jim Greenleaf","fromEmail":"james.a.greenleaf@gmail.com","sentAt":"2013-05-24T15:42:37Z","receivedAt":"2013-05-24T15:42:37Z","isPatch":false,"sender":{"key":"james.a.greenleaf@gmail.com","avatar":"https://gravatar.com/avatar/dc4e7f3bbb0eefe1e3daa76a87d355c1e4260d9b5a6614cbe773a14f7b3c2805?d=mp&s=160"},"body":"John Keeping keeping.me.uk> writes:\n\n> I wonder if this would be better as a file rather than another option to\n> git-update-index. We already have .git/info/exclude so we could add\n> .git/info/freeze or .git/info/local with the same syntax as the normal\n> .gitignore file.\n\n.git/info/freeze would be a good solution.\nIt would avoid the need to add a new class of files for git-status,\nwhile keeping a simple, familiar record of all frozen files in a single location.\n"},{"id":"218384","messageId":"20130524160143.GF27005@serenity.lan","threadId":"24008","inReplyTo":"loom.20130524T174015-773@post.gmane.org","subject":"Re: git stash deletes/drops changes of","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-24T16:01:43Z","receivedAt":"2013-05-24T16:01:43Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Fri, May 24, 2013 at 03:42:37PM +0000, Jim Greenleaf wrote:\n> John Keeping keeping.me.uk> writes:\n> \n> > I wonder if this would be better as a file rather than another option to\n> > git-update-index. We already have .git/info/exclude so we could add\n> > .git/info/freeze or .git/info/local with the same syntax as the normal\n> > .gitignore file.\n> \n> .git/info/freeze would be a good solution.\n> It would avoid the need to add a new class of files for git-status,\n> while keeping a simple, familiar record of all frozen files in a single location.\n\nNow I've thought about it a bit more, I'm not sure this does work.\n\nIf an entry in the freeze list means \"ignore local changes in this\nfile\", we really want to be talking about local changes relative to some\nbase. Otherwise, what happens if the upstream file is radically\naltered? A user probably doesn't want to keep their file unchanged when\nthis happens.\n\nSo we don't just want to store the filename, we want to store the\nversion of the file that the user chose to ignore. One way to do this\nmight be to mark the file as a conflict whenever a change to it comes in\nand ignore the freeze file when there is a conflict in the index. But\nthen we either need to introduce a new command to manage this state or\nsome way for the user to perform Git operations ignoring the freeze\nfile, otherwise how can the user pull down updates?\n\nPerhaps a more user-friendly way to handle this would be to introduce\nauto-stash around any operation that will modify a frozen file. So we\nstash the user's (frozen) changes and then apply them after changing the\nfile. If there are conflicts then these are marked in the index and\nmust be resolved, then the unstaged changes in the file are ignored\nagain.\n"}]}