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

11–20 of 26 posts

Re: Highlights from Git 2.23

#11

Post by ReidZB »

codetrotter wrote: post #9
ryanianian wrote: post #6

Earlier quoted context omitted.

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

I think people trip on these potential foot guns in part because a lot of git commands are long and annoying to type, so you end up working more based on your mental model of the state of the working copy and less based on the actual state of it. I am not so fond of analogies but I would like to offer up an analogy here anyway. I think for a lot of people, the way that they are using git is akin to utilizing a sharp…

I do something similar, though I use git's built-in aliasing so that I keep everything namespaced under "git". Mine are, for example, "git st" (status), "git ci" (commit), "git co" (checkout), "git dfc" (diff --cached), etc.

That said, my best advice for folks new to git, or folks who find themselves doing destructive actions often, is to embrace WIP commits. I "checkpoint" work somewhat frequently with "git add -A; git ci -m wip". They can be cleaned up later with soft resets, rebases, or similar. Once a commit is created, it's in the reflog, and it's quite rare to lose that set of work, even if a rebase or reset goes "wrong".

Re: Highlights from Git 2.23

#12

Post by _fbpt »

codetrotter wrote: post #9
ryanianian wrote: post #6

Earlier quoted context omitted.

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

I think people trip on these potential foot guns in part because a lot of git commands are long and annoying to type, so you end up working more based on your mental model of the state of the working copy and less based on the actual state of it. I am not so fond of analogies but I would like to offer up an analogy here anyway. I think for a lot of people, the way that they are using git is akin to utilizing a sharp…

I use prezto's 2-3 letter aliases. But that doesn't help when I run `git reset --hard` (or gwR) and erase changes I don't know exist.

I wish I could move HEAD to a different commit (git reset), and apply (new HEAD - old HEAD) to my working directory (--hard), but abort if working directory != old HEAD.

In fact, this sounds like `git reset --keep`, but unfortunately prezto doesn't have an alias for that.

I don't like prezto's git-reset aliases. gwr is "move HEAD", gir is "move HEAD and reset index", and gwR is "move head, reset index, and reset working directory". I wish gwr was renamed to ghr, and maybe gar (git apply reset) for --keep.

Re: Highlights from Git 2.23

#13

Post by yjftsjthsd-h »

dfabulich wrote: post #4
nemetroid wrote: post #2

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…

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)

Re: Highlights from Git 2.23

#15

Post by Smaug123 »

tomasyany wrote: post #10

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.

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.

Re: Highlights from Git 2.23

#16

Post by kissgyorgy »

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.

Re: Highlights from Git 2.23

#17

Post by wodenokoto »

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.

Re: Highlights from Git 2.23

#18

Post by mewse »

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

Re: Highlights from Git 2.23

#19

Post by int0x80 »

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.

Re: Highlights from Git 2.23

#20

Post by mhd »

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.
Post reply on HN