|
Vanadium posted:On github we keep doing that thing where we send a pull request, someone reviews+comments on the commits and suggests changes, and then we amend our commits and push -f them to the pull-requested branch until the pull request gets accepted. I don't think that's that weird a workflow? Why would you not just keep adding commits? If you think any commits are redundant (merge commits) you can just squash them together.
|
# ? Nov 12, 2013 10:50 |
|
|
# ? May 17, 2024 21:00 |
|
Superschaf posted:Why would you not just keep adding commits? If you think any commits are redundant (merge commits) you can just squash them together. It's a really dumb default of the push command to push all branches and they are/have changed it but when you're used to having set a config variable that overrides this and end up in a different environment it can be easy to forget.
|
# ? Nov 12, 2013 12:00 |
|
EAT THE EGGS RICOLA posted:Someone blew up all the Jenkins plugins repositories because they had forced push permissions without realizing it. I like the fact that he calls it an "involuntary" push. It evokes images of other antiperistaltic behavior.
|
# ? Nov 12, 2013 12:21 |
|
Sagacity posted:antiperistaltic What?
|
# ? Nov 12, 2013 15:46 |
|
teamdest posted:What? The reverse of a peristaltic process. Peristalsis is the process of moving something through a hollow tube by compressing the sides of the tube. Swallowing is a good example - the digestive system uses peristalsis to move food from one end to the other. In other words,
|
# ? Nov 12, 2013 16:00 |
|
Thanks, csammis!
|
# ? Nov 12, 2013 16:06 |
|
teamdest posted:What? If only there was another way to find the definition of a word.
|
# ? Nov 12, 2013 16:41 |
|
It was more disbelief that the word came up, well, anywhere, but in the context of a bad git push of all things.
|
# ? Nov 12, 2013 16:47 |
|
Vanadium posted:On github we keep doing that thing where we send a pull request, someone reviews+comments on the commits and suggests changes, and then we amend our commits and push -f them to the pull-requested branch until the pull request gets accepted. I don't think that's that weird a workflow? I am not against force pushing a PR branch but that requires you specify a 'repo+refspec' (e.g. git push --force origin +prbranch) to push to the intended branch. `git push --force` (as in literally just that command) is lazy and irresponsible, especially when he apparently had no clue which repos he was an owner of, had repos that were months behind, and didn't understand that GitHub lacks some 'no force push' feature. My point isn't that he actually used git push --force as much as his apology was half 'sorry', half blaming other factors when it could have been averted by being a bit more diligent with using a dangerous git command.
|
# ? Nov 12, 2013 18:54 |
|
I still don't understand what he even intended to do when he push --force'd in multiple repositories at once.
|
# ? Nov 12, 2013 18:57 |
|
Right now the best source of documentation for the project I'm working on right now is the .edmx file for EF that's still part of the project, even though we stopped using EF. That and actually poking into the database and webservices. We're copying a desktop app that called web services as we do a web app, and a lot of our documentation is screenshots put into a powerpoint with big red circles and boxes around things and "copy that." I wonder if we should have a project horror thread.
|
# ? Nov 12, 2013 19:12 |
|
I think the real horror is that apparently Git doesn't implement protection against any malicious attempts at wiping literally everything on it.
|
# ? Nov 12, 2013 19:38 |
|
Pollyanna posted:I think the real horror is that apparently Git doesn't implement protection against any malicious attempts at wiping literally everything on it. This is a preposterous canard.
|
# ? Nov 12, 2013 19:41 |
|
What do you mean? I could gain access to the mountains of open repos on there, git add . in an empty folder and do git push -f everything and tada the whole place is dead.
|
# ? Nov 12, 2013 19:50 |
|
It's still all in the ref log.
|
# ? Nov 12, 2013 19:55 |
|
The actual horror in your argument would be giving anonymous write/push access to whoever wants it and has nothing to do with git.
|
# ? Nov 12, 2013 19:55 |
|
If you chmod all your files 777, it is trivially easy for some other user to delete all your poo poo. This isn't a unix security vulnerability.
|
# ? Nov 12, 2013 19:56 |
|
rm is a coding horror because it allows me to rm -rf /
|
# ? Nov 12, 2013 20:19 |
|
Pollyanna posted:I think the real horror is that apparently Git doesn't implement protection against any malicious attempts at wiping literally everything on it. More accurately, Github doesn't, git has hooks that allow you to prevent a force push and there are git servers that let you disable it. Here is where I shamelessly plug gitano, which I've got commits in, and its primary developer is going to do a talk about it at some conferences in the next couple of weeks.
|
# ? Nov 12, 2013 20:22 |
|
astr0man posted:rm is a coding horror because it allows me to rm -rf / GNU rm doesn't unless you give --no-preserve-root. Not that that's the only dangerous case.
|
# ? Nov 12, 2013 20:23 |
|
Pollyanna posted:What do you mean? I could gain access to the mountains of open repos on there, git add . in an empty folder and do git push -f everything and tada the whole place is dead. github != git
|
# ? Nov 12, 2013 20:24 |
|
Thermopyle posted:github != git And github still doesn't just give you write access to everyone's repos.
|
# ? Nov 12, 2013 21:43 |
|
astr0man posted:I still don't understand what he even intended to do when he push --force'd in multiple repositories at once.
|
# ? Nov 12, 2013 21:46 |
|
Edison was a dick posted:Here is where I shamelessly plug gitano, which I've got commits in, and its primary developer is going to do a talk about it at some conferences in the next couple of weeks.
|
# ? Nov 12, 2013 22:05 |
|
Pollyanna posted:What do you mean? I could gain access to the mountains of open repos on there, git add . in an empty folder and do git push -f everything and tada the whole place is dead.
|
# ? Nov 12, 2013 22:52 |
|
Mogomra's Project Manager posted:Hey, Mogomra, I told our biggest client that you would fix all the retarded garbage data in this retarded table by 7am tomorrow morning. So fix all the garbage records by 7am tomorrow morning! code:
We use the table to store eBay listing fees on client's eBay listings (along with a poo poo ton of other different kinds of fees). We never checked anywhere to make sure we're not saving the same fee twice until I was assigned this ticket. The location_id is supposed to relate to the client's store that is being charged the fee. You'd think we'd check to make sure we're saving the fee to the correct store, but nope! We've also been doing this since 2009 at the latest. There are now over 15k records just for this client alone that either are a duplicate of a fee they were charged, or are saved to the wrong store, or both. Also, it's impossible to tell whether or not the location_id is correct unless you do two joins on other incredibly large tables. All of the data in this table is business critical unless of course they're duplicate records. Edit: Ah, I just found out he promised 7pm tonight instead of 7am tomorrow. Mogomra fucked around with this message at 06:44 on Nov 13, 2013 |
# ? Nov 13, 2013 02:00 |
|
That sounds like a job for Open Refine. Or it would if it wasn't completely ridiculous already.
|
# ? Nov 13, 2013 02:32 |
|
What is the point of NOT NULL DEFAULT = ''? One of my colleagues insists on doing this because "then you don't have to check for NULL when making reports", but UUUUGGGHHH
|
# ? Nov 13, 2013 10:16 |
|
Pollyanna posted:What do you mean? I could gain access to the mountains of open repos on there, git add . in an empty folder and do git push -f everything and tada the whole place is dead. Too bad literally everyone who ever worked on the repo you killed has all the commits and content in their copy of the repo or that might be a problem.
|
# ? Nov 13, 2013 12:46 |
|
zokie posted:What is the point of NOT NULL DEFAULT = ''? One of my colleagues insists on doing this because "then you don't have to check for NULL when making reports", but UUUUGGGHHH There are DB experts who believe NULL values should never exist. (I'm pretty sure they don't want you to just replace them with empty strings, though.)
|
# ? Nov 13, 2013 13:28 |
|
Essentially, absence of a field should be indicated by just not having a row for it at all. NULLs are only useful when you've denormalized your data such that you can't do that any more. Disallowing nulls but having a non-null "empty" value in their place seems a bit cargo-culty to me. I guess it could have some value if you legitimately want the empty string to be printed out when there's no data, but that seems like bad separation of concerns with how you're polluting the data model with application logic.
|
# ? Nov 13, 2013 13:52 |
|
Jabor posted:Essentially, absence of a field should be indicated by just not having a row for it at all. NULLs are only useful when you've denormalized your data such that you can't do that any more. Over 9000 NF? And how the hell do you accomplish that?
|
# ? Nov 13, 2013 14:21 |
|
Jabor posted:Disallowing nulls but having a non-null "empty" value in their place seems a bit cargo-culty to me. I guess it could have some value if you legitimately want the empty string to be printed out when there's no data, but that seems like bad separation of concerns with how you're polluting the data model with application logic. In MySQL it's typically done so the "empty" value is always an empty string instead of sometimes an empty string and sometimes null.
|
# ? Nov 13, 2013 14:37 |
|
What's the problem with that approach, provided that you don't care about the difference between no value and an empty string? I mean, if you do then it's stupid, otherwise it can eliminate the need for a whole load of pointless null checks in your code. e: vvv sorry, should have quoted, I was asking zokie why he had a problem with the NOT NULL DEFAULT approach ..btt fucked around with this message at 17:30 on Nov 13, 2013 |
# ? Nov 13, 2013 14:57 |
|
..btt posted:What's the problem with that approach, provided that you don't care about the difference between no value and an empty string? I mean, if you do then it's stupid, otherwise it can eliminate the need for a while load of pointless null checks in your code. I don't have a problem with it. Some might argue that fields with potentially empty values belong in a related table, but it's not always worth the hassle. I'd rather not have to do a bunch of left joins just because a few customers might not have a middle name or whatever.
|
# ? Nov 13, 2013 16:34 |
|
code:
|
# ? Nov 13, 2013 18:30 |
|
All this is moot on ~*Oracle*~ because '' IS NULL there...
|
# ? Nov 13, 2013 18:32 |
|
Every time I read that there's a part of me that believes it's not really true, nobody could design a database that isn't null aware and have, of all people, financial institutions adopt it as their standard RDBMS. It's some in-joke among Oracle-types... right guys?
|
# ? Nov 13, 2013 19:20 |
|
It's not that Oracle isn't aware of nulls - it's that the empty string is special case transformed into nulls for you. It actually used to be possible to accidentally get around this, and forcefully load in empty strings (using their bulk loader utility). These values would not count as nulls but couldn't be queried out unless you did things weird, like specifying length of 0 (since where foo = '' won't work, as '' is immediately transformed into NULL).
|
# ? Nov 13, 2013 19:57 |
|
|
# ? May 17, 2024 21:00 |
|
code:
|
# ? Nov 13, 2013 20:02 |