[Dropping "Jonathan Gilbert <logic@xxxxxxxxxx>" from the To: list because my mail server says "Domain not found". Putting the GGG address in To: instead.] On 02/11/19 11:41PM, Jonathan Gilbert wrote: > On Sat, Nov 2, 2019, 8:12 PM Pratyush Yadav, <me@xxxxxxxxxxxxxxxxx> wrote: > > On 30/10/19 12:16PM, Jonathan Gilbert wrote: > > > It's less about overloading the 'revert' operation as overloading the > > > UI action which is currently called "Revert". I think it would be a > > > worse experience to have to activate a different option to remove > > > unwanted files as to remove unwanted changes. Maybe the UI option > > > could be renamed "Revert & Clean" or something? > > > > I disagree. There are valid workflows where you want to remove all > > changes to tracked files, but leave untracked ones alone. As an example, > > say you wrote a small script to fix some textual things, like your > > variable re-name patch. Now you run a diff before you commit those > > changes just to be sure, and notice that your script was overzealous and > > made some changes it shouldn't have. So, you clean up all tracked files, > > and give your script a fresh start. Here, you don't want to delete your > > script. > > > > And in the other direction, say you want to delete all untracked files > > but have unstaged changes in your tracked files. Combining "Revert" and > > "Clean" does not give you an option to only delete untracked files. So > > you now either have to stash your changes, or run `git clean` from the > > command line. > > But, since this is in this GUI interface, you can clearly see which > are which and select only the files you want to affect. If you have so > many files that you have to select indiscriminately, then the > command-line is probably a better choice anyway. In any case, my > proposed change prompts for each part of the change, so you _can_ just > select everything, press ^J, and then say "Yes" to only one of the > prompts. Ah yes! Makes sense. I got too tunnel-visioned when thinking about this, and lost context. Sorry. > > > As a side note, `git clean untracked-file` won't do anything with a > > > default configuration, you have to explicitly `-f` it. Not sure if > > > that's relevant, but it does feel like a higher barrier to entry than > > > `git revert`. > > > > `git revert` is different from our "Revert", though I admit the naming > > is quite confusing. > [..] > > So I don't think you should, or _can_, use `git revert` for what you > > want to do. And so, I don't see why it is being factored in with this > > discussion. Am I missing something? > > You are entirely correct, this was just a massive brain fart. Every > time I wrote `git revert` in my head I was actually thinking of > exactly what Git Gui does, reverting working copy changes by checking > out the file. I should have written "reverting using `git checkout`". > My apologies! > > In my defence, I have over the past few days found myself digging into > code hosted in SVN repositories, and `svn revert` does exactly what > `git checkout` does to an unstaged modified file. :-) I have never used svn, but I can imagine now confusing that might be ;) -- Regards, Pratyush Yadav
