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

Git cheat sheet [pdf]

wizardzines.com

Post reply on HN
Print view View original

131–140 of 146 posts

Re: Git cheat sheet [pdf]

#131

Post by namaria »

vsnf wrote: post #56
acjohnson55 wrote: post #39

Earlier quoted context omitted.

The skillset to navigate this is one of the underappreciated challenges of teaching.

Exactly zero of my mathematics professors, and a large portion of my CS professors managed to adequately account for this. The professors of mine who did manage it remain firmly in my memories as great people and great teachers, while the one's who didn't inhabit an area between complete memory erasure, and disdain for how hard they made my life. This is at the very core of what it means to be a teacher, not just kno…

> I consider many of them to be failures at their main job for failing to navigate the curse.

A professor's main job is not to teach. It's publishing and getting funds into the university.

Re: Git cheat sheet [pdf]

#132

Post by Panzer04 »

PhilipRoman wrote: post #103
PhilipRoman wrote: post #92

Earlier quoted context omitted.

I can confirm the part about rebase workflow, it really forces you to understand the git model. I sincerely recommend every dev to try it at least once. It also got me into custom power tools for git, like incremental rebase, dual blame, etc.

Too late to edit but I just realized we probably mean very different things by "rebase workflow". I meant making extensive use of Git history editing even on public branches, (with tags serving as backup). I guess the common meaning of "rebase workflow" is just using rebase instead of merge.

Largely we rebase so that all PRs are defacto Fast Forward merges. Rebasing on publicly visible branches (PRs and the like) is common, although rebasing major branches (Master or a release) is not. We're small enough that we can get away with that if we must, though (usually if someone breaks something badly).

Basically, developers rebase all the time on their own branches, and rebase over their target branch (fixing conflicts) so that the PR is fast forward.

Agree on the git model thing, I feel like I have a reasonable idea of how git functions under the hood now, so I can figure out what most operations should do, even if I haven't used them before.

Re: Git cheat sheet [pdf]

#133

Post by adamsilkey »

Maybe my favorite option is missing here.

`git commit -v`

This will put the diff of the commit into your commit message as comments. Makes it easy to remember what you're doing/committing without having to jump back to the terminal/someplace else to look at the diff.

Re: Git cheat sheet [pdf]

#134

Post by euroderf »

Zambyte wrote: post #121
euroderf wrote: post #114

Earlier quoted context omitted.

So where is the totally refactored/revamped CLI that applies Occam's Razor ?

Jujutsu https://github.com/martinvonz/jj

I see that (in principle at least) it can be a simple UI for an existing git repo but then it gets kind of complicated again discussing how that works.

Re: Git cheat sheet [pdf]

#135

Post by guenthert »

vrinsd wrote: post #127
guenthert wrote: post #99

Earlier quoted context omitted.

It might also help understanding, when talking about the history of git, to keep in mind that it came to be out of the urgent need for a tool to replace (then still proprietary) BitKeeper. I wouldn't say that bk is as hard to grok as git, but it's certainly complex as well. I wonder if some of git's idiosyncrasies are a result of intentionally avoiding a look&feel equivalent to bk lest that would alienate Mr. McVoy.

I can't say I was front and center to everything happening, but I always thought it was strange that Linux used Bitkeeper which is very not open-source. So many battles have been fought around Linux and GPL that this seemed a bit hypocrtical. Of course things were run afoul when Tridge started reverse engineering the bk protocol/datastructure but frankly the need to switch away from bk was a bit self-inflicted from w…

> So many battles have been fought around Linux and GPL that this seemed a bit hypocrtical.

Throwing all in one bucket necessarily leads to confusion. Sure, there were and are FOSS zealots and Linux zealots and there is an overlap. Linus Torvalds himself however is a very practically minded guy who clearly expressed that he would use proprietary software if it would suit his needs better. He got a lot of heat for that stance, as some Linux kernel developers happen to be more ideologically pure. No need to warm that battle up.

(oh, BTW, BitKeeper is FOSS since about 2016)

Re: Git cheat sheet [pdf]

#136

Post by Zambyte »

euroderf wrote: post #134
Zambyte wrote: post #121

Earlier quoted context omitted.

Jujutsu https://github.com/martinvonz/jj

I see that (in principle at least) it can be a simple UI for an existing git repo but then it gets kind of complicated again discussing how that works.

I can tell you how to do a bunch of things with Jujutsu without looking it up: how to rebase a tree of branches given a common ancestor, how to do a 3+ way merge, how to split the changes in a commit into multiple commits, how to duplicate a branch, how to find all of the commits that haven't made it into the default branch...

I can't tell you how to do a single one of these things in git without looking it up. My years of experience with git is around a decade I think. My experience with Jujutsu adds up to about 3 months.

Sure, there are things that I would still have to look up how to do with Jujutsu; I don't know all of its features. I think the operations I know how to do with Jujutsu off the top of my head are strictly a superset of the operations I know how to do with git though.

Re: Git cheat sheet [pdf]

#137

Post by euroderf »

Zambyte wrote: post #136
euroderf wrote: post #134

Earlier quoted context omitted.

I see that (in principle at least) it can be a simple UI for an existing git repo but then it gets kind of complicated again discussing how that works.

I can tell you how to do a bunch of things with Jujutsu without looking it up: how to rebase a tree of branches given a common ancestor, how to do a 3+ way merge, how to split the changes in a commit into multiple commits, how to duplicate a branch, how to find all of the commits that haven't made it into the default branch... I can't tell you how to do a single one of these things in git without looking it up. My ye…

There's a common(?) use case for git/jujutsu that I can't find a simple answer to:

I clone a repo. I make some changes to my copy. But then I want to keep my copy up to date with the original repo by stirring in all the updates that have been made lately to the original repo.

Seems like it oughta be simple, but git makes it mysterious. Will jujutsu make this possible using only simple, sensible CLI commands ? And conflicts will be nicely stored away for near-term cleanup ?

Inquiring minds want to know.

Re: Git cheat sheet [pdf]

#138

Post by Zambyte »

euroderf wrote: post #137
Zambyte wrote: post #136

Earlier quoted context omitted.

I can tell you how to do a bunch of things with Jujutsu without looking it up: how to rebase a tree of branches given a common ancestor, how to do a 3+ way merge, how to split the changes in a commit into multiple commits, how to duplicate a branch, how to find all of the commits that haven't made it into the default branch... I can't tell you how to do a single one of these things in git without looking it up. My ye…

There's a common(?) use case for git/jujutsu that I can't find a simple answer to: I clone a repo. I make some changes to my copy. But then I want to keep my copy up to date with the original repo by stirring in all the updates that have been made lately to the original repo. Seems like it oughta be simple, but git makes it mysterious. Will jujutsu make this possible using only simple, sensible CLI commands ? And con…

jj fetch # get the most recent changes from the remote

jj rebase -b @ -d branch@remote # rebase the branch of the current working commit onto the newly fetched commits.

Note that the way to do this with git is almost identical, but maybe not as obvious. In git I think this can be done with a single command though: git pull --rebase.

If this is not the state you want your repo to be in and I misunderstood, I'm still pretty confident I could get a repo in the state you want using Jujutsu quite easily :)

Edit: though also the git way to do this would kind of force you to deal with cleaning up conflicts immediately, whereas with Jujutsu you can put off conflicts indefinitely.

Re: Git cheat sheet [pdf]

#140

Post by looshch »

redbell wrote: post #78

"There are only two hard things in Computer Science: cache invalidation and naming things ." - Phil Karlton [0] Based on the above statement, I find it extremely weird to see such git command named " blame ", then I realized I'm not the only one: What does 'git blame' do? [1]. Blame someone else for your bad code [2]. Git blame should be called git credit [3]. Does Git Blame sound too negative? [4]. _________________…

agreed, i renamed [1] it to ‘who’ (well, actually it’s just ‘w’ since i’m a vim-diehard)

[1] https://github.com/looshch/configs/blob/master/.gitconfig#L1...

Post reply on HN