Blakeyxkcd and the years and years of struggling with broken software that just so happens to use git



  • Today's xkcd almost feels like it could have been written (though perhaps not drawn) by @blakeyrat.

    Git

    ... except there's not enough ranting about how broken the interface is.



  • You must be new here, blakeyrat hates xkcd.

    Even though xkcd actually agrees a lot with him. It's mostly because it's popular.


  • Notification Spam Recipient

    To be honest he's not the only one who thinks GIT is just this is side of retardation. The only two arguments in it's favor is that management thinks its free and it's not perforce.



  • [url=http://lucumr.pocoo.org/2015/2/17/ui-and-hidden-consistency/]To the contrary[/url]

    Also, to make this post a little bit more informative, I'd only say, fuck Discourse.



  • Some inconsistencies on git CLI interface are annoying, but its much beter than the CLI interface in SVN, CVS or any of its competitors. It is harder than SVN for the basic tasks, but much simpler when you want to do something harder. An example I use sometimes is the "-p" option, where I do things interactvely chunk by chunk, instead of file by file or all at once.

    For people that don't like CLI, look at GitExtensions, it is a graphical interface for Git (only worked well on windows on my tests).


  • Discourse touched me in a no-no place

    I only use git on 2 projects and the Eclipse Git plugin works fine for those, no issues so far.


  • Notification Spam Recipient

    The newer versions are quite good since they stated following the git flows more closely.

    I remember on older versions you could get into bizarre situations where the only way out was to sacrifice a goat and hope for the best on the command line.


  • Grade A Premium Asshole

    @anonymous234 said:

    You must be new here, blakeyrat hates xkcd everything.

    FTFY


  • Discourse touched me in a no-no place

    @DogsB said:

    I remember on older versions you could get into bizarre situations where the only way out was to sacrifice a goat and hope for the best

    That's older versions of Eclipse in general though 😆



  • @anonymous234 said:

    It's mostly because it's popular.

    So you're saying that this is Blakey?

    Not big surprise...



  • JGit itself is mostly fine but the UIs for it (like NetBeans, don't know about Eclipse) don't handle many edge cases and those make people frustrated.

    Today, a colleague got a "whole file merge conflict" caused by some whitespace inconsistency within the file (it's a different :wtf: why such occurs) and you just couldn't fix it using NetBeans unless you accept the other version and by hand go fix your changes back.

    The easiest fix I could come up with was to do git rebase --ignore-whitespace and that's not something you can do with NetBeans. I didn't really care what happened to the whitespaces as long as the merge was resolved without rewriting the whole file.

    I believe the xkcd approach would have been taken if I were away.


  • Notification Spam Recipient

    @hifi said:

    The easiest fix I could come up with was to do git rebase --ignore-whitespace and that's not something you can do with NetBeans.
    This is the problem with git. It was designed with the command line in mind and if you follow those flows you'll be fine. Most of us have an aversion to the command line and go to the gui who have their own retarded logic of what should be done. NO! JUST WRAP THE SHELL! DON'T DO ANYTHING RETARD IN THE NAME OF WHAT YOU THINK IS USABILITY.


  • FoxDev

    @DogsB said:

    Most of us have an aversion to the command line

    you really shouldn't.

    embrace the CLI.

    You will not regret it.

    and as a limited time special offer for coming over the teh green on black side.... we have cookeis!


  • Grade A Premium Asshole

    @rc4 said:

    So you're saying that this is Blakey?

    He gets pissed when you dox him. You should take down the picture. :P



  • There are too many things that can go wrong and too many ways to get out of it so people just remove the repository and start over.

    The amount of options and switches is just too much to create anything simple like most current GUIs try to deceive the user and then leave them in the ditch when they really need help.


  • BINNED


  • Grade A Premium Asshole

    First thoughts on your post: " Why did @Onyx post a picture of some antique green screen? "

    -notices window controls-

    "Oh...well that's pretty freaking cool."


  • ♿ (Parody)

    @Polygeekery said:

    @anonymous234 said:
    You must be new here, blakeyrat hates xkcd everything that isn't Mac OS Classic.

    FTFY

    FTFTFY

    Also by your request:

    @Polygeekery said:


  • ♿ (Parody)

    @rc4 said:

    So you're saying that this is Blakey?

    No, he said that Blakey hates everything. Not that everything hates him.



  • @DogsB said:

    To be honest he's not the only one who thinks GIT is just this is side of retardation. The only two arguments in it's favor is that management thinks its free and it's not perforce.

    The couple times I used git I felt like it was a beast from another dimension where the rules of logic are totally different and incompatible with our own reality. It literally doesn't make sense to me, at all. I eventually got things to work but I don't know how or why. SVN is second-nature to me though. 🤷


  • Grade A Premium Asshole

    Needs more ranting about how:


  • ♿ (Parody)

    PR ACCEPTED. (See original.)



  • Can someone explain to me why people don't like git? It's the only VCS I've ever used, so it's all I know. I like it.


  • Grade A Premium Asshole

    @LB_ said:

    Can someone explain to me why people don't like git? It's the only VCS I've ever used, so it's all I know. I like it.

    Stockholm Syndrome.

    If every day, your alarm clock smashed you in the face with a shovel to wake you up, that would be normal for you. Git is your VCS smashing you in the face with a shovel.


  • ♿ (Parody)

    @Polygeekery said:

    Stockholm Syndrome.

    Also blub. Not that git isn't powerful.



  • GCC is stockholm syndrome because every day it smashes me in the face with uncolored and unformatted error messages. Before I found clang, I knew it was bad. After finding clang, I still use it because clang has terrible support on Windows.

    With git, I barely even notice when I'm using it because I almost never have issues, and any issues I do have are solved with a quick Google search. I've never had trouble manually resolving merge conflicts or understanding rebasing.



  • That's not even a joke, deleting the repo and re-downloading it when it gets in some strange retarded state (which is does at least once a quarter) is how 90% of people use Git.

    @anonymous234 said:

    You must be new here, blakeyrat hates xkcd.

    I don't hate xkcd, I hate people posting xkcd in lieu of something actually clever or at least original. Same reason I hate people posting Monty Python jokes.

    Before the whole XKCD -> Rosie O'Donnell thing started, something like 66% of posts in the old forum system were just people linking to a XKCD comic and nothing else. It sucked.

    @DogsB said:

    The only two arguments in it's favor is that management thinks its free and it's not perforce.

    ... and it's good at working offline. Not that anybody anywhere actually does that in practice, but in that strange parallel moon-universe where people work offline, Git's better at it than other source control systems.

    @fbmac said:

    Some inconsistencies on git CLI interface are annoying, but its much beter than the CLI interface in SVN, CVS or any of its competitors.

    SVN and CVS both have usable and functionally complete GUIs on the most popular OS in the world. Git does not. Not even a single one.

    @fbmac said:

    For people that don't like CLI, look at GitExtensions, it is a graphical interface for Git (only worked well on windows on my tests).

    From their own homepage:

    How is it possible to make software look this ugly? It's like some mutant combination of Windows 3.1 (the font in the window) and Windows 2000 (the window decorations), even though both of those OSes were obsolete long before Git even existed.

    Well it can't be worse than SourceTree I guess.

    @DogsB said:

    I remember on older versions you could get into bizarre situations where the only way out was to sacrifice a goat and hope for the best on the command line.

    That's a good description of how the GitHub for Windows client works.

    Except for one of the "bizarre situations" it pukes at is simple, "you merged two branches and there were conflicts." SO BIZARRE!

    @DogsB said:

    NO! JUST WRAP THE SHELL! DON'T DO ANYTHING RETARD IN THE NAME OF WHAT YOU THINK IS USABILITY.

    ... seriously? I hope you don't write GUI software for a living, because this is the worst idea.

    SourceTree just lightly wraps the CLI interface, and it's fucking terrible. It isn't even capable of greying-out buttons that aren't relevant, it'll just pass on your nonsense commands to Git and let Git give you an error in a dialog full of text spew. (For example, it'll happily let you checkout a remote branch when you already have a local version of it-- even though SourceTree KNEWS you already have a local version of it-- and then just vomits-out Git's CLI error at you. Which is, natch, terribly written.)

    Anyway, what you want already exists: it's called SourceTree. It's fucking awful.

    @accalia said:

    you really shouldn't.

    embrace the CLI.

    Right, why would you want computers to be easy-to-use? You want them to be fucking awful so that you can keep your position as the "high priesthood of technology". Fuck the users.

    @hifi said:

    The amount of options and switches is just too much to create anything simple like most current GUIs try to deceive the user and then leave them in the ditch when they really need help.

    I actually think you might be right. I've had Git fans in the past tell me that Git has a simple shared library applications can embed instead of passing along CLI commands to it, but since no GUI applications do that, I'm pretty sure they're lying.

    In any case, Git was obviously not "designed" with third-party clients in mind. It has no consistent error messaging. No consistency in command naming (so your GUI uses different terminology to do common-sense stuff, like "Sync" in Visual Studio and GitHub for Windows, but that terminology doesn't exist in Git because the common-sense operation "Sync" also doesn't exist in Git.)

    And then to make things worse: Git allows you to install little programs that run on commit, and those applications have absolutely ZERO standards as to how they report errors. And they can do stuff like, for example, let half of a operation succeed and another half of it fail but with no way to notifying the calling app that that happened.

    People say Linus Torvalds is a great software developer. No. He is not. Git is terrible software.

    @mott555 said:

    The couple times I used git I felt like it was a beast from another dimension where the rules of logic are totally different and incompatible with our own reality. It literally doesn't make sense to me, at all. I eventually got things to work but I don't know how or why.

    You, and all normal people.

    @LB_ said:

    Can someone explain to me why people don't like git? It's the only VCS I've ever used, so it's all I know. I like it.

    Have you ever noticed how the only people who actually like Git are the people who've literally never used anything else?

    @LB_ said:

    With git, I barely even notice when I'm using it because I almost never have issues, and any issues I do have are solved with a quick Google search. I've never had trouble manually resolving merge conflicts or understanding rebasing.

    You're either a super-genius, or a fucking liar.

    Or you've literally only used Git once, and all you did is copied-and-pasted the text from GitHub to start your repo. That one operation seems to work pretty reliably.


  • Notification Spam Recipient

    @blakeyrat said:

    ... seriously? I hope you don't write GUI software for a living, because this is the worst idea.

    SourceTree just lightly wraps the CLI interface, and it's fucking terrible. It isn't even capable of greying-out buttons that aren't relevant, it'll just pass on your nonsense commands to Git and let Git give you an error in a dialog full of text spew. (For example, it'll happily let you checkout a remote branch when you already have a local version of it-- even though SourceTree KNEWS you already have a local version of it-- and then just vomits-out Git's CLI error at you. Which is, natch terribly written.)

    Anyway, what you want already exists: it's called SourceTree. It's fucking awful.

    Obviously wrapping the console would be one of more retarded things that you can do but considering the state of git's landscape its one of the better ideas.

    Also I write shit guis but for some reason I get handed that mantle mostly because I actually fell upon the novel idea of asking users if the gui is shit and how can I improve it for them. Something git developers could fucking learn.



  • @blakeyrat said:

    You're either a super-genius, or a fucking liar.

    Or you've literally only used Git once, and all you did is copied-and-pasted the text from GitHub to start your repo. That one operation seems to work pretty reliably.

    Considering that I have 56 GitHub repositories and several others I've contributed to, as well as a group project where lots of people were messing with the code at the same time, I'm pretty sure I've done more than just copypaste example commands. By the time I found learnGitBranching I could already solve all the puzzles without help, so...


  • Grade A Premium Asshole

    From now until blakey's death, you will now be known as "that weirdo that gets Git".


  • Notification Spam Recipient

    @LB_ said:

    By the time I found learnGitBranching I could already solve all the puzzles without help, so...
    That's not exactly something you should be proud to admit... It's like admitting that you like drinking lead based paint.



  • Your warped, diseased, brain is good at using really fucking shitty software. Feel proud of yourself.

    Either that, or you're just like all those Linux users who say their laptop works "just fine", but when you ask some clarifying questions, it turns out their definition of "just fine" included installing custom drivers from source code and then just giving up on the Sleep feature ever working.

    I've been in that conversation enough times to know that people using open source have no idea if a particular thing works "just fine" because they have absolutely no concept whatsoever of "quality". Which I guess is common-sense when you think about it, because if they did, they wouldn't be using open source software...



  • Pretty much all software I use is broken and my computer sucks, I have a horrible daily experience developing code on my system. Git works great for me, though. I'm not saying git is the best VCS, I'm only saying I have never had annoying issues with it that I weren't my own fault or that I couldn't solve myself or that Google didn't know how to fix. My usual workflow with git is only a few simple commands that work pretty much all the time.

    I asked for people to explain what issues they have with git and instead you're criticizing my ability to use git as if it's a bad skill to have.



  • @Polygeekery said:

    From now until blakey's death, you will now be known as "that weirdo that gets Git".

    Reminds me of that xkcd comic!

    Git

    Edit: I meant the title text, specifically.



  • @blakeyrat said:

    you're just like all those Linux users who say their laptop works "just fine", but when you ask some clarifying questions, it turns out their definition of "just fine" included installing custom drivers from source code and then just giving up on the Sleep feature ever working.

    My Linux laptop works just fine, I never installed a custom driver and I never reboot it (except on kernel update) since Sleep works just fine.

    You are a fuckin liar !

    Hint : https://system76.com/


  • kills Dumbledore

    @accalia said:

    you really shouldn't embrace the CLI.

    FTFY



  • @LB_ said:

    Git works great for me, though.

    Since you've never used any other source control systems, how the FUCK are you qualified to judge this?

    That aside, you know, usually when I say people are liars, it's kind of a jokey "ha ha" type thing, but in this case you are actually a liar.

    You've never had any of the following happen:

    • A Git repo gets into a strange state you can't figure out and you end up having to re-pull a fresh copy to fix it

    • You want to do some extremely basic task (for example, editing the message on a commit that hasn't yet been pushed to a server) that Git makes extremely fucking difficult or impossible to do

    • You've had a build error because your poor compiler tried to compile the line:

    <<<<<<<<<<<<<<<<<<<<< frog.cs:36d7621efaa3b

    Because Git moronically overwrites your source files during merge conflicts, then fails to check whether the merges are resolved before continuing. How the fuck do you tab in this paragraph to match the bullet list it's a part of? Why is Markdown so fucking awful? This Markdown cheatsheet page says it's three spaces, but that sure as fuck doesn't work, and four spaces turns it into a preformatted pane thing. Fuck Discourse.

    • You've never been part of a project that would have benefited from the obvious features Git is missing, for example, being able to lock files, or having your "stash" space stored on the server

    • You've never had a pre-commit hook give you an extraordinarily-vague message like, "tag missing from source" which turns out, after wasting like 5 hours of your time, actually means, "commits to branches named after bugs need to have the bug number in the comment".

    @LB_ said:

    I asked for people to explain what issues they have with git and instead you're criticizing my ability to use git as if it's a bad skill to have.

    I don't care if you're good or bad at using Git. The important thing is:

    DON'T TELL PEOPLE GIT IS GOOD SOFTWARE WHEN IT'S NOT!

    I'm good at using Lotus Notes. I had to use it in an administrative capacity for like 4 years. But I'd NEVER in a MILLION YEARS tell someone it's good, just because I happen to know how to use it. Because it's not. It's utter shit.

    So is Git.

    Another example: I like the movie The Apple. I think it's entertaining as shit. I wouldn't ever call it a good movie, though. It's a terrible movie, possibly the worst musical ever made.


  • FoxDev

    @Jaloopa said:

    @accalia said:
    you really shouldn't embrace the CLI.

    FTFY

    not you too?!

    I expected Blakey to react with anti all things CLI, but you? i expected better.

    Son, i am disappoint.


  • kills Dumbledore

    Call me weird but I prefer software from this century, which is capable of giving hints as to how to use it



  • @blakeyrat said:

    Since you've never used any other source control systems, how the FUCK are you qualified to judge this?

    I didn't say it works better than other VCS. I said it works better than the rest of the crappy software on my crappy system.

    @blakeyrat said:

    A Git repo gets into a strange state you can't figure out and you end up having to re-pull a fresh copy to fix it
    This happened once when it wasn't respecting a rule in my .gitignore and files were being ignored that shouldn't have been.

    @blakeyrat said:

    You want to do some extremely basic task (for example, editing the message on a commit that hasn't yet been pushed to a server) that Git makes extremely fucking difficult or impossible to do
    git commit --amend opens notepad, letting me edit the message of the commit. I do this frequently without issue.

    @blakeyrat said:

    You've had a build error because your poor compiler tried to compile the line:
    Why the heck would you try to compile when you have merge conflicts!?

    @blakeyrat said:

    Because Git moronically overwrites your source files during merge conflicts, then fails to check whether the merges are resolved before continuing.
    I don't understand what you mean by "continuing". For me, it tells me that there were merge conflicts, and then I go fix them. I keep running git add --all && git status because it tells me whether or not I have fixed all merge conflicts. Then, I compile, fix any other issues, and git commit to conclude the merge.

    @blakeyrat said:

    You've never been part of a project that would have benefited from the obvious features Git is missing, for example, being able to lock files, or having your "stash" space stored on the server
    Why would I need to lock files? That's a :barrier: to progress in many cases.

    @blakeyrat said:

    You've never had a pre-commit hook give you an extraordinarily-vague message like, "tag missing from source" which turns out, after wasting like 5 hours of your time, actually means, "commits to branches named after bugs need to have the bug number in the comment".
    OK, you're right: I've never used hooks. You caught me.

    @blakeyrat said:

    DON'T TELL PEOPLE GIT IS GOOD SOFTWARE WHEN IT'S NOT!
    I only tell people that I like git and it works for me. I have never said it's good software. Now I don't know about you, but I only recommend software I have used myself.



  • @blakeyrat said:

    for example, editing the message on a commit that hasn't yet been pushed to a server

    I do that all the time. It's just git commit --amend and then it opens up whatever you have set as $EDITOR, which for me is vim.



  • @LB_ said:

    I didn't say it works better than other VCS. I said it works better than the rest of the crappy software on my crappy system.

    You must have the Guinness World Record crappiest of all crappy systems if Git's near the top of the quality list.

    @LB_ said:

    This happened once when it wasn't respecting a rule in my .gitignore and files were being ignored that shouldn't have been.

    Wow, it's almost as if Git was doing something buggy and wrong!

    @LB_ said:

    git commit --amend opens notepad, letting me edit the message of the commit. I do this frequently without issue.

    Right; now change the message for 3 commits ago.

    OH! Suddenly this super-easy task becomes NEARLY FUCKING IMPOSSIBLE! Even though none of those commits have been synced to the server, and there's no reason at all Git shouldn't allow you to change their comments at literally any time... well, you fucking can't. Why? Because Git won't let you. Why? ... because it hates all users, apparently.

    But oh wait! It has this extremely stupid feature where you can have Git "replay" your commits and during the replay you can edit their comments. Good luck trying to get this to work correctly without causing more problems, though.

    @LB_ said:

    Why the heck would you try to compile when you have merge conflicts!?

    1. I was referring to the merge conflicts getting pushed into the repo because Git retardedly stomps all over your source files, then doesn't bother checking whether you've actually resolved the conflicts before pushing

    2. Why the fuck shouldn't I be able to? A lot of times I have conflicts that can be quickly answered by simply trying to build the software ("which one of those enum names is the most recent? Well the wrong one will fail to build in like 0.5 seconds, quicker than looking it up..."). Visual Studio's conflict resolution thingy makes this trivially easy. If I were using Git outside of that, this extremely basic thing would be nightmarishly difficult.

    @LB_ said:

    I don't understand what you mean by "continuing". For me, it tells me that there were merge conflicts, and then I go fix them. I keep running git add --all && git status because it tells me whether or not I have fixed all merge conflicts. Then, I compile, fix any other issues, and git commit to conclude the merge.

    Right but you're Supergenius McGitsALot.

    @LB_ said:

    Why would I need to lock files? That's a :barrier: to progress in many cases.

    Maybe it's a binary file that you know in advance Git can't do shit to merge. And you want to save other people on your team time and effort by preventing them from editing the file simultaneously.

    Also note the standard open source user response, when you criticize their software for lacking a feature literally all of its competitors have: "you don't really need that". Fuck that attitude. Do you honestly think literally every company that uses TFS' file locking ability on a fucking daily basis, literally all of those thousands of companies don't really need the feature?! Seriously? That is the argument? Fucking-a.

    @LB_ said:

    OK, you're right: I've never used hooks. You caught me.

    Good; they're completely broken. So are submodules.

    Unfortunately, you need both to cover for Git's HUGE gaps in functionality.

    @ben_lubar said:

    I do that all the time. It's just git commit --amend and then it opens up whatever you have set as $EDITOR, which for me is vim.

    THAT ONLY WORKS FOR THE LATEST COMMIT YOU DUMB SHITS.

    Come on, Ben L, you know better than this. You fucking posted in the thread here where I complained about it.



  • In that case, git rebase -i will let you edit any commit(s) you want.



  • @ben_lubar said:

    In that case, git rebase -i will let you edit any commit(s) you want.

    Right; I know, we've had this discussion like a million times.

    The problem is: why would you post the solution you know, you know, you know DOESN'T FUCKING WORK in the first place? I know you know it. We've talked about it on this forum like a dozen times. You've been in those discussions. You've seen ALL of this before.

    Did you suddenly think I'd somehow lost like 45 IQ points and also all of my long-term memory and forget that? Did you think I'd go, "oh! Git Amend! Of course! The solution to my problem is simple!"

    No. Ben L, you're being fucking stupid. And moreso: you're being fucking stupid by assuming that I'm being stupid and don't do that because you're smarter than that, ok? Just don't.

    I gave LB_ a pass on the same comment because he probably wasn't here for those previous discussions, and he might genuinely think I would never in a billion years try to edit the comment of 3 commits ago. (He's still stupid for posting it without bothering to clarify when it works and when it doesn't, but he's not disappointingly stupid like you were.)


  • Grade A Premium Asshole

    @ben_lubar said:

    In that case, git rebase -i will let you edit any commit(s) you want.

    "Honey, I'm thirsty." – 02:46
    — kriegsman



  • @blakeyrat said:

    Wow, it's almost as if Git was doing something buggy and wrong!
    I didn't say it wasn't ;)

    @blakeyrat said:

    Right; now change the message for 3 commits ago.

    OH! Suddenly this super-easy task becomes NEARLY FUCKING IMPOSSIBLE! Even though none of those commits have been synced to the server, and there's no reason at all Git shouldn't allow you to change their comments at literally any time... well, you fucking can't. Why? Because Git won't let you. Why? ... because it hates all users, apparently.

    But oh wait! It has this extremely stupid feature where you can have Git "replay" your commits and during the replay you can edit their comments. Good luck trying to get this to work correctly without causing more problems, though.

    Just checkout that commit, --amend it, and then rebase the newer commits onto it. I don't have to do it often, but it's not hard. You could just use Google if you get confused.

    @blakeyrat said:

    1) I was referring to the merge conflicts getting pushed into the repo because Git retardedly stomps all over your source files, then doesn't bother checking whether you've actually resolved the conflicts before pushing
    Git always tells you about merge conflicts and it reminds you on git status, what broken version of git are you using that doesn't?

    @blakeyrat said:

    2) Why the fuck shouldn't I be able to? A lot of times I have conflicts that can be quickly answered by simply trying to build the software ("which one of those enum names is the most recent? Well the wrong one will fail to build in like 0.5 seconds, quicker than looking it up..."). Visual Studio's conflict resolution thingy makes this trivially easy. If I were using Git outside of that, this extremely basic thing would be nightmarishly difficult.
    I don't know what magical unicorns you expect your compiler to use in order to compile code with merge conflicts.

    @blakeyrat said:

    Maybe it's a binary file that you know in advance Git can't do shit to merge. And you want to save other people on your team time and effort by preventing them from editing the file simultaneously.
    No, I don't want to do that. I want everyone to be able to edit the file if they need to, because resolving merge conflicts by hand is trivial. Either pick one version or the other, or open the file and combine both versions in the correct way that git couldn't possibly have known ahead of time.

    @blakeyrat said:

    Also note the standard open source user response, when you criticize their software for lacking a feature literally all of its competitors have: "you don't really need that". Fuck that attitude. Do you honestly think literally every company that uses TFS' file locking ability on a fucking daily basis, literally all of those thousands of companies don't really need the feature?! Seriously? That is the argument? Fucking-a.
    I personally believe that locking should not be a feature. It's a bad idea IMO. Maybe it makes sense in other VCS because of their workflow, but it doesn't make sense in the git workflow.

    @blakeyrat said:

    So are submodules.
    I agree, but they're at least getting better. So far they only have issues with git worktree, they work pretty much everywhere else.

    @blakeyrat said:

    I gave LB_ a pass on the same comment because he probably wasn't here for those previous discussions, and he might genuinely think I would never in a billion years try to edit the comment of 3 commits ago.
    It is not a normal use case for me to have multiple commits not yet pushed. I almost always have either 0 or 1 unpushed commits. Sorry for making an ass out of me and you.



  • @blakeyrat said:

    Because Git moronically overwrites your source files during merge conflicts, then fails to check whether the merges are resolved before continuing. How the fuck do you tab in this paragraph to match the bullet list it's a part of? Why is Markdown so fucking awful? This Markdown cheatsheet page says it's three spaces, but that sure as fuck doesn't work, and four spaces turns it into a preformatted pane thing. Fuck Discourse.

    I love how you just went into another rant in the middle of a rant without warning, and then transitioned back to the original rant seamlessly. Rantception.



  • @LB_ said:

    I don't have to do it often, but it's not hard. You could just use Google if you get confused.

    OH LOOK you admit your solution DID NOT FUCKING WORK ALSO! You and Ben L should get a little cottage together and raise sheep or. Some fucking thing.

    @LB_ said:

    Git always tells you about merge conflicts and it reminds you on git status, what broken version of git are you using that doesn't?

    GitHub for Windows, SourceTree both allow "resolving" a conflict without actually resolving it. With no indication. When this happens, neither prevents you from simply pushing the commit up the chain and breaking everything, EVEN THOUGH THE COMMIT STILL CONTAINS THE MERGE MARKERS.

    Visual Studio is better about it, it takes a lot of human error to cause this in VS.

    There's only one version of Git: the really really shitty CLI version that all of those tools use. So it does allow this. And "Git Status" whatever that is is something I'm pretty sure I've literally never seen in my years and years and years of struggling with this shitty piece of ass broken software ass.

    @LB_ said:

    I don't know what magical unicorns you expect your compiler to use in order to compile code with merge conflicts.

    If Git didn't PUT THE MERGE CONFLICTS IN MY FUCKING SOURCE FILES! than it would be trivial.

    The biggest question is: why would you expect Git to stomp all over your source file because another source file in another branch entirely doesn't cleanly merge with it? Is it because you're a retard? I bet that's it.

    @LB_ said:

    No, I don't want to do that. I want everyone to be able to edit the file if they need to, because resolving merge conflicts by hand is trivial.

    So Bob spends 2 weeks editing "2015 forecast.xlsx". Two days after he starts, Sally begins her edits to "2015 forecast.xlsx" and it takes her two weeks as well. Now we merge.

    ... oops! I have to pick EITHER Bob or Sally's version! Which means, no matter what, OUR COMPANY JUST WASTED TWO ENTIRE WEEKS OF LABOR BECAUSE OF ITS SHITTY BROKEN SOURCE CONTROL PRODUCT. Gee, imagine how nice it would have been if Bob could have simply put some kind of lock on that excel file before he started.

    But you're ok with that. Because you're a fucking idiot who hasn't ever used anything besides Git and has NO FUCKING CLUE.

    @LB_ said:

    I personally believe that locking should not be a feature. It's a bad idea IMO.

    You're wrong. Wasting people's time is wrong. Software that easily allows people to accidentally waste their time is wrong.

    @LB_ said:

    Maybe it makes sense in other VCS because of their workflow, but it doesn't make sense in the git workflow.

    Then the Git workflow is also wrong.

    @LB_ said:

    I agree, but they're at least getting better. So far they only have issues with git worktree, they work pretty much everywhere else.

    YOU FUCKING LIAR you are such a liar. Jesus. It's giving me a headache.

    Unless "pretty much everywhere else" translates to "FUCKING NO GIT TOOLS ANYWHERE SUPPORT THIS, FUCK YOU". (Not even SourceTree, which supports most Git features, albeit in an incredibly awful UI.)

    @LB_ said:

    It is not a normal use case for me to have multiple commits not yet pushed.

    Doesn't matter; the point is YOU GAVE ME A WRONG SOLUTION YOU KNEW WAS WRONG and didn't even bother pointing out that it only worked in a single case.

    That kind of thing pisses me off. More so from Ben L, who knows better.



  • @blakeyrat said:

    years and years of struggling with this shitty piece of ass broken software ass.

    :crying_with_laughter:



  • @blakeyrat said:

    OH LOOK you admit your solution DID NOT FUCKING WORK ALSO!

    It has worked every time I've done it? Look, I don't claim to have memorized exactly how to do everything you could possibly come up with.

    @blakeyrat said:

    GitHub for Windows, SourceTree both allow "resolving" a conflict without actually resolving it. With no indication. When this happens, neither prevents you from simply pushing the commit up the chain and breaking everything, EVEN THOUGH THE COMMIT STILL CONTAINS THE MERGE MARKERS.

    Visual Studio is better about it, it takes a lot of human error to cause this in VS.

    There's only one version of Git: the really really shitty CLI version that all of those tools use. So it does allow this. And "Git Status" whatever that is is something I'm pretty sure I've literally never seen in my years and years and years of struggling with this shitty piece of ass broken software ass.

    So your opinion of git is based entirely on broken software that uses git as its back end? I've used GitHub for Windows, basically anything more than "edit files and commit them" breaks in it. It sucks. So, I use the command line instead because it actually works.

    @blakeyrat said:

    If Git didn't PUT THE MERGE CONFLICTS IN MY FUCKING SOURCE FILES! than it would be trivial.

    The biggest question is: why would you expect Git to stomp all over your source file because another source file in another branch entirely doesn't cleanly merge with it? Is it because you're a retard? I bet that's it.

    Please tell me: what do you expect to happen when there is a merge conflict? Almost always I want to either fix the conflict, or sometimes I want to abort. So git by default sets me up to fix the conflict, or I can run git merge --abort to cancel.

    @blakeyrat said:

    So Bob spends 2 weeks editing "2015 forecast.xlsx". Two days after he starts, Sally begins her edits to "2015 forecast.xlsx" and it takes her two weeks as well. Now we merge.

    ... oops! I have to pick EITHER Bob or Sally's version! Which means, no matter what, OUR COMPANY JUST WASTED TWO ENTIRE WEEKS OF LABOR BECAUSE OF ITS SHITTY BROKEN SOURCE CONTROL PRODUCT.

    But you're ok with that. Because you're a fucking idiot who hasn't ever used anything besides Git and has NO FUCKING CLUE.

    Actually, this is good, because now two people have done the work and if the work differs in any way you know immediately that one of them messed up. If only one person did the work, you'd have no idea.

    @blakeyrat said:

    YOU FUCKING LIAR you are such a liar. Jesus. It's giving me a headache.

    Unless "pretty much everywhere else" translates to "FUCKING NO GIT TOOLS ANYWHERE SUPPORT THIS, FUCK YOU". (Not even SourceTree, which supports most Git features, albeit in an incredibly awful UI.)

    I don't claim that it works with random git tools that you mysteriously find and download. I claim it works in git. git can't be held responsible for other people's broken software.

    @blakeyrat said:

    Doesn't matter; the point is YOU GAVE ME A WRONG SOLUTION YOU KNEW WAS WRONG and didn't even bother pointing out that it only worked in a single case.
    The solution I gave you was correct for the scenario I assumed you were talking about. Again, I'm sorry for making an assumption. The reason I didn't mention it doesn't work in other cases is because I believe those other cases are wrong. We're just going to have to disagree here about whether having more than one unpushed commit is an okay thing.


Log in to reply