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

Things I wish everyone knew about Git (Part I)

blog.plover.com

Post reply on HN
Print view View original

71–80 of 200 posts

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

#71

Post by stu2b50 »

chx wrote: post #30

> When I first used Git it drove me almost to tears of rage and frustration. But I did get it under control. I don't love Git, but I use it every day, by choice, and I use it effectively. Yes. For me the rescue was Charles Duan's git tutorial: Understanding Git conceptually. https://www.sbf5.com/~cduan/technical/git/ > you can only really use Git if you understand how Git works. Merely memorizing which commands you s…

> I disagree.

Anything that ends up in a commit should be recoverable (on the same local git repository, that is), no? The main things that can forever clobber your work afaik is git checkout -- , which will perhaps a little unintuitively just clobber over whatever is not committed.

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

#72

Post by cryptonector »

HWR_14 wrote: post #67
skrebbel wrote: post #7

Fwiw a branch isn't a named sequence of commits, it's just a label that points to a single commit. It's exactly the same as a tag except that git moves it when you make a new commit. Mercurial calls these bookmarks which IMO is a much better name because it works exactly like real bookmarks (in books, not browsers). A git branch feels a little bit like a branch of a tree because each commit points to their parent. Th…

Am I the only one sad that Git beat out Mercurial as the industry standard? And am I also the only one who still knows how to do things in Mercurial but not how to take the corresponding action in Git? I mean, they're things I haven't had a reason to do in years, but it has some psychological cost to feel like I'm using a system I'm worse at.

I'm not sad.

Mercurial is opinionated. It's had to adopt the Git way slowly, grudgingly.

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

#73

Post by gorgoiler »

Thing I wish I’d learned sooner about git: it was designed to make patches a first class entity. Trees of objects are indeed the fundamentals, but it’s quite possible to detach a commit by formatting it into a patch (“git format-patch”) and sharing it outside of the context of a repo. No ssh required: email it, fax it, print it out and mail it — all the metadata is retained allowing the commit to be reconstituted as if it were git pushed or pulled over TCP.

Why is this important? Because code review is about reviewing the changes and applying patches in a different context to where they were authored. If I fix a bug in my repo then you should be able to apply my fix cleanly to a repo in a quite different state that mine was in. We can work on different things in a decentralised way and yet still collaborate.

Most people of course don’t work like this. Most people in 2022 will literally share a parent commit from a central repository. They push and pull over the net instead of emailing patches. Their trees are in sync a lot more than the days of patch emailing yore. (Although emailing patches is still used by people who need to exfiltrate a change from some system not blessed with full access credentials to do a real push.)

The thing that does still hang around is the idea of a dissociated patch being the unit of a review. Some code review tools don’t really get this right — Gitlab in particular still muddles up the idea of a merge request and a commit. A merge request has a title and a description but so does a commit and yet they are kept separate. You view an MR’s changes as one big patch and these may or may not bear any resemblance to the git commit or commits and their own titles and descriptions. It is as if GitLab’s authors either purposely or naively ignored the idea that git was designed to think in this way from the ground up, and so they implemented a patch-like thing of their own, on top.

I’ve also never embraced the idea of commits that are for public consumption and those which are not. In my model, there are no feature branches, only branches that combine different sets of patches.

It doesn’t need to be so complex and indeed if you embrace the underlying tool (on which your product is named!) gitlab based git projects would be a bit less special and a bit more like everyone else.

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

#74

Post by cryptonector »

intrepidhero wrote: post #12

> But if you try to understand the commands without the model, you will suffer, because the commands do not make sense. I've read this about git several times and certainly felt it. My question is why hasn't anyone come along and fixed it? Git has the plumbing vs. porcelain separation. Why hasn't someone written new porcelain that makes git as intuitive as mercurial, subversion, etc? This seems like a similar situati…

> My question is why hasn't anyone come along and fixed it?

Because the model is simple and easy to understand, and you get a lot of power from understanding it. Whereas opinionated porcelain that tries to insulate the user from the model will tend to fail in obnoxious ways and will not serve the user.

Really, there's objects, there's commits, then there's a couple of methods for symbolically naming commits (branches and tags) because humans need symbolic names (because we can't memory SHA-1 hashes, or any hashes). Object and commit hashes function as pointers or inode numbers. Symbolic commit names function as hard links.

If you understand the Unix filesystem, you can understand Git.

Everything else follows from these things.

Merges create new objects referenced from the merge commit.

Rebase is just a script around cherry-pick.

Cherry-pick is just applying a delta from a commit and then re-committing.

Everything is copy-on-write except the symbolic names (branch names, tag names).

There -- I've just told you everything you need to know about the model. And all of that trivially carries over to the UI.

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

#75

Post by cryptonector »

lisper wrote: post #11

> But if I were going to tell everyone just one more thing, it would be: > It is very hard to permanently lose work. Unfortunately, this is not quite true. Git checkout will silently and irretrievably clobber all the changes in your working tree [UPDATE: if you do 'git checkout [path]', but that is not an uncommon thing to do.] It is true that it is very hard to lose work that you have committed. But even this is not…

Never `git checkout -f` or `git reset --hard` unless you know you want to throw away extant changes from the workspace.

That's it. Know that, live that, and you'll never lose work because of Git.

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

#76

Post by mjd »

skrebbel wrote: post #64
jsmith45 wrote: post #35

Earlier quoted context omitted.

This is exactly the point the author plans to address under "Branches are fictitious", in the outline at the top.

Sure but then why do they describe the term wrong in the first paragraph? That's just adding to the confusion they intend to fight. I'm not sure the author is reading this, but think it's worth rewording.

I'm reading it and I think I got it right. The Git community, the Git documentation, and the Git tools all refer to "branches", and I think what they mean when they talk about "branches" is much closer to what I described than to what you did.

For example, consider this very ordinary-sounding phrase that I just picked out of the git-rebase man page:

> If the upstream branch already contains a change you have made …

I don't think your account can explain what is meant by this.

In any case, I didn't make the choice casually, thoughtlessly, or from ignorance.

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

#77

Post by cryptonector »

karmakaze wrote: post #17

> Git has an elegant and powerful underlying model based on a few simple concepts: Commits are immutable snapshots of the repository Branches are named sequences of commits Every object has a unique ID, derived from its content I would list them as: Every object has a unique ID, derived from its content - and every commit id depends on its ancestors' commit ids Each commit has an associated snapshot (file tree) of th…

You can get by quite well w/o really understanding objects, just commits. So I like to start teaching Git concepts by looking at commits and refs first, then add color with objects.

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

#78

Post by cryptonector »

chx wrote: post #30

> When I first used Git it drove me almost to tears of rage and frustration. But I did get it under control. I don't love Git, but I use it every day, by choice, and I use it effectively. Yes. For me the rescue was Charles Duan's git tutorial: Understanding Git conceptually. https://www.sbf5.com/~cduan/technical/git/ > you can only really use Git if you understand how Git works. Merely memorizing which commands you s…

Basically, making `git reset --hard` and `git checkout -f` auto-stash would be great.

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

#80

Post by stu2b50 »

cryptonector wrote: post #75
lisper wrote: post #11

> But if I were going to tell everyone just one more thing, it would be: > It is very hard to permanently lose work. Unfortunately, this is not quite true. Git checkout will silently and irretrievably clobber all the changes in your working tree [UPDATE: if you do 'git checkout [path]', but that is not an uncommon thing to do.] It is true that it is very hard to lose work that you have committed. But even this is not…

Never `git checkout -f` or `git reset --hard` unless you know you want to throw away extant changes from the workspace. That's it. Know that, live that, and you'll never lose work because of Git.

You can git reset --hard and still get your work back without much trouble. Resets just move the branch pointer back, after all.
Post reply on HN