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

461–470 of 821 posts

Re: Git is too hard

#461

Post by mumblemumble »

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.

Cherry-pick probably depends on what kind of software you're working on. If there is alway exactly one version in production (two if you deploy gradually), then I don't see it being needed often. If you are supporting multiple versions at once, then it ends up getting used just about every time you have to fix a bug.

Re: Git is too hard

#462

Post by recursive »

jamienicol wrote: post #452
recursive wrote: post #407

Earlier quoted context omitted.

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.

I believe I've really only needed to do that once. git bisect handled it in about 10 minutes IIRC. It's hard for me to imagine how I could achieve a net time savings against that level of commit-hunting.

Re: Git is too hard

#463

Post by Tokkemon »

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

This is why I use Git Kraken. It abstracts away all the nonsense and gives me a lovely interface to work with my repos in a user-friendly way.

Re: Git is too hard

#464

Post by mcs_ »

I use a straightforward workflow, protecting master with PR, with some alias to create a new branch, pull and push, pick, and log.

I never used the GUI. It seems really complex for what we decided to be our workflow. Git is a complex software that can solve complex contexts, but you can limit your daily workflow to a few commands.

Re: Git is too hard

#465

Post by rleigh »

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 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 would require stashing, since all changes are done on feature branches.

Re: Git is too hard

#466

Post by [deleted] »

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…

[deleted]

Re: Git is too hard

#467

Post by jrumbut »

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…

It sounds like you're using a very different and much more complex process than average. Keep in mind for a lot of web projects releases are every day, sometimes multiple times per day.

If you take out the concept of builds, you just have short lived feature branches off of master, you're left with perhaps even less than the 8 commands listed above.

Re: Git is too hard

#468

Post by jariel »

jamienicol wrote: post #174
jariel wrote: post #148

Earlier quoted context omitted.

So this, to me, is not a 'benefit of git' it articulates in some ways how bad it is (although very powerful). Most people can get going with those 99% commands quite quickly, the problem with git is any move from the known path creates some pretty amazingly complicated scenarios. And those '1% of the time' commands blow up into time-consuming rabbit holes of complexity. Often, Stack Exchange has several answers for t…

You can't push a rebased branch without`--force`, and the server can be configured to disallow it entirely. This is exactly how it should be: I want to be able to rebase my by public branches but not the public branch.

" I want to be able to rebase my by public branches but not the public branch."

Already that's a little bit complicated though.

Even though yes, this use case probably does exist, it might be a tricky thing to unwind for some people - what would they do when they have already changed the history of 'their' public branch (?) is something they'd have to carefully think about.

Re: Git is too hard

#469

Post by bntyhntr »

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…

At work I have 30 stashed things some of which go back 2 or 3 years. I got distracted when I pull and forget to pop sometimes, or I was working on something so trivial I never unstashed it.

That doesn't seem great... Usually these days I try to put my temporary work on a temp commit or branch at least so I don't lose it to the stash. I'm not saying I'm stashing properly, just that stash is easy to mess up.

Also probably half of these are things I popped but had merge conflicts or something. I fixed the merge conflict why is it still there? (I know the reason, but still).

Re: Git is too hard

#470

Post by tgbugs »

javier10e6 wrote: post #457

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.

Compositional UIs are extremely hard to learn. You have to be a composer! Quite a high bar, but once you can clear it, you can do things that others consider impossible. Like writing a Symphony Fantastique. Wrapping the composable interface so that the 80% use cases don't require the user to be a composer is the challenge here, and what is interesting is that GitHub seems to be failing so miserably at this according to the folks in this thread.
Post reply on HN