Things I wish everyone knew about Git (Part II) • Hacker News Board

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

#111

Post by mabbo » Wed, Jul 20, 2022, 4:31 PM UTC

snarfy wrote: post #95

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…

It's vindicating to see the general response in this thread vs threads about git a decade ago, where everybody defended git and decreed all of us simpletons just don't understand it enough. Oh we do, and we understand how most of it is a flaming trash pile.

Oh no, I think it's a beautiful piece of art. With sharp edges that keep cutting my hands as I try to handle it.

I love git. I just wish it was more usable.

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

#112

Post by Vendan » Wed, Jul 20, 2022, 4:34 PM UTC

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.

do `export EDITOR="code -w"`

`git commit` will then open up the commit message as a temp file in vscode, you can write your message then save and close (cmd-s, cmd-w on mac, probably ctrl-s ctrl-w on windows and linux?) and git commit will continue on. `code -w ` is telling vscode "open this file for editing and don't return until the user closes it"

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

#113

Post by js2 » Wed, Jul 20, 2022, 4:36 PM UTC

> What if you can't find it?

Funny enough, I just wrote "git-lost-and-found" last week because I'd added a new file (`git add`) but before I created a commit I did a `git reset --hard` which deleted the file. It wouldn't have been in the reflog since there was never a commit created. But I knew it would be under .git/objects until the next time a `git gc` runs, so the trick was to just take a look at a few recent blob objects till I found what I was looking for:

https://gist.github.com/jaysoffian/f42f4b1806f65158b40408814...

Put that in your PATH as `git-lost-and-found` and then you can call it as `git lost-and-found` from inside any repo.

Edit: oh, MJD beat me to it by 6 years but I hadn't seen this when I wrote the gist above:

https://blog.plover.com/prog/git-reset-disaster.html

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

#114

Post by wonderbore » Wed, Jul 20, 2022, 4:41 PM UTC

sophacles wrote: post #103

kleinsch wrote: post #62

Earlier quoted context omitted.

If you're in a detached head state and create a new commit, you have a commit that isn't on a branch. The commit still has a parent, so it's not the branch that's tracking the sequence, it's the commit. Branches are just pointers that get updated as you add commits.

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 tag:

    /refs/tags/v1 = A

Neither a branch or a tag is “a series of commits” even if you think it does.

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

#115

Post by joe8756438 » Wed, Jul 20, 2022, 4:41 PM UTC

shikoba wrote: post #75

joe8756438 wrote: post #63

Learning git is not easy. There is one thing that will almost guarantee no work is ever lost: commit. if something is commit, even if it’s not pushed it can be retrieved. One other thing that has nothing to do with how it works, but makes all the difference in usability: write commit messages describing _why_. To learn git is to use git, reading about it has not helped me.

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

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

#116

Post by ajanuary » Wed, Jul 20, 2022, 4:42 PM UTC

layer8 wrote: post #105

stu2b50 wrote: post #98

Earlier quoted context omitted.

> But they are not immutable in the sense that you couldn’t change the history of e.g. a branch. That sentence doesn't make sense, though. Assuming from context that `they` = commits, "[commits] are not immutable in the sense you couldn't change the history of a branch" Branches and tags are mutable - they're just pointers to commits - but that doesn't change whether or not commits are immutable. When you "change" th…

You are defining commits to be different by the mere fact that their contents (and history) is different. With that definition, how could a commit ever be mutable? Only by an indirection were the VCS allows the referencee to change. And that is exactly what Git allows with branches. When rewriting history, the fact that the “new” commits are new is a tautology if you define commits to be different when their contents…

> With that definition, how could a commit ever be mutable?

It can’t. Hence commits in git are immutable. It’s a function of gits design that commits are immutable.

I could make my own VCS that doesn’t use content derived addressing, but instead uses UUIDs for commit IDs, and let you issue commands that changes the contents of that commit. In that system, commits are mutable. But that isn’t git.

> The expectation of immutable commits would be that history never gets lost and cannot be changed

No it isn’t. The expectation of immutable commits is that a commit object can’t be changed. And in git that is true, at least it can’t be changed without also changing its identity, which is functionally the same.

As has been explained, you can make an alternative parallel history, and you can switch to using that new parallel history as you’re new truth, but you haven’t changed the original commits. They remain un-mutated, because they are immutable.

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

#117

Post by [deleted] » Wed, Jul 20, 2022, 4:48 PM UTC

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…

[deleted]

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

#118

Post by everybodyknows » Wed, Jul 20, 2022, 4:49 PM UTC

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

Alternative:

  git-log --graph --all --stat

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

#119

Post by js2 » Wed, Jul 20, 2022, 4:53 PM UTC

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 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 are tools we use every day. Look, I'm the first person to throw out those furniture assembly instructions and dive right in. But the truth is, we'd all be better off reading the documentation for our tools.

The git man pages are far from the best, but they contain tons of useful information.

And it's not just with git that developers seem allergic to reading documentation. I noticed a colleague the other day doing this from a shell script:

    BRANCH=$(python -c 'import os; print(os.environ["BRANCH"].split("/")[1])')

I asked what they were trying to do. They wanted to strip "origin/" from the front of BRANCH. I showed them you can do that directly in the shell:

    BRANCH="${BRANCH#origin/}"  # strip origin/ from front

Or:

    BRANCH="${BRANCH#*/}"       # strip */ from front

They'd never read the bash man page. Had no idea the shell could do this. So I pointed them at https://www.gnu.org/software/bash/manual/html_node/Shell-Par...

I think we'd all be better developers if we RTFM, at least for the tools/languages we use every day. You simply don't know what you don't know. This way you at least know a little more what you don't know. :-)

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

#120

Post by roeles » Wed, Jul 20, 2022, 4:56 PM UTC

Tijdreiziger wrote: post #97

pif wrote: post #67

Earlier quoted context omitted.

> I find regex easier to write than to read. There is nothing new under the sun. Joel, 22 years ago: There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. [...] The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming: It’s harder to read code than to write it. https://www.joel…

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.