{"thread":{"id":"36305","subject":"Git feature request: Option to force Git to abort a checkout if working directory is dirty (i.e. disregarding the check for conflicts)","startedAt":"2014-03-27T16:15:33Z","lastAt":"2014-04-03T18:42:45Z","messageCount":7,"participants":["Jonas Bang","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"237909","messageId":"004d01cf49d7$c8b9cd90$5a2d68b0$@jonasbang.dk","threadId":"36305","inReplyTo":null,"subject":"Git feature request: Option to force Git to abort a checkout if working directory is dirty (i.e. disregarding the check for conflicts)","fromName":"Jonas Bang","fromEmail":"email@jonasbang.dk","sentAt":"2014-03-27T16:15:33Z","receivedAt":"2014-03-27T16:15:33Z","isPatch":false,"sender":{"key":"email@jonasbang.dk","avatar":null},"body":"Hi Git developers, \n\nThis is my first Git feature request, I hope it won’t get me hanged on the\ngallows ;o) \n\n*Git feature request:*\nAdd an option to Git config to configure the criteria for when a \"git\ncheckout\" should abort. \n\n*Name proposal and options:*\ncheckout.clean false <default> \ncheckout.clean true \n\n*False behavior:*\nAs is: \nWhen doing a checkout then Git will check if your working directory is\ndirty, and if so check if the checkout will result in any conflicts, and if\nso abort the checkout with a message: \n\n$ git checkout some_branch\nerror: Your local changes to the following files would be overwritten by\ncheckout:\n       some_file\nPlease, commit your changes or stash them before you can switch branches.\nAborting \n\nIf no conflicts then: \n\n$ git checkout some_branch\nM       some_file\nM       some_other_file\nSwitched to branch 'some_branch' \n\nI.e. it will only abort if there are conflicts. \n\n*True behavior:*\nWhen doing a checkout then Git will check if your working directory is dirty\n(checking for both modified and added untracked files), and if so abort the\ncheckout with a message: \n\n$ git checkout some_branch\nerror: Your working directory is not clean.\nPlease, commit your changes or stash them before you can switch branches.\nAborting \n\nI.e. it will abort if working directory is dirty (checking for both modified\nand added untracked files). \nI.e. you can only do checkout if you get \"nothing to commit, working\ndirectory clean\" when running \"git status\" (ignoring ignored files though). \n\n*Usecase in short:*\nIf you use an IDE (like e.g. Eclipse) and do a checkout\nof 'some_branch' with a dirty working directory which will not result in any\nconflicts, then you will not be nicely notified (as you would in Git Bash)\nthat the changes you were working on in 'previous_branch' are still present\nin your working directory after changing to 'some_branch'. I.e. when you\ncompile your code your uncommitted changes from 'previous_branch' are still\npresent in your working directory on 'some_branch'. \n\nAs I see it Git is extremely strong in context switching (i.e. working on\nmultiple issues on multiple branches), and I could see a use for a setting\nwhich setup a strict check for if working directory is not clean\n(disregarding the check for conflicts). This would mean that your changes\ncreated while on branch #1 will not be carried over when changing to branch\n#2, i.e. you will work strictly context based always. \n\n*Usecase also described here:*\nhttp://stackoverflow.com/questions/22609566/how-to-force-git-to-abort-a-chec\nkout-if-working-directory-is-not-clean-i-e-dis \n\nBr, \nJonas Bang Christensen\n"},{"id":"237920","messageId":"xmqqk3bfedqi.fsf@gitster.dls.corp.google.com","threadId":"36305","inReplyTo":"004d01cf49d7$c8b9cd90$5a2d68b0$@jonasbang.dk","subject":"Re: Git feature request: Option to force Git to abort a checkout if working directory is dirty (i.e. disregarding the check for conflicts)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-27T17:46:29Z","receivedAt":"2014-03-27T17:46:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Jonas Bang\" <email@jonasbang.dk> writes:\n\n> Hi Git developers, \n>\n> This is my first Git feature request, I hope it won’t get me hanged on the\n> gallows ;o) \n>\n> *Git feature request:*\n> Add an option to Git config to configure the criteria for when a \"git\n> checkout\" should abort. \n>\n> *Name proposal and options:*\n> checkout.clean false <default> \n> checkout.clean true \n\nA configuration variable without command line override will make the\nsystem unusable.  When thinking about a new feature, please make it\na habit to first add a command line option and then if that option\nturns out to be useful in the real world (not in the imaginary world\nin which you had such a feature, where even you haven't lived in\nyet), then think about also adding configuration variables to\ncontrol the default.\n\nAlso, a useful definition of \"clean\"-ness may have to change over\ntime as we gain experience with the feature.  And also as a user\npersonally gains experience with using Git.  It is somewhat\nimplausible that a boolean true/false may remain sufficient.\n\n\n> *False behavior:*\n\nWhat is \"false\"?\n\nAh, when the configuration is set to \"false\", which will be the\ndefault?\n\n> As is: \n> When doing a checkout then Git will check if your working directory is\n> dirty, and if so check if the checkout will result in any conflicts, and if\n> so abort the checkout with a message: \n>\n> $ git checkout some_branch\n> error: Your local changes to the following files would be overwritten by\n> checkout:\n>        some_file\n> Please, commit your changes or stash them before you can switch branches.\n> Aborting \n>\n> If no conflicts then: \n>\n> $ git checkout some_branch\n> M       some_file\n> M       some_other_file\n> Switched to branch 'some_branch' \n>\n> I.e. it will only abort if there are conflicts. \n\nSensible.  This is the behaviour that is very often depended upon by\npeople who use Git with multiple branches.  Are you thinking about\nchanging it in any way when the new configuration is set to \"false\",\nor is the above just a summary of what happens in the current\nsystem?\n\n\n> *True behavior:*\n> When doing a checkout then Git will check if your working directory is dirty\n> (checking for both modified and added untracked files), and if so abort the\n> checkout with a message: \n>\n> $ git checkout some_branch\n> error: Your working directory is not clean.\n> Please, commit your changes or stash them before you can switch branches.\n> Aborting \n>\n> I.e. it will abort if working directory is dirty (checking for both modified\n> and added untracked files). \n> I.e. you can only do checkout if you get \"nothing to commit, working\n> directory clean\" when running \"git status\" (ignoring ignored files though). \n\nThe above two say very different things.  For some people, having\nmany throw away untracked files is a norm that they do not consider\nit is even worth their time to list them in .gitignore and they do\nnot want to be reminded in \"git status\" output, and the latter\ndefinition of \"checkout.clean=true will kill checkout when status\nsays there are some things that could be committed\" would suit them,\nwhile the former definition \"checkout.clean=true will kill checkout\nwhen there is any untracked files\" would be totally useless.\n\nSo I can understand the latter, but I do not see how the former\ncould be a useful addition.\n\nFor some people it is also a norm to keep files that have been\nmodified from HEAD and/or index without committing for a long time\n(e.g. earlier, Linus said that the version in Makefile is updated\nand kept modified in the working tree long before a new release is\ncommitted with that change).  The default behaviour would cover\ntheir use case so your proposal would not hurt them, but I wonder if\nthere are things you could do to help them as well, perhaps by\nallowing this new configuration to express something like \"local\nchanges in these paths are except from this new check\".\n\nI dunno.\n"},{"id":"238050","messageId":"002001cf4b44$fe3550c0$fa9ff240$@jonasbang.dk","threadId":"36305","inReplyTo":"xmqqk3bfedqi.fsf@gitster.dls.corp.google.com","subject":"RE: Git feature request: Option to force Git to abort a checkout if working directory is dirty (i.e. disregarding the check for conflicts)","fromName":"Jonas Bang","fromEmail":"email@jonasbang.dk","sentAt":"2014-03-29T11:49:47Z","receivedAt":"2014-03-29T11:49:47Z","isPatch":false,"sender":{"key":"email@jonasbang.dk","avatar":null},"body":"Thanks for your feedback, Junio, I have added more details and tried to simplify the request.\n\n> \"Jonas Bang\" <email@jonasbang.dk> writes:\n> \n> > Hi Git developers,\n> >\n> > This is my first Git feature request, I hope it won’t get me hanged on\n> > the gallows ;o)\n> >\n> > *Git feature request:*\n> > Add an option to Git config to configure the criteria for when a \"git\n> > checkout\" should abort.\n> >\n> > *Name proposal and options:*\n> > checkout.clean false <default>\n> > checkout.clean true\n> \n> A configuration variable without command line override will make the system\n> unusable.  When thinking about a new feature, please make it a habit to first\n> add a command line option and then if that option turns out to be useful in\n> the real world (not in the imaginary world in which you had such a feature,\n> where even you haven't lived in yet), then think about also adding\n> configuration variables to control the default.\n\nProposal for \"git checkout\" command line option:\n--clean false|true|include-untracked|all\n\nIf the 'false' option is used then 'git checkout' will work as today. This should be the default behavior and it is not needed to use this command line option, nor set the configuration variable. The need for the '--clean false' option is if the configuration variable is set to 'true', ' include-untracked' or 'all' in global or local config then it is possible to override this configuration from command line by using '--clean false'.\n\nIf the 'true' option is used then 'git checkout' will abort if the index or the working tree differs from HEAD.\n\nIf the 'include-untracked' option is used then 'git checkout' will abort if there are any untracked files, or if the index or the working tree differs from HEAD.\n\nIf the 'all' option is used then 'git checkout' will abort if there are any ignored files added, or if there are any untracked files, or if the index or the working tree differs from HEAD.\n\nProposal is also to add this as a configuration variable (e.g. checkout.clean false|true|include-untracked|all), as the usecase is most relevant for people using 3rd party IDE or GUI which calls the standard \"git checkout\" command.\n\n> Also, a useful definition of \"clean\"-ness may have to change over time as we\n> gain experience with the feature.  And also as a user personally gains\n> experience with using Git.  It is somewhat implausible that a boolean\n> true/false may remain sufficient.\n\nI have added more options to specify more precisely the definition of \"clean\"-ness.\n \n> > *False behavior:*\n> \n> What is \"false\"?\n> \n> Ah, when the configuration is set to \"false\", which will be the default?\n\nYes, exactly, this was what I meant.\n\n> > As is:\n> > When doing a checkout then Git will check if your working directory is\n> > dirty, and if so check if the checkout will result in any conflicts,\n> > and if so abort the checkout with a message:\n> >\n> > $ git checkout some_branch\n> > error: Your local changes to the following files would be overwritten\n> > by\n> > checkout:\n> >        some_file\n> > Please, commit your changes or stash them before you can switch branches.\n> > Aborting\n> >\n> > If no conflicts then:\n> >\n> > $ git checkout some_branch\n> > M       some_file\n> > M       some_other_file\n> > Switched to branch 'some_branch'\n> >\n> > I.e. it will only abort if there are conflicts.\n> \n> Sensible.  This is the behaviour that is very often depended upon by people\n> who use Git with multiple branches.  Are you thinking about changing it in\n> any way when the new configuration is set to \"false\", or is the above just a\n> summary of what happens in the current system?\n\nThis was just meant as a summary.\n\n> > *True behavior:*\n> > When doing a checkout then Git will check if your working directory is\n> > dirty (checking for both modified and added untracked files), and if\n> > so abort the checkout with a message:\n\nThis will in fact be the 'include-untracked' option where all untracked files are also checked in addition to the index and the working tree.\n\n> > $ git checkout some_branch\n> > error: Your working directory is not clean.\n> > Please, commit your changes or stash them before you can switch branches.\n> > Aborting\n> >\n> > I.e. it will abort if working directory is dirty (checking for both\n> > modified and added untracked files).\n> > I.e. you can only do checkout if you get \"nothing to commit, working\n> > directory clean\" when running \"git status\" (ignoring ignored files though).\n> \n> The above two say very different things.  For some people, having many\n> throw away untracked files is a norm that they do not consider it is even\n> worth their time to list them in .gitignore and they do not want to be\n> reminded in \"git status\" output, and the latter definition of\n> \"checkout.clean=true will kill checkout when status says there are some\n> things that could be committed\" would suit them, while the former definition\n> \"checkout.clean=true will kill checkout when there is any untracked files\"\n> would be totally useless.\n\nRegarding those who has many throw away untracked files, they can either not change the configuration (i.e. keep the 'git checkout' functionality as it is), or optionally use the 'true' option which only checks the index and the working tree (i.e. not checking on untracked files).\n\n> So I can understand the latter, but I do not see how the former could be a\n> useful addition.\n\nBy changing my original behavior of 'true', and by adding 'include-untracked' and 'all', I believe I have taken into account the scenarios you describe.\n\n> For some people it is also a norm to keep files that have been modified from\n> HEAD and/or index without committing for a long time (e.g. earlier, Linus said\n> that the version in Makefile is updated and kept modified in the working tree\n> long before a new release is committed with that change).  The default\n> behaviour would cover their use case so your proposal would not hurt them,\n> but I wonder if there are things you could do to help them as well, perhaps\n> by allowing this new configuration to express something like \"local changes in\n> these paths are except from this new check\".\n\nYes, those people would probably use the default 'false' behavior as it is already. If they however would like to use e.g. the 'true' or 'include-untracked' setting as a configuration variable, then they can use the command line option 'false' if they wish to do a 'git checkout' even with modified files in the working tree.\n"},{"id":"238111","messageId":"xmqqha6e8f67.fsf@gitster.dls.corp.google.com","threadId":"36305","inReplyTo":"002001cf4b44$fe3550c0$fa9ff240$@jonasbang.dk","subject":"Re: Git feature request: Option to force Git to abort a checkout if working directory is dirty (i.e. disregarding the check for conflicts)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-31T17:13:20Z","receivedAt":"2014-03-31T17:13:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Jonas Bang\" <email@jonasbang.dk> writes:\n\n>> For some people it is also a norm to keep files that have been modified from\n>> HEAD and/or index without committing for a long time (e.g. earlier, Linus said\n>> that the version in Makefile is updated and kept modified in the working tree\n>> long before a new release is committed with that change).  The default\n>> behaviour would cover their use case so your proposal would not hurt them,\n>> but I wonder if there are things you could do to help them as well, perhaps\n>> by allowing this new configuration to express something like \"local changes in\n>> these paths are except from this new check\".\n>\n> Yes, those people would probably use the default 'false' behavior\n> as it is already. If they however would like to use e.g. the\n> 'true' or 'include-untracked' setting as a configuration variable,\n> then they can use the command line option 'false' if they wish to\n> do a 'git checkout' even with modified files in the working tree.\n\nSo in short, you are saying that \"The added code necessary to\nimplement this feature will not help them in any way, it is just\nthat we will make sure it does not hurt them\".\n"},{"id":"238233","messageId":"002a01cf4dd3$d88c8640$89a592c0$@jonasbang.dk","threadId":"36305","inReplyTo":"xmqqha6e8f67.fsf@gitster.dls.corp.google.com","subject":"RE: Git feature request: Option to force Git to abort a checkout if working directory is dirty (i.e. disregarding the check for conflicts)","fromName":"Jonas Bang","fromEmail":"email@jonasbang.dk","sentAt":"2014-04-01T17:57:26Z","receivedAt":"2014-04-01T17:57:26Z","isPatch":false,"sender":{"key":"email@jonasbang.dk","avatar":null},"body":"> >> For some people it is also a norm to keep files that have been\n> >> modified from HEAD and/or index without committing for a long time\n> >> (e.g. earlier, Linus said that the version in Makefile is updated and\n> >> kept modified in the working tree long before a new release is\n> >> committed with that change).  The default behaviour would cover their\n> >> use case so your proposal would not hurt them, but I wonder if there\n> >> are things you could do to help them as well, perhaps by allowing\n> >> this new configuration to express something like \"local changes in\nthese\n> paths are except from this new check\".\n> >\n> > Yes, those people would probably use the default 'false' behavior as\n> > it is already. If they however would like to use e.g. the 'true' or\n> > 'include-untracked' setting as a configuration variable, then they can\n> > use the command line option 'false' if they wish to do a 'git\n> > checkout' even with modified files in the working tree.\n> \n> So in short, you are saying that \"The added code necessary to implement\nthis\n> feature will not help them in any way, it is just that we will make sure\nit does\n> not hurt them\".\n\nI didn't realize they needed help. Based on what you describe it seems that\nthey are quite happy about their current workmode. The feature request I'm\nproposing is to aid a different workmode used by a different group of users.\n\nI did try to give it some thought to figure out if it would be possible to\naddress also your mentioned users workmode, but it didn't seem straight\nforward to solve in combination with my feature request, and the solution\nwouldn't end up being as simple. However I did already manage to include\nproposals on how to address your other comments, I believe.\n\nI have focused primarily on proposing a feature request which is as simple\nas possible and which addresses an issue with a workmode for a group of\nusers, and which in the same time doesn't \"hurt\" others.\n\nWhat are your thoughts on that part?\nHow and who to decide if this is a reasonable feature request to accept?\n"},{"id":"238317","messageId":"xmqq7g77vcnk.fsf@gitster.dls.corp.google.com","threadId":"36305","inReplyTo":"002a01cf4dd3$d88c8640$89a592c0$@jonasbang.dk","subject":"Re: Git feature request: Option to force Git to abort a checkout if working directory is dirty (i.e. disregarding the check for conflicts)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-02T17:55:59Z","receivedAt":"2014-04-02T17:55:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Jonas Bang\" <email@jonasbang.dk> writes:\n\n>> >> ...  The default behaviour would cover their\n>> >> use case so your proposal would not hurt them, but I wonder if there\n>> >> are things you could do to help them as well, perhaps by allowing\n>> >> this new configuration to express something like \"local changes in\n>> >> these paths are excempt from this new check\".\n>> >\n>> > Yes, those people would probably use the default 'false' behavior as\n>> > it is already. If they however would like to use e.g. the 'true' or\n>> > 'include-untracked' setting as a configuration variable, then they can\n>> > use the command line option 'false' if they wish to do a 'git\n>> > checkout' even with modified files in the working tree.\n>> \n>> So in short, you are saying that \"The added code necessary to implement\n>> this feature will not help them in any way, it is just that we\n>> will make sure it does not hurt them\".\n>\n> I didn't realize they needed help.\n\nIf so, then you could have just stated that way, instead of saying\nthey have an escape hatch ;-)\n\nIt is perfectly fine to answer to \"I wonder if there are things you\ncould do?\" with \"No, I am not going to help them with this series; I\nonly make sure I do not hurt them.\"  and that is perfectly fine, as\nlong as:\n\n - you do not directly hurt them with your series; and\n\n - you do not make it harder for those who are interested in helping\n   them to build on top of your work in the future.\n\n> How and who to decide if this is a reasonable feature request to accept?\n\nAs this project primarily works on \"scratch your own itch\" basis,\nsomebody who (1) thinks that the proposed feature is worth having in\nour system and (2) is interested in working on it will pick it up.\n\nIf nobody is interested, then usually nothing happens.\n"},{"id":"238360","messageId":"000601cf4f6c$81b72740$852575c0$@jonasbang.dk","threadId":"36305","inReplyTo":"xmqq7g77vcnk.fsf@gitster.dls.corp.google.com","subject":"RE: Git feature request: Option to force Git to abort a checkout if working directory is dirty (i.e. disregarding the check for conflicts)","fromName":"Jonas Bang","fromEmail":"email@jonasbang.dk","sentAt":"2014-04-03T18:42:45Z","receivedAt":"2014-04-03T18:42:45Z","isPatch":false,"sender":{"key":"email@jonasbang.dk","avatar":null},"body":"> \"Jonas Bang\" <email@jonasbang.dk> writes:\n> \n> >> >> ...  The default behaviour would cover their use case so your\n> >> >> proposal would not hurt them, but I wonder if there are things you\n> >> >> could do to help them as well, perhaps by allowing this new\n> >> >> configuration to express something like \"local changes in these\n> >> >> paths are excempt from this new check\".\n> >> >\n> >> > Yes, those people would probably use the default 'false' behavior\n> >> > as it is already. If they however would like to use e.g. the 'true'\n> >> > or 'include-untracked' setting as a configuration variable, then\n> >> > they can use the command line option 'false' if they wish to do a\n> >> > 'git checkout' even with modified files in the working tree.\n> >>\n> >> So in short, you are saying that \"The added code necessary to\n> >> implement this feature will not help them in any way, it is just that\n> >> we will make sure it does not hurt them\".\n> >\n> > I didn't realize they needed help.\n> \n> If so, then you could have just stated that way, instead of saying they\nhave\n> an escape hatch ;-)\n> \n> It is perfectly fine to answer to \"I wonder if there are things you could\ndo?\"\n> with \"No, I am not going to help them with this series; I only make sure I\ndo\n> not hurt them.\"  and that is perfectly fine, as long as:\n> \n>  - you do not directly hurt them with your series; and\n> \n>  - you do not make it harder for those who are interested in helping\n>    them to build on top of your work in the future.\n> \n> > How and who to decide if this is a reasonable feature request to accept?\n> \n> As this project primarily works on \"scratch your own itch\" basis, somebody\n> who (1) thinks that the proposed feature is worth having in our system and\n> (2) is interested in working on it will pick it up.\n> \n> If nobody is interested, then usually nothing happens.\n\nThanks for your replies and your time.\n\nI'll cross my fingers for someone other than me and my identified group of\nusers seeing the benefit of this feature request.\n\nBr,\nJonas\n"}]}