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

241–250 of 821 posts

Re: Git is too hard

#241

Post by thrwyoilarticle »

IshKebab wrote: post #124
remirk wrote: post #4

Git is one of those technologies where it's super important to get a good grasp of how to internals work. Once you got that, it get easier to answer git questions for others or yourself, and to read the documentation or man pages, as you know what is happening. With how software devs use git, it's 100% worth it to read a good book on it.

> Git is one of those technologies where it's super important to get a good grasp of how to internals work. That's just an excuse for Git being super confusing. Does Microsoft say "it's really important when using MS Word to get a good grasp of how its internals work"? Of course not. Yes you need to get a good mental model of how Git works (basically, commits are efficient snapshots of your code), but that's not the…

Schoolchildren can write documents. They can't write software with many authors creating disparate, conflicting changes across vast space and time. Complaining that git is too hard is claiming this is easy.

Re: Git is too hard

#242

Post by rusk »

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=…

> a system that knows it's connected to other people, where changes are instantly propagated and easily visible

We have this already. It's called collaborative desktops over VNC ...

> the differentiator between "branches" is not "what computer does it reside on" but "who did it"

So you're into collaboration, but not on branches? I would have said branches related to specific units of functionality, streams of development or specific issues.

Definition of branches aside, this is the way old-style centralised VCS like CVS, Subversion actually work - and you can still use SVN if you want to ... or you can use git in that manner and never have to worry about it's more complex details.

The whole point of Git is that it addresses the specific problem that once you are disconnected you de facto have a branch. Once you push to remote its more like that ideal you're reaching for.

> at this point it's not git anymore, so we might as well start from scratch.

I'm sorry this is really quite hilarious. Go! Stop whinging and go do it!

Re: Git is too hard

#243

Post by skohan »

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

> Resisting GUI's is not a good idea.

I disagree. In my personal experience, learning git took a lot of trial and error, but now whatever terminal I sit down in front of, I know exactly which commands I have to run to do what I want in git. When using a GUI, it's fine for the easy/common stuff, but if I want to do something more complex I have to figure out how to dig through the options provided by the tool to get the result I want.

Re: Git is too hard

#244

Post by Horba »

lmm wrote: post #191
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…

1. This isn't currently possible. It would require git to track the staging area for each commmit and branch.

2. See 1.

3. `git pull` by definition conducts a fetch because it Incorporates changes from a remote repository into the current branch.

4. Use `git config push.default current`.

5. Use `git branch --no-track new existing`.

6. I assume this is something to do with the reflog.

Re: Git is too hard

#245

Post by nicoburns »

whizzter wrote: post #209
nicoburns wrote: post #164

Earlier quoted context omitted.

Totally agree on the "staging area". I've always thought that the staging area should only activate when you `git add` or otherwise add files to it. If there are no staged files, then git commit should act like git commit -A.

Oh hell no, Visual Studio has this behaviour by default (commit all changes if nothing staged) and what we end up with is that some people keep checking in various experiments and privately modified launch config files (that should not be in the repo anyhow but that's another story related to the tools) that end up causing a lot of unnecessary merge conflicts when you pull in their changes (where you were really only…

We deal with this via code review. Anything with such files is going to get instantly rejected. And people soon learn not to do it.

Re: Git is too hard

#246

Post by grumple »

I disagree.

Your workflow should be pretty simple.

Go to a feature branch, make changes, add/commit changes, push up the branch, ask for a review, merge the request. This workflow is independent of the technology and can be implemented by git or anything else. There's a handful of commands involved.

When you're newer and make more mistakes, or if have more advanced needs, you can use other commands like rebase, reset, cherry-pick, bisect, etc.

Git is far simpler than the algorithmic crap we get whiteboarded on, or maintaining a complex web app.

Re: Git is too hard

#247

Post by x87678r »

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.

Re: Git is too hard

#248

Post by hakre »

jasode wrote: post #144
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…

>But IMO it isn't because Git is hard, but because they don't have to truly understand Git to use it. That's how easy it is. A copy&paste of my previous comment: Everybody's brain is different but I actually understand all of git's internals (the "plumbing") but it doesn't help me with the git CLI (the "porcelain"). Yes, I know that Git is a DAG (Directed Acyclic Graph), and that HEAD is a pointer, and the file forma…

For snapshots use backups. Git is not a backup.

For the questions, what's bad with quick help on SO? It's maybe less effective than reading the documentation that ships with git itself but for sure much more popular and less to read.

Git truly is a command-line utility, little known is that it ships with more than one gui in the base package out of the box. handling the staging area with git gui for example is straight forward unless you have more than 5000 unstaged files, then the gui informs you about it's limit and mass handling is far easier on the command-line anyway.

Re: Git is too hard

#249

Post by rusk »

oblio wrote: post #202
rusk wrote: post #193

Earlier quoted context omitted.

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, Cle…

> [you] types > of that strain [of people] > injured animal grandstanding ... Plus, sooo many assumptions in there. As an engineer, I know that assumptions are bad :-)

Thanks for the :-) makes me feel like we're not having an argument any more.

As an engineer you should also know, that often assumptions are all you've got to go on. The only way to address uncertainty is to get into the details and figure out what's going on. Complaining loudly and fruitlessly about things is good for getting emotional support but it's not generally a good strategy for getting things done.

Re: Git is too hard

#250

Post by Macha »

> >How do I delete a branch?

> and then I have to ask them:

> > Well, what do you want to do? Do you wanna delete a local branch, and then just get it recreated when you pull again from the same remote? Or delete the remote tracking branch? Or delete the remote branch?

I struggle to think of a reason why you would want to delete a remote tracking branch only. Maybe as part of a bulk cleanup if your tab complete list gets too cluttered and you want to remove ones that don't exist on the server, but that's an advanced topic.

So for most users, it's "Do you want to delete your copy or the server's copy"? This is just the kind of user focused language that the author highlights as simple and complains git makes it hard to think about.

The git UI sucks. I'd rather we were in a world where mercurial won for that reason alone. But it didn't, and I gave up that argument years ago. But the example given feels more about DVCS in general, which removing the distributed part feels like throwing out the baby with the bathwater.

Post reply on HN