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

671–680 of 821 posts

Re: Git is too hard

#671

Post by kelnos »

simiones wrote: post #447
masonhensley wrote: post #443

Earlier quoted context omitted.

Based on my experience - most teams will get by with ivanhoe's list. You additional items are definitely helpful - but the typical team member's workflow won't cross those bridges. Team leads perhaps. There's definitely levels of proficiency, but for a junior or even mid-level dev doing feature work, I think there red flags if they are needing to jump into stash, cherry, etc on a daily basis.

As I said to the other commenter - I don't even know how to use git without the stash, since you need everytime when you have some local changes but want to pull from the remote - the only alternative I know of is committing your local changes instead of stashing them. Also, git lfs and git submodules and their associated commands are necessary or not based on the project, not on your personal level of proficiency. I…

You can set `merge.autostash` and/or `rebase.autostash` to `true` in your global git config and then you can `git pull` with a dirty working tree.

Of course, to the point of this thread, that is yet another concept you have to understand to get a sane working environment. I assume autostash is disabled by default because the post-merge/rebase unstash could result merge conflicts and be a pain to unwind if you change your mind. If you just blindly set this option based on someone else's recommendation without knowing what the stash is, and things go wrong, you'll require a mental model of the steps involved to fix it, which you won't have.

Re: Git is too hard

#673

Post by pythonaut_16 »

bluehatbrit wrote: post #522
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…

Rather than a problem with GitHub, I think it's more just a problem of dominance. Git was originally designed for a work environment where people weren't on the same network, or any network at all when making code edits. At the same time, everyone wanted a copy of the history that they could change themselves to mirror their work. So we needed a tool which could be distributed, not require a regular network connectio…

It's worth highlighting that the Linux kernel was doing open source development using Git and email long before GitHub was created.

Re: Git is too hard

#674

Post by grey-area »

etripe wrote: post #587
grey-area wrote: post #64

Git's plumbing is simple and intuitive. Git's UI has grown organically and is still not great for common tasks like undo, however they are working on it and it is slowly improving. For example, they've just added a restore command which should make it simpler to undo changes (git restore filename): https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things Things I'd also like to see improved: Undoing things locally sh…

Excellent ideas! I agree with you on all fronts, exception git add --all && git commit. I don't believe those should be joined at the hip, because staging and committing should be two distinct actions/decisions. Defaulting to including everything would lead to too many human errors and would therefore be dangerous in my opinion. A distinct flag like git commit --all -m "foo" might be OK in my book. Possibly even addi…

Yes I don’t think they can change the default now but many many people operate this way (commit everything not ignored), so most of the time don’t need to separate stage and commit (I agree there needs to be a way to do it, but I use it rarely).

My preference would be a command like git save, but a flag would be fine I guess. This is a concept that most beginners don’t really want or need.

Ideally git should evolve so that beginners can learn say 5 standard commands without args, and that’s enough to get on with their work.

Working should be as simple as:

git save, git amend, git tag, git push

Make everyday use simple and easy.

Re: Git is too hard

#675

Post by gknoy »

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…

I almost never use `git pull`. I have a helper script (written by an ex-coworker's father ...) that fetches + updates my master branch head to the proper place, without changing away from my current branch.

If I want to have things-from-master in my current branch, I either rebase my branch onto master or merge master into my branch. (I'm lucky that my branches are short-lived enough that rebasing on top of master is almost always easy and the right choice.) If I have unfinished things, I'll make a "WIP" commit, that I will unroll later after doing the rebase.

I nearly never use `git blame` on the command line, but have a very frequently used hotkey bound to it in my editor to show the blame annotations.

Re: Git is too hard

#676

Post by Izkata »

ric2b wrote: post #561
jcelerier wrote: post #477

Earlier quoted context omitted.

> Obviously you can't undo that. I'd wager I press the "undo" button in gmail at least 3/4 times per week

That's because you have a 30s timer that doesn't actually send anything until it counts to 0. After it actually sends the e-mail, there's no going back.

And for like a decade this was only available under Gmail Labs, and without it enabled gmail would send immediately and couldn't "undo" the send.

Re: Git is too hard

#677

Post by _ikke_ »

thaumasiotes wrote: post #357
Debug_Overload wrote: post #332

Earlier quoted context omitted.

That's just for compression. Commits aren't diffs, and when you checkout stuff, git doesn't do diffs to give you the working directory at that point. See https://stackoverflow.com/a/25028688/8272371 for detailed explanation.

> See https://stackoverflow.com/a/25028688/8272371 for detailed explanation. There is a disconnect somewhere. The linked answer says: > Now, git is different. Git stores references to complete blobs and this means that with git, only one commit is sufficient to recreate the codebase at that point in time . Git does not need to look up information from past revisions to create a snapshot. > So if that is the case, the…

What you are missing is the difference between gits object model (with loose objects) and packfiles. The delta compression happens when you run `git gc` (git does this automatically as well on occasion), and packfiles is how git fetches and pushes history.

But when you create a new commit, that commit object is stored as a loose object, with any new file blobs and tree objects. This represents a complete snapshot of your working tree.

But git does not need to make a complete copy of the working tree on each commit. Because objects are referred to by the hash of their contents (with a git specific header), git only needs to store each version of a file once.

Re: Git is too hard

#678

Post by circularfoyers »

dkdk8283 wrote: post #318
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.…

When I first started writing software I would often rewrite third party libraries I didn’t understand to reduce complexity. After growing up and becoming wiser I came to understand I did this all because I didn’t invest the time to learn how these complex things worked. It also made me feel smart to write more code. Big mistake. I can’t help but think a little bit of this pattern rears it’s head as the motivation for…

I still agree with your sentiment but wouldn't have writing more code still made you a better programmer when you were presumably still learning?

Re: Git is too hard

#679

Post by crispyambulance »

balabaster wrote: post #557
crispyambulance wrote: post #534

Earlier quoted context omitted.

We have no choice but to "get over it and get on with it". But it DID NOT have to be that way, and that's what makes many people keep their resentment. It's like a kind of "hazing" experience. Thankfully there are tools that make it less horrible. Git Tower and Visual Studio integration come to mind as examples. It's sad, however, that there's not been an overhaul of the git commandline into something coherent and us…

Ugh... the visual studio integration is HOOOOOORRRRRIBLE. I hated it. It didn't do anything to make my life easier. You know what made it bearable? SourceTree, and I tried GitKraken way back when it was first launched in beta, it seemed like it was on the right track but lacked too many of the features at that time. I would highly recommend SourceTree though.

FWIW, the latest git integration in visual studio seems to be better.

Re: Git is too hard

#680

Post by dang »

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 :-)

Please don't perpetuate tit-for-tat spats on HN. I know it's hard to walk away but they're tedious (to everyone else, at least) and off topic.

https://news.ycombinator.com/newsguidelines.html

Post reply on HN