Highlights from Git 2.23

https://github.blog/2019-08-16-highlights-from-git-2-23/

168 24 7 years ago

nemetroid3• 7 years ago

I'm wary about git restore --staged. It seems backwards to have a destructive (worktree-modifying) command become non-destructive by adding a flag. To me, this appears more footgun-prone than git reset, which defaults to non-destructive behaviour and requires the ominous --hard flag in order to become destructive.

So I will probably avoid both git restore --staged and git reset --hard (and suggest to others to do the same). I hope git status will keep the hint to use git reset to unstage, even after git-restore becomes stable.

dfabulich• 7 years ago

Yeah, it's mirroring the behavior of "git checkout -- myfile" which also does destructive changes without warning.

These new commands were hatched in response to a blog post from a couple of years ago pointing out the confusion. https://redfin.engineering/two-commits-that-wrecked-the-user...

A good conversation on HN followed. https://news.ycombinator.com/item?id=14712269

I've long wished git checkout (and now, git restore) would save the contents of blown-away worktree files somewhere (e.g. a throwaway stash) so that they could be retrieved from the reflog or something.

In my mind's eye, the command would be something like "git trash" and it would throw your changes into a trash can, where you could fetch them back out again later, until the GC erased them in ~30 days or so.

justsubmit• 7 years ago

I've long wished git checkout (and now, git restore) would save the contents of blown-away worktree files somewhere (e.g. a throwaway stash) so that they could be retrieved from the reflog or something.

Magit can do this. See https://magit.vc/manual/magit.html#Wip-Modes

ryanianian• 7 years ago

have the contents of blown-away worktree files somewhere

This would be an amazing feature for nearly all git commands that affect the worktree. Many times I've done `git checkout ./src` to blow away "unrelated" files forgetting that the file I was just working on was in that directory. Whenever I teach git to a new-hire I always talk about wanting revision-control for revision-control.

gregmac• 7 years ago

I agree, and it would be great if git adopted the general philosophy that it would never do a destructive change without stashing it in "trash" first. This could even go as far as adding a "git undo" command.

yjftsjthsd-h• 7 years ago

As a comparison, mercurial seems to do this; if you revert an uncommitted change, it makes a "*.orig" file. (Mercurial generally is more obsessed with never losing anything than git, such as its refusal to delete commits)

saagarjha• 7 years ago

It's nice to hear that there appears to be progress being made in making git's tooling nicer and more consistent. Git's model itself is pretty simple, but the command line tools for working with it aren't and I feel that this fuels most of the "Git is hard" complaints.

tomasyany• 7 years ago

On the one hand I'm happy on the new "switch" and "restore" commands. On the other hand I wonder if they truly add any value other than the semantic distinction of functions otherwise present in "checkout".

I tend to prefer smaller vocabularies tools: less to remember if you know what you are doing.

Smaug123• 7 years ago

I would argue that it's not really increasing the vocabulary. The fact that one word has (say) seven meanings doesn't mean the vocabulary you must learn is one word. It's still seven words, which happen to be spelt and pronounced the same way.

kissgyorgy• 7 years ago

This is still far from ideal. "git switch" and "git checkout" should not be able to create a new branch. It clearly should be the "git branch" subcommand's responsibility, because "You want to do something with a branch". It would be two commands to create and checkout a new branch, but less confusion. You can use your git alias anyway. But a shortcut for "git branch -c" would be better if you want to keep the "create and switch" shortcut IMO.

wodenokoto• 7 years ago

But I want to switch to my new branch. One of these commands will have to do double duty.

Either switch/checkout will create or branch will switch.

I don’t see why choosing one for double duty is inherently worse than the other.

But I do consider your proposal of `git branch —create` as a poor command for create and switch branch.

masklinn• 7 years ago

FWIW in their proposal `git branch -c` would be `git branch --checkout` not `git branch --create`, which is what `git branch <name>` does.

The `git checkout -b` and `git switch -c` docs specifically note that they're shortcuts for going a git branch then a git checkout/switch.

mewse• 7 years ago

I'm sure it's not what they were intending, but 'switch' used to be a pretty common term for a light, flexible branch.

And all of git's branches are pretty light and flexible, at least compared against the branches of the previous generations of version control systems..

But yeah. That's definitely not what they were intending.

int0x80• 7 years ago

I disagree. I found git checkout -b very convenient an intuitive way to say "create and checkout this branch".

For git branch -c one could say that the "branch" command should not do checkout-business.

sametmax• 7 years ago

I should be a separate cmd. It's such a common operation, and it's a huge noob trap.

nemetroid3• 7 years ago

It clearly should be the "git branch" subcommand's responsibility, because "You want to do something with a branch".

The git switch subcommand's description is "Switch branches", so clearly it, too, is intended to handle a subset of the cases where you want to do something with a branch. Switching to a branch that doesn't already exist is a special case of git-switch's main purpose, and you have to be explicit about it. Further, when you create a new branch, you just about always want to switch to it (because while you can do some things with a branch that's not checked out, most commands are designed to work on the currently-checked-out branch), so what's the point in forcibly separating the commands?

But a shortcut for "git branch -c" would be better if you want to keep the "create and switch" shortcut IMO.

Strongly disagree. In Git, creating a branch is a much smaller action than changing the state of your checkout. It makes much more sense to have the branch creation as the side effect than the other way around.

mhd• 7 years ago

I really need some kind of "modern git" tutorial. A lot of what we're doing day to day stems from the earlier days of the software (and SO posts from that time), and I bet there's plenty of new options that would make something easier or even enable different workflows. I just recently learned about "git worktree", for example.

Ayesh• 7 years ago

Similar to GUI apps that work on top of git binary, does anyone know a user friendlier CLI app?

It can have new commands:

- `gitlite create` vs `git init`

- `gitlite branch create feature-dom` vs `git checkout -b feature-dom`

- `gitlite time-travel cfae736` vs `git checkout cfae736`.

- `gitlite undo cfae736` vs `git reset cfae736 --hard`

- gitlite release create v4.2` vs `git tag v4.2`.

Each command will call the translated `git` command, and perhaps improve upon the output from the command.

Highlights from Git 2.23

Related Stories