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

Things I wish everyone knew about Git (Part II)

blog.plover.com

Post reply on HN
Print view View original

121–130 of 148 posts

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

#121

Post by sophacles »

wonderbore wrote: post #114
sophacles wrote: post #103

Earlier quoted context omitted.

This feels like declaring squares aren't rectangles because you can make rectangles that aren't a square.

Git is only commits. Branches and tags are references to the commits; one moves while the other one doesn’t. That’s it. Commits link to their parent(s) until the initial commit. You can visualize a “branch” as a series of commits, but the same thing can exist without calling it a branch: A -> B -> C —> Initial Is that a branch? No. How about: /refs/heads/main = A That’s a branch, and it looks exactly the same as a ta…

> You can visualize a “branch” as a series of commits, but the same thing can exist without calling it a branch

You can visualize a "square" as a rectangle with equal sides, but the same thing can exist without calling it a square.

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

#122

Post by peter_t_wilson »

praptak wrote: post #76
sophacles wrote: post #50

Earlier quoted context omitted.

Do you have an actual example of this? I've never encountered a situation where those three points are incorrect.

2. is true or untrue depending on how deeply you interpret it. A branch is named, points to a commit and under normal circumstances will track the sequence of commits made via itself (i.e. when you commit and HEAD points to branch b, b starts pointing to the child commit). So you could say it's a named sequence of commits. On the other hand you can reset the branch to any commit in the tree, even ones which aren't ev…

No post body was provided.

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

#123

Post by atq2119 »

yakubin wrote: post #99
mabbo wrote: 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 don't think the fact that you keep discovering features is a bad sign for a tool like git. It would be a bad sign if you kept discovering new footguns in the features you use (there is a fair bit of software like that). I'm 25 and a couple weeks ago I discovered a new way to use a knife to prepare a fish, even though I've been doing that all my life. I don't think knives or fish have bad UX, even though I keep disc…

All those bones in fish are pretty bad UX, compared to some of the competition.

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

#124

Post by shikoba »

joe8756438 wrote: post #115
shikoba wrote: post #75

Earlier quoted context omitted.

> write commit messages describing _why_. Could you provide a concrete example? I don't understand your point.

As in: "changed this property in the config _because_ it will extinguish all evil from planet earth" vs. "changed this property in the config". I can see _what_ somebody did well enough from the code diff itself -- reading an uninterrupted stream of messages explaining _why_ in a git log is a wonderful experience.

Thank you, I think I get your idea.

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

#125

Post by atq2119 »

themulticaster wrote: post #78
pc86 wrote: post #73

Earlier quoted context omitted.

> once you have to do anything more complicated than just commiting/merging If you really have to do more complicated things with git.. why? I mean that seriously, if your workflow necessitates anything more complicated that committing or merging with any level of regularity, it sounds like you have a bad workflow. Committing and merging should be 99.9% of your activity within git, shouldn't it?

It depends a little on how you use git. Apart from stashing (git-stash), I use interactive rebases a lot. Combined with autosquashing it's a very powerful tool to ensure a somewhat nice history. Of course, this only matters if you care about your history. It feels like there are two camps of git users: One camp squashes every MR/PR together even if it's huge, hasn't heard of git-bisect, creates plenty of merge commit…

This observation about the two camps rings very true. The sad part is that while the second camp is the original user base of Git, at least GitHub basically acts as if they don't exist and only really caters to the first camp.

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

#126

Post by [deleted] »

dale_glass wrote: post #17
stinos wrote: post #10

> But the old commit is still in there, pristine, forever. > (Git will eventually throw away lost and unused snapshots, but typically not anything you have used in the last 90 days.) Without having exlplained what a 'snapshot' is and what 'typically' means, it's pretty unclear whether the first statement is affected by the second, and if it were the first is incorrect, so I feel this clarification should be added to…

> Without having exlplained what a 'snapshot' A commit is effectively a snapshot of the repository at a given point in time. This is unlike some other revision control systems where a commit is a diff. In git, a commit contains whole files, and the diff is generated if needed. > and what 'typically' means Pretty much everything is configurable, and you can invoke the cleanup process by hand if you really want to. > i…

[deleted]

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

#127

Post by atq2119 »

rjmunro wrote: post #42
brenainn wrote: post #7

A simple one is being able to write multiple messages (subject and body), e.g. git commit -m "subject" -m "a longer body" or just running 'git commit' and using your text editor (subject first line, body after). I've worked on too many repos with messages like "fixed the thing" where a few more sentences of context would've prevented headaches when trying to debug or change something.

I always tell people the `-m` flag of `git commit` is only ever to be used in scripts. Let git open an editor and write your multi-line message there. Look at the comments telling you which files have been changed. Even better than using `git add` and `git commit` is to use `git gui` to add and commit files. The (standard) GUI is not to help beginners, it is to make you a more effective user of git. Note there are ot…

In addition to 'git gui' I would also recommend 'tig'. It allows you to stage individual lines and hunks like 'git gui' but also has a history view. With a little bit of creative key binding, this makes creating --squash commits a breeze. (It also has mouse support which needs to be enabled manually in the config.)

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

#129

Post by WorldMaker »

cassianoleal wrote: post #80
rjmunro wrote: post #42

Earlier quoted context omitted.

I always tell people the `-m` flag of `git commit` is only ever to be used in scripts. Let git open an editor and write your multi-line message there. Look at the comments telling you which files have been changed. Even better than using `git add` and `git commit` is to use `git gui` to add and commit files. The (standard) GUI is not to help beginners, it is to make you a more effective user of git. Note there are ot…

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.

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

#130

Post by WorldMaker »

afarviral wrote: post #70
brenainn wrote: post #7

A simple one is being able to write multiple messages (subject and body), e.g. git commit -m "subject" -m "a longer body" or just running 'git commit' and using your text editor (subject first line, body after). I've worked on too many repos with messages like "fixed the thing" where a few more sentences of context would've prevented headaches when trying to debug or change something.

I'd love to know how to do this in VSCode. Its infuriating that it yells at you for exeeding a 50 character limit.

The 50 character limit warning is just for the "top line" of a commit, the "commit subject line". It's general good advice to keep things like `git log --oneline` readable for people using fixed width command line terminals to view commit logs.

VS Code expands the box as you add newlines to allow you type a longer body below the "subject line". The lines in the body also give you suggested warnings to stick to 72 characters or below, which also comes from general good advice to keep things readable in fixed width command line terminals for things like `git log` and `git show `.

In some ways those warnings/general advice follow things like writing a plaintext email (or usenet posts or…) in pre-GUI days.

You don't have to follow those warnings' advice. You may not care how your commits look in fixed width command line terminals. Some GUI tools format commit messages poorly if you actually format it like an ancient email, and you can just write paragraphs and let the people with fixed width command line terminals use a pager tool that can better reflow the text for them.

The point is the advice comes from a good place, and there are git repos that are sticklers for plaintext commit formatting requirements which is why VS Code shows that advice. But you don't have to follow it.

Post reply on HN