Hacker News Reader

Comment by emodendroket | Hacker News Reader

I never feel this way. When I started to use it, I only had to understand a few concepts. And when it started to get more complex, it was because the things I wished to do were more complex in the first place.

View on HN

Honestly, git is absolutely needlessly complex. The worst aspect of git is the almost arbitrary naming of tasks that hardcore git users swear are obvious. E.g. "cherry picking", "fast forward", "rebase". Anyone not familiar with git will balk at the concept that the intent of these phrases are obvious.

Note: I use git frequently every day, not by choice, but simply because it is the defacto version tracking system. I have grown to like it, but I miss the more straightforward every day use of Mercurial (which is rarely supported by any services anymore).

Edit: ... and as a native English speaker, I can't help but feel bad for others who are expected to become familiar with these functions without familiarity with these colloquialisms.

If you used SVN or something similar, daily, prior to git existing, git operations actually does seem pretty obvious.

As the poster pointed out, he's coming from Mecurial, which is a DVCS similar to Git.

Fossil was designed by someone coming from CVS, so its everyday CLI is actually closest to that. As a Subversion expat, I found Fossil quite easy to pick up, modulo a few quibbles that muscle memory sorted out quickly enough.

Perhaps, but it originates from the days you'd run `man git <command>` before using it. `man git rebase` works and has a very lengthy description with example tree states.

git-remove-ref-format vigilantly removes non-annotated remote ref formats using non-configured upstream branches, while applying applicable parents to transfer the given ref formats.

https://git-man-page-generator.lokaltog.net

Well, sure, the names aren't obvious if you're not already familiar with them, but neither are names like "linear probing." New concepts come with new names.

The complexity isn't needless, it is hard to find a part of git that can be simplified without losing something important.

But the command line user interface is one of the worst I've ever seen. The names are bad, discoverability is poor and which command line tool does what doesn't always make sense.

I completely agree. Git is a product of its requirements. It's not perfect, but it gets the job done, and obviously it does it pretty well.

Products don't have requirements, users have requirements :)

The requirements of Linus and the kernel developers are completely different from the requirements of the vast majority of users of Git, who are using it in small teams in a centralized way.

I would argue that the only benefit that this decentralization gives is a local cache, which makes things nice and fast. Most users don't need to be able to create branches easily (code review tools already let you do that, effectively) and it's just given people enough rope to hang themselves (e.g. GitFlow).

IMO the worst aspect of this needless complexity is having to explain to people "you've got 1) the branch central repo, 2) your local copy of that branch, and 3) your local branch". It gets even more complicated when personal forks come into the picture, as there are just so many copies of things to manage or trip over.

Try explaining to a junior developer why "git fetch" takes two arguments ("origin" and "master") while "git rebase" takes just one: "origin/master".

I'm not sure it's so obvious that it does it well. The thing about the tech industry is there's a lot of cargo cult and leader/follower mentality. There are plenty of shops that use git just because every other shop uses git. Chances are, most of them don't need anything nearly as complex as Git and other version management approaches for their project would suffice just as well.

It's sort of how a lot of shops decide they need to incorporate 'AI' into everything, or they need to use microservices and Kubernetes to solve their problem. Some of it is just resume driven development but a lot of it is just observing and following trends.

> The thing about the tech industry is there's a lot of cargo cult and leader/follower mentality.

> Some of it is just resume driven development but a lot of it is just observing and following trends.

Couldn't agree more. That's exactly what I think happened with git.

Why the while "first stage, then commit" workflow though? Wouldn't it be simpler to just commit?

One of the ways I use the staging area is as an ephemeral wip commit: I've got a change that runs and gets me incrementally closer to the desired result, but isn't yet an atomic commit. Changes to that state can be built upon, undone etc until I've got something I'm happy to commit.

I often have local changes that I do not want represented in my commit (e.g. that code isn't done yet), so what would I do with those changes? One solution might be to stash them, select files while doing a commit, or otherwise put them aside, but that feels like reinventing the stage-then-commit workflow. That said, adding an alias for adding everything and committing it in one shot seems like a worthwhile quality of life change.

I find it's common that I want to change stuff in my local dev environment with changes I don't actually wish to commit -- let's say hardcoding to some folder on my local machine in a configuration file, or something like that.

Loosing something that a lot of people doesn't need and will probably never use. Beside the Linux kernel (that git was created for) or other big projects, most developer will only use a bunch of features.

The command line is shit, one example: `git checkout` can both switch to a new branch or restore a file.

Fossil is that thing: a simplified DVCS that doesn't have important bits missing.

There are certainly cases where Git is the right tool, but it's vastly overapplied, used because it's popular, not because it's the best tool for every job. For smaller projects without a lot of randos offering PRs from the outside, Git's probably costing you more in its complexity than it's saving you by having that complexity at hand.

> Fossil is that thing: a simplified DVCS that doesn't have important bits missing.

One of Fossil's selling points is that it's missing several important bits (i.e. all the tools for rewriting history)

Exactly. The Linux requirements are the single most complex problem and they need the power of git to handle that complexity. The problem isn't git.

The issue is that everyone is using the most complex tool, from solo developer, to 10 developer teams, to 1000 developer projects. You should use the simplest tool that gets the job done for your project[0]. That isn't git, but it's so easy to just pick the thing that "scales".

[0]: https://blog.codinghorror.com/the-principle-of-least-power/

If you've used a tool like Looker that tried to ignore the difficult parts of git, you'll quickly realize they are not ignorable, but necessary.

Genuinely curious: what would you rename cherry picking, fast forwarding, and rebasing?

I would eliminate these tasks from the aspect of the user and provide a more straight forward way to accomplish the same intent. You make a good point though because this is easier said than done with a typical terminal based application.

You want to remove fast-forward and rebase from a graph based version control system? What would you do instead? Always merge?

It's been working for me so far :)

It sounds like he wants a GUI so you’d just drag and drop.

Isn't that the hg concept, no history rewrites? Well it's more nuanced than that but you have much less freedom, I think

I don't think it makes sense to eliminate these, but I'll toss in "Take Commit" as an alternative name that might be more obvious than "Cherry Pick". Still, once you know it, you know it. You'd still need to understand what Take Commit means to use it effectively, but it would make it easier for a dev to learn it the first time.

Take commit sounds like some weird version of merging a pull request to me. Like you've sent me some commits and now I'm going to take them.

Cherry pick on the other hand has a non-technical definition that closely approximates what it does in git: https://www.merriam-webster.com/dictionary/cherry-pick

I’d answer that if I knew what they did. But I’ve only used git for 3 years now, so still a novice I guess.

If your git history were a tree: cherry picking is ripping a leaf off and gluing it some arbitrary place on the tree, fast-forwarding is ripping the leaf off and moving it to the end of the branch it’s on, and rebasing is ripping a branch off and gluing it somewhere else.

EDIT: cherry picking is actually making a copy of the leaf and gluing it elsewhere. And fast forwarding isn’t really moving the leaf, it’s taking the leaf you call BRANCHNAME and now calling a leaf further up the branch BRANCHNAME.

Yeah, all these are useful to prune the bonsai. It matters more when the project is big or has lots of branches, of course, but they have benefits even for a single developer.

agreed.. cherry-picking is actually a ridiculously good name.

Yes, it can be that way.

I know/use clone, diff, add, commit, and pull/push.

That is all I ever do with Git, and it's pretty straightforward. I have found no need for the rest of it, and it confused me when I tried to look into it.

Did you ever use any other VCS?

I used mercurial a bit when I was starting out but I saw which way the wind was blowing and switched.

Kind of similar. I went from Subversion to git, then tried mercurial. I found mercurial to be more natural, and still use it for my own projects. I have never seen it used in the workplace though.

My workplace switched from hg to git. Hg didn't get support for all the other tools we use. The Jenkins hg maintainers were all using git when we checked, and it showed. That is but one example of a tool that didn't work with hg.

Subversion, and mercurial to a lesser extent.

CVS and Visual Source Safe way back in the day.

Intersting. I always found git needlessly obtuse, with for instance the status reporting diffs to local remote-tracking branches instead of the actual remote branches, the staging area having an unclear purpose to me at the start, that it mixes up "local" "remote" and "base" depending on how an operation is implemented, commands doing double duty providing wildly different functionality etc..

Yes, coming from Subversion the whole staging area concept seemed like needless complexity. For my purposes it still is, but I've gotten used to it.

It seems like a nice way of having changes you don't actually want to commit but I'm not sure how other systems approach that problem.

I really liked Perforce changelists, so in theory I should like the staging area, but I kind of don't :)

I use it nowadays, but I think it's too limited to provide value like Perforce changelists does.

I'd like to have one changelist for random local dev changes, like setting debug flags or turning off optimizations. Stuff I have no plan on checking in.

Then I'd like to group my edits into maybe one to three possible future commits.

The staging area doesn't allow this, I need to keep doing "git add -p" and carefully sidestep all the debugging stuff, plus that I can only work on one commit at a time.

So could have been useful, but not so useful in it's current state IMO.

> plus that I can only work on one commit at a time.

This is that part of git that bugs me the most! It's totally hostile to the way I prefer to work: one screen session containing all the editors and shells per change that I am concurrently working on. Git simply cannot do it, unless I clone the entire repo for every change, which is not practical for large projects.

Because it’s file based, and that’s obviously behind a lot of the criticism coming from the author of Fossil.

> simply cannot do it, unless I clone the entire repo for every change

Note that you can have multiple working copies from one clone for a few years now. git worktree add <path> <branch>

When I am working on assembling multiple commits at once, I make a large number of small commits with commit messages that indicate which commit they're going to end up in, and then do an interactive rebase at the end. The workflow looks something like:

    # At the point I realize I have two commits
    git add -p
    git commit -m 'first'
    git commit -am 'second'

    # Do some more editing
    git add -p; git commit -m 'debug' # commit the debug stuff so that I don't have to keep skipping it
    git add -p; git commit -m 'first'
    git add -p; git commit -m 'second'
    # After repeating the above a few times
    git rebase -i origin/master
    # Remove the debug commits, move the first/second/etc. commits together, squash the runs of first/second/etc. into one commit each, and then go back and write commit messages for each of them

I have used SCCS, CVS, VSS, SVN, Clearcase, darcs, git, and hg.

I found darcs to be the most ergonomic, except for the fact that it was orders of magnitude too slow.

SVN was good in that it fixed most of the pain-points that CVS had.

git and hg are both great. I tried them both out at about the same time and found hg to be more intuitive, but it didn't take me long using git to be comfortable with it.

The UI of git is honestly quite terrible. Commands are often confusingly named and have seemingly disparate uses. However the underlying model of git is straightforward enough for me to reason about what operations should be possible.

Pretty much all VCSs require some such knowledge and reasoning; e.g.:

- The lack of atomic commits in CVS stems from the underlying RCS stack it is based on.

- SVNs brain-dead branching stems from the fact that there are no branches in SVN, just O(1) copies from one path to another.

Reply on news.ycombinator.com