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

Learn the workings of Git, not just the commands (2015)

developer.ibm.com

Post reply on HN
Print view View original

91–98 of 98 posts

Re: Learn the workings of Git, not just the commands (2015)

#91

Post by torstenvl »

kwertyoowiyop wrote: post #62
zibzab wrote: post #22

A mucher better explanation of git interals: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects It is surprisingly simple and efficient. I am starting to think this Linus guy knows what he is doing.

He offloaded the complexity to its users! :-) If the command and option names had just been sensible, it would be a lot easier to learn and use. Half the usability difficulty, maybe more, is just this.

> If the command and option names had just been sensible

Holy shit, yes.

`git branch` in gitspeak really means `git branch list` in human-readable CLI

But `git branch ${NAME}` does not mean `git branch list ${NAME}`, instead it means `git branch create ${NAME}`

There is no `git branch switch ${NAME}` but instead it's `git checkout ${NAME}`

There is no `git branch log` – that would be `git log`, whereas if you want what should be `git log` what you really want is `git log --all`

Don't get me started on whether modified files are added, staged, or indexed...

Re: Learn the workings of Git, not just the commands (2015)

#92

Post by kwertyoowiyop »

torstenvl wrote: post #91
kwertyoowiyop wrote: post #62

Earlier quoted context omitted.

He offloaded the complexity to its users! :-) If the command and option names had just been sensible, it would be a lot easier to learn and use. Half the usability difficulty, maybe more, is just this.

> If the command and option names had just been sensible Holy shit, yes. `git branch` in gitspeak really means `git branch list` in human-readable CLI But `git branch ${NAME}` does not mean `git branch list ${NAME}`, instead it means `git branch create ${NAME}` There is no `git branch switch ${NAME}` but instead it's `git checkout ${NAME}` There is no `git branch log` – that would be `git log`, whereas if you want wh…

They are added, staged, indexed, AND cached!

Re: Learn the workings of Git, not just the commands (2015)

#93

Post by flohofwoe »

dogleash wrote: post #78
zibzab wrote: post #16

Earlier quoted context omitted.

Why does any post discussing _any_ aspect of git always results in these type of comments? "git is complex", "git command line is confusing me", "life would be easier is we all used subversion". Please let us discuss git in peace. (Although I admit that this one was funny)

>Why... Because lots of people don't want to learn git. They want to bungle through it the same way they bungle through most of the software they touch. People who work with software professionally are very adept at bungling. Even through complicated professional software that other users would need training for. But git is resistant. Even rote memorization won't let you hide completely from learning git. There's a s…

> Because lots of people don't want to learn git.

The thing is that something as trivial as version control should not require that much learning. Pretty much all version control systems other than git had already achieved that (by not providing such a vast "feature surface").

Of course this isn't exactly git's fault. It was developed specifically for Linux kernel developers, not (for instance) for artists on a game development team. The problem is that nowadays, people start to get the impression that git is the only version control system, and want to use it for things it wasn't designed for.

Re: Learn the workings of Git, not just the commands (2015)

#94

Post by shxdow »

zoomablemind wrote: post #82

As a user, I see absolutely no reason to know the internal workings of Git. It supposedly offers a service, which is tracking and recording changes to files. In a way, it's a very able SaveAs/Open command and also offering some way of altering the recorded history. How it's done internally, as much as it's remarkable, is just an implementation detail. The fact that users are repeatedly being referred to docs/books, p…

One reason why you would want to know how Git internally works is to make a better use of it. The interface it exposes is relatively low level and as such suffers when uses don't understand how the software internally operates. If anything, used being repeatedly pointed to docs shows the lack of understanding of Git's inner workings.

Re: Learn the workings of Git, not just the commands (2015)

#95

Post by toopok4k3 »

flohofwoe wrote: post #93
dogleash wrote: post #78

Earlier quoted context omitted.

>Why... Because lots of people don't want to learn git. They want to bungle through it the same way they bungle through most of the software they touch. People who work with software professionally are very adept at bungling. Even through complicated professional software that other users would need training for. But git is resistant. Even rote memorization won't let you hide completely from learning git. There's a s…

> Because lots of people don't want to learn git. The thing is that something as trivial as version control should not require that much learning. Pretty much all version control systems other than git had already achieved that (by not providing such a vast "feature surface"). Of course this isn't exactly git's fault. It was developed specifically for Linux kernel developers, not (for instance) for artists on a game…

Version control contains problems that are not trivial. Git exposes the right parts of the problems and conflicts for the user, that are in no way trivial for a computer and require human decisions on what should be done with them.

Re: Learn the workings of Git, not just the commands (2015)

#96

Post by michaelcampbell »

zibzab wrote: post #16
throw0101a wrote: post #3

It's been over a decade and I still find this joke amusing: > @wilshipley git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space. * https://twitter.com/agnoster/status/44636629423497217 (It's a 'spoof' on the Monad joke.)

Why does any post discussing _any_ aspect of git always results in these type of comments? "git is complex", "git command line is confusing me", "life would be easier is we all used subversion". Please let us discuss git in peace. (Although I admit that this one was funny)

> "git is complex"

Because it is.

> "git command line is confusing me"

Because it does.

Life being easier... maybe, I'm sure it would be for most projects. For some where git is required, likely not. I'd reckon MOST projects don't really need a DVCS; they have the much easier mental model and work quite well with a centralized "source of truth" that people can take from or give code to (coughgithubcough)

Re: Learn the workings of Git, not just the commands (2015)

#97

Post by michaelcampbell »

toopok4k3 wrote: post #95
flohofwoe wrote: post #93

Earlier quoted context omitted.

> Because lots of people don't want to learn git. The thing is that something as trivial as version control should not require that much learning. Pretty much all version control systems other than git had already achieved that (by not providing such a vast "feature surface"). Of course this isn't exactly git's fault. It was developed specifically for Linux kernel developers, not (for instance) for artists on a game…

Version control contains problems that are not trivial. Git exposes the right parts of the problems and conflicts for the user, that are in no way trivial for a computer and require human decisions on what should be done with them.

For SOME projects, that rely on a truly distributed model.

Most don't.

Most at GITHUB don't. It's why they use github.

Re: Learn the workings of Git, not just the commands (2015)

#98

Post by balefrost »

erwincoumans wrote: post #41
balefrost wrote: post #23

Earlier quoted context omitted.

Quick tip: Git branches are cheap. Like super-cheap. IF you want to create a safe point just before doing a tricky merge, just spin off a new branch pointing at the current commit: git branch blah_branch_backup Later, if your merge gets completely messed up, you can do: git merge --abort git reset --hard blah_branch_backup That final command will restore the current branch's HEAD to point to the same commit as blah_b…

Thanks, I should have been mote precise in my post. I meant, I zip repo root folder before a complex git operation (certainly not before every single merge). One example: changing the commit email, somewhere on the middle of many commits. On github, I sometimes need to use the work email instead of personal email (due to https://github.com/apps/google-cla ) Changing the email of an existing commit messed up my repo b…

That's exactly the sort of operation for which backup branches can help.

When you rewrite history, Git makes new commit objects that have the same topology as the original branch topology. It also updates the branch pointer to point at that new HEAD commit.

History rewriting commands essentially just fork the repo at some point in the past and create an alternate commit history. The original commits still exist, at least for a little while. Git will eventually garbage-collect them.

By creating a backup branch, you're "pinning" those old commits. With the backup branch in place, after you run a command that rewrites history, you will be able to look at the commit graph and see the point where the backup branch and the rewritten branch diverged.

I used to do what you do until I learned more about how Git works internally. And Git's really not super complicated at its core. I think much of Git's complexity comes from the minutiae of the CLI options. (For example, when you want to delete something, do you use `-d` or an explicit `remove`? It depends on the command you're running.)

But hey, if you have a workflow that works, then you do you.

Post reply on HN