More GitHub WTF



  • I just got

    from GitHub.

    How on $planet does GitHub suddenly decide that an account that exists for some years, has repositories, has comments in many bug reports that are not being marked as spam, has integrated merge requests and is member of two organizations is not a human?


  • sockdevs

    Dodgy reverse Turing test


  • Winner of the 2016 Presidential Election

    mostly harmless robots

     

    We promise we won't require DNA proof

    Uurgh, I hate all that "we're so friendly and wacky. Look at our friendly and wacky error messages" shit.



  • Can you still use it? Can you use this way to get unlimited free private repositories?



  • @Jaloopa said:

    Uurgh, I hate all that "we're so friendly and wacky. Look at our friendly and wacky error messages" shit.

    Well, if you are called GitHub, it can be kinda expected.

    It seems to conflict with their social justicy attitude.

    Filed under: does it?



  • It's not what I need and to their credit, they fixed the issue pretty quickly.


  • Winner of the 2016 Presidential Election

    Personally, I think they should be the first against the wall when the revolution comes.



  • Second, Oracle are first


  • sockdevs

    @Onyx said:

    Personally, I think they should be the first against the wall when the revolution comes.

    The guys at Sirius Cybernetics Corporation breathe a collective sigh of relief



  • @RaceProUK said:

    The guys at Sirius Cybernetics Corporation breathe a collective sigh of relief

    Perhaps Github is the corporate ancestor of the Sirius Cybernetics Corporation, although Oracle does sound a more likely candidate.



  • @Jaloopa said:

    require DNA proof

    How about Douglas Noel Adams proof?



  • It's not even a close call, come on - Look what Oracle have done to MySQL, OpenOffice, Java...and then there's Oracle DB.

    Granted, some of the sin is with Sun but that's officially Oracle now, so they get the blame.



  • To be fair, we only have your word for it that you're not a robot.





  • As I discovered, they have taken their cue from git on useful error messages. It possibly means that someone flagged something as a Terms of Service violation. Have you contacted them?

    :hanzo:

    @Bulb said:

    It's not what I need and to their credit, they fixed the issue pretty quickly.

    Did they say why your account got flagged?



  • @thegoryone said:

    some of the sin is with Sun but that's officially Oracle now

    I know a guy who works there. When they were taken over, he said they instituted about every bad software engineering practice he could think of. And he explicitly mentioned underrating of security issues as one.


    @boomzilla said:

    Did they say why your account got flagged?

    Of course not.



  • Hence why I just said "some", they do get the blame for some terrible Java releases but I think we can all agree it's gotten considerably worse since J7 thanks to Oracle



  • @Bulb said:

    How on $planet does GitHub suddenly decide that an account that exists for some years, has repositories, has comments in many bug reports that are not being marked as spam, has integrated merge requests and is member of two organizations is not a human?

    It happened to me when I was pushing the same commits to two repositories repeatedly. Got fixed pretty easily.



  • The site has "git" in the VERY NAME, why are you people surprised that it's awful?



  • @blakeyrat said:

    why are you people surprised that it's awful?

    Because the website itself is not open source. :wink:


  • Impossible Mission Players - A

    @gordonjcp said:

    To be fair, we only have your word for it that you're not a robot.

    Nobody seems to honestly believe I'm not, so I would suspect that I've been largely successful in that regard. :thumbsup:


  • area_can

    This banhammer made with :heart: in San Francisco



  • @Hanzo said:

    Perhaps Github is the corporate ancestor of the Sirius Cybernetics Corporation, although Oracle does sound a more likely candidate.

    No need to panic until the announcement that Oracle has bought GitHub.

    Filed under: signs of the end times


  • :belt_onion:

    GitHub channeling Atwood:

    tl;dr: CLOSED WONTFIX DOING_IT_WRONG


  • Impossible Mission Players - A

    @Greybeard said in More GitHub WTF:

    GitHub channeling Atwood:

    tl;dr: CLOSED WONTFIX DOING_IT_WRONG

    Also, we can easily modify the space-time continuum!

    0_1478146976996_upload-ca5408c3-201e-491f-be5d-a5576737688a


  • Winner of the 2016 Presidential Election

    @Greybeard said in More GitHub WTF:

    GitHub channeling Atwood:

    tl;dr: CLOSED WONTFIX DOING_IT_WRONG

    "If you rewrite your commit history"

    WELL THERE'S YOUR PROBLEM


  • Grade A Premium Asshole

    @Greybeard said in More GitHub WTF:

    GitHub channeling Atwood:

    Eh.

    You can either show commits in tree order or in chronological order. Given that the timestamp of any commit can be altered, and/or that commits can be reordered within a tree while preserving their original timestamp, tree order is not always going to match chronological order.

    From a user perspective, either order is going to be wrong some of the time. (Though -in my experience- you almost always want tree order.) It's best to either pick an ordering and stick with it, or -failing that- add a button to switch between orderings.

    That's not Atwood levels of bad... not anywhere close. I'm would hesitate to call it bad.


  • Winner of the 2016 Presidential Election

    @bugmenot said in More GitHub WTF:

    @Greybeard said in More GitHub WTF:

    GitHub channeling Atwood:

    Eh.

    You can either show commits in tree order or in chronological order. Given that the timestamp of any commit can be altered, and/or that commits can be reordered within a tree while preserving their original timestamp, tree order is not always going to match chronological order.

    From a user perspective, either order is going to be wrong some of the time. (Though -in my experience- you almost always want tree order.) It's best to either pick an ordering and stick with it, or -failing that- add a button to switch between orderings.

    That's not Atwood levels of bad... not anywhere close. I'm would hesitate to call it bad.

    Indeed. And that link is specifically about history rewriting, which is known to everyone as "breaks EVERYTHING"

    So yea. Not a problem really.


  • :belt_onion:

    @bugmenot said in More GitHub WTF:

    From a user perspective, either order is going to be wrong some of the time.

    When would tree order ever be wrong? If you folllow their "never rewrite history" advice, tree order is also correct.

    The only advantage of the way there're doing it is to punish people who rebase.


  • Discourse touched me in a no-no place

    @Greybeard said in More GitHub WTF:

    punish people who rebase

    That sounds like a great plan!


  • Winner of the 2016 Presidential Election

    @Greybeard said in More GitHub WTF:

    people who rebase.

    after pushing.

    So people who push rebased history.

    Which you should never do

    Because it breaks everything


  • :belt_onion:

    @sloosecannon said in More GitHub WTF:

    Indeed. And that link is specifically about history rewriting, which is known to everyone as "breaks EVERYTHING"

    It also screws up a commit stream with cherry-picks, which the text completely ignores.

    And history rewriting does not break everything. It is useful for making a commit stream clearer before submitting it for first review. Rebasing is only problematic after someone else has added commits to a copy of the branch.


  • Winner of the 2016 Presidential Election

    @Greybeard said in More GitHub WTF:

    And history rewriting does not break everything.

    Correct, if it's only done locally.

    If you push it up, and someone pulls that version down though, they're in for a world of hurt when you force push your rewritten history.

    IOW, force pushing rewritten history is a big :middle_finger: to all the other people working on your project, and anyone/anything that might have pulled your now-rewritten history


  • Discourse touched me in a no-no place

    @sloosecannon said in More GitHub WTF:

    If you push it up, and someone pulls that version down though, they're in for a world of hurt when you force push your rewritten history.

    No, they just force-push their own history back over yours and you get the SVN experience once again!


  • Winner of the 2016 Presidential Election

    @dkf said in More GitHub WTF:

    @sloosecannon said in More GitHub WTF:

    If you push it up, and someone pulls that version down though, they're in for a world of hurt when you force push your rewritten history.

    No, they just force-push their own history back over yours and you get the SVN experience once again!

    And this is why history rewrites are disabled on all the repos I own.

    I don't care if you rebase locally - it makes the merges cleaner and stuff, so cool!

    But don't you dare to rewrite history after it's been pushed.


  • sockdevs

    @sloosecannon said in More GitHub WTF:

    @dkf said in More GitHub WTF:

    @sloosecannon said in More GitHub WTF:

    If you push it up, and someone pulls that version down though, they're in for a world of hurt when you force push your rewritten history.

    No, they just force-push their own history back over yours and you get the SVN experience once again!

    And this is why history rewrites are disabled on all the repos I own.

    I don't care if you rebase locally - it makes the merges cleaner and stuff, so cool!

    But don't you dare to rewrite history after it's been pushed.

    there are a couple of reasons to rewrite history..... but they are few and far between.

    like a repo split where a repo hosts two projects and they are to be split into two different repos where the history of the projects is detangled. that's a perfect situation for a rewrite. course the correct way to do it is to fork the repo twice, rewrite the history on the forks, then make the forks public, and mark the old repo as read only so everyone can migrate to the new repo.

    Anotehr reason would be to remove sensitive or over large files that should never have been committed in teh first place. In that case you may need to rewrite history, but you do it with EVERYONE ON BOARD WITH THE PLAN and you lock the repo down until you're done.

    out side of those two, and maybe a couple i havent thought of, there is no valid reason to rewrite public history, and honestly disabling rewrites is a good thing because it makes you have to take extra steps to do it if you do happen to be that one chance in a trillion, it absolutely has to happen..... because then you might actually do it right and not fuck your entire team over.....

    /me speaks from experience

    /me may have done that in early sockbot trying to correct author information

    /me may have royally screwed things up so that after all the dust settled all the commits from before the attempt were duplicated because she didn't fully understand what rewriting history entailed yet.


  • mod

    @accalia said in More GitHub WTF:

    may have done that in early sockbot trying to correct author information

    So that's what (may have) happened! ;)


  • sockdevs

    @Yamikuronue said in More GitHub WTF:

    @accalia said in More GitHub WTF:

    may have done that in early sockbot trying to correct author information

    So that's what (may have) happened! ;)

    i can neither confirm nor deny that statement.


  • Grade A Premium Asshole

    @Greybeard said in More GitHub WTF:

    When would tree order ever be wrong?

    This is a bit contrived, but if you are -say- using Git as a document repository and change tracker and are strictly interested in the chronological order of commits, rather than the tree order? Granted, if this is the case, you should probably disable branching and rebasing so that tree order and chronological order always match.



  • @bugmenot said in More GitHub WTF:

    This is a bit contrived, but if you are -say- using Git as a document repository and change tracker and are strictly interested in the chronological order of commits, rather than the tree order?

    What if you're using it as a backup system? Asking for an alt.


  • :belt_onion:

    @sloosecannon said in More GitHub WTF:

    I don't care if you rebase locally - it makes the merges cleaner and stuff, so cool!

    Then push, create a pull request, and GitHub will display the commits in the wrong order. CLOSED WONTFIX DOING_IT_WRONG.


  • Winner of the 2016 Presidential Election

    @Greybeard said in More GitHub WTF:

    @sloosecannon said in More GitHub WTF:

    I don't care if you rebase locally - it makes the merges cleaner and stuff, so cool!

    Then push, create a pull request, and GitHub will display the commits in the wrong order. CLOSED WONTFIX DOING_IT_WRONG.

    I don't believe so, because I don't actually believe that's possible. If history is rewritten, there's no record left, so how could it be out of order?


  • :belt_onion:

    @sloosecannon GitHub sorts commits by authorship date



  • @accalia said in More GitHub WTF:

    @sloosecannon said in More GitHub WTF:

    @dkf said in More GitHub WTF:

    @sloosecannon said in More GitHub WTF:

    If you push it up, and someone pulls that version down though, they're in for a world of hurt when you force push your rewritten history.

    No, they just force-push their own history back over yours and you get the SVN experience once again!

    And this is why history rewrites are disabled on all the repos I own.

    I don't care if you rebase locally - it makes the merges cleaner and stuff, so cool!

    But don't you dare to rewrite history after it's been pushed.

    there are a couple of reasons to rewrite history..... but they are few and far between.

    like a repo split where a repo hosts two projects and they are to be split into two different repos where the history of the projects is detangled. that's a perfect situation for a rewrite. course the correct way to do it is to fork the repo twice, rewrite the history on the forks, then make the forks public, and mark the old repo as read only so everyone can migrate to the new repo.

    Anotehr reason would be to remove sensitive or over large files that should never have been committed in teh first place. In that case you may need to rewrite history, but you do it with EVERYONE ON BOARD WITH THE PLAN and you lock the repo down until you're done.

    out side of those two, and maybe a couple i havent thought of, there is no valid reason to rewrite public history, and honestly disabling rewrites is a good thing because it makes you have to take extra steps to do it if you do happen to be that one chance in a trillion, it absolutely has to happen..... because then you might actually do it right and not fuck your entire team over.....

    You forgot a third reason:


  • sockdevs

    @The_Quiet_One said in More GitHub WTF:

    @accalia said in More GitHub WTF:

    @sloosecannon said in More GitHub WTF:

    @dkf said in More GitHub WTF:

    @sloosecannon said in More GitHub WTF:

    If you push it up, and someone pulls that version down though, they're in for a world of hurt when you force push your rewritten history.

    No, they just force-push their own history back over yours and you get the SVN experience once again!

    And this is why history rewrites are disabled on all the repos I own.

    I don't care if you rebase locally - it makes the merges cleaner and stuff, so cool!

    But don't you dare to rewrite history after it's been pushed.

    there are a couple of reasons to rewrite history..... but they are few and far between.

    like a repo split where a repo hosts two projects and they are to be split into two different repos where the history of the projects is detangled. that's a perfect situation for a rewrite. course the correct way to do it is to fork the repo twice, rewrite the history on the forks, then make the forks public, and mark the old repo as read only so everyone can migrate to the new repo.

    Anotehr reason would be to remove sensitive or over large files that should never have been committed in teh first place. In that case you may need to rewrite history, but you do it with EVERYONE ON BOARD WITH THE PLAN and you lock the repo down until you're done.

    out side of those two, and maybe a couple i havent thought of, there is no valid reason to rewrite public history, and honestly disabling rewrites is a good thing because it makes you have to take extra steps to do it if you do happen to be that one chance in a trillion, it absolutely has to happen..... because then you might actually do it right and not fuck your entire team over.....

    You forgot a third reason:

    nope. that's not a reason to rewrite history. that's a reason to update your resume.


  • mod

    @accalia said in More GitHub WTF:

    that's a reason to update your resume.

    What if I rewrite history on my resume? Asking for a friend



  • @boomzilla said in More GitHub WTF:

    Asking for an alt.

    Quit putting words in my mouth! ADMIN ABUSE!


  • sockdevs

    @Yamikuronue said in More GitHub WTF:

    @accalia said in More GitHub WTF:

    that's a reason to update your resume.

    What if I rewrite history on my resume? Asking for a friend

    go for it, just don't do it in your git repository. :-P


  • Discourse touched me in a no-no place

    @Greybeard said in More GitHub WTF:

    GitHub channeling Atwood:

    tl;dr: CLOSED WONTFIX DOING_IT_WRONG

    Needs git-investigate-commit(1). (Yes - I've posted this before.)


  • Winner of the 2016 Presidential Election

    Awww. I've been doing it wrong?

    I mean, I'm a big fan of git give --hard HEAD

    Wait... that's not how that goes, is it?


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.