On Sat, Nov 2, 2019, 8:12 PM Pratyush Yadav, [off-list ref] wrote:

On 30/10/19 12:16PM, Jonathan Gilbert wrote:

quoted

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.

quoted

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. :-)

Jonathan Gilbert

On Sat, Nov 2, 2019 at 8:12 PM Pratyush Yadav [off-list ref] wrote:

On 30/10/19 12:16PM, Jonathan Gilbert wrote:

quoted

On Wed, Oct 30, 2019 at 4:09 AM Bert Wesarg
bert.wesarg-at-googlemail.com |GitHub Public/Example Allow|
[off-list ref] wrote:

quoted

in Git speak, that operation is called 'clean' (see 'git clean') why
should we overload the 'revert' operation here?

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.

quoted

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. `git revert` creates a new commit that "reverses"
the changes made in an earlier commit(s). The important point to note
here is that `git revert` is used when you publish some commits, and
then realise later they had some bugs. Now you can't just drop those
commits because that would re-write the history, and it would change all
the commit hashes since that commit. So, you use `git revert` to create
a new commit that _textually_ reverses those changes. The buggy commit
still exists in the tree, but its changes don't.

In contrast, git-gui's "Revert" works on unstaged changes. It does not
create a new commit. In fact, our revert does something similar to `git
checkout -- <file>` (it uses `git checkout-index` to be precise).

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?

--
Regards,
Pratyush Yadav