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?
-
Dodgy reverse Turing test
-
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?
-
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.
-
Personally, I think they should be the first against the wall when the revolution comes.
-
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
-
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.
-
-
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?
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.
Did they say why your account got flagged?
Of course not.
-
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?
-
why are you people surprised that it's awful?
Because the website itself is not open source.
-
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.
-
This banhammer made with in San Francisco
-
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
-
GitHub channeling Atwood:
tl;dr: CLOSED WONTFIX DOING_IT_WRONG
-
@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!
-
@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
-
@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.
-
@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.
-
@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.
-
-
@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
-
@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.
-
@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 to all the other people working on your project, and anyone/anything that might have pulled your now-rewritten history
-
@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!
-
@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.
-
@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.
-
@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! ;)
-
@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.
-
@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.
-
@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.
-
@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?
-
@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:
-
@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.
-
@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
-
-
@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
-
@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.)
-
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?
-
@Onyx said in More GitHub WTF:
that's not how that goes, is it?
It's superceded by the deepthroat flag
-
@Onyx said in More GitHub WTF:
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?
>git give git: 'give' is not a git command. See 'git --help'. Did you mean this? archive
Hmm. Not sure I want to archive that...