Live data from Hacker News

Git is too hard

changelog.com

751–760 of 821 posts

Re: Git is too hard

#751
> "Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it?" - adding a revert commit, rebasing and squashing it together with the original is the standard way. I know, it may be painful, but back in the time when I used SVN that was only possible by asking the local sysadmin to run a bunch of hacks on the server.

Also, people must cope with the fact that "undoing" something that has already been pushed isn't just like typing Ctrl-Z in a text editor. If you're the only developer of the repo then no problem - rebase like there's no tomorrow and nobody will complain. If you work on the same project with other people, then you must take into account that someone may have already pulled your commit and added something on top of it, and you can't simply "undo it" without breaking his/her git tree unless you rebase. It's not a limitation of the tool, it's a common solution to a common problem in versioning systems.

And the confusion about local and remote branch just vanishes once one figures out that there's a local copy and a remote copy of the repo, and those may not necessarily be in sync - of course, it adds a layer of complexity, but it solves a lot of other problems when collaborating with multiple people on the same code base.

I believe that git is really the best version in system around. The way it works may have a bit of a steep learning curve, but once you master it you realize that its entities and functions (commits, branches, tags, reverts, rebases, submodules etc.) are really the best way to solve the problem of distributed software development without adding any more complexity.

The only argument one could make against git is that its cli is sometimes confusing and inconsistent - checkout can do tons of things, from resetting a file to the original version to create a new branch; some branch actions can be done through git branch, some through git checkout, some through both; you can pull --rebase, or you can run either pull or rebase alone as commands, but one pulls things from the server, the other is used to manipulate commits on the local copy - unless you want to change the commit message, and in that case you use git commit --amend.

I agree that the cli nomenclature is sometimes very puzzling. But let's really try and separate the discussion around the technology and its implementation (which is, IMHO, absolutely brilliant) from that around the user interface (which is sometimes inconsistent, but it's also the result of adding more and more functionalities on top of relatively few existing commands).

Re: Git is too hard

#752

Earlier quoted context omitted.

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

Yes. We clearly do. Appreciate your input though. It's always interesting to understand different perspectives.

Cheers!

Re: Git is too hard

#753

Earlier quoted context omitted.

I don't think memorizing commands is really the problem. Learning just 8 git commands (clone, pull, checkout, checkout -b, commit, push, merge, rebase) will cover like 99% of situations average dev will ever encounter. And when you need something more exotic you usually can google it, usually in under 5 mins. The problem, at least for me, was the complexity of the model which makes the whole thing super scary when yo…

Never use pull, always use fetch. You shouldn't merge changes into your remote tracking branch, it causes nothing but problems.

I was going to negatively answer your comment until I remembered that I have had [pull]rebase=true in my config for almost 10 years, so it have always been the "normal behaviour" to me. I never looked back to this.

So I agree with you, the default pull behaviour that pollutes the branch with useless merge commits is plain stupid.

Re: Git is too hard

#754
post #521

Earlier quoted context omitted.

Imagine if SQL databases had reflog.

https://en.wikipedia.org/wiki/Temporal_database

You're still imagining a centralized solution with a single source of truth and less power than Git. Git history is a directed acyclic graph, not a single linear timeline.

Re: Git is too hard

#755

Earlier quoted context omitted.

Not just that, they seem to suggest Github created Git... > the quality of the tech that is Git is a testament to GitHub being able to make it this far in the tech space But in reality, Github makes Git more complex, because now you have to understand the concept of forks. Not only is there your local copy and an origin, there is a 3rd repository in play.

What other structures would work for having a public forum for PRs? I'm having trouble coming up with many that would be compelling enough to make that change, especially once you consider bad-faith actors in there (eg, I can't flood your git repo with my nonsense, because my code doesn't exist in your repository until the PR is merged) I spend too much time doing archaeology to support squashed PRs, which eliminates…

They could have added namespaces to branch names. Right now branch names are just a free-for-all. Instead, if they insisted that branch names are always prefixed with "username/", then you wouldn't need forks and anybody could freely submit code to any project. PRs would become MRs.

I believe this is how most Git repos are managed within organizations. I'm not sure why public repos need to require users to fork things to propose changes.

And isn't this basically how Github works internally anyways? (eg https://news.ycombinator.com/item?id=24882921)

Re: Git is too hard

#756

Earlier quoted context omitted.

If you rm -r some_common_dir/ or echo foo > important_file.txt that would also be perceived as your fault. And yet, command shells are pretty good software. As for non-devs editing the same document - unless that document is text (which typically it isn't for non-devs), I would probably not use git on them either.

> And yet, command shells are pretty good software. This is a contentious statement. Fred Brooks himself calls the separate command language, which began with JCL on OS/360, a mistake.

Now that is interesting! Do you remember where he said this?

Re: Git is too hard

#758

Earlier quoted context omitted.

> I have to laugh when you say its replacing email. Laugh all you like, but kids and the interns I've chatted with see email as something akin to how I feel about fax machines: not something they'd use by choice, but necessary for historical reasons. When I've been at organizations during a Slack adoption, email volume drops hugely; 50-80%, I'd guess. I've closed most of the mailing lists I used to run because they s…

I have no problem with using Slack or Hangouts or Discord or some other chat solution while at work. I also tend to use discord/steam for throw-away conversation with friends. At no point did I appeal to authority or history in my argument above, so drop the shit around > "Lo it was handed down to us by Postel the Wise, and none shall tamper with His choices." --- If you think Chat apps are winning, let me know when…

> drop the shit around

You jumped into a discussion. The person I replied to was treating the email we happen to have as some sort of unchangeable given. That's what I am objecting to. If you are disavowing that side of his argument, feel free to say so, but it looks to me like you lean pretty heavily on it.

> let me know when you can buy an item online without an account linked to an Email. I'd love to see an example.

You mean aside from the billion or so users of WeChat Pay?

Re: Git is too hard

#759
post #402
post #243

Earlier quoted context omitted.

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

> learning git took a lot of trial and error, but now whatever terminal I sit down in front of This insight why git, like other tools, is stupidely designed. The "wrong" defaults and UX is the DEFAULT, and each USER must learn it. Meaning: UX * N Users = Wasted time and money --- If I present you a screenshoot of a (real!) business apps with mis-aligned buttons, some put in weird places that mean different things tha…

How is a GUI a better option than the git cli? Especially for more complex operations.

Re: Git is too hard

#760

Earlier quoted context omitted.

Thanks for the explanation, but I ran mail servers for ~25 years. I am familiar with the technology, and in the mid-90s even wrote a chapter of a book explaining email. And I've been using version control even longer. Maybe try rereading what I wrote without the assumption that it comes from ignorance.

I think your comments are coming from ignorance, though. Without trying to be snarky - All your comments directly ignore that what you're proposing values one stakeholder more highly than another. People keep pointing out that there are two users involved in this exchange, and they both weigh equally, and you dismiss them and talk about running mail servers 25 years ago (who cares?). You keep saying "I should be able…

I have in fact never said "I should be able to unsend my email". Once. In my life. Please try to argue with my actual points; I don't have time for straw men.
Post reply on HN