Hacker News Reader

Comment by andyjohnson0 | Hacker News Reader

> I believe the core issue is devs like above never take the time to “grok” Git.

The problem I have with git us that it's just too complicated. When I'm juggling project complexities and design complexities and implementation complexities, I frequently don't want to have to deal with git too.

I understand how to stage and check in and squash, and branch and merge, and how to manage remotes. But last week I still managed to get a new repo into a state where I couldn't push local changes to github without doing a pull first, and I couldn't do a pull without (apparently) first updating the remote. I had a hard deadline and ended up deleting the repo and starting fresh. Nothing much was lost. I never had this trouble with tfs...

Maybe I'm just not clever enough, but I've never come across a dev tool with as much surface complexity as git.

(Not a git hater. Use it every day. Have had a personal github profile for a decade. Etc etc.)

View on HN

I've resigned myself to accepting git because I have to use it. But JFC, I've hated it from the first time I tried it.

We now have a large selection of tools that allow you to visualize what's going on (I use git-kraken), as well as google for help on doing something that isn't in muscle memory.

But, really, SO MUCH pain and suffering could have been resolved by refactoring the damn commands to something more coherent and consistent. Git people sometimes call this "porcelain"-- which I guess is an apt name because it makes one think of a toilet (but an improvement to a hole in the ground).

> We now have a large selection of tools that allow you to visualize what's going on (I use git-kraken), as well as google for help on doing something that isn't in muscle memory.

Git Kraken is excellent, though Git has a page on various GUIs, many of which are free with no restrictions: https://git-scm.com/downloads/guis

Personally, on Windows I like SourceTree: https://www.sourcetreeapp.com/

Some that have worked with SVN back in the day like TortoiseGit: https://tortoisegit.org/

On *nix Git Cola seems to do the job for me: https://git-cola.github.io/

Then again, the most complex workflow I've worked with was Git Flow and I didn't need anything more advanced than that. Come to think of it, I don't really do rebases often either and mostly just take advantage of squashing commits through GitLab/Gitea and such, when needed. But hey, that's also valid, using Git in a way where you get version control but mostly keep the technical details out of your way (though Git LFS and certain cases with particular line endings being needed does make you drop down occasionally).

Seconded. Git, like Linux is used everywhere, you can't avoid them. And even though I use it externally locally I use subversion, whose commands make a lot more sense to me. But Linus has something going for him: he knows how to establish critical mass for his projects, and how to create viable ecosystems.

i am no apologetic for the messy git UI. But i also know that any competent software engineer can be given a sufficient understanding / mental model of the basic git way of doing things in 1-2 hours, after which they can Google for the exact syntax of the commands they need (if they are doing complicated things). i feel that if they are unwilling to invest even that much time, then they are going to waste an eternity on endless tools and GUIs.

it's like tar or rsync or ffmpeg. Yes, it's hard to keep track of all the command line flags etc. but thanks to the internet we don't need to. it's far more useful to understand the underlying concepts.

Git is intrinsically a graph model. It's well-suited for very rich and effective visual representations.

If the cli "matched up" with a visual way of thinking, for many of us, the cli would become second nature. But it just doesn't match up. It's fugly and needlessly hard to remember and become fluent in at least for us "incompetent" engineers who already have too much to work on.

And how do you KNOW this? My experiences-- and many other's experiences have suggested otherwise.

Also it's foolish to suggest that one of the 21st century's most complex repository management software is just like tar, or rsync. What planet are you from?

This is maybe the most cogent version of my exact feelings on git I’ve ever read. In theory, I have no issues with git! In practice, the UX is often very very bad.

I teach git professionally. I have a 3-day 12-hour course I give.

I'm amazed how many people who have used SVN or CVS just assume git works like that but with different commands. And, of course, they get very screwed up. (GitHub contributes to this problem, too, with their own set of commands like "forks" and "pull requests" that aren't really a part of git.)

One you understand the Merkle DAG that's at the heart of git, understanding the rest is simple. Yes the commands are named badly, but get past that and it's a great system.

These days, with more young people developing, it's less CVS assumptions as such and more a Frankenstein of cargo-culted CVS assumptions they got at a remove from the Internet and Github's truly awful and confusing web interfaces.

You can't even get a simple gitk-style graph visualization on Github. Which is a website. After so many years, I really think all the blame for developer confusion can be laid at Github's feet.

There's been a graph visualization in GitHub for a long time, they've just intentionally buried it. Currently: Insights tab > Network

Arguably they buried it because it isn't actually what people want when they are looking for commit information. I know I've confused many developers by showing them gitk. I've been slowly working on a hypothesis that "subway diagrams" of commits look fantastic (Git Kraken looks great in screenshots) but get in the way of actually getting work done, much less thinking about the git DAG as an important tool beyond just "visualizing branches". (At this point I keep threatening to build a --first-parent based drill-down UI, that would look ugly as all get out in screenshots but might be a joy to actually use, but so far no one has sent me the check to make good on that threat.)

I wondered if someone would mention that this time around; it is a really bad piece of slow javascript that shows completely whacked-out graphs though, because it is trying to show the "fork" feature from github (and doing a poor job), not really the gitk or log --graph output of anything.

Yes, first-parent and expand would be a good way to view history. Github is a website and should be providing new and interesting ways to view information, not failing to provide even the basic lowest-common-denominator view (the gitk view).

12 hour days? That seems way too long. How did the participants handle the amount of information over the time period?

No! It's 12 hours over 3 days.

Apologies for misreading. That makes much more sense

It is not outside the realm of possibility that Github itself had a problem. I've seen instances where "git fetch" pulls refs but not the objects pointed to by the refs, then it gets cleared up an hour later and my builds suddenly start working again.

It's almost pure happenstance that Linus's idea of Git being distributed lent itself to the Cloud hosting business model. And the hardest thing to teach is the mental mapping of local and remote refs.

So this isn't just Git being too complicated. It's a confluence of several factors that would never have been possible if Git had never happned.

One thing to remember is that a pull is fetch + merge. I always fetch first which doesn't change any local branches. If that doesn't work fix your remotes. You can always recreate your local branches to track remotes, then reset to specific git hashes (if you take note of them or give them temp branch names).

You're not alone. Git is an embarrassment to our profession.

No, it isn't. It's just a tool designed to work with complex software development workflows, which 90% of software projects do not need. 8 commands (pull, fetch, merge, push, add, commit, checkout and branch) are all you need to get going for git, which is like 2-3 more than what you need for svn/cvs. It's like getting upset that cars that are manual have an extra pedal (clutch) compared to automatic cars with their 2 (brake, accelerator).

Why does any serious workflow require you to be in the middle of an interactive rebase all the time?

Huh? You only rebase when you're either:

* Trying to shorten commit history

* Trying to merge feature branches together (main or other feature branches)

* Trying to remove feature branches

None of which are necessary in a lot of development models. If you have that many feature branches that you have to rebase constantly, it doesn't sound like feature branches as a concept are properly understood.

The idea behind feature branching is one of 2 models:

1) either the main branch always works, and development is done in a feature branch, only to be rebased into main when development, testing, and sign off occurred, or

2) serious bug fixes occur outside the main branch, to be re-incorporated back into the main branch once it's been proven to be effective.

The 1st model should only require a rebase when the feature is complete. The 2nd model MAY require a couple of rebasing, dependent on how extensive the bug fixes are, and how fast the main branch is moving along, but not to the point where constant interactively rebasing your branches is the norm.

If you're writing a local stack of commits, you need to do an interactive rebase to edit the commits in the middle. You can't just check out and amend earlier commits in the stack, since git has a branch-first rather than commit-first model (one of its biggest UI failures).

No, I don't. Again, this seems to be a personal design/preference rather than a behavior git is forcing upon you, which is my point (This isn't a git issue, this is a development workflow that seems needlessly over complicated). When I do development locally, I only commit changes I want to keep. If there is something wrong, or code that needs to be modified, I make those changes, and then commit. When the work is done, if pressed upon me by the team, I rebase the local commits to a single commit before submitting a merge request.

It's the same development workflow used by the Linux kernel? You know? The project that Git was invented for?

There are tons of different workflows used by Linux Kernel maintainers. Some of them don’t even use Git except to submit patches.

Whose workflow are you trying to emulate? (followup question: and why?)

Are you working on something as complex as the Linux kernel?

None of my serious workflows require rebases, much less interactive ones.

Not that I don't do interactive rebases sometimes in local branches, but that I absolutely do not make them a part of any more general workflows. I rather try to avoid rewriting shared history where I can, and I'm happy with DAG navigation tools like --first-parent.

How do you manage stacks of commits for code review? (I'm guessing you just don't -- a lot of git users have really messy, unprofessional repository histories. The fact that git doesn't have great tooling for history management is also an embarrassment to our profession)

As I stated in the comment you are replying to:

> Not that I don't do interactive rebases sometimes in local branches

I don't have a problem with rebasing in local branches before code review. I just don't allow rebasing once a branch has started code review, and I especially don't allow rebasing in a public integration branch ever.

(I also rarely feel the need to rebase, personally, even in my own local branches. Working in better tools than git in a past life has given me a lot of the discipline I feel that I need to build good commits as I work. I make much more use of the git staging area than I see most devs generally do and use `git add --patch` and `git add --interactive` far more than `git rebase`. `git add --patch` especially is an under-sung hero that I think a lot of junior developers should learn well in advance of rebase.)

Also, I'm just not that bothered by messy histories in code reviews when I review other developers work. If the idea comes across even if the commit messages don't have the greatest narrative flow or are perfect, I'm perfectly fine with that. I make sure all merges are --no-ff and after that I can browse a "clean" history post code reviews with DAG traversal tools such as --first-parent. But that also gives me an opportunity to dig back into the mess months or years later after the code review if I need to research a bug or a regression. That sort of "sewage archeology" isn't "fun" by any means, but the number of problems I've been able to solve with it is high enough I appreciate keeping that mess around in source control. It's source control's job to keep the mess for me and present me pretty views for more regular work. That's why I prefer to trust tools like --no-ff and --first-parent over --squash, because that's what source control is built to do, control old histories messy or not.

What can I say. You're locked into a significantly worse maximum than is possible (and exists) using better tools. In a normal workflow your commits are small enough that you don't have to do "sewage archeology".

I don't think you are reading me correctly. That is a rare occurrence, but it is possible when using merge commits to correctly describe the DAG. It's entirely impossible if you overly rebase/squash. Those rare times that I've needed to do it it have "saved" a project a lot of time from a major bug or regression. My normal workflow I look at a "clean" faux linear view, but it's just the "--first-parent" view of merge commits, which gives me a "PR focused" or "integration focused" view of source control first.

If your average commit size is 30-40 lines of code, this isn't an issue. Stacks of small commits is a time-tested workflow, used by the Linux kernel among many other projects.

I think we are talking about different things at this point, but I may be losing the thread of your argument here.

I love a code review to consist of lots of small commits. I'm mostly fine if even some of them from developers more junior than me are just named "commit" if they are small.

When I finish the code review I prefer to only `git merge --no-ff`. All those small commits stay in the code history in the exact form they were reviewed under.

If I'm looking at history I'm most often using something like `git log --first-parent`. In my --no-ff integration branch that just shows me an integrated change list (PR list). Git gives me a "straight line" view down the DAG and hides irrelevant information I don't want in that moment like all the small "commit" commits.

If for some reason I find a bug or issue in some code, I may need to drill down into specific small commits including the "commit" commits, and I have that ability because all those commits are still in the DAG.

Finally someone comes out and says it - I totally agree. I don't recall ever having to have a "tutorial" on Subversion. Git solves a problem the average dev really doesn't have in the first place.

It was painfully difficult to branch in subversion. And remember the agony of asking someone to check in a file so another developer can check it out?

Branching was just a copy? What was so hard about that?

As for check-out locks. you only had to ask them to do that if they'd requested a lock on the file which was not the default. I hope people weren't doing that too often at your workplace.

Merging is an operation which takes three inputs: left, right, and common ancestor. This is a very old algorithm, the diff3 utility on Unix is at least from the 70s I think? The reason history is a graph is to walk the graph and find common ancestors. Subversion's model cannot do this (screw off, pedants, I know they added an attempt at detecting common ancestors after Git had long since supplanted Subversion in relevance).

And if you can't merge, you can't branch. And if you can't branch, you need locks.

I'm just saying, as someone who has used subversion quite a lot over the years, the situation he is describing where you have an exclusive lock where they have to check in before you can, does not happen. Exclusive locks are very rarely used in subversion. If you and your coworker are working on a file, and he checks in before you, you will simply have to update and merge. Similar to if you were both working on a local git or mercurial tree.

Oh, and in that situation the 3 way merge is between the version he checked into the repo, your local version you are trying to commit, and your parent revision.

Well put! And it demonstrates why people (like the HN'ers who think they're 10xers) have trouble with git. They fundamentally don't understand the problem and how git solves it.

This is correct, and yet Git is an embarrassment to our profession. That's how bad it is.

To be fair, Subversion had plenty of serious limitations. Local commits are a really good thing. It's just that Git itself is a terrible UI around a bunch of decent ideas.

Sure. Absolutely but there were some benefits to its simple model that are still attractive for a corporate env.

https://www.bitquabit.com/post/unorthodocs-abandon-your-dvcs...

One of my fav rants on this subject.

Mercurial should have won, it's superior in every way. For pesonal projects I use Fossil, which is fantastic.

I organized the migration from CVS -> Mercurial at my last job, and finally after several years when it became clear Git was where industry was headed we switched from Mercurial -> Git. After resisting it for a long time and then being forced to use it for a collaborative project with another firm, I have to say git is way better at being a DVCS than Mercurial.

I think, as other have mentioned, that once you truly "grok" git you begin to understand the elegance and simplicity of the system and how its layered. Ultimately git's use of branch pointers was a way better solution than encoding branch data in the commit itself. To it's credit Mercurial did attempt to rectify this later with bookmarks, but ultimately DVCSs are about branch management, and git has always excelled at it.

Mercurial's branch management makes more sense. If you want to know which branch a commit originated from in git, good luck.

Many things in git, are frankly anti-patterns in any other sane versioning system - comitting partial changesets because of the index? gross. Rewriting history and force pushing? absolutely insane.

The fact that I don't have to "grok" mercurial like you need to git is actually a plus. Mercurial can do everything that git does (and more: check out changeset evolution in mercurial, it blows anything you can do with git rebase out of the water) and it doesn't require Ph.D. level knowledge in directed acyclic graphs to do it either.

> Mercurial's branch management makes more sense. If you want to know which branch a commit originated from in git, good luck.

`git merge --no-ff former-branch` by default includes "former-branch" in the auto-generated merge commit name. When it matters what branch a commit "originated" on, it's very easy to use `--no-ff` (which doesn't rewrite history and won't need any sort of force push!) and most PR tools used to default to that before "rebase" and "squash merge" became some people's favorites because of some weird (in some cases OCD) wish to see SVN-like straight lines only in their commit history.

It isn't a "weird ... wish", a linear history is the correct default. Merges have always been, and should continue to be, a tool of last resort. In general it is good to minimize complexity in life.

Merges are the default state of life in any source control system with more than one person or machine involved. They are a regular, required need. Sweeping them under the rug, pretending that they don't happen, acting like they are rare is exactly the sorts of things that added complexity to systems such as CVS, SVN, TFS, Perforce and much more. It is exactly what adds complexity to so many of these rebase-only and squash-only workflows people like to constantly post about using in git.

Linear history is a punchline that ignores the reality of source control. The only truly "linear" history I'm aware of in source control is systems built on patch theory/operational transforms/CRDTs and that form of linear is subject to reordering and still needs explicit merge commits with (implicit) multi-commit dependencies even if there are few stated needs to visualize that as a DAG.

I agree with you, in general it is good to minimize complexity in life, which I why I eliminate rebase workflows and squash merges from mine. I prefer to see the evidence of where merges happened (and they should happen early and often), and graph data structures are very familiar to me as a software developer, including traversing them. (And git offers useful traversal tools such as --first-parent for when you want to view the DAG more like a linear history and ignore some of the noise. There's no reason to artificially simplify the DAG when DAG traversal is easy and accurate.)

Reply on news.ycombinator.com