"Jonas Bang" <email@xxxxxxxxxxxx> writes: > Hi Git developers, > > This is my first Git feature request, I hope it won’t get me hanged on the > gallows ;o) > > *Git feature request:* > Add an option to Git config to configure the criteria for when a "git > checkout" should abort. > > *Name proposal and options:* > checkout.clean false <default> > checkout.clean true A configuration variable without command line override will make the system unusable. When thinking about a new feature, please make it a habit to first add a command line option and then if that option turns out to be useful in the real world (not in the imaginary world in which you had such a feature, where even you haven't lived in yet), then think about also adding configuration variables to control the default. Also, a useful definition of "clean"-ness may have to change over time as we gain experience with the feature. And also as a user personally gains experience with using Git. It is somewhat implausible that a boolean true/false may remain sufficient. > *False behavior:* What is "false"? Ah, when the configuration is set to "false", which will be the default? > As is: > When doing a checkout then Git will check if your working directory is > dirty, and if so check if the checkout will result in any conflicts, and if > so abort the checkout with a message: > > $ git checkout some_branch > error: Your local changes to the following files would be overwritten by > checkout: > some_file > Please, commit your changes or stash them before you can switch branches. > Aborting > > If no conflicts then: > > $ git checkout some_branch > M some_file > M some_other_file > Switched to branch 'some_branch' > > I.e. it will only abort if there are conflicts. Sensible. This is the behaviour that is very often depended upon by people who use Git with multiple branches. Are you thinking about changing it in any way when the new configuration is set to "false", or is the above just a summary of what happens in the current system? > *True behavior:* > When doing a checkout then Git will check if your working directory is dirty > (checking for both modified and added untracked files), and if so abort the > checkout with a message: > > $ git checkout some_branch > error: Your working directory is not clean. > Please, commit your changes or stash them before you can switch branches. > Aborting > > I.e. it will abort if working directory is dirty (checking for both modified > and added untracked files). > I.e. you can only do checkout if you get "nothing to commit, working > directory clean" when running "git status" (ignoring ignored files though). The above two say very different things. For some people, having many throw away untracked files is a norm that they do not consider it is even worth their time to list them in .gitignore and they do not want to be reminded in "git status" output, and the latter definition of "checkout.clean=true will kill checkout when status says there are some things that could be committed" would suit them, while the former definition "checkout.clean=true will kill checkout when there is any untracked files" would be totally useless. So I can understand the latter, but I do not see how the former could be a useful addition. For some people it is also a norm to keep files that have been modified from HEAD and/or index without committing for a long time (e.g. earlier, Linus said that the version in Makefile is updated and kept modified in the working tree long before a new release is committed with that change). The default behaviour would cover their use case so your proposal would not hurt them, but I wonder if there are things you could do to help them as well, perhaps by allowing this new configuration to express something like "local changes in these paths are except from this new check". I dunno. -- 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