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

451–460 of 821 posts

Re: Git is too hard

#451

Post by robotnikman »

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

I agree with the SVN part. I learned how to use SVN before git and it helped me with learning how it worked.

Re: Git is too hard

#452

Post by jamienicol »

recursive wrote: post #407
jamienicol wrote: post #400

Earlier quoted context omitted.

> The vast majority of people do not. That's a very bold claim. It's certainly been the expected workflow everywhere I've worked. You might consider it a waste of time but I'd wager the resulting mess of commits from not doing so wastes far more time in the long run.

I've never worked in an environment where it was expected or used. As far as I can tell, no time has been wasted as a result. How would it cause time wasting?

Without a clean history it takes longer to find which commit changed things and why.

Re: Git is too hard

#453

Post by lionkor »

simiones wrote: post #438
ritchiea wrote: post #432

Earlier quoted context omitted.

I think of log, cherry-pick, stash & blame "quarterly use" commands rather than "daily use" commands. log maybe monthly, the rest quarterly unless you're doing something wrong.

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…

`git pull --rebase` ?

Re: Git is too hard

#454

Post by simiones »

linuxftw wrote: post #431
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…

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

You need to use either merge or rebase, or git won't allow you to push. Also, pull doesn't modify your remote tracking branch (origin/branch) - fetch does that.

I do agree that usually, when you have a local branch dedicated to a particular remote tracking branch, it's not a good idea to merge the remote into your local branch - it's generally much better to rebase your local branch onto the remote tracking branch (pull -r).

Re: Git is too hard

#455

Post by beagle3 »

wpietri wrote: post #429
thrwyoilarticle wrote: post #213

Earlier quoted context omitted.

+1. The very first question: >Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it? Is a Github problem, not a git problem. You might as well ask how to unsend an email. If you don't know what git push means, you shouldn't be using it and are playing with intellectual property fire. The conflation of Github with git is responsible for a lot of confusion. Having Github be your first interac…

> You might as well ask how to unsend an email. That is also a reasonable request. I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer. The whole point of computers is to do things for people. With physical messages, unsending has at least partial support. Before the mailman picks up from my porch, I can grab a sent message any time. I…

> The reason email doesn't support unsending is not some essential property of messaging. It's just that at the time our email protocol was defined,

email supports unsending in exactly the same ways you described for packages. It most definitely is a property of messaging.

Your fron porch is called "outbox". works the same - you can delete from outbox before sending.

If both you and your recipient are on a properly configured Microsoft Exchange server, you can unsend a message, which is similar to the university department.

And if you aren't, you can still send a message saying "hey, please don't open the last email", and it's up to the other side if they do or don't.

For better and worse, email has a lot of similarity to real mail, down to the distinction between content and envelope.

The main difference is the speed of delivery - you would not expect any of the ways you suggested to work 3 months after you've sent your package -- and yet, compared to the 500ms or so that it takes the email to reach the recipient, that's what attempting to unsend after one minute is.

Re: Git is too hard

#456

Post by outsomnia »

recursive wrote: post #380
larzang wrote: post #343

Earlier quoted context omitted.

Completely agree, a change is an atomic change and should be contained in a single commit, I don't need to know the sub-steps it took to arrive at the final solution when I'm trying to blame or log the reason it changed 6 months from now. It also encourages bad commit messages which further confuse change history and motivation when you're creating separate commits just to fix formatting and such in your real change.

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…

Rebasing one tree on another is a pretty specific thing, you may not need to do it very often.

But casually manipulating the order of, or combining or filtering, patches near the top of the tree is something else. There are tools for this, eg

https://github.com/stacked-git/stgit

Re: Git is too hard

#457

Post by javier10e6 »

Git is like piano. You can play chopsticks or Berliotz. Are piano's too hard? Unlike other tools out there, git is utterly transparent on the mechanics above and under the hood. This coming from someone who has gone trough the gauntlet, MS Visual Source Safe, ClearCase, CVS, Subversion, Razor and (gasp) Perforce.

Re: Git is too hard

#458

Post by [deleted] »

lionkor wrote: post #453
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…

`git pull --rebase` ?

[deleted]

Re: Git is too hard

#459

Post by simiones »

lionkor wrote: post #453
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…

`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 think, but that is relatively recent (maybe 1 year?)

Re: Git is too hard

#460

Post by horsawlarway »

wpietri wrote: post #429
thrwyoilarticle wrote: post #213

Earlier quoted context omitted.

+1. The very first question: >Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it? Is a Github problem, not a git problem. You might as well ask how to unsend an email. If you don't know what git push means, you shouldn't be using it and are playing with intellectual property fire. The conflation of Github with git is responsible for a lot of confusion. Having Github be your first interac…

> You might as well ask how to unsend an email. That is also a reasonable request. I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer. The whole point of computers is to do things for people. With physical messages, unsending has at least partial support. Before the mailman picks up from my porch, I can grab a sent message any time. I…

I think you're twisting the problem statement a little here.

Asking "How do I unsend an email" is just as unreasonable as asking "Hey, give me that gift I gave you back".

The problem is that, regardless of your intent, you've given something to someone and they own it now.

You can't undo that without involving the 3rd party (Or breaking the law and stealing it, digitally for the email).

And I want to be clear upfront - THIS IS A GOOD THING.

I don't want Amazon to be able to "unsend" my receipts. I don't want Google to be able to "unsend" my support chat log. I don't want my boss to be able to "unsend" his approval for my time off.

This system is designed explicitly to put the USER first. But it treats each side of the exchange as user, and values them equally - If they disagree, it's not the system's job to resolve that, they have to talk it out.

Slack and Messenger (and a lot of other modern chat) have an arbiter - They don't require users to agree because they own the content, not the users. In a company slack, I haven't given you anything when I message you. I've just pinned something to the company message board. I can take it down, and so can anyone else who has the key. It's not mine and it's not yours - It is very clearly owned by the company.

That can work great in a well structured environment, but I have to laugh when you say its replacing email. It's not a replacement, it's a complement - They are not the same things.

Just like an oral promise with no witnesses is NOT the same as a signed receipt. Use each as needed.

Post reply on HN