Lol yeah - this is how the entire world works now. Tell your C++ devs to get over it.

In Go do you have to repeat the full URL in every file you want to import the package into, or just once?

And npm fixed the problem within a few hours I think. Which shows you that the system is robust.

Let n be the number of commits you want rollback.

git reset HEAD~n
git stash
git push origin --force
git stash pop

Communicate this to anyone else working on the branch, otherwise they may introduce your old stuff.

Also, I've never used git revert, so unsure if there's a better way using that.

If a file uses an imported package, it must specify the import URL. (in practice, once I have the repo on disk, if I try using something from it in a file then the Go plugin for VS Code will add the import line for me)

I love when VS Code adds an import. I get hysterically upset when it removes them

So a lot of your files have a bunch of full URLs at the top?

Like say whatever the Go equivalent of lodash is - you either have that url at the top of every file that uses it, or you assign godash (heh) to some global or app-level variable and use that?

Could you import different versions of 3rd party packages into different files?

...and this assuming you need to immediately update remote. Otherwise it's easier to simply ammend commits.

I think yes, but I'm not confident. Mostly quoting for new page.

Go get seems horrendously stupid. There's not even versions? Standard practice for npm/js is to pin dependencies to a version which should make it dependable. At least better than go.

Yeah devops is a great field to get into right now. Everything is changing so fast that experience isn't as important.

Funny thing is I've always been the opposite - I just want to code and avoid all that gnarly system stuff. But DevOps with cloud has kind of met me half way. At least I don't have to worry about **** like how to install gcc 10.2 on Ubuntu 4.2.0 and make sure chmod is right and my PATH is correct and my process is in background mode and whatever other painful crap.

- yep, URL goes in every file that uses it
- packages are not objects, can't assign or pass them
- can only import different versions of the same package in different places by importing the repo yourself and putting it in a special dir where the Go tools will look for it

- yes
- yes

It seems funny to me that there aren't version in "go get"

The imports are all, like, git repos, right? They couldn't let you add a "tag=" or "branch="?

So in this example - the imported loader package is referenced later on in the code as "loader".

What happens if there's a name conflict? I guess all go packages must have unique names? Well npm is like that. So ok. But how do you enforce if they can be hosted anywhere?

This is where "observability" tooling is nice. Ideally you don't go weeks before noticing a problem. But even if you do (it obviously still happens), you can easily go back and see when exactly the problems started happening and isolate it to a specific release. And since you're doing small frequent releases - its usually pretty obvious what the problem is.

I don't think release branches are inherently bad - but they're a sign of things being done in a way that really aren't ideal anymore for most companies/software.

I remember when I first learned about them watching a talk (by Etsy I think?) and I was blown away and was like "We have to add this!". It was brilliant.

Is 8-space tabs some kind of Go thing? https://github.com/sipt/shuttle/blob/master/model.go - second repo I've seen like this.

If so I'm out. I'd rather make hats on the beach.

Is this like a runtime hot-config, or something different?

Sort of? I don't know if there's a formal definition. For us a feature flag is a name, a boolean, and a blob of json data.

If you add a new feature, you make a new FF for it. If you just want to turn it off/on then you don't add any data. But maybe you want to have a few knobs to turn, so you stuff those in the data blob. Like maybe thresholds or timeouts or percentage of the time to show A vs B, etc. So you can tweak those in real time and they instantly will take effect.

Most FF are short lived, like you add a feature, and once it's stable you remove the FF. The system I made has deprecation dates built in. If a deprecation date is set, then once the date is hit, the flag is treated as if it's always on and you'll get nagged about it periodically.

We have some long-lived FF though. Like we have a lot of APIs that are "paged" but the # of pages is nearly infinite. Normally we don't restrict how deep people go but every now and then someone will think it's a great idea to start up 100 threads and start plowing through "everything" in an endpoint. Or, once, due to a misconfiguration, thousands of clients all decided to walk a "subscription" endpoint from the beginning of time instead of just getting what's new since the last time they checked (i.e. everyone decided at once that they needed a few million pieces of data instead of the 0-10 they might normally get).

So if that happens again I can turn on this feature flag, that limits how deep you can go on certain endpoints, let things unwind, and then resolve everything.

It's a C thing. Look at anything by Torvalds.

Well, sort of. There are certain areas of C programming where 8-space tabs (and really constrained column sizes, like 80) are required. The linux kernel comes to mind.

I don't know why except that it used to be very common for tab stops to be set to 8 characters so all the old dudes were used to it that way.

Awesome. Here's the thread: https://news.ycombinator.com/item?id=17871313

Total nitpick but one thing I didn't like is separating a block of single use code out into another function just to make it read easier. Just leave it inline imo.

I don't recall off the top of my head if we reference repos not in our control but I def recall seeing repo names referencing a lot of our private repos in go imports.

After thinking about it a bit more, I've come to the conclusion that there are likely a myriad of possible ways it could be accomplished. Seems like a good interview question if someone claims to be proficient at git. I would expect, at the very least, they should be able to reason their way to a working solution.

So I have a question for everyone. What approach does your company use...

One dev branch to rule 'em all. Everyone commits to it and that only gets merged to master with big releases. Any other branch that exists is presumably a hotfix for a bug that was branched off of master.

or...

Many feature branches that, realistically, should have master merged in on a regular basis. Any other branch that it might intersect with in some way should be merged in on a regular basis too.

My company started out with approach #2 (my preference) and eventually moved to #1 (don't like at all).

That reminds me... how often do you guys merge? Daily? Weekly? Some other time frame?

I had to write something similar as my first assignment in a Java language course:

https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life

#1 sounds awful wtf. The feature/project can't be broken down and attacked in parts? Only once have I shared a branch with another dev, and it was a massive branch.

Funny you ask, my boss complains I submit too many MRs. Today I asked him to merge something small I pushed yesterday, and he jokingly asked, "You expect something you pushed yesterday to be merged today?" I responded, "I expected it to be merged yesterday." Everyone laughed.

Anyway, I have small branches that I start and submit the same day to merge, and branches that take weeks, and everything in between.

Linus is very adamant about it, on the grounds of readability:

https://www.kernel.org/doc/html/v4.1...ing-style.html
https://yarchive.net/comp/linux/coding_style.html

Linus might be old, but I don't consider him an "old dude" lol. And I'm in favor of 80 column sizes, because code doesn't wrap on tiled terminals. It's also enforced at where I work.