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

61–70 of 148 posts

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

#61

Post by badpun »

sophacles wrote: post #50
eulenteufel wrote: post #25

Earlier quoted context omitted.

The quote is kinda wrong in that point 1 and 2 are mixed up. Branches are just pointers to commits. Commits contain a reference to their history. It's only kind of incorrect because in praxis branches are used to refer to a history (a sequence of commits). But it's also misleading once you have to do anything more complicated than just commiting/merging. When I started out using git I was working with the same assump…

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

Git branch is actually very similar to git tag[1]. For example, there are commands to point branch to completely different commit in different section of the commit graph, just like you can do it with tags.

[1] The main difference perhaps is that, if you create a new commit, the branch pointer will actually be moved to point to that latest commit (while tag stays fixed).

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

#62

Post by kleinsch »

sophacles wrote: post #50
eulenteufel wrote: post #25

Earlier quoted context omitted.

The quote is kinda wrong in that point 1 and 2 are mixed up. Branches are just pointers to commits. Commits contain a reference to their history. It's only kind of incorrect because in praxis branches are used to refer to a history (a sequence of commits). But it's also misleading once you have to do anything more complicated than just commiting/merging. When I started out using git I was working with the same assump…

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

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.

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

#63

Post by joe8756438 »

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.

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

#64

Post by bloopernova »

donatj wrote: post #4
mg wrote: post #2

"It is really hard to lose stuff" Indeed. This also means that garbage keeps piling up in git repos. This is how I make sure, I do lose stuff eventually: https://github.com/no-gravity/git-gc-all-repos.sh A script that goes through all my repos and performs garbage collection.

Disk space is cheaper than lost data.

True, but wouldn't the reduction in size make it a little quicker to transfer over slow networks?

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

#65

Post by stackbutterflow »

NKCSS wrote: post #54
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…

GIT is just the new Regex. Everybody uses it, most have no clue how it works and just copy/pasts stuff from other places/repeats the same little trick

I find regex easier to write than to read.

I never copy them from stackoverflow because I'm worried it does some weird magic that I don't want. Instead I build them against one or more examples.

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

#66

Post by ExtremisAndy »

stackbutterflow wrote: post #65
NKCSS wrote: post #54

Earlier quoted context omitted.

GIT is just the new Regex. Everybody uses it, most have no clue how it works and just copy/pasts stuff from other places/repeats the same little trick

I find regex easier to write than to read. I never copy them from stackoverflow because I'm worried it does some weird magic that I don't want. Instead I build them against one or more examples.

Totally agree! But oddly enough, I have this problem with all code/languages… I always write code much more easily than I read it. I can write fairly complex applications just by following the logic of what the application must do in my brain (but with ZERO cleverness). But give me the source code of even the simplest Unix command and I’ll struggle to understand the purpose of every #define, the variable naming scheme, etc., etc. I’m sure this is telling me something interesting about how my brain works but I’m not sure what!

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

#67

Post by pif »

stackbutterflow wrote: post #65
NKCSS wrote: post #54

Earlier quoted context omitted.

GIT is just the new Regex. Everybody uses it, most have no clue how it works and just copy/pasts stuff from other places/repeats the same little trick

I find regex easier to write than to read. I never copy them from stackoverflow because I'm worried it does some weird magic that I don't want. Instead I build them against one or more examples.

> 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.joelonsoftware.com/2000/04/06/things-you-should-...

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

#68

Post by pif »

ExtremisAndy wrote: post #66
stackbutterflow wrote: post #65

Earlier quoted context omitted.

I find regex easier to write than to read. I never copy them from stackoverflow because I'm worried it does some weird magic that I don't want. Instead I build them against one or more examples.

Totally agree! But oddly enough, I have this problem with all code/languages… I always write code much more easily than I read it. I can write fairly complex applications just by following the logic of what the application must do in my brain (but with ZERO cleverness). But give me the source code of even the simplest Unix command and I’ll struggle to understand the purpose of every #define, the variable naming schem…

> I’m sure this is telling me something interesting about how my brain works

See my sibling comment. Joel says you are just normal.

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

#69

Post by stackbutterflow »

pif wrote: post #67
stackbutterflow wrote: post #65

Earlier quoted context omitted.

I find regex easier to write than to read. I never copy them from stackoverflow because I'm worried it does some weird magic that I don't want. Instead I build them against one or more examples.

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

I say that because there's a meme that nobody writes regex and that everyone copy-paste it from stackoverflow.

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

#70

Post by afarviral »

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