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

761–770 of 821 posts

Re: Git is too hard

#761

Post by wpietri »

pythonaut_16 wrote: post #668
Spivak wrote: post #607

Earlier quoted context omitted.

I think you're missing the forest for the trees here. The point of version control systems is to make developing software easier. It's a tool that exists for the convenience of its users. It's reasonable for people developing software to ask for the ability undo a change or restore a repository to the way it was a second ago. Telling a team of people using Git "it doesn't work like that" is unhelpful because it's not…

VCS exist to make it possible to organize and track changes to project source code. Convenience of the user is a secondary goal to clear organization and code management. A VCS shouldn't be unnecessarily difficult to use, but the fact that this conversation around Git's UX is endlessly rehashed is proof that version control is a hard problem. If there was an easy and obvious 10x improvement over Git it would have rep…

I don't think that last bit is necessarily true. Git has strong network effects, and people are generally very conservative about tools like source control. Git also has the benefit that there are a lot of people used to its quirks, and that skill investment makes them feel fond of it.

The same was true with the switch to WYSIWYG OSes and word processing tools; they were generally liked by people new to computing, but people who were steeped in the old ways, many switched only reluctantly.

Re: Git is too hard

#762

Post by eiz »

horsawlarway wrote: post #739
wpietri wrote: post #639

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…

> If you think Chat apps are winning, let me know when you can buy an item online without an account linked to an Email. I'd love to see an example.

https://www.amazon.com/gp/help/customer/display.html?nodeId=...

Re: Git is too hard

#763

Post by jjav »

I've never shied away from embracing complexity in trade of more power and/or flexibility wherever it brings me value.

I run UNIXen as my desktops (Linux, Solaris, BSDs) even if it takes more understanding and tinkering than OS X, because in the end it's more powerful. I run my own email infrastructure instead of giving it up to gmail, because it's more flexible and powerful and I'm in control. And so on.

But git? What a curse it is. I identify with the comments that liken it to hazing. A lot of pain to be inducted into the club, just for the sake of pain. No gain.

I've been using source control systems for many decades and all of them have been tools that provide their value without being intrusive. Never have I had to fight a source control tool or take backups before every operation like with git.

So that explains the hate, from my perspective. git came along and polluted a perfectly good tool space with something extremely user-hostile and didn't add any extra value (no, git did not invent distributed source control so that's not the explanation; I've been using distributed source control since the mid 90s and today I use mercurial wherever I get a choice).

Re: Git is too hard

#764

Post by a1369209993 »

horsawlarway wrote: post #740
jayd16 wrote: post #693

Earlier quoted context omitted.

>I don't have particular reason to believe that balancing users needs would come out in favor of the current behavior. Gitlab and Github (rightfully imo) came to this behavior. It was not random and is not the default git behavior which is to just allow the force push and all the chaos afterward. If you don't like it, mark your master branches as unprotected. However, there's clear reasons for the current defaults.

It's ok, I'm not really convinced the poster above you actually understands how distributed systems work. They seem entirely stuck in the assumption that there's a more powerful entity in the relationship that can arbitrate interactions between individuals.

Technically, I think their problem is assuming that it's acceptable for there to be such a entity, not that one necessarily exists. And then misinterpreting/misrepresenting git's semi-intentional exclusion of such a entity as a bug when in fact it's a feature.

Re: Git is too hard

#765

Post by rswail »

lmm wrote: post #311
acdha wrote: post #221

Earlier quoted context omitted.

> Why can't there be an equivalent of stash that keeps track of which parts were added and which weren't? What do you mean by this? It sounds like how stash already works. > If switching branches wouldn't conflict with my current change, why do I have to stash/checkout/unstash instead of just doing it? This is how git has worked for years: you can checkout a non-conflicting branch without stashing. > Why can't I pull…

> What do you mean by this? It sounds like how stash already works. I want to switch branches when I have some added (staged) changes and some unstaged changes, and keep the same set of staged and unstaged changes afterwards. > This is how git has worked for years: you can checkout a non-conflicting branch without stashing. Only if none of the changes are to the same file, even if they don't conflict. > Have you cust…

> If I do "git pull" it does a fetch and then something else. I'd like to do just the part that's not a fetch (because I fetched the same remote recently).

Pull = fetch remote branches + merge remotes -> local tracking branches

If you want to do the second part without the first, the git merge command will do it.

From the first line in the man page for git-pull:

"Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD."

Re: Git is too hard

#766

Post by [deleted] »

lstodd wrote: post #595
anuila wrote: post #524

Earlier quoted context omitted.

I disagree on GitHub Desktop. The whole point of the UI is so that your workflow is simplified without having to understand the exact inner workings of it all. GHDesktop’s simplicity means that most of time I don’t have to call 4 commands to just check out a new repository or PR because one click runs all those 4 commands and more. As simple as it is, lately I rarely have to use the CLI (which however I still use bec…

So you're fine with not understanding what are you doing. This sounds ominious.

[deleted]

Re: Git is too hard

#767

Post by hvidgaard »

jorams wrote: post #526
hvidgaard wrote: post #322

Earlier quoted context omitted.

That breaks a very simple rule that a VCS tools should adhere consistently. Do not make destructive changes unless explicitly told to. Since most other commands to not allow you to do this without -f, the same should apply here.

I'm not sure I see your point. The entire reason `git push --mirror` exists is to turn the remote end into a mirror of the local end. By definition that's a destructive operation. What would it do without a further --force? If you just want to push all branches or tags you should use --all or --tags.

Because you normally cannot make remote destructive changes without the --force. Unless you know the commands that does that by default. That is bad UX.

Re: Git is too hard

#768

Post by lmm »

rswail wrote: post #765
lmm wrote: post #311

Earlier quoted context omitted.

> What do you mean by this? It sounds like how stash already works. I want to switch branches when I have some added (staged) changes and some unstaged changes, and keep the same set of staged and unstaged changes afterwards. > This is how git has worked for years: you can checkout a non-conflicting branch without stashing. Only if none of the changes are to the same file, even if they don't conflict. > Have you cust…

> If I do "git pull" it does a fetch and then something else. I'd like to do just the part that's not a fetch (because I fetched the same remote recently). Pull = fetch remote branches + merge remotes -> local tracking branches If you want to do the second part without the first, the git merge command will do it. From the first line in the man page for git-pull: "Incorporates changes from a remote repository into the…

But FETCH_HEAD only exists because of the fetch command. Git knows what the upstream branch for this branch is. It should know what the remote-tracking branch for that branch is. So why isn't there a command to merge that branch in?

Git remote-tracking branches are just a cache except when they're not. A better model would be for every command that can interact with remote refs to fetch first by default (like pull does) but take an option to "work offline" and use the remote-tracking version (which would then be a proper cache). Or vice versa, for every command to not fetch unless given a parameter that tells it to. It's ridiculous to have to guess which commands will fetch or not.

Re: Git is too hard

#769

Post by GarvielLoken »

simiones wrote: post #419
ivanhoe wrote: post #381

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…

You forgot log, cherry, stash, blame, which are also daily use commands. You also have to learn a lot of concepts to even understand the help and error messages for these commands - the worktree, the index, the stash, HEAD, ours vs theirs, conflicts, remotes, tracking branches, when it is safe to push -F, etc. Depending on the project you joined, you may also have to immediately learn about git LFS, submodules, squas…

You don't have to "understand" it. Just form a basic opioun of what you think they will do and build an experience of what usually happens. That is what I do anyway as a software developer for 8 years.

Re: Git is too hard

#770

Post by thaumasiotes »

Qwertious wrote: post #491
thaumasiotes wrote: post #240

Earlier quoted context omitted.

> But that flexibility adds an extra cognitive burden when a newbie just wants to save a "backup snapshot of the repo". Simple needs have simple answers. git add . git commit -am '2020-11-17' Sure, you can ask "why are there two commands?", but this is not so much an issue of cognitive burden as of typing burden. If you only want one thing, you only have to know how to do one thing. If you don't want to know why the…

When you're writing into a text file and then save it, you don't have to manually select what lines or pages you're saving - you're saving all of it. This is the mental model 99% of newbies will have for something that basically pledges to save and sync each version of your files. Deviating from the user's mental model will create roadbumps and should not be done without a very strong rationale. Especially not for a…

> When you're writing into a text file and then save it, you don't have to manually select what lines or pages you're saving - you're saving all of it.

I don't understand the point you're trying to make; this is just as true of the command I gave.

Post reply on HN