More stupid Git errors THIS TIME IN FIRST-PERSON!

Salamander

But the "have fun diving through internals" retort just doesn't work in this case, because while it's very easy to fuck yourself up, it's equally easy to fix that stuff up after you do it.

Easy only if you already know how to do it.
And your solution only works if you know that git garbage collects commits, you can still reference commits that have not been garbage collected, and that the command git reflog will show you which operations you just performed and what they changed.
That's pretty damn deep into git internals already.
And just think how all this could have been avoided if git undo existed instead.

charlieda

I think you're making an incorrect assumption here. Complaining that a software's UI is rubbish is very different from being unwilling to understand the concepts of it.

Do you think that this error message is useful? Do you think git is well designed and easy to use? Do you think git should be easy to use?

I'm entirely sure this community would laugh if someone proposed the "implement each subcommand as a shell script or perl script" as a design philosophy for a software program.

hifi

@charlieda said:

I think you're making an incorrect assumption here. Complaining that a software's UI is rubbish is very different from being unwilling to understand the concepts of it.

The UI is shit and blakeyrat has stated he is unwilling to learn the concepts.

tar

So I went off to learn the difference between git fetch and git pull by reading the git docs. That was probably a bad idea on my part and I'm sorry:

There is a difference between listing multiple <refspec> directly on git pull command line and having multiple Pull: <refspec> lines for a <repository> and running git pull command without any explicit <refspec> parameters. <refspec> listed explicitly on the command line are always merged into the current branch after fetching. In other words, if you list more than one remote refs, you would be making an Octopus. While git pull run without any explicit <refspec> parameter takes default <refspec>s from Pull: lines, it merges only the first <refspec> found into the current branch, after fetching all the remote refs. This is because making an Octopus from remote refs is rarely done, while keeping track of multiple remote heads in one-go by fetching more than one is often useful.

Octo...wait, what now, again?

Gąska

@Salamander said:

Easy only if you already know how to do it.

That's important too. Changing lightbulb is easy once I've read how to do it. Typing in Vim is still hard despite years of exposure.

@Salamander said:

That's pretty damn deep into git internals already.

Just shows how easy those internals are. Definitely easier than SVN's properties mumbo jumbo.

Magus

Yes, true. Octopus.

ben_lubar

The difference between git fetch and git pull in English this time:

git fetch gets the changes from the remote repository.
git pull runs git fetch followed by git merge.
git pull --rebase runs git fetch followed by git rebase.

Gąska

@tar said:

So I went off to learn the difference between git fetch and git pull by reading the git docs.

You've chosen the worst way to learn.

Basically - git pull is like git fetch followed by git merge. Though most often what you want is git pull -r, which is git fetch followed by git rebase. One of the hard parts of git is changing your mindset and learning that branch foo in your repo and branch foo on remote are two separate branches, just like foo and bar. Although you only need to learn it if you want to know why you have to always use -r option in git pull - cargo-culting with git isn't that bad idea when you're making your first steps.

JBert

@tar said:

by reading the git docs

Oh, but you want the git user docs: https://www.kernel.org/pub/software/scm/git/docs/usermanual.html

Filed under: Not really, Correct link

Yamikuronue

@Gaska said:

cargo-culting with git isn't that bad idea

This is a major sign your UI is fucked.

tar

@Gaska said:

@tar said:
So I went off to learn the difference between git fetch and git pull by reading the git docs.

You've chosen the worst way to learn.

I guess the learning-git-workflow is:

Think about what the obvious and most straightforward next step is; what you'd do when faced with any other tool.
Don't do that! It's not that, it's some other thing...

Anyway, I've gone to read this in the vague hope that there's at least one explanation of git which makes sense to someone who's mind has been tainted by the expectations of other source control systems...

tarunik

@charlieda said:

I think you're making an incorrect assumption here. Complaining that a software's UI is rubbish is very different from being unwilling to understand the concepts of it.

Do you think that this error message is useful? Do you think git is well designed and easy to use? Do you think git should be easy to use?

I'm entirely sure this community would laugh if someone proposed the "implement each subcommand as a shell script or perl script" as a design philosophy for a software program.

While Blakey does have some legitimate criticisms of git, a good chunk of his problem is that he's flailing about blindly pushing buttons without understanding what he's actually doing, and insisting that that's a legitimate way to use anything.

And I'd rather deal with each subcommand being implemented as an individual script than a giant, tangled, goto-infested, blob of spaghetti code in any language.

hifi

@tar said:

* Think about what the obvious and most straightforward next step is; what you'd do when faced with any other tool.

Don't do that! It's not that, it's some other thing...

Actually, that was one of the original design principles.

blakeyrat

@hifi said:

I've heard people defend the Modern UI of Windows 8 or whatever it was finally called.

And why not? It's not a bad interface for tablet and tablet-like computers. Is it so unthinkable someone may genuinely like it?

@hifi said:

Criticize it for the right reasons and I'm with you.

I am. Usability is the most important thing in software. By far. By leagues. By universes. The entire point of writing software is for people to use it, if you've made using it difficult, I am going to call you an idiot moron asshole dickhead.

@hifi said:

Criticizing git because SourceTree is crap is the wrong reasons.

Except the shitty usability of Git is the one and only reason I'm even running SourceTree. And SourceTree has shitty usability, too-- it's just slightly less shitty. Very slightly.

@hifi said:

I can do this too: "If I need to read a book to use a programming language, that language is horribly flawed.".

Are you assuming I'd disagree with your statement there so you could flag me as a hypocrite? Because I agree with it.

@charlieda said:

The same applies here - git is so difficult to start off with, and continues to demonstrate flaw after flaw.

It's not just that it's difficult, but that it's so buggy. I could also add "bloated", "slow", "lacking features almost every other SCM has", etc.

@Gaska said:

I had to read a manual for my car to know how to replace lightbulb. Does it mean my car is horribly flawed?

Not horribly, but flawed: yes. The bulb should be designed so that it never goes out in the first place.

@gleemonk said:

I know this is an alien perspective to you, but to me you sound like a tourist complaining about the natives not responding to your pictograms as you think they should.

Ok? Did you have a point?

@gleemonk said:

No wonder you get irritated when Git strikes a conversational tone. When I work with Git, it is a dialogue.

Oh; you're just crazy. Gotcha.

If someone came up to someone else at a party and started "conversing" with them in the way Git does, he'd leave that party with a fat lip or perhaps in an ambulance. I guarantee it.

@gleemonk said:

Then this guy comes along and asks, "how do I buttons?" and I can't imagine how he even works when he can't talk to things.

My inability to communicate with Git is Git's fault, not mine. 95% of software I have no problem communicating my intent to.

@tarunik said:

throws @blakeyrat at the computer-aided dispatching console for a track warrant territory Have fun!

WTF are you talking about? Are you crazy too, now?

@tarunik said:

No amount of UI will help you if you aren't willing to understand the concepts of what you're working with.

THE UI IS SUPPOSED TO TEACH ME THE CONCEPTS. You idiots, did you just sleep through the GUI revolution in the late-80s and early-90s? Were you unconscious then? Is that the explanation?

@tarunik said:

I'm not sure what it is about you and certain systems -- but your expectation that everything should fit into the same concept-set that you already know isn't a good one.

The problem can use new concepts, of course. The point is: if it's going to, it needs to teach me those concepts as it goes. Either explicitly or implicitly. Sending the user to read a book is shit. (And note that Git, on its own, will never send the user to read a book anyway-- it doesn't even offer that shitty level of guidance!)

@Salamander said:

And just think how all this could have been avoided if git undo existed instead.

You can't have Undo in CLI programs! Because then they might be easy-to-use and all these uncultured plebes (who won't even get my 1974 Doctor Who jokes!) might start using Linux and all hell would break loose! DEFEND THE HIGH PRIESTHOOD OF TECHNOLOGY!

@hifi said:

and blakeyrat has stated he is unwilling to learn the concepts.

Sorry? When did that happen?

@tar said:

I guess the learning-git-workflow is:

Think about what the obvious and most straightforward next step is; what you'd do when faced with any other tool.
Don't do that! It's not that, it's some other thing...

Yes.

It's like the INTERCAL of source control. The difference is: INTERCAL was a joke!