Live data from Hacker News

Things I wish everyone knew about Git (Part II)

blog.plover.com

131–140 of 148 posts

Re: Things I wish everyone knew about Git (Part II)

#131

> A few things can be lost forever! > The dangerous commands are git-reset and git-checkout Don't forget about `git clean`, which will happily gobble up all your important ignored files (API keys, IDE configurations, etc)

That! Also, 'git reset' is only dangerous in some modes, e.g., --hard. It's a user experience nightmare to have the same command be nice in one case and dangerous in another, depending on an option parameter. It is a very useful command, so it's likely that you accidentally lose your local changes the one day when you're a bit tired, maybe. Also, 'git checkout' is used for many good things like, well, checkout. To ab…

> It should have a different command for that functionality.

It does in today's git. Rather than using `git checkout` you can migrate to using the two split commands `git switch` (switches branches, generally safe) and `git restore` (restores files, generally "dangerous"). `git restore` also has the benefit that the some of the most dangerous commands at that point have similar names: restore, revert, and reset.

It will take a while for people's `git checkout` muscle memory to be replaced with `git switch` and `git restore` (and `git restore` is still marked as "experimental" despite being stable for quite a few git releases now, though that "experimental" suggestion seems to be mostly earmarked for people thinking to use `git restore` in automated scripts than it is for human users), but the command split is a very good thing for git user experience.

(I've mostly gotten used to `git switch` at least and have stopped using `git checkout` in my own work.)

Re: Things I wish everyone knew about Git (Part II)

#132
post #48

> The dangerous commands are git-reset and git-checkout Don't forget about `git-restore` which replaces `git reset -- filename`

It's also designed to replace `git checkout branch -- filename` and related complicated `git checkout` uses. (It was added alongside `git switch` and between `git switch` and `git restore` you can entirely avoid `git checkout`.)

Re: Things I wish everyone knew about Git (Part II)

#133
post #119
post #44

I said this in another comment recently about git, but I find it odd that even after a decade of using git as a mandatory part of my professional life, I'm still learning new things. That's maybe not a good sign about the usability of git. That `@{'3 days ago'}` thing? That's incredible. Why didn't I know about that 8 years ago? Why wasn't it obvious, intuitive to me that this was possible? git is brilliant and I lov…

> I said this in another comment recently about git, but I find it odd that even after a decade of using git as a mandatory part of my professional life, I'm still learning new things. If I can humbly offer a suggestion: read the man pages. A man page read once thoroughly is much more useful than the same man page skimmed 1000 times. The syntax in question is in the rev-parse man page (`git help rev-parse`). These ar…

Agree with your point, but I am thinking now how many people understand python part and how many bash version.

Re: Things I wish everyone knew about Git (Part II)

#134
post #120

Earlier quoted context omitted.

And the corollary: since code is harder to read than write, steer clear of writing clever code where simple code would suffice, as the clever code will be much harder to read.

A second argument is that debugging is harder than writing.

s/writing/reading

Re: Things I wish everyone knew about Git (Part II)

#135
post #21

Earlier quoted context omitted.

You can't recover where your references were but all the objects (anything with a SHA1) are still there.

reflog tells you when you created/changed a label and what ID it had, so you can recover them.

Has anyone written a tool to actually does this? I want to add that to my post-rewrite hook immediately so that I can gain peace of mind I will always be able to switch to a branch where I can study the previous reality after rebasing a new one.

Re: Things I wish everyone knew about Git (Part II)

#136
I wish that instead of focusing on this API view of git that everyone seems to have run with that something akin to a plan9/fuse file server was the main interface everyone learned. I would imagine it would work like a souped up version of RepoFS:

https://github.com/AUEB-BALab/RepoFS

There is a paper to go along with the package which showed some convincing examples that much of the git tooling could just go away in favor of already existing shell commands: e.g. no need for `git grep` when `grep` will do the job.

Re: Things I wish everyone knew about Git (Part II)

#137
post #93

Earlier quoted context omitted.

What's `git gui`? $ git gui git: 'gui' is not a git command. See 'git --help'. The most similar commands are ci gc grep init lg80 pull push

Your package manager seems not to include it. `git gui` is available in the standard Windows installer for git. The package on Ubuntu 20.04 seems to not include the gui. As noted on git website, there are two GUIs that are in-tree -- native components of the project. https://git-scm.com/downloads/guis

Yeah it's packaged separately. I'm using git from Homebrew on macOS.

Re: Things I wish everyone knew about Git (Part II)

#138

Earlier quoted context omitted.

What's `git gui`? $ git gui git: 'gui' is not a git command. See 'git --help'. The most similar commands are ci gc grep init lg80 pull push

You may be able to get to it from `gitk` (it's under File > Start Git Gui). I've seen distributions that don't include the `git-gui` shortcut in PATH but do add `gitk` to somewhere in PATH.

Thanks for the tip. I was mostly curious about it as I had never used or heard of it. I have looked into gitk in the past, and also other GUIs but I find git easier to use via the CLI.

Re: Things I wish everyone knew about Git (Part II)

#139

Earlier quoted context omitted.

> Look at the comments telling you which files have been changed. And you can make this even better by adding the diff that’s being committed with verbose mode (see `git commit --help`), so that you can scroll down and easily see exactly what’s going into the commit: git commit --verbose You can make it permanent so: git config --global commit.verbose 1 I also recommend setting commit.cleanup = scissors as a related…

Thanks for this tip. One of the things I always did in larger commits was compose the commit message in a separate text editor while reviewing the diff in my terminal. This puts the diff right where I can see it, although time will tell if I enjoy scrolling up and down to switch between reading the diff and editing the commit message.

See if your editor supports a split view; in Vim, for example, you have :split or :vsplit.

Re: Things I wish everyone knew about Git (Part II)

#140
post #44

I said this in another comment recently about git, but I find it odd that even after a decade of using git as a mandatory part of my professional life, I'm still learning new things. That's maybe not a good sign about the usability of git. That `@{'3 days ago'}` thing? That's incredible. Why didn't I know about that 8 years ago? Why wasn't it obvious, intuitive to me that this was possible? git is brilliant and I lov…

git could also have just followed some standards. For instance, how am I supposed to know the syntax of "3 days ago" in general? They could have used time spans from ISO 8601 standard, so for instance simply "P3D". Or "P3Y6M4DT12H30M17S". git is powerful but it involves a higher amount of time investment than it could if it were not reinventing the wheel and taking shortcuts as much. It's easy to see that it is and w…

Are you really suggesting that more people know what "P3D" means than "3 days ago"?
Post reply on HN