More stupid Git errors THIS TIME IN FIRST-PERSON!
-
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 commandgit 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 ifgit undo
existed instead.
-
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.
-
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.
-
So I went off to learn the difference between
git fetch
andgit 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?
-
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.That's pretty damn deep into git internals already.
Just shows how easy those internals are. Definitely easier than SVN's properties mumbo jumbo.
-
Yes, true. Octopus.
-
The difference between
git fetch
andgit pull
in English this time:git fetch
gets the changes from the remote repository.git pull
runsgit fetch
followed bygit merge
.git pull --rebase
runsgit fetch
followed bygit rebase
.
-
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 likegit fetch
followed bygit merge
. Though most often what you want isgit pull -r
, which isgit fetch
followed bygit 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 ingit pull
- cargo-culting with git isn't that bad idea when you're making your first steps.
-
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
-
-
@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...
-
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.
-
* 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.
-
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?
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.
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.
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.
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.
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.
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?
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.
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.
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?
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?
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!)
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!
and blakeyrat has stated he is unwilling to learn the concepts.
Sorry? When did that happen?
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!
-
@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?
I implied desktop. Sorry, I'll be more clear in the future.
@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.
And there I can agree with you. Git CLI usability isn't the best and the commands and documentation could be cleaned up with a lot of man hours. But that's not good use of anyones time, better write an UI for libgit2 which isn't a mashup of shell scripts and Perl.
@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.
So you're unwilling to learn the ropes of the CLI and use something that tries to hide the CLI and failing at that. Ok.
@hifi said:
and blakeyrat has stated he is unwilling to learn the concepts.
Sorry? When did that happen?
Right where you refused to read the book about git which starts with the concepts.
-
I implied desktop.
You demonstrably did not.
And there I can agree with you.
So shut up and start bitching at Git and the people who force you to use it.
But that's not good use of anyones time, better write an UI for libgit2 which isn't a mashup of shell scripts and Perl.
Ok; then do that. Either way, stop saying I'm the idiot.
So you're unwilling to learn the ropes of the CLI and use something that tries to hide the CLI and failing at that.
-
It's more "unable" than "unwilling"
-
I know the ropes of the CLI (although I wish I didn't), that doesn't mean I'm going to use it when I could avoid it
-
I'm not the one doing the failing, the tool is failing to work correctly
Right where you refused to read the book about git which starts with the concepts.
I didn't realize there is a "the" book.
Question: how do you know I haven't read it? ... are you sure?
Whether or not I've read "the" book, my criticism in this thread is 100% correct, on-target, and valid.
-
-
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.
You've said so in the past, and it's every bit as much of a blakeyhowler now as it was last time.
-
Ok? Did you have a point?
Yes, but you're ignoring it.
THE UI IS SUPPOSED TO TEACH ME THE CONCEPTS.
Fine paradigm. But we're talking about a highly specialized tool here.
-
But we're talking about a highly specialized tool here.
It could, at minimum, be as good as its peers.
-
OK, now I find myself wondering if I should just do this:
$ git config --global --bool pull.rebase true
And carry on pretending that
git fetch
isn't a thing...On the plus side, now I have at least some idea why my DAG looks like a trapezoid...
-
@blakeyrat said:
Buddy's the one who said it, ask him.
You're the one disagreeing on git's hardness. I just want for everyone to be on the same page, otherwise the discussion doesn't make the least lick of sense.
What? I'm not seeing any disagreement. Git is poorly documented and a pain in the ass to use. Unless you've got a photographic memory, the only sensible way to enter git commands is to use your shell history, or to check the manual every single time to make sure you've got the switches right. Whether you would call that hard or not is just semantic pedantics.
-
All I'm saying is, I'm incredibly glad I don't work for you.
-
Just use git up already. It stashes your uncommitted changes, fetches every remote branch that you have checked out, rebases any commits you have on top of them, then unstashes your local changes. It's what pull should have been in the first place.
-
You demonstrably did not.
Why do you have to be a dick even when people are apologizing to you? Good lord.
-
I've been meaning to write a brainfuck interpreter in our inhouse business rules engine, just to prove that I can. But I haven't been bored enough.
Do it. And do use it to develop logic for the business.
-
Why do you have to be a dick even when people are apologizing to you?
What apology?
He said he implied desktop. He did not. I said he did not. How could you possibly interpret anything in that exchange as an apology?
-
Just use git up already.
I'd love to, but:
Windows support is predictably absent.
Well, actually I have Python installed, so I can give the python port a test run...
-
What apology?
Go read it. Right after he said that, he said that he was sorry and would try to be clearer.
How could you possibly interpret anything in that exchange as an apology?
I could have kept reading after that sentence.
-
Well sorry, next time we'll all try to read your posts better.
<It really doesn't sound like an apology to me either :/
-
Blakey -- You have a bunch of almost-good arguments. The problem is they are undermined by your lack of understanding of DVCS concepts. And you're right, Git's UI should teach you those concepts. But it doesn't. And light bulbs should work forever. But they don't.
So go learn. Read Pro Git or something or watch some videos. Not only will this make your life a lot easier, you will be able to formulate arguments that are actually convincing to the people you are trying to convince.
As it is, it's very hard to take your arguments as anything but idiotic ramblings. Because that's what they sound like. But somewhere in there you are actually right. Fix it.
-
And why not? It's not a bad interface for tablet and tablet-like computers. Is it so unthinkable someone may genuinely like it?
On PC? Yes.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.
Usability isn't just ease of use - it's also about how much you can do. If we were to go just by pure ease of use, it would mean Paint is better than Photoshop because it's easier to do things with it.Are you assuming I'd disagree with your statement there so you could flag me as a hypocrite? Because I agree with it.
Did you seriously just said that a good language is such that every single feature it has is instantly comprehensible to everyone without even reading the most basic of tutorials!?!?!?!?!?It's not just that it's difficult, but that it's so buggy.
I was going to challenge you on that but I remembered that you consider things you don't like to be bugs.I could also add "bloated"
One rabbi says bloated, another rabbi says full of features."slow"
Define "slow". Because you're certainly not talking about the amount of time it takes to perform requested operations."lacking features almost every other SCM has"
Only an inexperienced Sith talks in absolutes - an experienced Sith always leaves a way to back out from unfortunate statement by being precisely vague. Even if I demanded you to state a feature that most VCS-s have and Git doesn't, you could find one that satisfies only the latter condition and pretend that the subset of VCS-s that do have it is "almost every other". Well played.Still, I'm interested in what particular feature you had in mind when stating the above.
The bulb should be designed so that it never goes out in the first place.
Agreed. But we live in a world where all lightbulb manufacturers have an agreement with each other that no lightbulb will exceed 8000 hours.THE UI IS SUPPOSED TO TEACH ME THE CONCEPTS.
Yes, UIs are supposed to do this. I mean, GUIs, not all UIs - because most other interfaces, most notably CLIs, just don't have a possibility to provide similar click-shiny-thing-and-see-what-happens kind of user experience. Sadly, all Git GUIs suck ass, so you can't rely on them to teach you. However, anything you can learn from randomly clicking GUI shinies, you can also learn from a book. And due to popular demand, the internets are filled with thousands upon thousands of Git tutorials, of any size, depth and target group's expertise - including ones explaining total basics to total noobs. Your inability to use Git is only due to your stubborness and aversion to written guides.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!
Just when you were scolding @gleemonk and @tarunik for being crazy...1) It's more "unable" than "unwilling"
If that's true, it means you're too stupid to be a programmer. But you have a job. So is your inability just extreme case of laziness and/or hatred, or are you just a mere code monkey who doesn't really know why the fuck this snippet from SO works?2) I know the ropes of the CLI
Maybe you should stop repeating the same lies and misconceptions about CLI over and over again everywhere you are, so people would actually believe this?although I wish I didn't
You're doing terrible job at convincing people that you have ever tried to actually learn git.Whether or not I've read "the" book, my criticism in this thread is 100% correct, on-target, and valid.
Not until you at least answer to paragraphs 3, 6 and 7 of this post.It could, at minimum, be as good as its peers.
SVN is Git's main competitor. I don't know a single person who knows both and prefers the former over the latter, and I know great many whose likings are opposite. I know it's just anecdotal evidence, but I think it's general trend. By know, I of course mean successfully learned basic and intermediate operations, not merely heard of it.
-
Git is poorly documented and a pain in the ass to use.
Poorly documented? Yes. PITA to use? Once you know your way around, not at all. Basic git commands - clone, pull, push, commit, rebase, checkout, cherry-pick, reflog, reset, diff, apply, merge - are perfectly clear to me. It needed some getting used to, but I'm fine now, and will never look back to SVN (which is the only other VCS I've ever used, save for several minutes in total messing with Mercurial). The only command I encountered so far that I don't know what the fuck is even going on when you run it is read-tree.Unless you've got a photographic memory, the only sensible way to enter git commands is to use your shell history, or to check the manual every single time to make sure you've got the switches right.
Care to elaborate? I have little to no photographic memory, yet I'm perfectly fine typing every command I use by hand without checking manpages every other second. Of course, sometimes I need to double-check, but I find myself doing it less often than with e.g. grep.
-
Did you seriously just said that a good language is such that every single feature it has is instantly comprehensible to everyone without even reading the most basic of tutorials!?!?!?!?!?
YMBNH
-
I could have kept reading after that sentence.
What for? I already had the snappy reply.
Blakey -- You have a bunch of almost-good arguments. The problem is they are undermined by your lack of understanding of DVCS concepts. And you're right, Git's UI should teach you those concepts.
So I have good arguments which are "undermined" by my also-good arguments.
Note that it's not so much I don't understand DVCS concepts as I ignore them because I have absolutely no need for working offline and so they're useless to me.
Not only will this make your life a lot easier, you will be able to formulate arguments that are actually convincing to the people you are trying to convince.
I don't give a shit about convincing anybody on this forum. What the fuck do you think I'm posting here for?
Usability isn't just ease of use - it's also about how much you can do.
Right; but the two also aren't mutually-exclusive. (Although you wouldn't know that from talking to moron open source developers.)
Did you seriously just said that a good language is such that every single feature it has is instantly comprehensible to everyone without even reading the most basic of tutorials!?!?!?!?!?
Nope.
I was going to challenge you on that but I remembered that you consider things you don't like to be bugs.
Look at the OP of this thread and tell me again how are zero bugs in Git. There's at least two just in the text. Ignoring the fact that retrying the operation worked with no errors, so the entire displayed error was a bug.
One rabbi says bloated, another rabbi says full of features.
I'm not Jewish.
Define "slow". Because you're certainly not talking about the amount of time it takes to perform requested operations.
Yes I am. Git's slow as shit.
Only an inexperienced Sith talks in absolutes - an experienced Sith always leaves a way to back out from unfortunate statement by being precisely vague.
I'm not a Jedi.
Still, I'm interested in what particular feature you had in mind when stating the above.
How about being able to check-out only a small subset of the files in the repo? Something which prevents me from putting my Skyrim mods on Git source control (because I'd have to check-in all 12 GB of Skyrim's data directory.)
You know what I did when Google Code shut down? I deleted them all. Because all of the free hosting alternatives use Git, and you can't check in a subset of files with Git. So there you go: an example of Git making open source software disappear.
We've already talked about a half-dozen other features Git lacks, most notably file locking, but you'll have to dig up older Git threads to find those.
But we live in a world where all lightbulb manufacturers have an agreement with each other that no lightbulb will exceed 8000 hours.
Right; LED lights don't exist. I forgot for a second. I thought they were even in my car! Haha I'm so crazy and you are so obviously sane.
Yes, UIs are supposed to do this. I mean, GUIs, not all UIs - because most other interfaces, most notably CLIs, just don't have a possibility to provide similar click-shiny-thing-and-see-what-happens kind of user experience.
Why do you exempt CLIs? Just because current ones are shit doesn't mean future ones that are not shit could someday exist.
Your inability to use Git is only due to your stubborness and aversion to written guides.
Why the fuck do you people keep saying this? I'm not unable to use Git. WTF. I use it fine. How would I still be working here if I were unable to use it?!
If that's true, it means you're too stupid to be a programmer.
Right; dyslexics should be chained up in dungeons. They're too stupid to participate in society.
Fuck you. Fuck you you piece of shit.
SVN is Git's main competitor.
I've worked at 3 companies that switched from TFS to Git and ze-- oh wait one that switched from SVN to Git.
The real shame is TFS 2013 has all the offline features of Git and all the online features of SVN and is fast and works well and has a reasonably complete GUI. People moved off TFS right as it became better than Git in every way.
Care to elaborate? I have little to no photographic memory, yet I'm perfectly fine typing every command I use by hand without checking manpages every other second.
And what happens when you typo one and fuck everything up?
-
What the fuck do you think I'm posting here for?
Shits and giggles, just like me?Right; but the two also aren't mutually-exclusive.
I know. But more advanced features will always require more advanced skills - because otherwise they would be of no use for you anyway. Git isn't great at being user-friendly (even for seasoned developers), but it's learnable, and quite powerful.Nope.
Then why do you insist on every git feature to be instantly comprehensible to everyone without even reading the most basic of tutorials? Programming language and version control software are both a programmer's tool. Why is one of them being hard OK while the other is not?Look at the OP of this thread and tell me again how are zero bugs in Git.
You used GUI. Git GUIs are buggy as shit. It says nothing about the quality of Git itself, since they're unofficial. My custom dual-monitor-taskbar software throws random exceptions from time to time, but I don't blame Windows but the buggy third party taskbar.I'm not Jewish.
Me neither. It was a paraphrase of popular adage.Yes I am. Git's slow as shit.
Benchmark or didn't happen.How about being able to check-out only a small subset of the files in the repo?
Can do. Requires some effort though - I'll give you that. SVN is better at it. But the feature exists nonetheless.file locking
Yeah, Git doesn't have that, for obvious reasons. But this feature became kinda obsolete nowadays when branches and merging is so common and easy.Right; LED lights don't exist. I forgot for a second.
Me too; my car is 2001, and thus I tend to think of cars the way they were in 2001.Why do you exempt CLIs? Just because current ones are shit doesn't mean future ones that are not shit could someday exist.
The very basic idea behind CLI is why it won't work - program is run the very moment there's work to do, it shuts down when the work is done, and all the commands and options are issued before the program is run. There's no this idle period during the program execution where the user can just dumbly glance at all the options available to him, as is the case with GUI applications.Why the fuck do you people keep saying this?
Because you make it look like it's true.I'm not unable to use Git.
Your post history suggests otherwise.How would I still be working here if I were unable to use it?!
I have no idea. That's why I was confused this whole time.Right; dyslexics should be chained up in dungeons.
They definitely shouldn't be put in copywriter's seat.They're too stupid to participate in society.
I think you don't know what dyslexic means.Fuck you. Fuck you you piece of shit.
I love you too!I've worked at 3 companies that switched from TFS to Git and ze-- oh wait one that switched from SVN to Git.
Then I'm wrong, apparently. But just like my experience might be a cognitive bias, so might be yours.The real shame is TFS 2013 has all the offline features of Git and all the online features of SVN and is fast and works well and has a reasonably complete GUI. People moved off TFS right as it became better than Git in every way.
I'm definitely going to look into it. Thanks for recommendation!And what happens when you typo one and fuck everything up?
Usually when I typo, it says something like "gi: command not found" or "clne is not a git command. See git --help" or "unknown option: no-fff". You have to be really unlucky or @accalia to fuck up repo in a way that git reset can't help.
-
So I have good arguments which are "undermined" by my also-good arguments.
Note that it's not so much I don't understand DVCS concepts as I ignore them because I have absolutely no need for working offline and so they're useless to me.
No, your arguments are undermined by your false assumptions. They could be strengthened immensely by clearing those up. But hey, it's your loss.
DVCS is not just about working offline. What do you think the D stands for? This is a an example of one of your misunderstandings watering down your argument.
-
You have to be really unlucky or @accalia to fuck up repo in a way that git reset can't help.
OI! now that is unfair.
I may have issues with typos but i've never blown up a repo beyond my abilities to unblow it up.
The only time i need to resort to backups are when the server shits the bed. usually because of the meddling of our supposed outside contracted sysadmins.
-
Ok, ok. I'm sorry. Please, don't be mad.
Still, gonna leave my post unedited. I hope you don't mind, because why would you?
-
The bulb should be designed so that it never goes out in the first place.
Ha. You're funny.
Let me know when you find any technology whatsoever that lasts forever with no maintenance.The very best LEDs are rated to last about 70000 hours on average under perfect conditions.
Normal ones are around 20k to 50k hours, and in reality it's usually worse because the diode isn't the only component.At which time, either half are dead, or they are half as bright as new (depending on which lifetime spec they chose and whether the driver failed first)
If the car is designed assuming that the LEDs will never fail, then you'll need to throw away half of those cars at under 10 years old because the lights are dead and irreplaceable.
Reality isn't perfect, and demanding perfection leads to fear. Fear leads to anger, and you probably know the rest.
-
If the car is designed assuming that the LEDs will never fail, then you'll need to throw away half of those cars at under 10 years old because the lights are dead and irreplaceable.
Now you're getting it! Soon you'll be a great manager.
-
I hope you don't mind, because why would you?
not really. in hindsight it's pretty funny.
-
It is.
-
Then why do you insist on every git feature to be instantly comprehensible to everyone without even reading the most basic of tutorials? Programming language and version control software are both a programmer's tool. Why is one of them being hard OK while the other is not?
Neither is ok.
Yeah, Git doesn't have that, for obvious reasons.
Not obvious to me.
The very basic idea behind CLI is why it won't work - program is run the very moment there's work to do, it shuts down when the work is done, and all the commands and options are issued before the program is run.
That is currently true, that does not have to be true.
They definitely shouldn't be put in copywriter's seat.
I'm not a copywriter, I'm a software developer.
And if I may toot my own horn, I type a lot better than most of the fuckers here who don't have dyslexia. Or at least I assume FrostCat doesn't.
I think you don't know what dyslexic means.
Right.
DVCS is not just about working offline. What do you think the D stands for?
It stands for "distributed". The benefits of which is:
-
Every person working with the project has a full copy of the repo (i.e. you can't check-out selected files which is incredibly handle to have)
-
You can work offline
I don't need or want "benefit" 1) or 2).
-
-
Can do. Requires some effort though - I'll give you that. SVN is better at it. But the feature exists nonetheless.
Jesus Christ, what a PITA.
And BTW it still downloads the entire repo, so there's no bandwidth/storage savings in using this.
-
git fetch
(no locally modified files)
git rebase
(fail)
git rebase --abort
git rebase
(success)CLI interfaces, on the other hand, do exactly what you tell them to do.
When they feel like it...
-
It stands for "distributed". The benefits of which is:
-
Every person working with the project has a full copy of the repo (i.e. you can't check-out selected files which is incredibly handle to have)
-
You can work offline
I don't need or want "benefit" 1) or 2).
Well that's a start. There's a lot more to learn than that though. Writing it all off as "I don't need it" is a big part of why you have so much trouble.
-
-
Well that's a start. There's a lot more to learn than that though. Writing it all off as "I don't need it" is a big part of why you have so much trouble.
But I don't want it, I don't need it, and I don't use it. So why the fuck do I even need to know it exists?
Oh yeah: Git is a piece of shit.
-
TFS is so great it's actually the industry standard !
Oh wait...
-
(b) spend the next n hours futzing around with git stash and risk git destroying all my uncommitted work becuase I used -D instead of -d somewhere.
(c) commit my untested changes anyway, and then hope I can use "Amend Last Commit" to finesse that change once I've actually got HEAD onto my local workspace.I've done (b). But trying to deal with popping a stash with conflicts has lead me to doing (c). (thankfully) I haven't had any issues with amending.
-
This industry always standardizes on broken shit. There's even a little slogan for it: "worse is better".
This is why IT is shit.