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

561–570 of 821 posts

Re: Git is too hard

#561

Post by ric2b »

jcelerier wrote: post #477
thrwyoilarticle wrote: post #406

Earlier quoted context omitted.

They're complaining about git and the very first thing they discuss is how git interacts with a completely separate piece of software. Push doesn't have to be to Github, it can also mean sending an email. Obviously you can't undo that. The Github-first problem is viewing git merely as an interface to Github, where the home of the work is and where all things are collected and operated on. From this it follows that gi…

> Obviously you can't undo that. I'd wager I press the "undo" button in gmail at least 3/4 times per week

That's because you have a 30s timer that doesn't actually send anything until it counts to 0.

After it actually sends the e-mail, there's no going back.

Re: Git is too hard

#562

Post by darekkay »

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…

> 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.

That's a great summary for the majority of Git users. I am still motivating people to spend the time to learn it "properly" if they're using Git daily.

First of all, it will make them more efficient. I've seen too many people literally redoing their changes, because a cherry-pick/rebase is "an operation they don't understand".

Secondly, they will be able to solve most issues when (not if) they occur. Sure, I am more than happy to help my colleagues solving their issues. From "why are those changes in my PR" to "our Jenkins job went rogue and now we've got hundreds of MB of data in our repository that we would like to remove". But the time of me explaining things the "learning by doing" style would be better spent actually learning Git.

Re: Git is too hard

#563

Post by chriswarbo »

bak3y wrote: post #442
holtalanm wrote: post #437

Earlier quoted context omitted.

> Is a Github problem, not a git problem. Git (the software) consists of two things. the git client (on your machine) and the git server (wherever you push). It is most definitely not a GitHub problem if you pushed your changes to a local network git server, for example.

It's entirely possible to run git standalone, there's no hard requirement for there to be a git server that you push to.

Yep; plus changes can even be pushed/pulled between local directories (e.g. using 'file://'). Rewriting history can break all sorts of things.

Re: Git is too hard

#564

Post by aulin »

simiones wrote: post #459
lionkor wrote: post #453

Earlier quoted context omitted.

`git pull --rebase` ?

If you have a dirty worktree, `git pull --rebase` fails. You need to either commit or stash your local changes. To stash them, you can use git stash. If you decide to commit them, that's ok, but then you also need to learn about `git reset --hard` or `git commit --amend` or `git push --squash` if the changes were work-in-progress. So which would you recommend? Oh, there is also the option of enabling autostash I thin…

commit soon, commit often, work in a dev branch and rebase -i to squash, amend, edit anything you want before pushing

Re: Git is too hard

#565

Post by kazinator »

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…

This sort of developer blindness once you have learned something is why we need user interface people as a whole separate discipline.

The "concept" of resetting? "git reset" does different things in one command: there is no one concept. It can discard your staged changes and working tree so that your workspace looks like your head. It can move your head ref while doing that. It can move your head without changing the working tree. It can interactively stage the changes to another commit (e.g. to selectively revert).

Re: Git is too hard

#566

Post by at_a_remove »

peterangular wrote: post #430

No it's not. If you're a dev/SWE you should be able to grok a semi-complex CLI API to control software... but the further the world gets into "everything as UIX" and "everything has to be 'easy'" the more we stray from incredibly powerful, immediately available CLI tooling. I know of too many highly-paid people who literally refuse to learn the CLI `git` or `docker` and limit themselves/skillsets by doing everything…

Git can still solve an incredibly complex problem, have a lot of capability and complexity, etc, and still have lousy porcelain.

It's awful. The porcelain is awful. Git solves problems and it has awful porcelain. Git is very useful and it has awful porcelain. Everyone would benefit from learning the basic model of git and ... it has awful porcelain.

Re: Git is too hard

#567

Post by peterangular »

SpeckOfDust wrote: post #515
peterangular wrote: post #430

No it's not. If you're a dev/SWE you should be able to grok a semi-complex CLI API to control software... but the further the world gets into "everything as UIX" and "everything has to be 'easy'" the more we stray from incredibly powerful, immediately available CLI tooling. I know of too many highly-paid people who literally refuse to learn the CLI `git` or `docker` and limit themselves/skillsets by doing everything…

It's probably laziness. Is that such a bad thing though? I think its ok to expect tooling to be easy so we can spend our times on actually writing code. To me it's the same thing as expecting auto completion and line by line debugging from our IDEs.

> It's probably laziness. Is that such a bad thing though?

Yes.

> I think its ok to expect tooling to be easy so we can spend our times on actually writing code.

I have never seen someone use a git GUI alternative as quickly and effectively as a competent CLI user. Especially if you're dealing with anything of reasonable complexity, but still, even for simple stuff. I can hit F1 for my quake-like terminal and type out `git add . && git commit -m 'Adds [...]'`, or a `git stash`, etc. faster than someone can reach over to the mouse and even open the GUI (let alone actually committing).

That's not to say that I don't use Sublime Merge but it's only for complex visualization situations of weird branching etc. But... it's worth noting that most of the time I can get that hammered out on my GitLab instance.

So, if you're looking for efficiency and want to "spend time actually writing code" I attest your argument that a GUI would speed anything up only if you refuse to learn the CLI.

> To me it's the same thing as expecting auto completion and line by line debugging from our IDEs

I work in Sublime all day long and actually actively turn features like this off because they slow me down. Also this is not to say I don't often jump into Intellij for heavier IDE stuff (step-through debugging) but that's like 1-2 times a week max. Otherwise, get out of my way and just let me get the code onto the page, I know 100% what I'm doing/writing and my docs are immaculate and accurate.

---

Overall we probably work in very different ways, with very different development philosophies - which is 100% fine =)

Re: Git is too hard

#568

Post by rleigh »

simiones wrote: post #500
rleigh wrote: post #465

Earlier quoted context omitted.

I rarely use "git pull". Why would you? More typically, I will "git fetch origin" to fetch the current integration branches, then "git checkout -b origin/master" to start a new feature branch from a given integration branch, then push that once the change is completed. If I need to update a local copy of an integration branch, then I might well use "git pull". But I would never have any local changes made there which…

It sounds like you finish your work much faster than I do. I usually go for the same workflow as you do, but it can take days between a branch being created and the moment I'm done with it. During this time, I often want to keep up with the latest changes on master. Other times, more than one person works on a feature branch, so they still need to git pull from origin/feature-branch into feature-branch to get the cha…

No, I don't necessarily work any faster. But I will switch between multiple feature branches as necessary. And to keep up with master, I'll rebase my feature branch onto origin/master or depending upon the circumstance I'll directly merge origin/master. Both keep me up-to-date without a direct pull.

Re: Git is too hard

#569

Post by IAmNotAFix »

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…

All is well until you need merges, which is where the confusion happens and minds are lost.

- You have a branch `master`.

- You have a branch `feature` which contains commit C, which conflicts with `master`.

- You merge `feature` into `master`, fixing conflicts.

- You log the commits of `master`.

  * First is the merge commit, whose diff contains code added by commit C (including the conflict resolution).

  * Next you see commit C, whose diff contains code added by commit C (obviously)
Wait, how can 2 commits in a row have a diff that modifies the code in the same way? Well, mind you, the diff of a commit doesn't correspond to the moment the patch of the commit was added to the current branch, it only corresponds to the moment it was added to its own branch.

Re: Git is too hard

#570

Post by SoSoRoCoCo »

rossdavidh wrote: post #410

I've used git for ten years, at half a dozen organizations (I'm a consultant/contractor). I have accepted that it's what we use now, so I use it. But... Git is the bad boyfriend of the developer community. If anything bad happens it was your fault. If you ask it to do something and it does something else, it was your fault, and also you are stupid. If you ever make a mistake, you will be punished for it with a long d…

Reading all of these threads, I think the conclusion is: we still haven't figured out how to do revision control in an intuitive way, because it is highly nonlinear and our brains just don't work that way. There isn't a clear vocabulary for intricacies of revision control, yet. And if you can't name something clearly, you can't explain it clearly.

The author's idea of putting an abstraction on top of git is the way to go. As an analogy, Git is a great toolbox, but sometimes you need a plumber. I like how apt and apt-get came into being on Ubuntu.

The comments about the logical inconsistencies in Gits command line are a clue.

When is the last time you wrote a CLI utility and listed all of the commands, subcommands, and options to make sure they all had a consistent look and feel? Most single-author tools do not do this. It is a consequence of developing in a vacuum. Team-based development allows other eyes to look at it and say "why is checkout used during branch in a different way then branches are checked out?". Git came from, essentially, one person. That's part of it.

But that is also a legacy of Unix/BSD. Consider `du` and `find`. Both have an option for max depth, but is it --max-depth, -maxdepth, --maxdepth, -d, or -m (or even -L for `tree`). There is a lack of consistency that is a rite of passive for Unix/BSD acolytes that even Gnu didn't fix... C'est la vie? Or maybe a /bin rewrite? bahahahaa who am I kidding.

There's no question Git is a powerful tool, it just needs to evolve and gain some consistency. And I think the answer is a higher level abstraction. And for the love of Benji, NOT a GUI.

Post reply on HN