4 ms·

Even after years of Git usage, `git reset --soft -- file`, `git reset --mixed -- file`, BUT `git checkout file` instead of `git reset --hard -- file` is ugly an

Even after years of Git usage, `git reset --soft -- file`, `git reset --mixed -- file`, BUT `git checkout file` instead of `git reset --hard -- file` is ugly and symptomatic of Git's lackluster UX.

bicolao 7y ago
This particular pattern should be fixed in a future git (hopefully). There's a new command that supports all these git restore --staged file # reset the index from HEAD git restore --worktree file # reset the worktree from the index git restore --source=HEAD --staged --worktree file # reset both the index and worktree from HEAD Still in development [1] so if you think something can be improved, I'd love to hear it. [1] https://github.com/git/git/blob/pu/Documentation/git-restore.txt https://github.com/git/git/blob/pu/Documentation/git-restore...
- mleonard 7y ago
  Hi. Interesting to know thanks! Would you mind giving the current commands to achieve the three things you just listed? That way I learn the future restore command along with the current approach and you description. T
  - bicolao 7y ago
    "git restore --staged" should be the same as "git reset -- file" (--mixed, --soft and --hard cannot be used with individual files). "git restore --worktree" is the same as "git checkout -- file". "git restore --source..." should be the same as "git reset --hard -- file" if --hard was made to work with individual files. Though "git restore" should make it clear (or clearer) to the user what they want to restore without resorting to more mysterious options like --hard/--soft. So if that's not obvious from my examples, I think I've failed :)
    - mleonard 7y ago
      Thanks really very helpful! When you hoping to have git restore in the official git release?
      - bicolao 7y ago
        > When you hoping to have git restore in the official git release? If things go well, maybe v2.23.0, unless we find serious UX flaws and scrape the whole thing.
- jnbiche 7y ago
  imho the natural default for any of these types of commands should be to reset the worktree, never the index. In my experience, people almost always want to review a file before they stage it, even if it's coming from HEAD. So `git restore file` should reset the worktree, if you allow an unflagged version of that command.
  - erik_seaberg 7y ago
    I can't test the index. If the index and workspace are different, the index is wrong. I would like an option to make the index go away (or else become a buildable filesystem dir), and stash whatever I don't want to commit yet.
    - bicolao 7y ago
      > I would like an option to make the index go away By Git design, you will have to face the index when you have merge conflicts. I don't know how to avoid that (and now is not the time for fundamentally change how conflict resolution is done). But yeah, the other times, I think you can just live just fine without knowing or touching the index. > I can't test the index. I'm not trying to convince you to use the index. But to me, the way I test the index is commit it. Then I could use "rebase -i" to revisit the old commits (i.e. the index content) and test or make more fixes if needed.
  - bicolao 7y ago
    "git restore file" does reset worktree. Sorry I didn't mention it. If neither --worktree or --staged is present, the default target is the worktree. It still restores worktree from the index though. But if your workflow ignores the index, then index should be the same as HEAD. "restoring from index" and "restoring from HEAD" will mean the same thing.
- fouronnes3 7y ago
  Two things I don't like in your examples: First, the default source changes depending on the target. In my opinion it would be more intuitive and simple if the default source is always HEAD. The documentation for --source in your link probably makes sense for a git developer, but not at all for a user. (Especially the part about its default value if absent). Second, rename "--staged" to "--index". So in summary, to update your examples, how about: git restore --index file # reset the index from HEAD git restore --worktree file # reset the worktree from HEAD git restore --worktree --source=index file # reset the worktree from the index git restore --index --worktree file # reset both the index and worktree from HEAD git restore file # reset the worktree from HEAD
  - bicolao 7y ago
    Since this is posted on Git mailing list, the reply is here https://public-inbox.org/git/20190515103031.GA29149@ash/ https://public-inbox.org/git/20190515103031.GA29149@ash/
bloopernova 7y ago
Has there been any efforts to add a wrapper around git's commands to make a more friendly command line UI? I've tried maybe 3 different GUIs for git and none of them really seemed to help that much. However my usage of git is pretty basic, with branches and tags being about as complex as I get.
- Matumio 7y ago
  There have been many attempts. I liked easygit a lot (seems to be unmaintained now: https://people.gnome.org/~newren/eg/documentation/ https://people.gnome.org/~newren/eg/documentation/). It had really nice docu. It took me a while to memorize all the native git replacements for `eg revert`. Gitless looks like it could fit your needs (https://gitless.com/ https://gitless.com/). The problem is, in the end, you'll still need to know the original git commands with all their quirks in addition to the easier commands, because that's what you'll find on stackoverflow or when asking colleagues or inside of error messages. And those command names will either clash with the names used in plain git or are different partially-overlapping concepts (`git reset` is the worst offender here). So eventually you'll need to memorize twice as many things.

Even after years of Git usage, `git reset --soft -- file`, `git reset --mixed -- file`, BUT `git checkout file` instead of `git reset --hard -- file` is ugly and symptomatic of Git's lackluster UX.

bicolao 7y ago

This particular pattern should be fixed in a future git (hopefully). There's a new command that supports all these git restore --staged file # reset the index from HEAD git restore --worktree file # reset the worktree from the index git restore --source=HEAD --staged --worktree file # reset both the index and worktree from HEAD Still in development [1] so if you think something can be improved, I'd love to hear it. [1] https://github.com/git/git/blob/pu/Documentation/git-restore.txt https://github.com/git/git/blob/pu/Documentation/git-restore...

mleonard 7y ago
Hi. Interesting to know thanks! Would you mind giving the current commands to achieve the three things you just listed? That way I learn the future restore command along with the current approach and you description. T
- bicolao 7y ago
  "git restore --staged" should be the same as "git reset -- file" (--mixed, --soft and --hard cannot be used with individual files). "git restore --worktree" is the same as "git checkout -- file". "git restore --source..." should be the same as "git reset --hard -- file" if --hard was made to work with individual files. Though "git restore" should make it clear (or clearer) to the user what they want to restore without resorting to more mysterious options like --hard/--soft. So if that's not obvious from my examples, I think I've failed :)
  - mleonard 7y ago
    Thanks really very helpful! When you hoping to have git restore in the official git release?
    - bicolao 7y ago
      > When you hoping to have git restore in the official git release? If things go well, maybe v2.23.0, unless we find serious UX flaws and scrape the whole thing.
jnbiche 7y ago
imho the natural default for any of these types of commands should be to reset the worktree, never the index. In my experience, people almost always want to review a file before they stage it, even if it's coming from HEAD. So `git restore file` should reset the worktree, if you allow an unflagged version of that command.
- erik_seaberg 7y ago
  I can't test the index. If the index and workspace are different, the index is wrong. I would like an option to make the index go away (or else become a buildable filesystem dir), and stash whatever I don't want to commit yet.
  - bicolao 7y ago
    > I would like an option to make the index go away By Git design, you will have to face the index when you have merge conflicts. I don't know how to avoid that (and now is not the time for fundamentally change how conflict resolution is done). But yeah, the other times, I think you can just live just fine without knowing or touching the index. > I can't test the index. I'm not trying to convince you to use the index. But to me, the way I test the index is commit it. Then I could use "rebase -i" to revisit the old commits (i.e. the index content) and test or make more fixes if needed.
- bicolao 7y ago
  "git restore file" does reset worktree. Sorry I didn't mention it. If neither --worktree or --staged is present, the default target is the worktree. It still restores worktree from the index though. But if your workflow ignores the index, then index should be the same as HEAD. "restoring from index" and "restoring from HEAD" will mean the same thing.
fouronnes3 7y ago
Two things I don't like in your examples: First, the default source changes depending on the target. In my opinion it would be more intuitive and simple if the default source is always HEAD. The documentation for --source in your link probably makes sense for a git developer, but not at all for a user. (Especially the part about its default value if absent). Second, rename "--staged" to "--index". So in summary, to update your examples, how about: git restore --index file # reset the index from HEAD git restore --worktree file # reset the worktree from HEAD git restore --worktree --source=index file # reset the worktree from the index git restore --index --worktree file # reset both the index and worktree from HEAD git restore file # reset the worktree from HEAD
- bicolao 7y ago
  Since this is posted on Git mailing list, the reply is here https://public-inbox.org/git/20190515103031.GA29149@ash/ https://public-inbox.org/git/20190515103031.GA29149@ash/

bloopernova 7y ago

Has there been any efforts to add a wrapper around git's commands to make a more friendly command line UI? I've tried maybe 3 different GUIs for git and none of them really seemed to help that much. However my usage of git is pretty basic, with branches and tags being about as complex as I get.

Matumio 7y ago
There have been many attempts. I liked easygit a lot (seems to be unmaintained now: https://people.gnome.org/~newren/eg/documentation/ https://people.gnome.org/~newren/eg/documentation/). It had really nice docu. It took me a while to memorize all the native git replacements for `eg revert`. Gitless looks like it could fit your needs (https://gitless.com/ https://gitless.com/). The problem is, in the end, you'll still need to know the original git commands with all their quirks in addition to the easier commands, because that's what you'll find on stackoverflow or when asking colleagues or inside of error messages. And those command names will either clash with the names used in plain git or are different partially-overlapping concepts (`git reset` is the worst offender here). So eventually you'll need to memorize twice as many things.