Can’t wait for part 2, way to be a tease, author!
[deleted]
Things I wish everyone knew about Git (Part I)
81–90 of 200 posts
Re: Things I wish everyone knew about Git (Part I)
#82Fwiw 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…
[deleted]
Re: Things I wish everyone knew about Git (Part I)
#83Earlier quoted context omitted.
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.
Hard resets throw away extant changes in the workspace that are not in the index or committed. You can't find those changes in the reflog or stash.
Re: Things I wish everyone knew about Git (Part I)
#84> 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.
That's what the script does for the first. Essentially.
Re: Things I wish everyone knew about Git (Part I)
#85Thing 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…
Does the same criticism apply equally to GitHub’s pull requests? I feel like they are essentially the same thing layered on top of a repo, gitlab even supports merge requests across forks.
Re: Things I wish everyone knew about Git (Part I)
#86I'm not a fan of this mythos around Git's complexity. It is simply a DAG, a bunch of references to nodes in that graph, and a stack of commands that let you make any modification to that system you so desire. If you just learn the mapping of those concepts to Git's vocabulary, you really don't need to memorize all the commands. In the odd case, you can just look up the docs. Nodes are commits, references are either b…
1) Git's vocabulary is bizarre.
2) Every tutorial and book leans into the horrible vocabulary, and the metaphors they use to "simplify" and "explain" it only make it worse. All of the analogical baggage is far more complicated than a straightforward description of the data structures.
It took an embarrassingly long time for me to understand that HEAD was just a pointer at the branch or commit you were currently working with (I wish somebody would take that "detached HEAD" terminology out back and shoot it), and that a branch was just a tag that, if HEAD is pointing at it, will move to point to a new commit that you make.
That's because "HEAD" and "branch" are stolen terms crowbarred into something quite different than CVS.
edit: the actual Git book from git-scm.com is not bad at all, but most people aren't learning from that.
Re: Things I wish everyone knew about Git (Part I)
#87Earlier quoted context omitted.
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…
But what’s the precise rule defining what constitutes the commits of a branch, after you reach a merge point? Does the branch end there? If not, which parent of the merge does it go? It’s not clear a priori.
Re: Things I wish everyone knew about Git (Part I)
#88Earlier quoted context omitted.
just to spell it out fully for dear reader: that's how merge commits work.
and Just for fun, sometimes it can be as big as 66, meet Cthulhu merge [1] 1. https://lkml.org/lkml/2014/1/21/361
And when you are playing around with git to try this strategy and it's not allowed you get the wonderful error message "should not be doing an octopus".
(IIRC, from some version of git from about 6 years ago)
Re: Things I wish everyone knew about Git (Part I)
#89Given how widely used git is, we must also empathize as widely as possible. Meaning, users of git are on a spectrum from hardcore engineer with two decades of Unix experience to casual hobbyist.
The casual group may include people very young/old, people with no (significant) background in programming, people that had little formal education in general, non-English speakers, people with cognitive limitations.
When you approach Git like that, neither the commands nor the concepts behind them make any sense.
Saying something like "see, git is just a merkel tree of immutable objects with a unique hash id and a commit is a blah blah..."
...makes no sense whatsoever to the casual group. They are alien words and concepts that are not relatable to the actual task: I just want to version manage something.
Re: Things I wish everyone knew about Git (Part I)
#90> 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.
> no?
Technically no, due to GC.