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

111–120 of 821 posts

Re: Git is too hard

#111

Post by ramraj07 »

tankenmate wrote: post #106
ramraj07 wrote: post #95

Earlier quoted context omitted.

I am limited by time on what I can learn, every day I have five other things I'd rather spend my time learning about instead of git. The "git experts" that I know of are no more productive than me and more often than not do annoying things like rewriting commit histories after I made comments in their PRs, that I'm not convinced it's worth the day or two I need to learn it fully. In the end git is not in production,…

Before undertaking his craft, the artisan first sharpens his tools.

A good cook doesn't need to own 5 stones to sharpen his knife, he just needs to have the number of the sharpening guy.

Re: Git is too hard

#113

Post by gitowiec »

Exactly! It is too hard for me. I'm webdeveloper mainly full stack since 2009. Since the begining I used SVN but after few years transited to Git. I never had any training where I could put my hands on many use cases and situations of git. I did some tutorials and watched some youtube videos, also checked on f. manual. I can do pulls and fetches, I don't recognize strict difference (I try this or that). I am able to work smoothly inside my feature branch and can do pull requests to any other branch. I can resolve conflicts. But other stuff is out of my reach - and I now why. Because it almost never happens in day to day job. And if it does not happen I don't remember the procedures to perform.

Re: Git is too hard

#114

Post by mcintyre1994 »

zingermc wrote: post #83
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'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?

Re: Git is too hard

#115

Post by bipson »

ramraj07 wrote: post #95
ghayes wrote: post #85

Earlier quoted context omitted.

I'm not sure I follow your logic: why not take a few days to learn the fundamentals of git? I did that a few years back (and I'm not saying I read the source code, just learned about the base concepts from a few blogs and played around with some more advanced commands), and it has paid dividends _every single day for the last several years_. For example, I avoid tracking branches and have started using `git fetch`, `…

I am limited by time on what I can learn, every day I have five other things I'd rather spend my time learning about instead of git. The "git experts" that I know of are no more productive than me and more often than not do annoying things like rewriting commit histories after I made comments in their PRs, that I'm not convinced it's worth the day or two I need to learn it fully. In the end git is not in production,…

That's a very shortsighted view on the world. Particularly if you're working with other people.

Once you are collaborating, there is simply more to good code than what you our your peers know about the code or the language. Working well and effective with others has a huge impact on you, your peers, the "company" and in the end the product.

Further, I know a lot more about my cars than just how to change the tires. E.g. there are know issues with certain popular car models. Knowing about them does help, not every random mechanic does.

Also, if my car does certain things (surprise, they do all the time, they are complex nowadays) that are easily explainable or even somewhere in the manual, I am not going to ask for help every.single.time. I have stuff to do, be somewhere. I am not going to put my car in the dealership all the time.

Git for me is a productivity tool, in particular when I'm working with others.

You sound like the guy I once collaborated with that didn't want to use git (because why should he learn it now?) and instead sending the whole code via skype every day.

Re: Git is too hard

#117

Post by jariel »

dimgl wrote: post #6

I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…

Git is I think objectively more complicated any other popular VCS, simply due to the fact it has much more in the design model.

It's also more powerful.

But the tradeoff is ugly within the context of the nature of the UI.

Git is like C++, it has a lot of features, the UI is not well thought out and it creates countless corner cases.

Git was not designed to focus on the core cases, making things simple.

Git is one of the great 'litmus tests' for product design thinkers. People who don't understand why git is problematic (even if they are really good at it) I think would have trouble with product design.

Re: Git is too hard

#118

Post by bipson »

ramraj07 wrote: post #111
tankenmate wrote: post #106

Earlier quoted context omitted.

Before undertaking his craft, the artisan first sharpens his tools.

A good cook doesn't need to own 5 stones to sharpen his knife, he just needs to have the number of the sharpening guy.

You would be surprised how many cooks sharpen their knives themselves.

It is also a very wholesome and meditative activity.

Re: Git is too hard

#119

Post by gitowiec »

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…

Exactly what I feel about this tool. I don't get it what is the structure of the inner tree of git changes. Once I though I understand those graphical graphs where branches go out of other branches and than after some commits are merged back. But then I learnt something more and I lost confidence in what I believed before.

Re: Git is too hard

#120

Post by ChrisMarshallNY »

ramraj07 wrote: post #38
dimgl wrote: post #6

I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…

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 folks that would spend three days, writing CLI tools that saved, maybe two hours, over the course of a year.

Post reply on HN