Re: [PATCH 0/2] git-gui: revert untracked files by deleting them

[Pratyush Yadav <me@yadavpratyush.com>]

[Dropping "Jonathan Gilbert <logic@deltaq.org>" 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@yadavpratyush.com> 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