Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Highlights from Git 2.23

github.blog

Post reply on HN
Print view View original

21–26 of 26 posts

Re: Highlights from Git 2.23

#21

Post by sametmax »

int0x80 wrote: post #19
kissgyorgy wrote: post #16

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 "creat…

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.

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

Re: Highlights from Git 2.23

#22

Post by masklinn »

wodenokoto wrote: post #17
kissgyorgy wrote: post #16

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 "creat…

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.

FWIW in their proposal `git branch -c` would be `git branch --checkout` not `git branch --create`, which is what `git branch ` 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.

Re: Highlights from Git 2.23

#23

Post by nemetroid »

kissgyorgy wrote: post #16

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 "creat…

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

Re: Highlights from Git 2.23

#24

Post by nemetroid »

sametmax wrote: post #21
int0x80 wrote: post #19

Earlier quoted context omitted.

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.

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

The reason it's a noob trap isn't that the two operations should be separate.

The issue is that "-b" (mnemonic for "branch") in no way suggests that it creates a new branch. Since checkout does so many different things, it would be reasonable to guess that -b limits the command to perform the "branch" action (i.e. switch to a branch). Git-switch doesn't have this issue.

Re: Highlights from Git 2.23

#25

Post by chongli »

yjftsjthsd-h wrote: post #13
dfabulich wrote: post #4

Earlier quoted context omitted.

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 r…

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)

Mercurial generally is more obsessed with never losing anything

Which is silly, because people often commit sensitive data such as private keys or customer's personal information. Sometimes you really do need to delete a commit (or worse, a file that lives through a long history of commits).

Re: Highlights from Git 2.23

#26

Post by Ayesh »

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.

Post reply on HN