Coding Blocks - Source Control Etiquette

Episode Date: October 12, 2013

This episode is all about source control etiquette. It’s a bit different from the last two podcasts we released and we’d love to hear how you liked it! Subscribe on iTunes or Stitcher and make sure to send us your feedback! Show Notes Duration ~56 Discussion on Source Control Etiquette 00:00 – 25:09 A tale […]

you are listening to coding blocks episode three subscribe to us on itunes stitcher and more using your favorite podcasting app and be sure to leave us a review on itunes or stitcher or wherever you happen to have found us and also don't forget to check us out at codingblocks.net where you can find show notes examples discussion and much more your feedback, question, and rants to comments at codingblocks.net. And with that, welcome to Coding Blocks. I'm Michael Outlaw. I'm Alan Underwood. And I'm Joe Zack. And we've gathered around the proverbial water cooler to discuss source control today. That's right. In today's episode, we're going to step away from the keyboard. And take our propeller hats off and stay out of the weeds if possible and without further ado i want to start off with a story all right so there was

a situation where uh another person wanted to commit some stuff that they were working on and they were convinced that their stuff was fine, it was all good, but there was a compile error. It couldn't compile. And this person was adamant on committing the code and pushing it into the main repository because it was not their problem and whatever. And I was taking the stance that no, no, no, no. Even if it wasn't any fault of yours, you've now found it. It's your responsibility.

You should do the honorable thing and correct it. You shouldn't knowingly commit it if you know that there's a problem there. And we went back and forth on it until finally, lo and behold, we found out, oh, it did turn out to be a problem that was newly introduced and got fixed beforehand.

So reluctantly, the compile error was fixed prior to the commit was being pushed into the main repository. But it brought me into this greater concept here, whereas the moral of the story being you should not knowingly commit broken code so let me get this straight so we've got maybe the build wasn't working when uh they got started but how you know how do you test your code if you can't compile it yes and that is a very valid valid question that you know, that's a whole other ball. Right. Yeah. Beside the point. Testing, testing, I feel like should be a different conversation here.

We're talking about source control. I don't know if you heard the intro. All right. But yeah, I mean, and, and just to be clear on that though, there's a couple of things that could go wrong, right? He commits that code. It goes into the master repository. Now everybody who checks out is going? He commits that code. It goes into the master repository. Now, everybody who checks out

is going to get that broken code. But even worse than that, people that have continuous integration things that are running behind the scenes, it would have gotten that code out of there. It would have built it. It would have stuck it out on a dev server and everybody would have been down.

Like there's so many things that can go wrong. Yeah, so there's actually two things there. One is just my personal thing is I don't know. I don't like to knowingly commit code even locally that I know is broken, right? That, that just seems like a bad workflow to me because eventually that commit, you know, might make it up. And then if anybody wanted to check that commit out as a point in time of, Hey, let me see what was happening from here. It's broken and it won't compile.

And they might not know, uh, is it something that they did or is it the state of the code at that time? But then there's also the concept of especially don't push that broken commit up to the main repository. Right. That's, that's like all kinds of negative.

No. Right. And I mean, to, to go back on what you said about uh actually having a bunch of developers get that and wondering if they did it you're talking about hours and hours of lost time right and and there's nothing more frustrating than chasing your tail on something thinking that you screwed something up only to find out well yeah

because i picture the story could happen like you know it it's a year later yeah or or you know some some time some serious time has gone by and you're like well we used to have this concept let me go back and check it oh here's the commit i think this was around the time i remember that we were doing it let me just check out this particular id and oh it doesn't build what did i do wrong right you know what i gotta admit i do this all the time especially when i'm working on my own projects like i cannot go to bed until i'm committed and sometimes it is the my project is tore up and uh i just kind of you know i put in a comment that's a really bad comment something like almost working and uh now see this is where i think in that scenario that would be

uh where you would do something like a stash or a shelf uh command and for me personally uh no no i i take a different approach like we got the two ocd guys here that have to commit stuff i leave that on my system and i don't commit it until i'm done the next day well okay but okay but let me give you a scenario where that will not work though right let's say that i'm working on something it's incomplete regardless of whether or not that the the unit of work is compiling or not it's just in some kind of an incomplete state right and i'm not ready to commit it and then lo and behold somebody walks up and they're like oh my god we got this big sev one problem well i need you to look at it right now i have to switch okay a branch right right i'm not ready to commit what i've got and but i

don't want to lose that either so i want to just save that so so like if you're in git you know you could stash it if you're in mercurial you could shelve it. But my point is, as my personal workflow, I don't like to knowingly commit something if I know that it's broken. No, correct. But those are two different scenarios, right? He's talking about he's up working on his own project late at night, and then he's like, I have to commit this because I have to because I won't sleep well at night until I do it. Well, did I misunderstand the scenario you were describing? You were describing it was broken though, right? Oh, yeah.

Yeah, it's broken, but he doesn't have to commit it. He's not working on anything else. This is his own personal project. He just literally cannot sleep well at night unless he's done something to save this into his repository. Well, I got another situation too. So this is the same kind of thing, but I'm upstairs typing away. I'm getting pretty close. I can feel it, but it's not compiling.

It's certainly not working. And then the hour hits and I know the voice is on. Right? Now, I got to watch the voice of my wife. But I don't want to stop working. So I save, commit, push, and then run downstairs to my want to stop working. So I save, commit, push, and then run downstairs to my laptop to keep working

while checking out my man's silo. You checking out the extra Christina. Come on, let's be honest. Okay, so it sounds like you're suggesting you use your repository, at least for your personal use, as a distributed file system. That's exactly what it is. Yeah, but although a lot of my stuff is actually in Dropbox as well,

so I really don't have much of an excuse. It's just a bad habit I've gotten into with my personal stuff. I'm not as bad about it on work, but, man, if you look at ColorMind, you're going to see a lot of almost workings in there. I know it's bad, but it feels so right. So maybe that's fine right now while you're the sole developer on it, but if it ever got to where you had multiple people

working on the thing, obviously that would be a bad idea, right? Because now you're going to have people pulling down code that straight up doesn't work. Again, going back to the example that I gave, even if you are the only developer on there and you have commits in there that are broken, and let's say that Joe a month later wants to go back to something that's horrible

and from the commit maybe the commit uh message and description wasn't clear enough that hey this one's broken it might not be obvious from the get-go if you were to go back to that specific commit that oh yeah this is not compiling because there's something there well that's why i like i like the workflow where like you shouldn't knowingly commit something if if you know it's broken don't commit it stash it so that you can come back to it later but i say you don't even stash i say you don't even stash unless you have the use case come up exactly like what you said to where you now need to switch branches because you're working on a different problem, you don't even stash.

You have it on your local file system. Well, but I mean, in both of our scenarios, though, you needed to get away from it, though. I mean, the only difference in the stash versus his push scenario is that on the second computer, you can't get to it in the stash scenario. And that's what I'm saying.

There's no reason to even stash it unless you need to switch branches, leave the code on your computer. There's no reason to do anything with it until you come back to it and finish it or have to switch to another branch. Another computer. Yeah, that's where his push comes in. And I was only suggesting the stash if you needed to save that state for some reason. Okay, okay. you needed to save that state for some reason okay okay and and the example was you know if you had to go fix a 7-1 but you know um yeah i think you just need to come with a better fossil i know i'm doing it wrong man it's so convenient and to me it's not saved until it's committed

and usually even pushed i just can't i can't do it well you know what's interesting about that i at one of my previous gigs we actually had a decree and this was partially due to the fact that we were using an old version of visual source safe which if anybody is familiar with it concurrency was just it was basically it was it was the library model it was how i referred horrible yeah you couldn't take i checked out the book nobody else could touch it exactly so there was no concurrency so literally there was a decree that every day at the end of the day, you checked in your code, regardless of what state it was in. So you literally check. Don't even wait that late.

Just check it in every five minutes. Check it back in when you're done with that file. But, I mean, that literally turned into a, you know, people were pushing in broken code all the time simply because concurrency was horrible. Now, granted, with subversion, Git, Mercurial, all these other solutions nowadays, that really should not be a problem. Well, okay, so I think we hit on another topic, though, as far as my personal workflows go that Joe kind of hit on is that I won't even push to the main repository

until I know that whatever that branch is that i'm working on whatever that that that entire unit of work is supposed to be i don't um push it up until i'm done with it i might have multiple commits locally but i don't even bother to push it up until i'm ready for it to be, um, you know, consumed by the public. Does that make sense? Yeah. The only time I end up doing that, and this is usually when you have pressure, like people are wanting to see stuff happening, you know, that's about the only time that you'll, that

I do exactly what you're saying. I'll do in an intermittent push. If somebody says, Hey, I want to see the code. I want to be able to look at what's going on because maybe they're working on something in conjunction with me. Like there's been situations where all three of us are working on things and and you know you need something that i'm working on so i'll push it up to the service but for the most part i agree like i typically try not to push code that's not in its pretty much final state minus any kind of bugs that come up right so um i don't know i i think that also

kind of begs the whole you know what is the workflow that we typically do like i'm a big fan like i may not always be the kiss simple or the kiss methodology keep it simple stupid but i know with source control i try to keep it as vanilla as possible like i'm doing clones and pulls and i'm branching i'm making changes and then i'm doing pushes right like that's like two percent of the git commands right there i know and that's the thing like the the git especially is insane like there's 5 000 commands you can do and there's like man pages that are longer than dictionaries like it's they're all full of awesome and there's a switch for that and by the way that switch can be used on multiple commands just to make things a

little bit uppercase and lowercase versions you know yeah i'll pass if you want to do an ff only you could use it on multiple commands. See, this is ridiculous. Well, speaking of commands, so Visual Source Safe was, I'm sure there's a way to script it, but it's pretty much a UI program. That's how people interact with it. But, you know, from pretty much like CVS,

SVN, Git, Mercurial, those are typically console-based and there are UIs for them, but I don't know. What do you guys think? I'm, I'm kind of a console guy, but,

um, dude, I'm command line all the way. Yeah. So I'm, I'm the, uh, I'm the man in the middle here.

Cause I absolutely, I use the console for doing the ads, the commits and all that kind of stuff. But you will not catch me diffing files on the console. I cannot stand it. i think it's horrible i i do not like it like i basically i feel like we got some green eggs and ham coming i can't do it you don't like it on a train no i don't like it on train i don't like it a plane no seriously i i mix them so so i understand where like that – okay, so there are some great UIs out there.

I won't deny that. For me though, I like to stay in the practice of using the command line because from one environment to the next, maybe I'm on a Linux environment and I'm using Git and that same – maybe some Visual some visual studio plugin you know might not it's obviously not going to be available so i like this i like to stay on top of the command line options just to stay sharp on it you know so it doesn't get forgotten so what if you're working with someone who's a little less technical do you recommend that they use the command line uh actually i have that's a great question i have because i i i think that you nah i have but but i'm saying like i've done it though i have i have recommended to people uh you know i i'll i'll walk them through in the beginning you know using the command line but i think that there's something to be gained from

that personally do you think they understand it more if they use the command line what's really happening it depends right like i mean there's less things hidden from you there's they're completely i mean all the guis are our wrappers for the console ever pretty much in any kind of source control right and a lot of times yeah a lot there's there's some guis out there they're all they're doing is executing you know five different commands that you would have done on your own. But if there's in that chain of commands, if there's a problem, they might not handle it the way you would have wanted to handle it. And that's why I think it's better to just stay command line.

And that's my own personal preference. That one's tough to me because being that like i said i use both but all my commits all my pulls all my pushes all that kind of stuff the cloning that's all done at the command line so really the meat of what i'm doing is the command line when i'm trying to diff files to see what was different before i push them up though i'm using something like kdiff3 or or some other tool that is available through Visual Studio or whatever else I'm using, simply because I like to look at the differences side by side. Because I don't like looking at them in the console. I don't like having a page down and go back up and down.

I want to be able to scroll in a window, right? So it's hard. You can scroll through the command line, too. Yeah, it's not pretty. It's not pretty. This is more. See, I've never even handled it. I wasn't even thinking of that.

I was actually thinking about where you can diff through your commits. I'm sorry to interrupt. No, no, you're good. Yeah, I don't like it. But the one thing I will say is it's almost hard for me to recommend a GUI because I don't use them that much except for diffing files. So, I mean, I would have to go learn the gui yeah and that's that's the reason why so when you ask me do i tell somebody use the command i think yeah i'm that

i'm that guy that's actually recommending command line because as you mentioned i don't really have a good one that i would want to recommend that i've got enough exposure to and used to but then that's because i try to practice you know the command line option so that it's multi-platform but if you're truly trying to keep it simple stupid if you're trying to kiss it then maybe And that's because I try to practice the command line options so that it's multi-platform. But if you're truly trying to keep it simple, stupid, if you're trying to kiss it, then maybe the UI isn't so bad for some people. Yeah. As long as they have Michael Outlaw to call on if there's a problem. Yeah, because Outlaw knows every obscure command on the planet. I've gotten my share of calls.

But, yeah, I don't know. When merges go bad. But how do you do merge conflicts on the command line like that's got to be disgusting i've never even tried it like i don't even want to know uh well okay so um so back when it's been a while since i've used Mercurial, but I did have, uh, you know, that one did bring up, uh, a, a GUI diff, uh, for you. That was really nice where you could select, you know, it would show you like a present an A, B and C kind of option and you can select through that. And that was nice in, uh, at least in the way that I'm currently using Git. It's all, uh, you know, I'll see the, so if it's a, for example,

a merge conflict, I'll see the files that are, have the errors, and then I'll just go and open them up separately in an editor of choice, whether it's, you know, if you really wanted to VI it, or if you wanted to use a notepad or whatever. So you have to handle all those, like, less thans that they throw in the files. Like, you've got to clean all that garbage up. See that's why i like using the guis right because like kdiff which is available on linux available on windows available on every platform on the planet um when that thing opens up it gives you that choose a b or c and then it'll bring those together and then you don't have to worry about cleaning up all the files behind the scenes right and deleting the files out that it created that were the merges and

i don't know it just it's just so dirty yeah i i've just gotten used to it i guess you know i've never used tfs but i've always wondered um you know if that's more of a gooey heavy or if maybe the gooey makes more sense than it does for something like git or mercurial but I don't know if anyone's out there using it and you should let us know. Yeah. Cause I mean, from what we've seen of TFS, it looks like it's, you know, Microsoft's version of like almost subversion, right? I mean, it's a central repository, uh, which by the way, um, I don't know if we've, we haven't even really touched on that.

I mean, you had the old school stuff that was central repositories. You have the new school stuff that's like the distributed repositories. Everyone's a repository. Yeah, exactly. Your Gits, your Mercurials. I've yet to work somewhere that doesn't treat it as a central repository. Well, yeah. I mean, there was even a conversation today that came up that was similar to that, and I kind of chuckled.

Yeah, it's kind of funny. So we're distributed, and we all have our own copies, but really there's one authoritative copy that we all use. But man, is it so much faster than what Subversion was. I mean, seriously. And I guess at the end of the day, though, like Subversion was always pinging back to the server, right? Always checking. Whereas Git kind of leaves it alone. Yeah?

I mean, until you do that pull or pull or push yeah so i don't know you kind of left alone to your own devices there but um yeah i like distributed since i've switched to it i mean it's always a pain going from one source control system to another but since we've moved over to git i love it yeah there's no going back for me and plus a github is so nice and it's so um it's like it's the place to go to to host your code so you know it's hard to be a coder nowadays and not be familiar with git yeah i from my point of view um is it has been a couple years since i used used material, but I will say that I, I do recall,

like I loved their command set. Like the commands just made sense. Like, like I, but the thing is, is that it's been stocks that I've used it. I don't remember the commands anymore. I just remember that like they made sense what they did,

you know, that, that the names of the commands, like it just seemed a little bit more intuitive. Yeah. Even the install is just a couple of double clicks. It did you know that the names of the commands like it just seemed a little bit more intuitive yeah even the install was just a couple double clicks it you know just works really well on on windows you don't have that whenever you install git on windows you've got that weird kind of question do you want to modify your your uh your path do you want there's like three options and each one sounds more confusing than the last well Well, that and there's a whole slew of different options, too.

I mean, so I know that as far as which tool I use compared to anyone else, I'm a SigWin fan. So I use Git through SigWin. So I definitely have path issues there because my path is on a Windows machine as user bin git and that's not going to work out too well right yeah i mean at the end of the day though mercurial is basically only for dot net stuff right like or was that what it was generated for no no no i think it's just you know i don't know why but it was written in python And it just seems to me to be just so much more polished than Git.

It doesn't have all the flags. It doesn't have all the bells and whistles. But it just seems to flow. It's like the commands are named what you think they'd be named. Yeah, the commands are way more intuitive. But if I remember right, it literally started, I think it started a few days before Git, right? Like the first development on it, if I remember right, the history of it? The history of those two are, timeline-wise, they were really close together to one another.

Yeah, so there's a little bit of trivia. Well, speaking of new repositories and the rise of GitHub and its takeover, when you're committing to a new repository for the first time, this is really big in open source. If you see a project that you like and you want to add something to it, I just want to mention a couple of things. You should try to keep your names and style consistent, even if the current repository is totally wrong

and uh i know that could be tough you know sometimes if they're using you know spaces instead of tabs or whatever just just consistency is more important in my opinion than being right yeah i mean especially if it's not yours right that's true yeah it's really it's really not yours you don't go in and rearrange somebody else's house when you go over. No. Well, there's that one. That reminds me of a story I heard, and I wasn't able to confirm it, but back when GitHub was first getting popular,

people would write bots that would go out and auto-format other people's repositories. They would fork the repository, auto-format, and then send a pull request, which can be kind of rude to wake up and see that someone's sending a pull request for uh you know converting your tabs to spaces or renaming your variables whatever just like cleanup type stuff you know it's a little offensive but it's also kind of funny just don't do it to us. It will be denied. Oh, wait, you just brought up something else we didn't touch on. So, like, one of the big things in source control is pull requests, right? Oh, right.

I mean, that's probably, I don't know how many people have dealt with it, but it's beautiful. It's like code reviews before you actually commit things, right? Fully commit things. Or merge them in, rather. Or merge them, yeah, not commit, before they get merged. Yeah, it's a way of bringing more process into your organization, right? Yeah, I've never tried to submit a fix for anything that was on Subversion, but I can't even imagine what you'd do.

I guess you just kind of take the files that you modified and you email it to the person like, hey, what do you think of this? Yeah, I mean, it's a beautiful thing because i'd worked in uh visual source safe and subversion for years and there was no such thing yeah like you committed your stuff and you know it was basically hey you know the heck with what you guys have mine's going in there enjoy exactly but but with like git now you can literally say hey i want to push these all into this branch hey somebody take a look at this make sure i didn't do anything completely crazy and it's beautiful especially for companies that that don't have a

lot of time to do real code reviews to where you know hey i got this thing we want to release and then everybody sit down and do it this is like almost you know a check that's easy to do because it's kind of built into the system to say hey take a look at these quickly briefly go over them diff them and then bam so what i really like is that you can write up a nice description and github actually submit uh accepts gifs now so you can put like images and moving pictures inside your pull request but it kind of minimizes all those little uh those little dinky commits that people may not be interested in, especially when the commit's something like almost working. Which we've already established.

Yeah. And speaking of other bad practices, I wanted to ask a couple questions and see what you guys thought about some issues in source control etiquette. So what do you guys do with your branches after they're merged? Yeah. Alright, so... About that.

Right. I'm scared to delete them. I'm bad about leaving them. Yeah, we can all fess up to that. But didn't... We had a discussion not too long ago about the fact that even if you delete the branch the commit history is still yeah you're not changing the

commit history at all so you can kill at least let's we're speaking specifically about get just right get clear yeah but yeah you're not changing the commit history you're just getting rid of the into the branch i i'm i'm bad about leaving the branch there and i know that um and well i think because because part of it is is that you don't always know when it got fully merged in like like uh well i'm sure you have a command line oh. Oh, yeah. No, there is totally. But my point, though, is that you make your commit, you push that into the master repository, create your pull request, and then you move on to the next thing. Right. Uh, you know, there might be several days before your peers have a chance to do a peer review on it and approve that pull request, you know, under special circumstances, there might even be a delay before that pull request, even after it has been merged in i can safely delete the branch from both my local repository and you know from the master and i've actually reverted merges also which is terrible don't do it if you can avoid it but it's possible but uh what's weird i've been looking at automatically deleting all branches that have been merged in and i did

it on my local computer and nothing exploded it's fine but uh what's weird about that is i'm deleting other people's branches yep and so how do i really know that they're done with that branch do i want to do that on the remote server or you know what happens if i'm working on a big team so if you were to push all those it would actually push and delete those from the remote right yeah i don't know if i like that yeah i mean you'd actually have to go through and look through the branch history to see which ones have been merged in and not right yeah but that wouldn't tell you that they're done right and i've got a command that will only delete the um the merged ones but it's still it's kind of weird well like you said you could still be

working on that branch you could have merged it in continued working on it and be ready it might be like iteration two yeah feature yeah so that's yeah that's uh not the end of the world but you know yeah typically do you don't want to delete anybody else's branch i don't think well have you guys ever lost a branch so i guess i guess one takeaway from this i need to get better at deleting my branches is what we're getting at yeah i mean i try to delete mine but it's but it's kind of like when your room gets too dirty it's like man if i just cleaned it up a week ago it'd been so easy now i'm just not gonna screw with it right uh well i've definitely lost branches and and one way for me to do that easily is i'll commit something locally and you know once i hit commit i feel like it's truly saved but for some reason uh maybe it's

the old subversion mindset like i think when it's committed it's like really safe and then i go and reformat my computer and i go to merge it a day later i'm like oh crap uh so you didn't push it up to the repository right uh yeah so you really do use commit like a save like when you're closing that word document your commit is your save yeah i just i feel like i'm just risking everything if i don't even though it's on your local computer yeah so so you're trying to you're bringing this one up to support your use case of pushing it to the remote i've done it i'm not proud but in fairness how many people format their computer

and then do it I've done it I've refarted three computers in the last month holy crap different computers keeps you honest I don't know as far as me specifically having lost a branch

I don't format my computers that often. I'm one of those that if there's a problem on the particular operating system, I will really try to get to the root of what the problem is before. Rebuilding the computer is the absolute last thing. There goes a Saturday, right? Oh, I'm getting good at it now. I got a list. Boom, boom, boom, boom.

Yeah. I mean, I guess back in the early days, though, I took it as a learning lesson to better understand things rather than just taking the easy way out. Well, all three of mine have been different operating systems. Jeez. Rather than just taking the easy way out. Well, all three of mine have been different operating systems. I just don't really mind. I'll watch a movie and get my computer back up, try something new. Yeah, I mean, I had the worst one I had recently was, well, we're getting specific, but it was, you know, I had a corrupt OS X install, and I think I left that thing going for probably a good six months to a year

trying to get to the root problem. Oh, wow. It might have even gone on for a year and a half. I could not for the life of me find out what the root problem was, and it was so scattered. Well, that reminds me of my next question. How do you guys feel about foul language in commits? It's happened at times.

Don't recommend it. You don't know who's coming behind you. I mean, God could be in the code right after you, so you could be really in trouble. Even with my Tourette's, I don't think I've actually taken the time to write it down, though. Yeah. I'm sure that someone's written some sort of bot

that goes through GitHub looking at commits with the bad words in it. That seems like kind of something fun to do but uh yeah i try not to do it because i learned a lesson a long time ago you should keep the bad words where someone no one can see them wait how did that happen i really want to hear this it actually wasn't in source control just um we had a a project that we're going to be demoing in a little while and you know we're working late nights. The South Park movie had just come out. There was just bad stuff throughout the site. It ended up getting shown to investors a little bit early.

There were videos autoplayed and stuff. Something about someone's uncle? Yeah, exactly. Might have come into it. Oops. Less, oops. Yep, lesson learned. So have you guys ever omitted your own commit to fix like a grammar or something? Yes.

What about somebody else's? Yes. Well, I mean, are we talking about specifically? Okay, so we're talking about the message, the description? The message. No, never. Oh, the commit message? Never. Yeah.

Oh, no, not just the message, but like if somebody misspells a variable name, I can't take it. Yeah. I will modify that variable name. Well, yeah. I mean, that goes back to our other topic about it should – don't commit it if it's broken. Well, it worked. The closest thing that I've done to this and and it wasn't because of the the the commit message or the commit description um you know but I have gone back and um

after making a commit realized oh I wasn't quite ready to make that commit. And then I will undo that commit finish or fix whatever I just found that was incomplete and then re do the commit. I've done that, but not, not fixing somebody's commit message though. That's the, maybe you don't have enough. That's getting to a whole nother level of OCD.

It is beyond. I've never done it either. Yeah, no, that's, but, but code actually. Yeah. If somebody has bad grammar in their code, I never done it either. Yeah, no, that's... But code, actually, yeah. If somebody has bad grammar in their code, I can't take it.

Yeah. Well, speaking of bad grammar in code, have you ever been in the middle of bug fix and you see that misnamed variable being used somewhere throughout the file or files and you just... Yeah, you don't want to stop what you're doing. You just go ahead and rename it even though it's kind of unrelated yeah committed so do i drink now like i take a shot yeah never have i ever so yeah okay yeah i've totally basically uh more than one thing in a in in a commit or a branch

to what we're gonna i where where i've gone with that is um if i see something like that and it's bugging me i will fix it while i'm in let's say that branch that ticket you know while i'm working on that you know unit but i will do them as or try my best to do them as separate commits just so for my own peace of mind if i needed to undo something i don't want to muddy what the real purpose of me getting into that file was with me doing some ocd cleanup on whatever the file is yeah i'm bad about that too but but ever since i started really using git i don't really even think too much about the commits but i think about the pull requests so all those little commits that happen in between they just kind of get lost to me and i just think about the the kind of the bigger pull

requests so i you know i'm i'm really bad about slipping stuff in there and then feeling bad about it later well i mean just before we leave that i mean one of the good practices, and this is kind of what's suggested from many places, is you want to commit a single piece of work, right? Like, let's say that you're working in a branch, and you've got 10 things that you're doing in this branch. When you go to commit, even though you might have touched 20 files, you really only want to commit three files that had to do with the one thing that you were completing, right? And that's good practice. I don't know that we always do it because a lot of times you wait until you're done with a bunch of stuff and then just commit all the files at once, right? But there's this whole idea of committing a unit of work as opposed to the entire piece, right?

So I don't know, that kind of goes to what you were talking about, where you try and break up your grammatical fixes from what you're actually trying to work on. And that's kind of doing the unit of work. Whereas Joe said that he's basically thinking about the big picture when he's ready to push the whole freaking branch up and be like, hey, here it is. Yeah, I mean, I've definitely had pull requests that afterwards I'm like, oh, I should probably feel guilty about that.

Because there's a lot there to review to see what actually changed. Gigantor pull requests, 73 files coming in. So what do you do? But the problem with that, though, is that, and I'm sure like every developer on the planet would have a similar story. It's difficult to make time to just go in and clean up your code. And even more difficult than it is to make that time, it's more difficult to convince your boss, hey, listen, I'm going to stop all this productivity that we've got going on. Because if you see this file, that is really bothering me.

I just want to take the time to clean that one up. And there's about 100 more just like it that I also want to clean up. So I take the approach of, you know what, if I've got a bug or a feature that i'm adding into here and i'm already in the file and i see that improvements could be made then it is my responsibility to make that improvement right it's kind of like the the boy scout motto i guess you know like you know if you see something it's your responsibility to take care of it to make world, to make the place better than what you found it. Right. Right.

And that's the way I treat it. Speaking of which, how many of you guys here have had the same problem since we did that boxing unboxing thing to where you freaking look at all your code and you're like, I can do this better now. I could do this so much better. It's actually annoying now. It bothers me. Yeah. I keep wanting to add two strings to everything i'm definitely uh more aware of like when re sharper is uh it has like the little three green dots below so i'm like no this is it's not quite telling you that you should get rid of that

it's a redundant call but it's just letting you know that it's uh it's a redundant quantum value type that is not so bad to leave right hey back to his gigantor pull requests there like i know i've put in pull requests that have like 300 files being touched and joe's usually the recipient of those and maybe outlaw too like what do you guys do do you actually go through all 300 what do i really do yeah what do you really do or do you just browse to make sure it's not touching your code so i i mean the greater question there being was like how do you peer review other people's code when you have okay when it's 10 files we can all agree that we probably go in and we actually take a look at all of them when it starts getting 50 and above like we're all looking at it going oh my god i got so many other things i need to do right yeah it's exhausting yeah i deal with a lot of pull

requests and man it's uh it's exhausting yeah when you're trying to code review that many files i don't know that you can really give any serious value other than just like looking through them for like obvious things. Right. But the context of what was being changed or what was happening there is going to get lost. So it's going to be

really difficult to go through that large of a change set. So the key is don't do Gigantor pull requests. Right. Try and keep them pretty small. Actually, I just got a book on code reviews. I'll put it in the show notes. I don't remember gigantor pull requests, right? Like try and keep them pretty small. Actually, I just got a book on code reviews.

I'll put it in the show notes. I don't remember the name, but I'm hoping it's got some secrets in there for handling this. But right now I just try and probably do a bad job of it. Yeah. I mean, I guess the proper workflow

in that scenario that I was describing should be, you know know i'm already in the file i see that there's a problem with it let me create my whatever the bug fix that i'm doing or the new feature that i'm adding and push that you know go ahead and create a pull request for that but then create a separate branch as the cleanup branch and treat that completely separate from the bug or the new feature would honestly be a better way to do it. But yeah,

like I said, I'm, I'm guilty of, of not doing that. Maybe another good thing you could do is just grab the person who did the pull request and be like, all right, first file,

what'd you do? Why don't you do it? All right. That's actually not a bad thing. Yeah. So, um, uh,

I got a good one now now do you guys commit generated files usually no usually yeah so the only the only thing that i can tell you that is different in that regard is um being that we're typically in visual studio we use new get packages and we have or we're in the process of trying to get a continuous integration thing up and running. It pulls things out of Git to do its builds. If those NuGet packages are not in source control, then it doesn't have them to do its build. So I have pushed in the binaries for NuGet packages so that when the continuous build is trying to do its run that it can do that. But otherwise, no.

Like any of the bins or obvs or anything like that, no, I don't. So, I have mixed feelings about this one. So, if it's anything that I can create, then no. Yeah, fair

enough. If it is third party dlls for example and and maybe those are hard to come by which is less and less every day but you know in some scenarios then maybe i do want to have a history of those especially like if i get a new version that's about the only scenario that i can think of where i've done it so very specific needs though yeah because like if i had the source code and i can compile it myself then no there's no need for it right but yeah in those scenarios where it's third party and it's difficult to get your hands on it but uh or even more even more so, maybe that third party, they don't expose their version history to you, then I like to have that for myself.

What about the documentation that goes with that? Let's say they give you a PDF or something. Is that something that you would put in there? I would think probably yes, right? Yeah, I mean... So usually if I have some sort of wiki or something set up, I'll put it there. But sometimes it's so nice to have a little folder with documentation just right there where you're at. And it's not necessarily so much for source control. You're really kind of just using it as a repository at that point, right?

Because you're not really thinking that it's going to change. Unless, like what you said, Michael, where the DLL changes and then maybe they come out with new documentation. But I mean, I, I'm definitely in the court. Like that's, it is nice to know that you can go one place to find all your stuff and anybody can go to that one place. It's not like you put it on your computer and in your own folder called, you documentation that's all well and good but nobody else can find it now so i have used it in situations like that but that's that's rare i don't know yeah speaking of documentation uh how do you guys feel about readme files uh they're awesome they're awesome but uh how often do you end up writing them not often enough well

okay so i mean if we're talking about for every pull request is that what we're talking about like roots of maybe projects for your whole project yeah for for projects sure probably necessary i'd say i'd say in today's world you should have one if you're if you're putting anything out that anybody else is going to touch it should be there the first thing i do on github is uh i create a readme file like it suggests and then i leave it blank but it's there that's there no i mean i've actually tried to put some meaningful stuff in there at the time or at least what i thought was meaningful at the time yeah i tried to on my bigger projects but, but it's a pain kind of. I don't know what it is about readme files.

Just even coming up with comments sometimes, just the message for my commits are really tough. It's like I'll know what I did, but sometimes when it comes time to type, I'm like, ah, fixed the bug. Commit committed. Go back and look at the original ticket. Actually, I don't know what I only fixed what i was told to do it brings us uh to the kind of the fun stuff um one of the things we found when we were researching this podcast was a website called what the commit.com that's

http colon slash slash what the commit.com and that'll go in the show notes yep and it's actually a comment generator and uh it's fantastic yeah we all have our favorites if if you don't by the way just a word of caution if you don't like foul language this may not be the place to go hit refresh 100 times because you're gonna get a little bit of it that's true blame todd i'm sure we've all seen commits like this i'm hitting the site now and i'm seeing comments like just shoot me or this solves it um some bad language yeah probably one out of every three or four is gonna have a little bit of that yeah it's a fun little site and apparently coders are angry people at times um yeah my favorite of the ones that i saw earlier after my 500 refreshes on the page was friday 5 p.m i really understand the intent of the author in that one yes yes i don't care what i did here

but it's getting committed because i'm going home i don't even remember now the the favorites that i had found uh i mean there was the one about todd committed but there was another one and i don't even remember uh that i'd found earlier there there's some there's some comic gold on that site though for uh so so some of my commits might be uh a little bit more comical from now on. Yeah. I just saw one, one that I would do a work in progress.

It should not have been. Oh, I remember what I remember what the, what my absolute favorite commit message from what the commit was, was don't push this commit. Hoping somebody read that before hitting that merge button. I think my favorite is the effect of, I don't know why I'm doing this. And speaking of that, there's actually a website, there's a Tumblr called epicpoolrequests.tumblr.com.

And you can actually, it got links to to pull requests on github and other places that just they're epic so you can actually submit your own there too

but they're pretty funny you know there's some Chuck Norris references in there some unit testing stuff change all colors to hot pink you know some joke

pull requests which are funny unless you're getting them all the time, I imagine. Yeah, yeah. If you're the one managing all those approvals, you're probably hating life. Yeah.

And we also, we already mentioned using GIFs in your pull requests, which can be a good or bad thing. I've seen some pretty obnoxious GIFs. Oh, GIF. No, no. no all right so for you listeners out there we would love to hear from you do you say gif or do you say jif well wasn't this debate just settled by the inventor of the stupid format no it shouldn't be like i don't care what he expected it to be unless he agrees with you maybe i always liked the the mantra from

a long time ago like choosy hackers choose jeff nice well uh well if we can find that earl we'll throw in the show oh dear god shoot me now is that my name is Earl alright wow we've definitely stayed out of the weeds yes yes completely oh man well that's pretty much it for the fun stuff I wanted to mention so

some tips of the week then I found my favorite tip so far and i was when i saw this i i would dance it around the office had to share it with everybody i thought it was fantastic so okay here let me let me uh first paint the picture for what this looks like you're you have a scenario within visual studio. This is a Visual Studio specific tip. And let's picture if you had two lines of text and they're both using like the same namespace, for example. They're both in a system dot something.

And maybe you already have a using statement up there and you want to remove the, the system part from those two lines, right? So in visual studio, if you press the alt key and then drag the, a box around the word system in that scenario with your mouse, it'll draw, it'll draw a box and whatever you start typing or deleting happens across all of the lines at the same time and it is awesome

it looks like magic because you do outlaw so in that simple scenario like i mentioned two lines you're like oh big deal i could just like delete those or in that scenario you could also say you know a refactor kind of scenario but it is awesome you know to be able to edit multiple lines of of code at the same time if you want to change the name of something or if you maybe may maybe you have the same variable uh well you know because you could refactor it so then i was gonna say like maybe you have the same variable and you wanted to append something to it, you know, to the name. You wanted to add something to the name. It's hard to come up with a real good scenario, but it doesn't even matter.

Watching it happen is, like, magical. Yeah, I'm just saying, like, the scenario has to be, though, that all of the lines that you're selecting, that box that you're drawing around is something that you want all of those lines to do, right? So the text has to line up. Yeah, I mean, even if it was as simple as just deleting, holding down that alt and blocking off a section and just deleting that whole area. Yeah, ever since I found that, I've been using it for deletes. Like if I'm going in and cleaning up, there have been scenarios where I'm cleaning up code and maybe a using statement wasn't there. And, and I added in a using statement so that I could get rid of these long namespaces. Uh, and then, you know, maybe that same namespace was referenced five times in a row with, for different variables. And I just want to remove the piece that I've added in a

using for. And I mean, there's other tools to do that, but you know, that, that all left click that it's gold. We'll, we'll actually do a screencast on this so you can see what we're talking about. Cause it's,

it's pretty cool. It's actually one of those features. That's just fun to use. It's like going down a slide. Great analogy. Oh, so I guess then my tip of the week is this is along the topic that we were talking about today with source control. One of the most popular applications that you can get for just about any source control provider out there is Tortoise.

There's a Tortoise for Git. There's a Tortoise for SVN. I think there's Tortoises for pretty much everything. For Mercurial. Okay. And here's the thing. If you're brand new to source control, it's fantastic because you can just go into Windows Explorer and you can see what's changed.

You can see green on your folder, meaning that everything's good. You can see a red indicating that there's been changes. It's fantastic. The problem is that is now, because it's integrated in Windows Explorer, it's integrated into your system and it's integrated into your shell, which means that your computer is constantly having to pull and ping and update all these folders, all these images, all these icons on the folders to let you know that things have changed or they have not. And initially when you start out, if you're just on a small project, not a big deal.

You've only got it on one or two folders. If you start getting into thousands of files, and I know this because it's happened to me years ago when I used to use this stuff a lot before I went command line, your system will start bogging down. And because it's just constantly having to sweep through those directories, looking for changes and comparing it to either what was previously there in the file history or if you're using subversion specifically it's going back to the origin server and if it's not on a close network

share then you're going to have latency between the drives coming back and forth so my tip is if you can do what we mentioned earlier and get command line tools don't install something that is going to wrap itself into the shell of into the shell of your computer and honestly that's what drove me to learning the command lines behind it because i was perfectly fine with the gui because i was like you know what it's windows there's a reason why people like windows it's because it's easy but at the end of the day if it comes down to my system performing poorly like literally to where you'd open up Windows Explorer and sit there for 10 seconds waiting for it to even refresh the file list, you know, it was horrible. So if you can, if you're using Git, if you're using Subversion, try and get the command line utilities and get some supplemental things that maybe just plug directly into an IDE as opposed to installing on your system. So that's my tip of the week. And, and I do have some of those ID ones that are hit or

miss sometimes they can be, but they're not integrated into your system. So they're heavy while your ID is open and it might slow down your ID a little bit, might be worth it depending on your level of expertise. But at least when you you shut that down it's not eating up your system resources so you know my there there's mine yeah i restart my ie a lot more often my computer yeah so um i wanted to mention um there's a a nice little javascript application called learn get branching and it's free it's hosted actually on github and i'll give you the url in a second url but uh it's actually like a little hosted actually on GitHub. And I'll give you the URL in a second. URL. But it's actually like a little game.

And there's 16 levels where they give you like a picture of a branching scheme. And it's up to you to type in the commands to make your graph match. And it actually sounds a lot harder than it is. But you just go to this page in your browser and uh start click clacking away and uh it does a really good job of teaching you about rebasing and branching and merging and all the all the cool stuff yeah and uh that url is http colon slash slash p coddle that's p c o t t l e dot github.io slash learn get branching and that'll be in the show notes yeah and and honestly if you guys this is a fantastic tip that joe's given because he actually passed this around when we were all learning it and it really does make it like a game like you get points if i remember

right like as you complete things like you get points like you complete things oh yeah yeah when i finished the last level i took a screenshot i tweeted it that's a big deal so yeah that one's fantastic so um yeah we'll uh we'll be putting all these things up that we've discussed we'll be putting them in the show notes and again you'll be able to find this at www.codingblocks.net slash episode three. That'll be just episode with the number three. And that'll take you straight there. And you'll find this and everything else we've talked about in this episode. We also tried something new with this episode. So let us know what you think and hit us up at comments at codingblocks.net. And if you want, you can go directly to the episode page as well and leave comments there. I mean, if that's your thing.

Whatever's convenient for you. Yes, absolutely. We are easygoing guys. So with that, subscribe to us on iTunes, Stitcher, and more using your favorite podcast app. Be sure to give us some reviews on iTunes and Stitcher. Visit us at CodingBlocks.net where you can find our show notes, examples, discussion, and more. And as we said, send your feedback, questions, and rants to comments at codingblocks.net.