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

191–200 of 821 posts

Re: Git is too hard

#191

Post by lmm »

m12k wrote: post #39

Git is hard because it precisely models the complexities of concurrently modifying source code on multiple computers. It explicitly models all of the concepts and operations that are relevant in that domain - branching, merging, my local changes, the server that my local branch is kept in sync with, rewriting local history, rewriting public history. Can you shoot yourself in the foot? Absolutely, because this stuff r…

Why can't there be an equivalent of stash that keeps track of which parts were added and which weren't?

If switching branches wouldn't conflict with my current change, why do I have to stash/checkout/unstash instead of just doing it?

Why can't I pull without fetching?

Why will none of the 5 or so push configurations just do "push the current branch to the branch of the same name on the remote"?

Why is there no way to stop git from setting master as the upstream every time I do git checkout -b myfeature origin/master?

Why do I have to detach from a branch before deleting it?

None of this stuff is inherent to the problem or due to being a precise model of things; quite the opposite.

Re: Git is too hard

#192

Post by bollu »

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

While the above is tecnobabble, there /is/ a simple way to state what git is. It's an API to interact with a torsor.

We have files, which are inert objects and form a "file space". We have diffs. Diffs can "act" on a file to produce a new file or a conflict --- we call this as "applying a patch". Mathematicians would call it a "group(oid) action". Diffs are a groupoid because (1) there's an identity diff that does nothing, (2) diffs can be smashed together, (3) if the smashing of diffs succeeds, the operation of concatenation is associative, (4) all diffs are invertible. If we were to delete added lines and add the deleted lines, this inverts the diff.

Finally, we have a rooted DAG where each node is a diff, and the root is the empty diff. Git queries enable to manipulate paths in the DAG, which corresponds to smashing together diffs along a path to produce a file.

If one groks this, the rest of git is a pretty poor interface on top of this nice mathematical structure.

For more physics-y applications of torsors, check out the baez article: https://math.ucr.edu/home/baez/torsors.html

Re: Git is too hard

#193

Post by rusk »

oblio wrote: post #104
rusk wrote: post #89

Earlier quoted context omitted.

I hope I never end up working with you bud. “Where is the code?” “Oh I’m sorry I couldn’t do it because it was hard can I still be paid please?”

With that attitude, I definitely wouldn't want to work with you either. I also love the assumptions about me and the thinly veiled ad-hominem :-) We should be able to admit that a tool has a crap UI and cut out the macho geek attitude. I've been working in this field for about of 15 years and the amount of needless pain we endure from core tools is unimaginable. I'm waaaay past the learning curve for Unix tools, git,…

I'm really not sure what to say to this.

I'm guessing you're not an engineer. It's only product management types that cast around technical criticisms without proposing any solutions so I guess you are of that strain. I don't believe you're stupid, far from it but I think your perspective needs some correction.

We've been using VCS fairly universally for the last 25-30 or so. There's been RCS, CVS, SVN, Perforce, Clearcase ... the list goes on. They all have their warts. Git as it stands at this point in time is the best VCS system that the global software development community has come up with. It's exactly as easy to use as the community that developed it needs to be.

You are free to explore alternatives. You can get commercial products for this kind of thing, and they may well be easier to use, but in my experience these are more buggy, though they do try to provide a more user friendly experience.

You are also free to use the many freely available front-ends to git that are available, or you can use Git in the old centralised model if you like, and go crying to the admin when things get too tricky, as with any other VCS.

By far the biggest gripe with Git is the inconsistency of the tooling, and I guess you could fork it and make whatever improvements you feel are appropriate and then set about getting people to use it. But again, there are numerous front ends (IntelliJ is my favourite) that shield you from these minutiae if needs be.

So please, spare me your injured animal grandstanding. Git is for the choir, not the masses, and to make it suitable for the masses would be a waste of everybody's time because the masses have no interest. You have an interest that would be better served by just sitting down and learning how to use the damn tools that the rest of your colleagues do.

15 years. LOL.

EDIT - if you want something that is "like git" but "easy to use" then, in all seriousness you should check out Mercurial. I always thought it looked nice, but it's of little use if none of my collaborators are on it.

Re: Git is too hard

#194

Post by rmtech »

krageon wrote: post #127
ramraj07 wrote: post #38

Earlier quoted context omitted.

I'm not an idiot, but I don't fully understand git. I am coding for a living, and I use git every day. I probably could sit down for a couple of days and fully understand how git works, but I've never needed it, I understand how basic git operations work, and I stay away from commands that I don't understand. With GitHub desktop you don't need to open the command line for any standard operations, I only need to use t…

> I probably could sit down for a couple of days and fully understand how git works This means it isn't hard. If you are capable of understanding algorithms of any complexity you should be able to learn how to use git (and how much of it) without treading on ground that is dangerous for you to use. All of this "it's too hard" rhetoric is infantilising or coddling people who frankly shouldn't be trusted to code anythi…

Yeah this is incorrect.

One of the reasons that we able to achieve so much with computers is that there is a separation of concerns between different areas.

Requiring everyone to fully understand git is like requiring people who code in high-level languages to understand and apply chip design in their day-to-day work.

Imagine if when you tested some Python or Java code you got an error from your CPU and needed to take it out and debug it with an electron microscope.

Contemporary git has this disease. Its (command line) user interface is a mess. I could say more about what you would do to make a better version but a comment isn't the place for that.

The defence that you are using - that smart people should be able to learn git fully - is like saying that any and every smart programmer should learn IC design and buy their own electron microscope, and that's why it's OK that the chips keep breaking.

Re: Git is too hard

#195

Post by zitterbewegung »

bollu wrote: post #192
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

While the above is tecnobabble, there /is/ a simple way to state what git is. It's an API to interact with a torsor. We have files, which are inert objects and form a "file space". We have diffs. Diffs can "act" on a file to produce a new file or a conflict --- we call this as "applying a patch". Mathematicians would call it a "group(oid) action". Diffs are a groupoid because (1) there's an identity diff that does no…

What do you think of darcs?

Re: Git is too hard

#196

Post by bob1029 »

Git is hard if you allow it to grow into a monster via neglect. Having a clear, consistent process for branching, reviewing and merging code is virtually 100% of the battle with any vcs.

We use a very basic GitHub PR squash+merge process. One other person must review all code and it must pass checkbuild. Simple enough. To avoid horrible conflicts we have daily standups where we make our work areas known so these concerns, dependencies and blockers can be handled asap.

For us, a PR/branch that lives longer than 48 hours is rare, so things don't have a whole lot of time to get fucked up. If we know we are going to be working on something longer term, rebasing after every merge to master is strongly encouraged.

Re: Git is too hard

#197

Post by nottorp »

The author hasn't used the likes of cvs or the commercial systems much, I think? :)

I mean, git is hard, but it's a big improvement over what we had before. And so will whatever replaces git be, whenever it shows up.

Re: Git is too hard

#198

Post by niceairport »

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.

Re: Git is too hard

#199

Post by teekert »

Git is indeed hard and it would help to have some metaphors for it. One I ofter use (I work in biology) is that it is like a lab journal. A lab journal also needs to be in a specific format, dated, indexed, checked every now and then (by someone else), changes have to be dated and signed.. And it's also hard :)

What make it less hard is something like vscode, just click the file you want to register the change that you made for, make a nice description, sign and date (commit).

I also went through the xkcd 1597 phase, we all do, but over time you start to appreciate the beauty. Like all hard things, take it easy and allow yourself to learn.

Maybe something easier will come along in the future, but also making it better will probably very difficult. It is more likely that more convenient layers are build on top of Git, imho.

Re: Git is too hard

#200

Post by ajuc »

ChrisMarshallNY wrote: post #120
ramraj07 wrote: post #38

Earlier quoted context omitted.

I'm not an idiot, but I don't fully understand git. I am coding for a living, and I use git every day. I probably could sit down for a couple of days and fully understand how git works, but I've never needed it, I understand how basic git operations work, and I stay away from commands that I don't understand. With GitHub desktop you don't need to open the command line for any standard operations, I only need to use t…

That’s a similar approach to mine. I tend to learn enough about something to “get the job done.” This is both good and bad. I get a lot done, but not always as efficiently as possible, and I do find myself realizing, down the road, that I didn’t need to do it that way. But it’s entirely possible to get caught in “tool rabbitholes,” where the main goal becomes subservient to the infrastructure. I remember dealing with…

I learn similarly (breadth first search + going deeper when needed) and my wife just does depth first seach. I've tried studying with her when we were at university and we just couldn't make it work - she would want to go 10 levels deep into the first subject and I would get insane trying to remember all the nested questions that get us there withotu understanding where the thing I'm learning about will be used :)

Her problem is she gets discouraged halfway through and never gets to use the stuff she learned.

My problem is I got good at winging it and looking up stuff as needed so I never learn the stuff I didn't needed even when it could be useful if I knew about it.

Probably some compromise would be the best - start with what you need and force yourself to go deep into one random topic each month.

> I remember dealing with folks that would spend three days, writing CLI tools that saved, maybe two hours, over the course of a year.

My friend is like that, but I learnt to aprecciate this when I worked with him. The script maybe only saved 1 minute of work 10 times a year, but more importantly it's self-checking documentation of how we are doing stuff we rarely do.

Post reply on HN