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

281–290 of 821 posts

Re: Git is too hard

#281

Post by kemiller2002 »

I have a real question (not trying to start a flame war). Truthfully, why do people think git is hard? Seriously, as programmers we do many, many things that are really hard. Things like thinking about abstract data structures, understanding concurrent processing, etc. I can understand not knowing it and how that frustrates people, but I genuinely don't understand why people are afraid to just dig in and learn git. Some of the commands I admit are confusing at times, and I have to look commands up, but I don't think I've ever looked at git and said, this too difficult for me to understand.

Honestly, I would really love to know, because I have to teach git fundamentals in a couple of months at work.

Re: Git is too hard

#282

Post by me_me_me »

x87678r wrote: post #247
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.…

Wait what? How come nobody told me about gitk.

I am sorry and happy for you.

gitk is like an anchor for me to understand where I stand in given repo.

Make sure to set default view to display all branches and mark branch sides.

Re: Git is too hard

#283

Post by gregoriol »

If you think commandline git is complicated, try to make a symbolic link or an rsync backup from the commandline.

Commandline is not easy, it is powerful: that's why we use it, that's why we love it.

We don't have to know exactly all the command parameters except one or two: if need more, make a script/an alias or use --help or man; there are many ways.

As long as we keep it powerful and can script it, it is good for me. Actually, most of the time I use a GUI for git, because that's what the tool allows and as a human I feel it more practical. But sometimes I go beyond the GUI and use some very specific commande to get back the raw power of it.

Re: Git is too hard

#284

Post by thrwyoilarticle »

rmtech wrote: post #252
thrwyoilarticle wrote: post #218

Earlier quoted context omitted.

>I could say more about what you would do to make a better version but a comment isn't the place for that. I'd be very interested because it's rare for me to see anyone attempt and, when I do, they break a basic use case.

Probably the biggest problem with the git interface is that the interface exposed to the user isn't sufficiently abstracted from the implementation. Insanely complicated commands to undo things are one symptom of this. As a user, you want to "save" some code and you also want to "share" it with others. You also want a historical record of what you did. But obviously you will occasionally save and share things you did…

Then you'd need centralised protections to decide who can delete and you instantly lose the distributed features.

If I'm a user and I want to save, I do it with my text editor. If I want to share, I can do it with Github, Gerrit, Gitlab, email, pigeon.

I never email people things I didn't mean to and, if I did, I wouldn't expect my email software to let me delete it. The centralised services allow it to some degree but even they don't allow information to be un-disseminated.

VCS is necessary to deal with changes that overlap and conflict. It's not for backup and it's not a method of communication. If all you need to do is save and share, you don't need VCS.

Re: Git is too hard

#285

Post by mannykannot »

aulin wrote: post #152
zingermc wrote: post #83

Earlier quoted context omitted.

I've definitely been the victim of my own git hubris. Once, when leaving a job, I decided to copy all of my local WIP branches to the server. I whipped out this fancy --mirror option I had just heard of: git push --mirror $remote Surprise! All branches on the remote repo got wiped. My local refs replaced the refs on the remote. Somehow I found the right commits floating around in the git ether. I was able to recreate…

this definitely shouldn't happen if shared branches are properly protected against non fastforward pushes

...and if you didn't know that, you shouldn't be using git!

To be fair, one should always look up options you are unfamiliar with before using - and Stack Exchange is not an authoritative source.

--mirror

...Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end... [my emphasis.]

On the other hand, if you are on a system where the behavior can be fundamentally altered by multiple configuration options, this will not necessarily help you much.

...This is the default if the configuration option remote..mirror is set.

Re: Git is too hard

#286

Post by irjustin »

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?

git works off of snapshots which are blobs, and blobs are compressed very effectively, but if your file takes 30KB compressed then yes, 30KB compressed is being added for every white space added[0].

Another way to think of it, if it was diffs, if you had 1000 commits, getting to the 'head' would take forever because it had to replay all the commits diffs just to get there.

Yes, you could combine diffs & snapshots, but that in itself is a tricky complexity in an already very complex system.

[0] https://tom.preston-werner.com/2009/05/19/the-git-parable.ht...

Re: Git is too hard

#287

Post by the_af »

edflsafoiewq wrote: post #259
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.…

checkout -b seems more logical to me, but not even close to 1000x more logical. Whether it should go on branch or checkout is just an opinion. You're blowing some tiny disagreement up to ridiculous levels.

On aggregate, a large collection of individually tiny annoyances can add up to a tool that's confusing to use.

Re: Git is too hard

#288

Post by thrwyoilarticle »

bipson wrote: post #91

What I often experience (see also a lot of comments here): Some people, however smart, try to force git to do something in particular, without asking first "How can I do x with git" (I don't think I ever had a use case where stackoverflow didn't have a solution for). Then they end up with a borked repo, everything is confusing (because it should have almost never been in this state), angry at the tool they abused so…

>Could git have named some commands better? Yes, of course. If you don't know what git is doing internally on a checkout, it makes little sense. But this is being worked on.

Sadly these improvements rarely make it into the public consciousness because people don't pay attention to them and instead find stale or inappropriate StackOverflow solutions.

Re: Git is too hard

#289

Post by outsomnia »

Macha wrote: post #253
outsomnia wrote: post #234

Earlier quoted context omitted.

Right, it's also because github guides people into a history-only flow instead of rebase / force-push. Casual github users know they should follow the tree with pull and don't know what fetch is. With history if you make a vcs mistake, or realize iteratively after pushing that corrections are needed, your worthless threshing around trying to fix it becomes part of your project log forever, instead of just pushing the…

The objects are still there even with a rebase flow, it's not as if github does a gc every push?

It's not about the object database, it's about what you see with git log.

History flow will show all the meandering around forever, but rebase will remove it and just put the most recent version of the commit on top of the tree. Ie, your log looks like you pushed just the perfect patches each time, every time, and the junk is gone.

Re: Git is too hard

#290

Post by LgWoodenBadger »

anotherevan wrote: post #139

“Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.” — Isaac Wolkerstorfer http://twitter.com/agnoster/status/44636629423497217

Seems like an obvious play on "a monad is a monoid in the category of endofunctors, what's the problem?"
Post reply on HN