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

621–630 of 821 posts

Re: Git is too hard

#621

Post by bch »

skulk wrote: post #614
simiones wrote: post #419

Earlier quoted context omitted.

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 have to understand a lot of things before you can somewhat comfortably use git, much more than something like P4. And conversely (at least in my experience), being very familiar with git makes it _really_ hard to work with something like p4.

In my experience, P4 is simply hard. Maybe my introductions were rubbish, but I’ve found it difficult in its own right.

Re: Git is too hard

#622

Post by chihuahua »

simiones wrote: post #554
harrisonjackson wrote: post #496

Earlier quoted context omitted.

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

Why is small frequent commits a good practice? What is to be gained from committing a change to a file, then a commit to undo the previous one if you decide the change wasn't useful/needed? Also, cherry is often needed daily in short bursts around releases. Blame is rarer, absolutely, but I don't think you're using your version control to anywhere near its full potential if you don't use blame (and log) while investi…

One benefit of frequent commits is that it allows you to go back to a recent commit in case your code gets screwed up and you want to undo some recent changes. For example, if you do a search/replace in hundreds of files and make a mistake.

Re: Git is too hard

#623

Post by tylerchilds »

> (And it does not have to be something separate than Git. It should maybe be just a really powerful abstraction built on top of Git.)

GitHub drooling now that their extinguish end-game will actively be welcomed by the community.

Re: Git is too hard

#624

Post by simiones »

rleigh wrote: post #568
simiones wrote: post #500

Earlier quoted context omitted.

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

No, I don't necessarily work any faster. But I will switch between multiple feature branches as necessary. And to keep up with master, I'll rebase my feature branch onto origin/master or depending upon the circumstance I'll directly merge origin/master. Both keep me up-to-date without a direct pull.

Well, if you're switching branches, you already have problems with a dirty worktree. Also, pulling can actually mean rebasing (I always use pull --rebase).

Re: Git is too hard

#625

Post by rakoo »

recursive wrote: post #492
WalterSear wrote: post #485

Earlier quoted context omitted.

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.

Check your local branch and the associated remote branch in your git log.

If the remote branch is an ancestor of your local branch, you have some commits that haven't been pushed yet and you can "play" with them.

If the remote branch and the local branch point to the same, you can't rebase without potentially impacting someone else.

If the remote branch and the local branch have diverged, it's already too late.

Re: Git is too hard

#626

Post by baud147258 »

I was doing a proof of concept work on transferring a mercurial repo to git, following the official documentation. I then used push --all to copy all the changes to the shiny new bitbucket server (corporate decision, we didn't had the choice...) then wonder why all the tags were missing. Apparently, by default push --all doesn't push the tags...

Re: Git is too hard

#627

Post by rossdavidh »

gizmo385 wrote: post #578
SoSoRoCoCo wrote: post #570

Earlier quoted context omitted.

Reading all of these threads, I think the conclusion is: we still haven't figured out how to do revision control in an intuitive way, because it is highly nonlinear and our brains just don't work that way. There isn't a clear vocabulary for intricacies of revision control, yet. And if you can't name something clearly, you can't explain it clearly. The author's idea of putting an abstraction on top of git is the way t…

> When is the last time you wrote a CLI utility and listed all of the commands, subcommands, and options to make sure they all had a consistent look and feel? Most single-author tools do not do this. It is a consequence of developing in a vacuum. Team-based development allows other eyes to look at it and say "why is checkout used during branch in a different way then branches are checked out?". Git came from, essenti…

Python an interesting example because, as the BDFL has ceded more control over development to others, it has been gradually losing some of that consistency.

Re: Git is too hard

#628

Post by adkadskhj »

ritchiea wrote: post #432
simiones wrote: post #419

Earlier quoted context omitted.

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…

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 funny, i use log multiple times a day. But i also stash things in my commit, per branch, and cleanup later. /shrug

Re: Git is too hard

#629

Post by gitowiec »

jgilias wrote: post #310

Git is as hard as you make it. It's a bit like raising kids. You don't bash them with the intricate model of the world that you have developed at an age when they are not ready for it. The police are the good guys, the criminals are the bad guys. Sure, there are places where it's the other way around, but you don't really go about telling them about corrupt police departments or authoritarian governments when they ar…

That is funny because I read that developers tend to behave as specialists of everything (here raising kids). And that is also sad because looks like a narrow minded point of view

Re: Git is too hard

#630

Post by 0xffff2 »

CuriousCosmic wrote: post #436
simiones wrote: post #419

Earlier quoted context omitted.

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…

Don't forget `rebase -i`, `reflog`, and `bisect`. Rebasing is always a good skill to know for when someone inevitably commits binary files or secrets to a repo and you have to do a bit of surgery to fix it. Bisect of course isn't required knowledge but by god is it one of the most useful git commands a developer could know.

I think I've used `reflog` maybe... twice in a decade of daily git use. It's crazy to me that anyone would think that it's a daily use command. I don't even know what bisect is off the top of my head.
Post reply on HN