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

271–280 of 821 posts

Re: Git is too hard

#271

Post by jorams »

mcintyre1994 wrote: post #114
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…

I have a horrible feeling your answer to this is going to stress me out, but does that work even without a force push?

Yes, --mirror implies a level of force. The man page contains this:

"...locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end..."

Re: Git is too hard

#272

Post by gjmacd »

IMHO, No it's not. This isn't Dropbox or FTP. Conceptually, some of thing things Git does is are not easy concepts to distill into a couple commands to achieve what Git sets out to do. Sure, you can use it in a basic way, but that's not the point, Git is incredibly powerful tool.

In fact, on my teams, I make sure people use the CLI and not use a frontend wrapper so they grab the concepts before they go "willy nilly" into the comfort of GitLens or another UI that masks their understanding of what they are actually doing.

You should always understand the underlying commands you're executing. Rebase, merge, branch, etc. aren't easy concepts to understand and they aren't easily conveyed for beginners in a graphical tool.

Re: Git is too hard

#273

Post by exDM69 »

jariel wrote: post #131
exDM69 wrote: post #74

Earlier quoted context omitted.

Exactly. I like to say that git is a "white box". You need to understand the internals to be able to use it. Contrast this with "black boxes" where you don't have to or even can't understand what's going on. Some would argue that software shouldn't be built that way, but I will respectfully disagree. It's not an end user facing consumer product, it's a tool for professionals. You wouldn't expect anyone to operate a t…

"You wouldn't expect anyone to operate a table saw" ? Coming from a family of carpenters, I can assure you none of them really know that much at all about the internals of the table saw. Maybe a little bit. The 'black box' analogy is upside down: there are a million artifacts of the computer that you use every day for which you have no understanding. We use encapsulated concepts to be able to leverage much more compl…

> Coming from a family of carpenters, I can assure you none of them really know that much at all about the internals of the table saw. Maybe a little bit.

Every carpenter I know knows how to change the blade, tighten the arbor, check the fence, adjust riving knives, clean away the dust, tension the belts (if applicable) and maybe even change the motor. And there isn't much more to a table saw.

Getting back to Git, I agree with your sentiment "Within Git, there is a much smaller and clearer CVS struggling to get out.". Most of us should strive to stay within the set of simple git operations.

However, then there's all the other corner cases that are sometimes applicable. Such as clearing away your accidentally published private keys using `git filter-branch`. Most of us will never need this, but it's there for a reason.

But if one groks the "DAG of commits" concept behind git, you can understand what filter-branch does and why and how. It's not a very complex concept.

Again, I won't defend the inconsistent user interface. It could be better. But even that can be understood when needed by looking at the documentation as long as the concept is clear.

Re: Git is too hard

#274

Post by NateEag »

dimgl wrote: post #94
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…

I get it, but I'm not sure you should fault Git for that. Nothing like that has ever happened to me and I wouldn't use a command I don't know in a critical setting...

Any sane piece of software should warn you before doing a highly destructive operation.

Something like

  You are trying to remove commits from twelve branches.
  Are you sure that's what you want to do?  
  Include the --force option to go ahead with this change.
would be a whole lot better.

Even if it gives you the tools to undo the mistakes, it saves you time and stress if it keeps you from making the mistakes in the first place.

Re: Git is too hard

#275

Post by Toutouxc »

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.

Re: Git is too hard

#276

Post by kadoban »

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?

It does, yes. To add a bit more color though, what happens is that when you run `git gc` (or it's run automatically for you sometimes) an extra compression step is done that uses diffs of some sort to avoid storing so many near copies. Packfiles are related to this.

Re: Git is too hard

#277

Post by seppel »

thaumasiotes wrote: post #229
matthiasv wrote: post #214

Earlier quoted context omitted.

While this sounds all nice it actually fails to model Git as it is. Git is an object database and its objects are blobs, trees and commits not diffs, so your premise is based on a misconception.

> Git is an object database and its objects are blobs, trees and commits not diffs What do you think is the difference between a "commit" and a "diff"?

A diff is something that describes the changes between two versions but does NOT refer to any specific version; or at least it is something that can be worked with independent of any specific version.

Ie. I can develop a fix for a issue for version 1.2.30 of some software, generate a the diff using the diff tool and then apply this diff using the patch tool to version 1.1.15 of the software. This might fail (or result in something undesired), but there no principal problem in moving the diff around and applying it somewhere else.

A git commit however is a particular version, so git is not really good at applying a commit somewhere else.

Re: Git is too hard

#278

Post by ReptileMan »

niceairport wrote: post #198
tasubotadas wrote: post #48

I loved using Mercurial. It provides such a nice UX and it is very intuitive to use. It's a shame that github was created and not MercurialHub and now we are stuck with Git. Now even Atlassian abandoned Mercurial.

I think one of the reasons as to why that happened is that Git is a much better piece of software in pretty much every aspect.

expect stuff like ease of use, learning curve and more intuitive.

Re: Git is too hard

#279

Post by hvidgaard »

thrwyoilarticle wrote: post #213
rakoo wrote: post #167

> I’ve used it since GitHub was in beta This is the root of the author's issue. As another commented, git is born in a world where computers are mostly offline, people are highly technical, and will spend a lot of time manually crafting the messages they will send to the numerous collaborators. It is an alone-first software. What the author wants (and exactly what I want as well: https://news.ycombinator.com/item?id=…

+1. The very first question: >Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it? Is a Github problem, not a git problem. You might as well ask how to unsend an email. If you don't know what git push means, you shouldn't be using it and are playing with intellectual property fire. The conflation of Github with git is responsible for a lot of confusion. Having Github be your first interac…

Mercurial has solved this quite elegantly. The Evolve extension is basically standard functionality and all changesets (commits) have a state: secret, draft, public. You can share the changesets and you can "prune" them, which basically tells the world that if they have a changeset with that hash to delete it.

Re: Git is too hard

#280

Post by dijit »

nikola1010 wrote: post #235
dijit wrote: post #211

Earlier quoted context omitted.

Weird question; have you looked at perforce? My previous and current company use perforce but many people (often those who recently join) are decrying that perforce is less elegant than git, but, realistically and based on your own criteria it would be "better" for the connected case. I'm personally a big fan of 'offline/local-first' being a thing, but I'm a sysadmin not a developer.

At my current job, I had to create a command-line tool just to be able to checkout things from perforce. It is ridiculous how difficult the UX is for this. And companies are still paying for it!

I really don’t want to be the guy defending perforce as I have gripes with it and prefer git for the reasons I mentioned..

but what was the issue with `p4 edit` that caused you to write a new CLI tool for checking out files?

Post reply on HN