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

491–500 of 821 posts

Re: Git is too hard

#491

Post by Qwertious »

thaumasiotes wrote: post #240
jasode wrote: post #144

Earlier quoted context omitted.

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

> 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 feature that's fundamentally optional.

Re: Git is too hard

#492

Post by recursive »

WalterSear wrote: post #485
recursive wrote: post #380

Earlier quoted context omitted.

I have been using git for years, and have never rebased once. I'm kind of scared to try, perhaps irrationally. Rebasing seems to change commit relationships in a way that seems like it may be difficult to untangle if it later differs with someone else's clone. I would also like the ability to see a nicely curated set of changes. This mostly exists in the diff tabs of a pull request. If this were to be a first-class f…

Rebase is best done before you share commits with anyone. I routinely do an interactive one before PRs to clean things up.

Is there a reliable way to know whether any of the involved commits have been pushed anywhere? I would probably usually know off the top of my head, but not always.

Re: Git is too hard

#493

Post by SpeckOfDust »

I've never understood why so many pro developers around me speak so highly of git. I get that its powerful but why does it seem so convoluted?

I'm not a git expert. Just a developer who likes to get things done with the least amount of effort. I use a combination of git cli, vscode git extension and SourceTree to do everything I need to do. I hate that I have to use SourceTree given its many flaws. Yet, the way that it lets me visualize branches-merges history and do interactive rebase is just unmatchable.

Also, never understood why Github Desktop exists or what people use it for.

Re: Git is too hard

#494

Post by kps »

matthiasv wrote: post #214
bollu wrote: post #192

Earlier quoted context omitted.

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…

While this sounds all nice it actually fails to model Git as it is. Git is an object database and its objects are blobs, trees and commits not diffs, so your premise is based on a misconception.

And that's a bigger problem with git than the horrible commands. Every project I've worked on that has used git has had a diff-based workflow, and sometimes the mismatch is painful — I wish I didn't have to know about `--full-history` and that `git show X` isn't necessarily the same as `git diff X^..X`.

I really hope something like pijul takes off.

Re: Git is too hard

#495

Post by emidln »

rob74 wrote: post #480
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…

The problem is not the 99% of situations that you can memorize, but the 1% of times when you realize you have made a mistake and strayed from your beaten path into the dark scary unknown Git woods where monsters with detached HEADs may be lurking behind every tree, and you have to ask a coworker or StackOverflow to rescue you...

> and you have to ask a coworker or StackOverflow to rescue you...

That or you could RTFM. That's what your coworker and the person writing on StackOverflow did.

Re: Git is too hard

#496

Post by harrisonjackson »

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…

Small frequent commits will limit the need for stash. That's a good practice anyway.

The others I'd say could be completely excluded from daily/weekly/yearly use. If you are using cherry or blame daily then there is probably something wrong :D

Re: Git is too hard

#497

Post by distortedsignal »

rleigh wrote: post #465
simiones wrote: post #438

Earlier quoted context omitted.

How can you pull without using stash? Do you always commit everything before pulling? You also need the log daily to know things like "what changes made it into this build", or almost everytime I fix a merge conflict, to understand why something is the way it is. I can grant that cherry-pick & blame are more rarely used, though blame is often on by default in many editors, and cherry-pick is something my team does da…

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…

I use git pull pretty frequently. I like to keep my main branch up to date with the main branch of the remote repo. I find it's helpful to have that consistency across contexts.

I think diffs are faster if it's to the local repo vs the remote repo.

I always make branches off local-main, as opposed to remote main as in your example.

I think it's also helpful to have the main branch replicated across as many machines as possible. There have been one or two times where a dev has deleted remote main at my company where some (very VERY CALM) git push solved the problem. I probably could have checked out a tracking branch and fixed it that way, but having a local copy of main made it a one-step process (I think the resolution was just to git push the main branch?).

Re: Git is too hard

#498

Post by Qwertious »

mannykannot wrote: post #285
aulin wrote: post #152

Earlier quoted context omitted.

this definitely shouldn't happen if shared branches are properly protected against non fastforward pushes

...and if you didn't know that, you shouldn't be using git! To be fair, one should always look up options you are unfamiliar with before using - and Stack Exchange is not an authoritative source. --mirror ...Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end... [my emphasis.] On the other hand, i…

>To be fair, one should always look up options you are unfamiliar with before using - and Stack Exchange is not an authoritative source

https://xkcd.com/293/

Re: Git is too hard

#499

Post by Raidion »

rleigh wrote: post #465
simiones wrote: post #438

Earlier quoted context omitted.

How can you pull without using stash? Do you always commit everything before pulling? You also need the log daily to know things like "what changes made it into this build", or almost everytime I fix a merge conflict, to understand why something is the way it is. I can grant that cherry-pick & blame are more rarely used, though blame is often on by default in many editors, and cherry-pick is something my team does da…

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's just a preference thing. If I'm sitting down to write a new feature I can do the git fetch origin and go directly to a branch, but if I'm investigating an issue, I'll often open that develop/master branch directly, find the problem, do a pull to make sure there are no changes that got checked in, then "git checkout -b".

Alternately if I'm helping other developers, I'm on their branch a lot, and it basically becomes a "push your changes and I'll take a look" and I just open that folder and git pull.

I think I use more git pull now than I did originally, because I'm working on less of my own code.

Re: Git is too hard

#500

Post by simiones »

rleigh wrote: post #465
simiones wrote: post #438

Earlier quoted context omitted.

How can you pull without using stash? Do you always commit everything before pulling? You also need the log daily to know things like "what changes made it into this build", or almost everytime I fix a merge conflict, to understand why something is the way it is. I can grant that cherry-pick & blame are more rarely used, though blame is often on by default in many editors, and cherry-pick is something my team does da…

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 changes from the other committer.

I would be very happy if I could just merge to master every day, but that is extremely rare for me and my team.

Post reply on HN