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

Git is too hard

changelog.com

Post reply on HN
Print view View original

291–300 of 821 posts

Re: Git is too hard

#291

Post by willis936 »

skohan wrote: post #243
rjmunro wrote: post #212

The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour) Resisting GUI's is not a good idea.…

> Resisting GUI's is not a good idea. I disagree. In my personal experience, learning git took a lot of trial and error, but now whatever terminal I sit down in front of, I know exactly which commands I have to run to do what I want in git. When using a GUI, it's fine for the easy/common stuff, but if I want to do something more complex I have to figure out how to dig through the options provided by the tool to get t…

How is this not a shortcoming of the GUI implementation? What could a CLI do that a GUI could not?

Re: Git is too hard

#292

Post by swiley »

rjmunro wrote: post #212

The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour) Resisting GUI's is not a good idea.…

> Resisting GUI's is not a good idea

I would completely disagree with this, anything that adds layers between you and git creates more opportunities for misunderstanding and corner cases.

Resisting a feature branch/merge workflow is what's a bad idea.

Re: Git is too hard

#294

Post by thaumasiotes »

detaro wrote: post #262
thaumasiotes wrote: post #254

Earlier quoted context omitted.

You really believe that git stores -- in full -- every version of a tracked file? Every commit that deletes the whitespace from an otherwise empty line in a 30KB file is another 30KB of hard drive space gone?

The git book explains the internals very well, so you can easily verify it for yourself. Files are referenced as objects in trees, which are pointed to by commits. editing a file creates a new object for it. (edited for tone)

From the book:

> You have two nearly identical 22K objects on your disk (each compressed to approximately 7K). Wouldn’t it be nice if Git could store one of them in full but then the second object only as the delta between it and the first?

> It turns out that it can. The initial format in which Git saves objects on disk is called a “loose” object format. However, occasionally Git packs up several of these objects into a single binary file called a “packfile” in order to save space and be more efficient. Git does this if you have too many loose objects around, if you run the git gc command manually, or if you push to a remote server.

> When Git packs objects, it looks for files that are named and sized similarly, and stores just the deltas from one version of the file to the next. You can look into the packfile and see what Git did to save space.

https://git-scm.com/book/en/v2/Git-Internals-Packfiles

Re: Git is too hard

#295

Post by luord »

Toutouxc wrote: post #275
luord wrote: post #258

While I generally disagree with what he's saying, I do think that most of his points are understandable, even if not persuasive to me. Except this one: >> I will get you to think about a directed graph or as operations on a directed graph > No human thinks about that! Well, that's not wrong, people don't usually think like that, but people also don't usually think about possible specimens living in some forest during…

You could also say that software engineers should be able to focus on building the product, instead of splitting their cognitive capacity between the actual work and fiddling with the versioning system. Getting dirty with git when you really wanted to build the product sounds a lot more like the zoologist binding and gluing together his notebook in the middle of the forest.

I see your point, but in my opinion, part of a job is knowing how to use the tools for the job. New, easier to use or more efficient tools could be created? Absolutely, but knowing how the tools work is never a disadvantage, IMO. And at least we software engineers have an advantage there in that most, if not all, of our tools are themselves software.

For instance, an analogy with zoologists I would make is knowing how to set up their observation equipment in whatever remote area they're doing their research. They have to do it and they have to know how to do it, and maybe they even have to do troubleshooting in case something is not working quite like it should. None of that has to do with zoology per se, but it is part of a zoologist's job.

They can get better and/or more reliable tools over time? Absolutely, which is what I think most of TFA is understandable. I happen to think that git is already a pretty good tool, but I absolutely do see why many people disagree.

Re: Git is too hard

#296

Post by outsomnia »

aulin wrote: post #207
jariel wrote: post #148

Earlier quoted context omitted.

So this, to me, is not a 'benefit of git' it articulates in some ways how bad it is (although very powerful). Most people can get going with those 99% commands quite quickly, the problem with git is any move from the known path creates some pretty amazingly complicated scenarios. And those '1% of the time' commands blow up into time-consuming rabbit holes of complexity. Often, Stack Exchange has several answers for t…

you shouldn't change history once you make it public, how hard is that? that's the golden rule, if you promise something to be immutable, stick to your promise

Tags are immutable. Branches are mutable.

You can add to them and refactor patch series that are on them, equally valid in the eyes of git.

For example a development branch has no implied "promise" about stability of its history, it is much better to not only refactor the code but also refactor the history so sub-patches are squashed into the single feature patch that they logically belong to, and not spawn lives of their own. There is no reason to run that kind of development branch like a stable "branch of record".

Re: Git is too hard

#297

Post by Subsentient »

Well if you want to know how to unpush, here's how. You can also use this to just uncommit locally if you made a mistake, too.

>git reset --soft HEAD^

That preserves your work, but it uncommits it. You can now make changes, re-add files, and recommit. If you want to destroy the last commit instead, replace --soft with --hard.

>git push origin +mybranch

The plus sign forces an overwrite of the remote branch.

I've used this technique countless times, for years. It works fine.

Re: Git is too hard

#298

Post by necheffa »

willis936 wrote: post #291
skohan wrote: post #243

Earlier quoted context omitted.

> Resisting GUI's is not a good idea. I disagree. In my personal experience, learning git took a lot of trial and error, but now whatever terminal I sit down in front of, I know exactly which commands I have to run to do what I want in git. When using a GUI, it's fine for the easy/common stuff, but if I want to do something more complex I have to figure out how to dig through the options provided by the tool to get t…

How is this not a shortcoming of the GUI implementation? What could a CLI do that a GUI could not?

Automation for starters.

Re: Git is too hard

#299

Post by [deleted] »

thaumasiotes wrote: post #254
detaro wrote: post #237

Earlier quoted context omitted.

A "commit" doesn't contain a diff, it contains (references to) the blobs of the files at that state. Diffs are display-only, generated by comparing two full file states.

You really believe that git stores -- in full -- every version of a tracked file? Every commit that deletes the whitespace from an otherwise empty line in a 30KB file is another 30KB of hard drive space gone?

[deleted]

Re: Git is too hard

#300

Post by blackrock »

The actions for the commands ‘commit’ and ‘push’ were always confusing to me.

‘commit’ will take a snapshot to your local branch. But then, you have to “push” it to the remote branch.

I understand what it’s doing, but the choice of words seem wrong. It sounds like “push” has a lower importance than “commit”. But because “push” will sync your local changes with the master remote system, then this obviously has more importance.

Instead, I think they (Linus) should have used something like “snap” for snapshot, to take a snapshot of your local changes. Then “commit” would be used to push your local changes out to the remote server or repository.

Post reply on HN