Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Git Irreplaceable? (2019)

fossil-scm.org

Post reply on HN
Print view View original

551–559 of 559 posts

Re: Is Git Irreplaceable? (2019)

#551

Post by munmaek »

antris wrote: post #550
munmaek wrote: post #443

Earlier quoted context omitted.

> we can make the claim that it could be better I’m not disputing this. Of course git isn’t perfect. What I’m against is changing git to cater to people who can’t read the manual and make basic mistakes.

> What I’m against is changing git to cater to people who can’t read the manual and make basic mistakes. Why? Isn't software that doesn't require reading a manual and doesn't let the user make irreversible mistakes considered good design?

Not if it means reducing capabilities of the program in order to add bumper guards.

I can’t think of any software that handles a complex program that doesn’t have a manual, documentation like a manual, or a learning curve. Git is a tool for developers, not casual users who want typical apps.

Again, you wouldn’t make an argument like this for a tool used by a plumber or a mechanic. If a tool succinctly handles a problem, good! But using tools is part of the profession; they have learning curves.

Most issues with git are PEBKAC issues because people refuse to spend 10 minutes of their life reading about a tool they may use for hundreds or thousands of hours. I wouldn’t want to cater to those kinds of people.

Re: Is Git Irreplaceable? (2019)

#552

Post by brigandish »

munmaek wrote: post #551
antris wrote: post #550

Earlier quoted context omitted.

> What I’m against is changing git to cater to people who can’t read the manual and make basic mistakes. Why? Isn't software that doesn't require reading a manual and doesn't let the user make irreversible mistakes considered good design?

Not if it means reducing capabilities of the program in order to add bumper guards. I can’t think of any software that handles a complex program that doesn’t have a manual, documentation like a manual, or a learning curve. Git is a tool for developers, not casual users who want typical apps. Again, you wouldn’t make an argument like this for a tool used by a plumber or a mechanic. If a tool succinctly handles a probl…

What can Git do that Fossil or Mercurial can't?

Re: Is Git Irreplaceable? (2019)

#553

Post by antris »

munmaek wrote: post #551
antris wrote: post #550

Earlier quoted context omitted.

> What I’m against is changing git to cater to people who can’t read the manual and make basic mistakes. Why? Isn't software that doesn't require reading a manual and doesn't let the user make irreversible mistakes considered good design?

Not if it means reducing capabilities of the program in order to add bumper guards. I can’t think of any software that handles a complex program that doesn’t have a manual, documentation like a manual, or a learning curve. Git is a tool for developers, not casual users who want typical apps. Again, you wouldn’t make an argument like this for a tool used by a plumber or a mechanic. If a tool succinctly handles a probl…

Software can cater to multiple types of uses at the same time. You can have a learn-as-you-go experience while keeping your powerful tools that enable more fine-tuned or complex tasks. Easy-to-use vs. powerful is a false dichotomy.

About the plumbing/mechanic analogy, I totally would make the same case! Hammers and wrenches don't require a manual and can be used for very complex tasks, and that's exactly what makes them so well designed and popular. Few people want their hammer to have more features, and if they do, they still want to keep the good old hammer ready, because it's so easy and simple to use.

Especially calling out PEBKAC (Problem Exists Between Keyboard And Computer) - while even most of the expert git users, including the author himself say the interface could at least be made much better - makes me really suspicious that you simply like feeling superior to other people because you know something they don't, and you don't want to lose your "edge" if suddenly everyone can use version control without resorting to manuals.

Re: Is Git Irreplaceable? (2019)

#554

Post by munmaek »

antris wrote: post #553
munmaek wrote: post #551

Earlier quoted context omitted.

Not if it means reducing capabilities of the program in order to add bumper guards. I can’t think of any software that handles a complex program that doesn’t have a manual, documentation like a manual, or a learning curve. Git is a tool for developers, not casual users who want typical apps. Again, you wouldn’t make an argument like this for a tool used by a plumber or a mechanic. If a tool succinctly handles a probl…

Software can cater to multiple types of uses at the same time. You can have a learn-as-you-go experience while keeping your powerful tools that enable more fine-tuned or complex tasks. Easy-to-use vs. powerful is a false dichotomy. About the plumbing/mechanic analogy, I totally would make the same case! Hammers and wrenches don't require a manual and can be used for very complex tasks, and that's exactly what makes t…

> Easy-to-use vs. powerful is a false dichotomy.

iMovie vs Premiere/Final Cut. Final Cut X vs 7. Garageband vs Pro Tools. Word vs LaTeX. and so on. It's very difficult to design interfaces that are easy enough for average users that don't impede pros/power users.

> hammer

A hammer isn't a good comparison. Something like a multimeter is what I was thinking of, etc. Git solves a significantly more complex problem than either of these, though.

> including the author himself say the interface could at least be made much better

I don't disagree! Git's interface -could- be better. That has nothing to do with my points above with regards to people refusing to read basic literature about the tools they use, expecting them to just magically do everything for them out of the box, "intuitively".

> feeling superior ... you don't want to lose your "edge"

This could not be further from the truth. I simply have no sympathy for people who refuse to read the manual or an intro to using a tool, and then complain about the tool being hard to use. Yeah.. it's hard because you didn't do any reading! Git is actually really easy if you read about the model that it uses. Most people don't need to venture out beyond ~5-6 subcommands, and even then it's easy to learn new subcommands like cherrypick, rebase, etc.

Adobe Photoshop, as another example, has a learning curve, but that tool is indispensable for professionally working on / editing images. (GIMP is also good, but that's not in the scope of this discussion). A lot of beginner issues are basically PEBKAC because they didn't read the manual. Same with Pro Tools, or probably any other software used by industry professionals. They're harder to use but what you can do with them (since they treat you like an adult, instead of holding your hand and limiting you) is incomparable to the output of apps designed for casual users.

Re: Is Git Irreplaceable? (2019)

#555

Post by chrisweekly »

MaulingMonkey wrote: post #549
chrisweekly wrote: post #517

Earlier quoted context omitted.

Yeah, I get it. Still seems a stretch to fault git for "failing" to optimize for that inefficient-by-design use case though.

To be fair, I mostly don't fault git for failing to optimize that far, even if there are alternatives that do. That's far enough outside the core use case for myself and those I know that I'd be willing to sacrifice it for other, more important considerations. But I'm totally willing to fault git for failing to optimize enough to handle the manual commit cadence of source game assets though. Because that's not just a…

Right on. Thanks for clarifying -- and for confirming a legitimate complaint based on real-world, personal experience.

Re: Is Git Irreplaceable? (2019)

#556

Post by tomesch1982 »

tomesch1982 wrote: post #239
reissbaker wrote: post #186

Earlier quoted context omitted.

As an FB employee, I use hg regularly (because it is required). I would not use it as a git replacement for non-FB-sized repos. It has some weird design choices (e.g. branching is bad), and it very often requires manual intervention for merges that git performs correctly and automatically. You can get around branching-is-bad by changing your workflows a bit, but you can't get around the bad merges: over time it's lik…

The branching in hg is actually way better than with git. The reason you are confused is probably because you learned the wrong (git) way of branches. If you want the wacky and unreliable git branching you can use hg bookmarks.

For example: https://stackoverflow.com/questions/36358265/when-does-git-r...

This page has been viewed 230 thousand (!!) times. Because git is so easy and elegant that it lies to you what branches exist on the remote.

It is not even funny any more how bad this is.

Re: Is Git Irreplaceable? (2019)

#557

Post by jnurmine »

wyoung2 wrote: post #502
jnurmine wrote: post #499

Earlier quoted context omitted.

> You must be referring to just the table at the top, not to the detailed argument below Well, not entirely, because in my opinion the detailed argument kind of hand-waves away the entire git worktree. Continuously switching branches inside a single large Git repo is certainly a suboptimal way to work with Git, but most of the time one should be able to avoid that with the worktree (though the worktree stuff is, of c…

You’re not addressing the list of problems resulting from the use of this tacked-on feature. Also, Git continues to be taught with the switch-in-place method by default. I’m not saying it is impossible to get a Fossil-like workflow with Git, just that there are consequences from that not being the default.

Getting a "Fossil-like workflow with Git" is not really the point, is it? One could argue that Fossil does not support "Git like workflow". It is not really a good argument either way.

It is not like Fossil's workflow is a global optimum, it's just something Fossil does well.

Re: Is Git Irreplaceable? (2019)

#558

Post by reissbaker »

kccqzy wrote: post #193
reissbaker wrote: post #186

Earlier quoted context omitted.

As an FB employee, I use hg regularly (because it is required). I would not use it as a git replacement for non-FB-sized repos. It has some weird design choices (e.g. branching is bad), and it very often requires manual intervention for merges that git performs correctly and automatically. You can get around branching-is-bad by changing your workflows a bit, but you can't get around the bad merges: over time it's lik…

Paper cuts can be addressed with more users reporting bugs and contributing fixes. The fundamental design issues with git that prevent scalability cannot. As a Google employee I use hg every day, even though it's not required. (Some teams at Google do mandate its use, but these are few and far between.) I don't use branches, but I use bookmarks. I didn't notice any merges that really ought to be performed automatical…

For most people, avoiding thousands of papercuts is better than scaling massively. Few people need massive scale, but everyone hates papercuts.

I'm also not certain that the "fundamental design issues" with git are truly fundamental to its design. For example, partial clones and sparse checkouts are seeing increasing support in recent versions of git — and those are really all you need.

Re: Is Git Irreplaceable? (2019)

#559

Post by reissbaker »

GuB-42 wrote: post #523
reissbaker wrote: post #186

Earlier quoted context omitted.

As an FB employee, I use hg regularly (because it is required). I would not use it as a git replacement for non-FB-sized repos. It has some weird design choices (e.g. branching is bad), and it very often requires manual intervention for merges that git performs correctly and automatically. You can get around branching-is-bad by changing your workflows a bit, but you can't get around the bad merges: over time it's lik…

What is so bad about mercurial branching? The underlying structure is the same as git: a directed acyclic graph, the only real difference is how branches are named. Mercurial has 3 ways of doing branching: - bookmarks: these are like git branches, a pointer to a revision - branches: when you are in a branch, all commits are permanently affixed with that branch name. Less flexible than bookmarks (and therefore git bra…

Specifically I meant that branching is less flexible. Bookmarks are better than Mercurial branches (and at FB it's what we use instead), but even with bookmarks there are gotchas compared to git. For example:

* Pushing them is (slightly) more annoying than pushing git branches — you need a separate command, whereas `git push` just does the right thing by default * Deleting them doesn't delete the corresponding commits * There is only one global namespace shared across all remotes

Post reply on HN