More stupid Git errors THIS TIME IN FIRST-PERSON!



  • It seems that there is already a rebase-merge directory, and

    I wonder if you are in the middle of another rebase. If that is the
    case, please try
    git rebase (--continue | --abort | --skip)
    If that is not the case, please
    rm -fr "c:/Users/blakeyrat/Documents/Source/ACompany/.git/rebase-merge"
    and run me again. I am stopping in case you still have something
    valuable there.

    What is this, a fucking conversation now!? FUCKING WORK YOU PIECE OF SHIT!

    Oh and good job with your Windows "port"; obviously in Windows "rm -fr" is the correct thing to you, you broken piece of shit written by idiots who should die.

    (And no, I was not in the middle of another rebase. And when I did the identical operation a second time, it worked with no error. How about that error message reads: "it looks like git is a piece of trash that doesn't work".)


  • FoxDev

    @blakeyrat said:

    >I am stopping in case you still have something valuable there.

    well at least it's being polite and not nuking whatever rebase it detected you were in the middle of.

    and yes, rebase, because of its nature rewriting history has always had the potential to be a conversation like that, because as you merge commits there may be merge conflicts that you would have to deal with on a commit by commit basis. That's something you could do in a workflow in a GUI but the canonical git client is CLI only so it doesn't have that option.



  • That's a pretty poorly phrased error message, but I disagree that the intent of the message is bad. It's stopping you from potentially breaking your repo.



  • @accalia said:

    well at least it's being polite and not nuking whatever rebase it detected you were in the middle of.

    I just added a bit to the OP to point out the only rebase I was in the middle of was the one I was trying to do when that error appeared.

    @JazzyJosh said:

    That's a pretty poorly phrased error message, but I disagree that the intent of the message is bad.

    The problem is:

    1. The message is written in the first-person when LITERALLY NO ERROR MESSAGE I'VE EVER SEEN FROM GIT EVER BEFORE EVER IS, is there just no style guide whatsoever for Linux errors? It's just "shit text on the screen, who gives a fuck what format it's in?" (Complete with all the problems involved in writing an error in first person, for example, now my fucking computer is musing at me. You don't know the cause of the error? It's your fucking error!)

    2. The error is Git's own fault; it fucked something up and caused its own error, then told me about it as if it was my fault. Fuck that noise.

    3. The instructions the error message gives you to resolve the situation are plain wrong. Just fucking WRONG.


  • FoxDev

    @blakeyrat said:

    I just added a bit to the OP to point out the only rebase I was in the middle of was the one I was trying to do when that error appeared.

    hmm... my apologies then. it was not on my screen when i submitted the original reply.

    The message reads as if you were trying to continue a rebase and didn't set the continue flag. What operation were you attempting to perform? You havent indicated and it may be relevant.

    @blakeyrat said:

    1) The message is written in the first-person when LITERALLY NO ERROR MESSAGE I'VE EVER SEEN FROM GIT EVER BEFORE EVER IS, is there just no style guide whatsoever for Linux errors? It's just "shit text on the screen, who gives a fuck what format it's in?"

    a valid point i guess. AFAIK there is no such styleguide ecosystem wide but most projects do have a local styleguide. if this really is the only git error message that is in first person then it may have missed the style guide check when it was added or the reviewer determined that the case was important enough to allow the break in style.

    @blakeyrat said:

    2) The error is Git's own fault; it fucked something up and caused its own error, then told me about it as if it was my fault. Fuck that noise.

    if true a valid point, what operation were you attempting when this error message was generated and what state was your repo in at that time?

    @blakeyrat said:

    3) The instructions the error message gives you to resolve the situation are plain wrong. Just fucking WRONG.

    Yes, that is an issue. a valid point.



  • @accalia said:

    The message reads as if you were trying to continue a rebase and didn't set the continue flag. What operation were you attempting to perform? You havent indicated and it may be relevant.

    Who gives a shit?

    But for the record, I needed to change the message of a commit, because I typoed the issue number and our "pre-commit hook" (which is a code phrase meaning, "useless shit installed to piss everybody off") rejects commits with the wrong issue number.

    Per usual with that broken piece of shit program, it would have been quicker for me to make a new branch and push the fix there instead of trying to fix a 1-character typo. Because easy things should be hard as fuck, that's the open source way.

    @accalia said:

    a valid point i guess. AFAIK there is no such styleguide ecosystem wide

    Which is especially awesome when programs are running these other programs as if they were APIs. Which probably also explains why SourceTree just flat-out gives up trying to interpret or handle any of Git's errors, and just barfs them back at you.

    @accalia said:

    but most projects do have a local styleguide.

    Gasp! It's almost as if Linus Torvalds, KING-EMPEROR OF ALL PROGRAMMERS EVERYWHERE doesn't do even the most basic shit to ensure software quality!

    @accalia said:

    what state was your repo in at that time?

    What does it even mean for a repo to be in a "state"? It's just a repo. It just sits there.

    @accalia said:

    Yes, that is an issue. a valid point.

    So were the other two.


  • area_pol

    And that's one of the reasons I hate git with all my heart. Why don't people use stuff that actually works (like Mercurial) and doesn't encourage you to shoot yourself in the foot.



  • @NeighborhoodButcher said:

    And that's one of the reasons I hate git with all my heart.

    I'm suspicious of anybody who doesn't.

    Other than Lotus Notes, no piece of software I've ever been compelled to use in my entire career has pissed me off as much as Git. And that includes that awful issue tracker that insurance company I worked for had.

    EDIT: and for the record, I only post maybe a third of the buggy awful Git behavior I see on a daily basis here. Maybe a third, probably far less.


  • area_pol

    @blakeyrat said:

    I'm suspicious of anybody who doesn't.

    I work with two gitologists and, goddamn, it's impossible to reason with them. Every git problemfeature is explained as "works for me, you're doing something wrong". Every show of a feature which is not present in git is met with "that's stupid/nobody uses that". I actually never met a gitologist who can make a reasonable argument about SCMs. It's like telling an Apple user that his product in inferior in some way - you'll only get garbage and generalizations thrown your way.


  • I survived the hour long Uno hand

    @blakeyrat said:

    What does it even mean for a repo to be in a "state"? It's just a repo. It just sits there.

    Not in git-land. In git-land, simple, atomic operations like a commit take multiple steps using the command line, so between issuing the first commit and issuing the last one, you're in a mid-commit state, which you could easily forget and walk away from and then be confused about later. This is true for most operations that matter. I still have no idea why that's supposed to be better; I have a hunch it's tied to how Github for Windows keeps fucking itself over so it can't sync anymore.



  • @Yamikuronue said:

    I still have no idea why that's supposed to be better;

    LINUS TORVALDS OUR GOD AND MASTER WROTE IT@@!!! HE ARE EXPERT SOFTRARE DEVLOPER!!! BOEW BEFORE THE TORLVALDSA!



  • @blakeyrat said:

    because I typoed the issue number and our "pre-commit hook" (which is a code phrase meaning, "useless shit installed to piss everybody off") rejects commits with the wrong issue number.
    I think I have found your problem. Since a "pre-commit hook" is whatever piece of shit script someone at your company has shat out in his spare time, it totally might have screwed up the state of the repo, such that rebase would get confused. (Literally, if you had to do anything other than "git commit" with the new message or "git commit --amend" with the new message, your company's hook done fucked up royally, not Git.)


  • FoxDev

    @blakeyrat said:

    Who gives a shit?

    because it turns out to have been relevant to the source of your issues.

    @blakeyrat said:

    I needed to change the message of a commit, because I typoed the issue number and our "pre-commit hook" (which is a code phrase meaning, "useless shit installed to piss everybody off") rejects commits with the wrong issue number.
    ah.

    precommit hooks are evil.

    evil i say.

    @blakeyrat said:

    programs are running these other programs as if they were APIs
    they are APIs.

    they may not be terribly nice APIs to work with, but APIs they are.

    @blakeyrat said:

    SourceTree just flat-out gives up trying to interpret or handle any of Git's errors, and just barfs them back at you.
    hell, i use git directly and over half the time i get errors like that i also give up trying to parse them and reset/reclone the repo and try again but different and with 100% more success (usually)

    @blakeyrat said:

    Gasp! It's almost as if Linus Torvalds, KING-EMPEROR OF ALL PROGRAMMERS EVERYWHERE doesn't do even the most basic shit to ensure software quality!
    he's king of the kernel, talk to GNU about userspace.

    @blakeyrat said:

    What does it even mean for a repo to be in a "state"? It's just a repo. It just sits there.
    it does more than that. is the repo currently merging/rebasing? is it dirty with uncommitted changes? is it ahead of upstream with unpushed changes? do you have any local stashes?

    all these things matter when you are talking about operations that affect the state of the entire repo.

    @blakeyrat said:

    So were the other two.
    fair enough, however i reserve the right to disagree with you on the severity and impact of the issues



  • @accalia said:

    it does more than that. is the repo currently merging/rebasing?

    That's not atomic? Why not?

    @accalia said:

    is it dirty with uncommitted changes?

    "dirty"? WTF are you even talking about?

    @accalia said:

    is it ahead of upstream with unpushed changes?

    Why is that a "state"?

    @accalia said:

    do you have any local stashes?

    Why is that a "state"?


  • I survived the hour long Uno hand

    @accalia said:

    precommit hooks are evil.

    evil i say.

    Precommit hooks to validate the commit message are an incredibly handy tool to use to ensure everyone's on the same page with what information goes in a commit message. We're looking at implementing them at my company using Subversion to ensure that a JIRA ticket is referenced before we even consider integrating your change. If we can swing it, we'll run the unit tests too, because why not?


  • FoxDev

    @blakeyrat said:

    That's not atomic?

    it requires extensive user interaction how could it be?

    @blakeyrat said:

    "dirty"? WTF are you even talking about?
    do. you. have. local. changes. that. are. not. part. of. the. index. yet?

    @blakeyrat said:

    Why is that a "state"?
    because your HEAD commit is part of the state and your HEAD is not the HEAD that is on upstream

    @blakeyrat said:

    Why is that a "state"?
    because they affect your local index.


  • I survived the hour long Uno hand

    @accalia said:

    it requires extensive user interaction how could it be?

    You initiate a multi-step process. An application of some kind takes over, walking you through the steps. When it quits, it leaves your repo in an atomic stage: merged, or reverted. Done. Why risk the user doing stupid shit in the middle of a complex action?



  • @Yamikuronue said:

    We're looking at implementing them at my company using Subversion to ensure that a JIRA ticket is referenced before we even consider integrating your change.

    If you do, FOR GOD'S SAKE MAKE SURE THE ERROR MESSAGES IT RETURNS ARE USEFUL!

    Because the messages you get from the Stash pre-commit hook are FUCKING AWFUL! And don't even slightly resemble the actual error. (The one for having the wrong issue number says something about failing to sync the list of tags, it's seriously completely bonkers.)

    @accalia said:

    it requires extensive user interaction how could it be?

    Works in TFS.

    @accalia said:

    do. you. have. local. changes. that. are. not. part. of. the. index. yet?

    I. Don't. Know. Even. If. I. Did. Why. Is. That. A. "State"?

    @accalia said:

    because your HEAD commit is part of the state and your HEAD is not the HEAD that is on upstream

    ... ok? And so what?

    @accalia said:

    because they affect your local index.

    ... ok? And so what?


  • FoxDev

    @blakeyrat said:

    Works in TFS.

    goodie for you. use that then.

    @blakeyrat said:

    I. Don't. Know. Even. If. I. Did. Why. Is. That. A. "State"?
    because that affects your local index. the local index is your state. you need to keep an eye on your state.

    you don't want to end up in florida when you were aiming for california.


  • I survived the hour long Uno hand

    @blakeyrat said:

    (The one for having the wrong issue number says something about failing to sync the list of tags, it's seriously completely bonkers.)

    eeeww, I hate that crap. We won't be using Stash, so hopefully we can get something sensible.



  • @accalia said:

    goodie for you. use that then.

    I'D FUCKING LOVE TO.

    @accalia said:

    because that affects your local index. the local index is your state. you need to keep an eye on your state.

    Ok, look. "dirty" is the word to mean, "you made changes to these files but haven't committed the changes yet?" So it's like not only is Git fucking terrible, but it's also insulting. "The code you write? It's dirty. It's filthy. Fuck you."

    Secondly, WHY? Why do I need to "keep an eye on my state?"


  • FoxDev

    @blakeyrat said:

    Ok, look. "dirty" is the word to mean, "you made changes to these files but haven't committed the changes yet?"

    no. dirty is the word to mean "this data structure is not in an internally and externally consistent state. you should treat it with respect and care until you can get the state to be clean. Look i'm sorry about the words but some greybeards came up with them eighty years ago and it's too late to choose better ones now okay!?"

    the fact that you have uncommitted changes is just one possible way that wave function can collapse.

    and yes it is a bad name, as are master/slave drives but unlike the PATA/IDE standard that concept in computer science is not going away any time soon. You could start a campaign to get it renamed if it would make you feel better though.

    @blakeyrat said:

    Secondly, WHY? Why do I need to "keep an eye on my state?"
    because operations that change the state of the repository, particularly potentially dangerous operations can have unintended consequences if the state you are actually operating on is different than the one you think you are operating on.



  • @accalia said:

    it's too late to choose better ones now okay!?"

    Git was built in 2005, that's not 80 years ago. They made the bed, now they have to lie in it.

    @accalia said:

    the fact that you have uncommitted changes is just one possible way that wave function can collapse.

    Again: what the fuck are you talking about? What's a "wave function?" Are you just making up new Git terminology now?

    @accalia said:

    and yes it is a bad name,

    So a developer who picks it is a bad developer.

    @accalia said:

    You could start a campaign to get it renamed if it would make you feel better though.

    I could also bang my head against a wall.

    @accalia said:

    because operations that change the state of the repository, particularly potentially dangerous operations can have unintended consequences if the state you are actually operating on is different than the one you think you are operating on.

    Sounds like a quality and easy-to-use software product.


  • Discourse touched me in a no-no place

    @Yamikuronue said:

    Precommit hooks to validate the commit message are an incredibly handy tool to use to ensure everyone's on the same page with what information goes in a commit message. We're looking at implementing them at my company using Subversion to ensure that a JIRA ticket is referenced before we even consider integrating your change. If we can swing it, we'll run the unit tests too, because why not?

    That is what we do as well, and also for securing branches of shipped code (only bug fixes are allowed, and only if customer has requested them). We have them for Visual Source Safe 6 (yea, still use that for an old development environment) and SVN. Then the number is stamped on on branches for tracking in our issue tracking software.



  • @blakeyrat said:

    "dirty" is the word to mean

    Changes that haven't yet been stored.
    I thought you wrote software?

    A "dirty" flag is almost universal nomenclature in applications with any kind of save/store/commit/refresh/caching functions to indicate when a user or external event has made/caused some changes but the application has not yet saved/stored/committed/refreshed them.

    You must have encountered it.

    "Do you want to save before quitting?" only pops up if you have unsaved changes - or if you're using Excel because Excel is stupid.



  • @lightsoff said:

    I thought you wrote software?

    I do.

    @lightsoff said:

    A "dirty" flag is almost universal nomenclature in applications with any kind of save/store/commit/refresh/caching functions to indicate when a user or external event has made/caused some changes but the application has not yet saved/stored/committed/refreshed them.

    You must have encountered it.

    Yeah, I have. It's a shitty, terrible term that should not be used by anybody. Especially when you're designing a new system from scratch in 2005, you should have known better.

    "We've always done it that way" is always the worst reason to justify any decision.

    @lightsoff said:

    "Do you want to save before quitting?" only pops up if you have unsaved changes - or if you're using Excel because Excel is stupid.

    And how would you feel if Excel called your spreadsheet "dirty"?



  • @blakeyrat said:

    And how would you feel if Excel called your spreadsheet "dirty"?

    Satisfied.
    (excel may be useful - but the way it's used is Waaaaayyyyyy too often beyond dirty)


  • ♿ (Parody)

    @blakeyrat said:

    I'm suspicious of anybody who doesn't.

    I like git, but mainly because of how it consistently trolls you. I've never used it beyond cloning something instead of downloading a tarball.


  • ♿ (Parody)

    @blakeyrat said:

    Git was built in 2005, that's not 80 years ago. They made the bed, now they have to lie in it.

    You're not saying that someone should take an established word and throw it away and use something else, are you? That sounds like gibberish talk to me.


  • ♿ (Parody)

    @blakeyrat said:

    And how would you feel if Excel called your spreadsheet "dirty"?

    Why do you think "dirty" is insulting? This sounds like a personal problem. Are you offended by "dirty" dishes? I assume that you don't have actual dirt as a big component of your cuisine.


  • Discourse touched me in a no-no place

    @accalia said:

    or the reviewer determined that the case was important enough to allow the break in style.

    Or maybe the person who wrote the error is, in fact, an idiot or otherwise goofy. In college I once got "I strongly object to casting <something> to <something else>" from a C compiler, and that was quite atypical.

    ETA: fixed busted html thanks to PM.



  • @lightsoff said:

    @blakeyrat said:
    "dirty" is the word to mean

    Changes that haven't yet been stored.

    All that mingling of semantic fields got me confused. Having dirty thoughts now means employing short-term memory.

    @boomzilla said:

    Are you offended by "dirty" dishes?

    I do actually like the word dirty in the context of caches. It creates a sense of urgency. You want to clear the dirty bits as soon as possible. That's all good usage. "Here the index is still dirty so we can't rely on it" sounds fine to me. We know the index is wrong and it's going to be cleared.

    When talking about changes we're uncommitted about, like changes to a repo, it might come across as judgemental. "Your repo is dirty and I won't touch it" is not very friendly is it? It does take an unexperienced or willfully malcontent mind to read it that way though. We're talking about tools developed for experts after all.

    Can't say I've been offended by Git talking dirty to me. But then I'm no bigot, and half of my changes are so dirty I wouldn't commit to them, and the other half, those I commit, are mostly dirty still. Some people apparently don't like to be reminded of that fact, or they're pedantic saints.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    "dirty"? WTF are you even talking about?

    Jesus, really? Dirty means "changes were made but not saved."



  • @accalia said:

    what state was your repo in at that time?

    Washington



  • @Yamikuronue said:

    simple, atomic operations ... take multiple steps

    Huh? If you mean that an error causes the previous steps to be rolled back, ok, I'll give you atomic. Simple? No. Or do you mean "things that should be simple, atomic operations?"



  • @boomzilla said:

    Are you offended by "dirty" dishes?

    You've never seen my kitchen. It's pretty offensive.


  • :belt_onion:

    Another Blakeyrat doesn't understand Git thread. Wohoo...

    /thread


  • :belt_onion:

    @blakeyrat said:

    @accalia said:
    it does more than that. is the repo currently merging/rebasing?

    That's not atomic? Why not?

    It is atomic. A merge either succeeds or fails. If it fails, the conflicted state is presented to you (the user) so you can either throw it (atomic) out or fix the conflict and then commit the edited data (also atomic). With a rebase the same thing happens, just with multiple commits being applied in order, one after the next+

    As others here have said, it sounds like the problem is with Stash / the company scripts, which aren't telling you what the underlying problem is - Git knows what it does well enough, but it can't know how it's being used at a higher level than the repository. Stash doing five different operations behind the scenes and then pushing any error message at you, rather than translating it into an error that makes sense in the context of what it's enabling you to do is TR :wtf:



  • @JazzyJosh said:

    That's a pretty poorly phrased error message...

    Some things need a diagram. I'm used to GUIs (e.g. sourcetree) for checking things like what branch I'm in, what the order of commits is, and what is merged into what.

    It would also be nice to see what stage of the rebase I'm in when I'm resolving merge conflicts, but then I get flashbacks to the war every time I have to resolve conflicts, so maybe it's just me.


  • I survived the hour long Uno hand

    @svieira said:

    It is atomic

    The series of operations cannot be divided apart and executed partially from each other, which makes the series of operations "indivisible", hence the name.

    If it takes multiple steps and you can do other things in between the steps, it's not atomic. It's been divided.


  • BINNED

    @blakeyrat said:

    And how would you feel if Excel called your spreadsheet "dirty"?

    The microagressions thread is :assorted_arrows.mp3:.



  • @sloosecannon said:

    Another Blakeyrat doesn't understand Git thread. Wohoo...

    If I understood Git, would that error message magically turn into a better one? Would it's instructions for resolving the problem magically become correct?

    @svieira said:

    It is atomic. A merge either succeeds or fails.

    Oh, ok, good.

    @svieira said:

    If it fails, the conflicted state is presented to you (the user) so you can either throw it (atomic) out or fix the conflict and then commit the edited data (also atomic).

    So... it's not atomic then. Good job instantly contradicting yourself. Either that or you don't understand what the word "atomic" means when applied to software.

    @svieira said:

    Stash doing five different operations behind the scenes and then pushing any error message at you, rather than translating it into an error that makes sense in the context of what it's enabling you to do is TR

    I concur. But it has nothing to do with the error I'm presenting here.

    @Shoreline said:

    Some things need a diagram.

    It's almost as if... GUIs are better at user interaction than CLIs? Hm!

    @Shoreline said:

    I'm used to GUIs (e.g. sourcetree) for checking things like what branch I'm in, what the order of commits is, and what is merged into what.

    The theory is nice, but SourceTree is fucking awful.



  • Subversion has states as well.

    Try editing the same part of the same file as one of your coworkers, have them check their changes in, then do an svn update.

    Any time you have a VCS that has manual conflict resolution, the local repository has state.



  • To me, the word 'dirty' implies gratuitous amounts of harmonic distortion, which doesn't sound like a good thing for source code to have.


  • kills Dumbledore


  • I survived the hour long Uno hand

    Sure. But Git has more of them. So we've moved the wrong direction IMO.



  • @blakeyrat said:

    you don't understand what the word "atomic" means when applied to software.

    Git should be "atomic."

    :)

    Disclaimer: Personally, I have nothing against git; I've never used it. However, based on what I've read here, I'd probably choose something else.


  • FoxDev

    @HardwareGeek said:

    Disclaimer: Personally, I have nothing against git; I've never used it. However, based on what I've read here, I'd probably choose something else.

    it's not as bad as we make it out to be. it's actually pretty slick. the problem is that while every VCS is going to have pain points and rough edges..... with git the rough edges are about a 20 grit sandpaper and the pain points are about 4k centigrade....



  • @powerlord said:

    Any time you have a VCS that has manual conflict resolution, the local repository has state.

    That may be true, but that does not have to be true.


  • ♿ (Parody)

    @blakeyrat said:

    @powerlord said:
    Any time you have a VCS that has manual conflict resolution, the local repository has state.

    That may be true, but that does not have to be true.

    How could it not be true? Is "state" a very loaded word for you here? The more I look at your comment it the less sense it makes.


Log in to reply