Oh and the two stash commands aren't necessary at all. I just rarely push with dirty files lying around.

That's how it started. I think what end up happening (and actually happened last week) was people got lazy (what a shocker!) and rarely merged in other branches so, when it came to trying to merge feature branches back into master it introduced merge madness and lots of bugs. My manager asked me to merge the main dev branch into a branch I was working in that was a bit of A/B testing for an existing page. Last week, two members of my team took turns introducing an influx of bugs into the main dev branch. I told my manager I would not merge the main branch in until **** settled down and we were pretty sure all the introduced bugs were fixed. I told him that on Friday with pretty strong language. Monday morning of course he asked to merge it in. It broke a number of things and caused me to do my first ever git revert for a merge.

I think when I say merging you are interpreting that as a merge request. Nobody in my team ever submits a mr for someone else to approve. By default, I only do mr's when I'm resolving a bug. That mr gets assigned to my team leader, who starts a stage push, tested, then included in next deployment. Typically, when I say merge (and might apply to other people) I mean something like
My general rule is to try and merge all my active branches at least once a week on Friday. I currently have 3 active branches that are distinct from the main dev branch. Since the main dev branch is ****ed right now, I've only been merging master in lately.

I'm totally with you there, and I don't think it is a nitpick.

Creating little functions all over the place that encapsulate short bits of code is not more readable. The more I have to jump around in the code to figure out what it is doing, the more confusing it gets.

Sure, you might remember right now, while writing the code, what parse(data) does. But when someone else encounters that code, they won't know, they won't even know if it is located in this module or not, and will have to jump around in the codebase to figure it out.

undo last commit is just a soft reset. hard reset will undo the commit and lose the changes.

"git reset --soft HEAD~1" where 1 is the number of commits to undo. so if its just your last commit, use 1. then you can stash that commit and you will always have those changes. this is a pattern I use a lot.

also, if you have EVER committed something, no matter what you do, you will almost always be able to get it back with a "git reflog". I say almost bc I am sure there are ways to mess it up but if you just undo the commit and then undo your changes or much up your changes or even do a hard reset, you can still just use the git reflog id to checkout that detached version. then do a git soft reset and bam your changes are no there in uncommitted state.

revert commit is strange in my experience and I avoid it. it creates a whole new commit that gets rid of your changes of the commit you specify. so I dont think it will do what you want bc it will never you leave you with your uncommitted changes existing. to do that you need to do a "git reset" at some point. I guess revert is nice bc it will leave in the history of the master branch the old changes so any developer can get to them (with a git checkout <commitId> then git soft reset last commit) so I can see why the revert makes sense to maintain the history. also, revert can undo a commit from long ago if necessary.

and you dont need to stash (tho I would use your pattern so that the changes exist in stash) bc you can push with uncommitted changes and it acts like they dont exist.

+1

Your editor/ide of choice might support huge columns of code fine, but you never know how your code will be reviewed or presented in the future. 80 is guaranteed to be readable basically in any screen or printout.

does your boss, or anyone, need to review your branch before merge? bc in my experience, many small branches/PRs/commits is like a million times easier on reviewers then sporadic massive changes to review.

Thanks for sharing that much of info and knowledge here it really helps me alot it may also help others

I believe it's a hangover from manual typewriters with fixed tab stops at every 8 characters, that were seen as the best compromise for creation and formatting of tables.

Yes and yes. I think they just like giving me a hard time.

Maybe it's a punch card thing lol.

When I went to college there was a professor who had a story about dropping his giant box of punch cards for his big year-long assignment. It took him days to put them all back in order.

You kids and your fancy 80 column screens don't know how good you have it.

The system stuff is challenging. No issue is ever alike and there are always 50 ways to do things and you need to try to pick the best one, it’s interesting

Re: 80 chars, i’m almost positive this goes back to punch cards and then early terminals being designed around this col length.

I think its weird to limit yourself to 80 characters given todays technology. But, meh, whatever.

The IBM punched card format (introduced in 1928!) was 80 columns wide

Most of the first displays were either 40 or 80 columns wide.

ETA: there were other formats but 80x12 was one of the first standards. The first displays I remember using were 80x24, and I bet the 24 height was because it was a multiple of 12.

No - you can rename packages on import, i.e.

The gofmt tool, which is pretty widely used, inserts tab characters for indentation. I would guess 8 spaces is just Github's rendering of a tab character. I use 4 in my IDE.

GROSS. DO NOT WANT.

80 is a good idea for commit messages but otherwise what goofy said

This brings me back to a years-old discussion (incidentally, with the same coworker who started the Go repositories thing above) about line breaks in Git commit messages. He included this (from Linus Torvalds) in his favor: https://github.com/torvalds/linux/pu...omment-5661185

"Word-wrapping is a property of the text (!!!!) and you should do it when you write it" strikes me as an indefensibly stupid and false statement, but that's just me.

Adding line breaks to writing is obviously different from line breaks in code, mostly this just reminded me about the humorous things that occasionally come out of the Church of Linus.

(I also love that even just pasting this here, the guy he's responding to has normal looking text while Linus' message is in this broken choppy format because of what he believes to be a superior method of communication)

He's basically arguing against word processors in favor of typewriters.

So Chrome (on Mac at least) has a fun new bug. Close a tab (or it could be closing a tab in separate window by closing the window), then switch to another tab. For a brief flash it displays the tab you just closed. Even if that tab/window was an incognito window you were using for certain things. Fun stuff.

Not always obviously but I've seen it a lot now.

It's not a technology thing, it's a readability thing. Code should flow vertically, not horizontally. And as I mentioned, if you multiple tiled terminals up, wrapped code everywhere is very unreadable.

Luckily, expanding to, say, 110 columns (I think that's Github's web UI limit for diffs, so that's what we use) has not inspired anyone, in my professional experience, to try using all this glorious extra space to jam multiple lines of code into one line, or anything of that nature. Our code still all flows vertically, even if some lines are long!

Just read up on git revert, and I agree. The only place where I can imagine using it is on a protected branch. Better to simply delete or ammend the commit.

Goofy or any Golang folks, anyone tried VGo out yet?

I can't get my own sub packages to work. Meaning:

main. go
foo/Foo.go

How does one import foo package into main?

Yeah, I mean we're talking 30-40 columns here. Although we don't use strict line limits, some lines go to like 160 columns!!!!, and I've never heard any problems about readability.

I've never really had a problem with line length (or anything related to it) but if anything short lines seem to force people to use short variable names which ends up making code less readable.