|
JawnV6 posted:the worst excel spreadsheet i ever used would talk over a FTDI cable to a development board and actuate it  
|
#
?
Feb 16, 2019 02:56
|
|
|
|
| # ? Apr 24, 2024 03:14 |
|
|
JawnV6 posted:the worst excel spreadsheet i ever used would talk over a FTDI cable to a development board and actuate it
|
|
#
?
Feb 16, 2019 02:56
|
|
|
mystes posted:Using VBA? Why would someone do this in Excel? "everyone has excel man"
|
|
#
?
Feb 16, 2019 02:57
|
|
|
ole was a mistake
|
|
#
?
Feb 16, 2019 03:05
|
|
|
if excel was designed to do the things that everybody uses it for then nobody would use it
|
|
#
?
Feb 16, 2019 03:13
|
|
|
excelerationists believe that by proliferating the use of excel as accounting software we can destroy capitalism from the inside
|
|
#
?
Feb 16, 2019 03:15
|
|
|
DONT THREAD ON ME posted:excelerationists believe that by proliferating the use of excel as accounting software we can destroy capitalism from the inside
|
|
#
?
Feb 16, 2019 03:23
|
|
|
DONT THREAD ON ME posted:your git usage depends very much upon: i used git for years before squash or rebase seemed like poo poo i might ever need. merge was plenty adequate even now, i occasionally run into situations where merge is preferable because we don't want to lose the branch's history
|
|
#
?
Feb 16, 2019 04:24
|
|
|
add, commit, and merge are all you need unless you're one of those people who cares about git history being pleasant in any way
|
|
#
?
Feb 16, 2019 05:23
|
|
|
DaTroof posted:i used git for years before squash or rebase seemed like poo poo i might ever need. merge was plenty adequate whereas i almost never use or used merge, relying on rebase almost exclusively (either rebasing my branch onto master or whatever as-is or rewriting my branch's history into more meaningful commits first). i dunno why, i just got into the habit of frequently rebasing my feature branches on the latest prod branch. probably because i got tired of fixing a pile of merge conflicts when it came time to actually deploy poo poo.
|
|
#
?
Feb 16, 2019 05:24
|
|
|
Corla Plankun posted:add, commit, and merge are all you need unless you're one of those people who cares about git history being pleasant in any way its me, i rebase and force push a lot (nobody uses my code anyway)
|
|
#
?
Feb 16, 2019 05:26
|
|
|
I pretty much use git like svn until it causes a problem and then I aimlessly Google until I find a way to fix it. so far it has been a better use of my time than actually learning git in any kind of depth
|
|
#
?
Feb 16, 2019 05:27
|
|
|
i think that the worst and nastiest git fails i've ever seen have been people who thought they could power through it on their own for half a day so knowing to google git stuff makes you a git expert of considerable distinction
|
|
#
?
Feb 16, 2019 05:49
|
|
|
also i use fork.app because i can never remember the commands for interactive rebasing https://git-fork.com Carthag Tuek fucked around with this message at 06:15 on Feb 16, 2019 |
|
#
?
Feb 16, 2019 06:06
|
|
|
https://twitter.com/PinoBatch/status/701215215975866372
|
|
#
?
Feb 16, 2019 06:21
|
|
|
i have this really lazy strategy of keeping my git history nice: 1. i start working on a new feature and do `git checkout -b feature`, and then `git checkout -b feature-wip` 2. i do a bunch of lazy commits against the wip branch 3. when i reach a point where i have something worth a single commit, i do `git reset feature`. this unstages all changes since the last merge. then i add everything back, craft my commit, and then merge it into the feature branch. 4. then keep going until the feature is ready. it's really easy and takes no thought and i've never hosed it up. i used to use magit and that was pretty cool but this is easier. DONT THREAD ON ME fucked around with this message at 06:36 on Feb 16, 2019 |
|
#
?
Feb 16, 2019 06:31
|
|
|
terrible programmer status: it took me 3 days to figure out that I had the N64 RDP in the wrong pipeline mode which was causing my triangles to be broken now they fill, they just have garbage colors which is an improvement
|
|
#
?
Feb 16, 2019 07:19
|
|
|
Corla Plankun posted:is performance testing in jenkins cicd a bad idea? it feels like it might be like, you wanna run a load test on your build machines? If you have the extra capacity it's not a terrible idea, but it's not a great one. using a jenkins pipeline to spin up a load test on other hardware and collect results afterwards is something I've done before and it's p nice. click button, see if you're lovely new code will fall over under load or not
|
|
#
?
Feb 16, 2019 07:32
|
|
|
Corla Plankun posted:add, commit, and merge are all you need unless you're one of those people who cares about git history being pleasant in any way If you don't care about the history being pleasant in any way then what you need is a backup agent, not a source control system
|
|
#
?
Feb 16, 2019 08:25
|
|
|
DONT THREAD ON ME posted:i have this really lazy strategy of keeping my git history nice: FWIW I think the more idiomatic way to accomplish the same thing is to squash all of the WiP commits with git rebase -i
|
|
#
?
Feb 16, 2019 09:24
|
|
|
VikingofRock posted:FWIW I think the more idiomatic way to accomplish the same thing is to squash all of the WiP commits with git rebase -i yeah i just find the rebase interface really annoying
|
|
#
?
Feb 16, 2019 09:37
|
|
|
pokeyman posted:I get the impression there are many git features where half the users say “I can’t believe anyone gets anything done without this feature” and the other half say “I never use that feature and I do ok” i walked them through it and in the process got tripped up by the new commit hook that requires an issue ref (added by me) because I was replaying non-compliant commits from like 2 weeks ago sooo i had to do a mixed reset then edit the messages, re commit and push and was like "there you go easy!" and just got dead silence lmao Oneiros posted:
this is exactly why I did it. I have a dev branch I've been fiddling with for like 5 months now and have rebased multiple times to keep it up to date vs master. when I finally do merge it it's gonna be a loving pain though. Powerful Two-Hander fucked around with this message at 10:47 on Feb 16, 2019 |
|
#
?
Feb 16, 2019 10:42
|
|
|
Powerful Two-Hander posted:i walked them through it and in the process got tripped up by the new commit hook that requires an issue ref (added by me) because I was replaying non-compliant commits from like 2 weeks ago owned
|
|
#
?
Feb 16, 2019 10:48
|
|
|
DaTroof posted:i've been 99.9% remote for a few years and have never run into a case where we needed anything like a whiteboard in a teleconference. (i can see how it could be useful though, so maybe we're an exception) Arcsech posted:I have not needed one, but a bunch of people on our UI team just has a whiteboard in their work space such that it’s easy to get a good view of in the camera. Thinking back to it, at job-2 we worked pretty well with just Skype and some screen sharing app sometimes, but that job also wasn't really innovative in any way -- just a lot of data pipeline plumbing. The current job OTOH is kinda math and research heavy, which is where I think whiteboarding shines. 
|
|
#
?
Feb 16, 2019 11:24
|
|
|
Sapozhnik posted:If you don't care about the history being pleasant in any way then what you need is a backup agent, not a source control system
|
|
#
?
Feb 16, 2019 11:25
|
|
|
https://twitter.com/kennwhite/status/1096542142900682752 hmm, hmm
|
|
#
?
Feb 16, 2019 12:43
|
|
|
DONT THREAD ON ME posted:i have this really lazy strategy of keeping my git history nice: this is a good strat but i feel obliged to tell you that you can do this with one branch (you can git reset to any commit in the git log, no branch names needed)
|
|
#
?
Feb 16, 2019 14:58
|
|
|
I usually just amend my most recent commit continually until I'm done with the feature
|
|
#
?
Feb 16, 2019 15:08
|
|
|
DaTroof posted:i used git for years before squash or rebase seemed like poo poo i might ever need. merge was plenty adequate I use interactive rebase a lot. I fork the project repository and force-push feature branches there until they're ready for prime time. I wish there was an easy way to split a commit into multiple commits without a ton of amends and squashes, though I've never learned a single command line option for git. SourceTree isn't great but it does almost everything I need, the only times I use the command line is for obscure things like recovering commits I unlinked by mistake (it turns out it really helps to think of a git repo as a graph - if you use a gui client and learn the weird names that were given to git concepts) Corla Plankun posted:add, commit, and merge are all you need unless you're one of those people who cares about git history being pleasant in any way commits are documentation, and writing documentation is half of your job as a software engineer. a good commit history is vital to continuous integration, regression testing and bisection, all tools as important to making software as editors and compilers
|
|
#
?
Feb 16, 2019 15:33
|
|
|
I find it helps to think of git as like a monad, but on the blockchain
|
|
#
?
Feb 16, 2019 15:37
|
|
|
Krankenstyle posted:I usually just amend my most recent commit continually until I'm done with the feature I've been bitten by enough regressions hidden in giganto-commits that I split my commits up as much as possible. it's a little tedious because git doesn't make it easy, and also because I'm a pedant and I make sure every single commit at least compiles right (without a test suite, I can't make sure they don't introduce regressions, but by keeping commits small and buildable I'm making bisection possible), but I take it as a chance to re-read the code and often re-write it in a better way, or catch bugs. if I had tests I would feel a little more confident and would do much less grunt work, but I don't, and until I write some, I feel a responsibility to write code a little slower in exchange for more rigour
|
|
#
?
Feb 16, 2019 15:44
|
|
|
Soricidus posted:I find it helps to think of git as like a monad, but on the blockchain  git commits are linked together, each commit has a pointer to its predecessors. they form an immutable data structure, so editing a commit necessarily involves recreating all successors - this is the meaning of "rebase", and the reason why a rebase changes the hashes of all commits downbranch. what are tags and branches? they're global variables, GC roots, nothing more and nothing less, and now you know how to recover a lost commit, or how not to lose a commit in the first place (just tag it) if you're a programmer in literally any language, you already have a good mental model of git
|
|
#
?
Feb 16, 2019 15:49
|
|
|
hackbunny posted:I use interactive rebase a lot. I fork the project repository and force-push feature branches there until they're ready for prime time. I wish there was an easy way to split a commit into multiple commits without a ton of amends and squashes, though documentation is obsolete almost the second it is written and its a waste of time to try to fight technical debt with words nobody will ever read
|
|
#
?
Feb 16, 2019 16:30
|
|
|
Corla Plankun posted:this is a good strat but i feel obliged to tell you that you can do this with one branch (you can git reset to any commit in the git log, no branch names needed) i like the idea of having a -wip branch so i don't mess anything up if i've pushed that feature branch to a remote repo this is kind of what I was doing in a less structured way so I'll adopt it git philosophers: what should you do when you're working on feature A, but then create breaking change B and merge it into master, and don't want to continue developing A from before change B? (also some of the same files are modified so rebasing isn't simple) why two separate changes affect most of the same files, well that's an old mistake i'm paying for now 
|
|
#
?
Feb 16, 2019 16:41
|
|
|
hackbunny posted:what are tags and branches? a miserable pile of commits, but enough talk... git push -f
|
|
#
?
Feb 16, 2019 16:42
|
|
|
hackbunny posted:I've been bitten by enough regressions hidden in giganto-commits that I split my commits up as much as possible. it's a little tedious because git doesn't make it easy, and also because I'm a pedant and I make sure every single commit at least compiles right (without a test suite, I can't make sure they don't introduce regressions, but by keeping commits small and buildable I'm making bisection possible), but I take it as a chance to re-read the code and often re-write it in a better way, or catch bugs. if I had tests I would feel a little more confident and would do much less grunt work, but I don't, and until I write some, I feel a responsibility to write code a little slower in exchange for more rigour actually yea i try to split commits as well. i mostly do the amendment dance when i have the mechanics working & im polishing indentation and such
|
|
#
?
Feb 16, 2019 16:45
|
|
|
long-lived branches suck regardless of what system you're using, hopefully you aren't in a situation where you have weeks of divergent work that you need to reconcile. but really just squash and rebase like you would do before actually pushing stuff into master. leave a tag around pointing to the pre-squash head if you think you'll need to look at the wip history.
|
|
#
?
Feb 16, 2019 16:48
|
|
|
fisting by many posted:git philosophers: what should you do when you're working on feature A, but then create breaking change B and merge it into master, and don't want to continue developing A from before change B? (also some of the same files are modified so rebasing isn't simple) the trick with your situation is that today’s rebase conflicts are tomorrow's merge conflicts. you can decide when you want to deal with them, but you’ll have to deal with them sometime. rebase and resolve conflicts. or new branch from master and cherry-pick the commits you still care about (maybe breaking change B obviates some of your A work)
|
|
#
?
Feb 16, 2019 16:51
|
|
|
pokeyman posted:the trick with your situation is that today’s rebase conflicts are tomorrow's merge conflicts. you can decide when you want to deal with them, but you’ll have to deal with them sometime. hm, that's true I did end up rebasing, glad I didn't totally waste my time
|
|
#
?
Feb 16, 2019 16:58
|
|
|
|
| # ? Apr 24, 2024 03:14 |
|
|
fisting by many posted:git philosophers: what should you do when you're working on feature A, but then create breaking change B and merge it into master, and don't want to continue developing A from before change B? (also some of the same files are modified so rebasing isn't simple) E: As pokeyman said.
|
|
#
?
Feb 16, 2019 17:04
|
|
