I'd rather not have it directly linked to my rl name here as who knows wtf I've said and you inexplicably can't delete your posts. But current game is an adaptation of a hidden role board game that came out in 2016.

The commit history ime is the thing you don't need until you do.

I think I probably know which one that is.

A friend of mine is waaaaay into board games - I just play occasionally. We're talking he has 40 games he's bought and hasn't played yet. Anyway one we played recently was "Food Chain Magnate" which we all liked.

There's a lot of tedious house keeping though, there's a phase of the game that is just awful. He wanted to write a computerized version, preferably something where each player had their own client (a tablet probably). I don't think he's made any movement on it and I kind of want to work on it myself. Not sure how long to wait to make that kind of not a dick move.

Every now and then I kick around the idea of making a gaming table with a frosted glass surface, with a projector(s) beneath it, and cameras beneath it. Cameras could read board pieces and values and essentially you could play most games "normally" but the board would be digitally projected and all the scoring etc would be automatic.

BaltimoreJones and I went to a boot camp where tuition was based on and paid out of your first year's salary.

The model was great, I wouldn't have been able to afford boot camp without it. At the time it was like 17%. I think the rate for the same place now is in the 20s. It used to be pay over 6 months so those payments were pretty painful but with the higher rate I think they've spread things out.

The genius (not really) of my server code is that all games are just a giant json blob in a games array and on every update it clonedeeps the game, copies over all the player's private info that is only for that player's client, deletes the top level "private" object and then emits the game to all websockets subscribed to that "room". Pretty much how I'd imagine any other game would work.

Yeah that sounds pretty reasonable. I've made network code for several board and card games but that was all in the distant past. Bytes were a little more in demand so clients sent "actions" to the server and got what amounted to diffs to game state in return. All the communication was numbered so if you missed an update you'd know and could re-request it.

The biggest obstacle for me is that I don't really know any JS frameworks well (I've worked with react a little) and my HTML/CSS is waaaaay out of date.

its still there locally with a git reflog. but do you merge commits individually? or as part of a cohesive pull request?

like, lets say I am working on a feature. its pretty simple, say a button that sends some data.

so I make a new branch and I start working. I am a new dev or whatever but I dont do stashes or anything bc whatever. so heres my commit history.

-temp commit. needed to switch branches to check something.
-Boom, got the button on the screen YES!
-temp commit. changed branch to help Jeff.
-Sweet, got the data. still need to send it properly.
-Score! sending data now. WE are good.
-Fix all the unit tests

Ok, now I submit a PR. Why do I need all of those commits in the PR?

anyway, PR is up and obv there is feedback and I fix stuff and sometimes I miss the fdescrib or fit and or some other little thing and need to make a new commit.

-addressed feedback 1.
-oops forgot unit tests.
-addressed more feedback.
-on and on.

anway, I am saying that for each PR, it seems there should only be a single commit. more importantly, for each PR, there should only be a single merge.

Hah, someone already made an online version of food chain magnate, although I doubt it's quite what I'd want - my goal is really to have people playing in the same room together, just with the busywork taken care of.
http://play.boardgamecore.net/

I've been doing this for awhile, and I really don't think I've ever needed a cleaned up version of the commit history (or even felt like the "messy" commit history was slowing me down).

PRs give a lot of context. Blame tells me who I should be talking to and the commit that mattered. And you still have the actual commit message for that commit.

Victor, I get that. But I was mostly curious how painful people felt the history with:

-temp commit. needed to switch branches to check something.
-Boom, got the button on the screen YES!
-temp commit. changed branch to help Jeff.
-Sweet, got the data. still need to send it properly.
-Score! sending data now. WE are good.
-Fix all the unit tests
-addressed feedback 1.
-oops forgot unit tests.
-addressed more feedback.
-on and on.

It doesn't feel horrible to me. And with Github at least you can do the squash seemlessly with the merging of a PR (which is what I typically do now).

We squash merge PRs but I never do any squashing/rebasing/amending of commits in my working branch, or elsewhere for that matter. Seems fine? I don't have a strong opinion either way, but our squash merge commits will just about always include a JIRA ticket number, and having there be one commit associated with a PR and a ticket number is sometimes useful for me when I'm trying to understand what happened. It's the PR that gets reviewed and against which CI gets run, and I generally don't care about having more granularity than that when looking for commits.

I like seeing the commit history because it tells me a story of how the feature was built/how the dev thinks/ the general strategy and steps taken.

Having that history is a positive. Not having it doesn't help anything imo.

So I just think it's a benefit with no downsides and squashing all commits into one PR is not as beneficial.

But 99% of what i/we do is on a PR and like well named we have a Jira ticket in the commit that gets linked so you can go through historical/contextual info.

I dont like it mainly bc it makes it very annoying to see the changes associated with that PR.

I will often git checkout a commit associated with a PR and then soft undo a commit to see the changes they made and play with it. if there are multiple commits that would be annoying as hell.

and I have fixed multiple bugs this way.

it's definitely easier to look at a single squashed commit (one commit per pull request) then to have go back and look through 20 commits to find something.

for example, say that i notice a bug in a form. i want to be able to look at the full PR that went with building/changing the form so that I can see what the full story of what the goal was in building/changing the form - that makes it easier to debug. otherwise i might change it back/from A to B, not realizing why they changed it to B (even if there is still a bug associated with it being B).

I don't see any benefit to having multiple commits per pull request and it suggests that you probably need to break up your pull requests.

How were they going to enforce that you pay them and keep track of whether you actually got a job a or not?

Also is it for one year after boot camp or one full year of employment? Guessing the latter.

There's a contract and a smallish deposit. Beyond that collections agencies and civil suits.
Yeah I think you didn't pay anything if you performed a good faith search (which they monitored) and didn't land a job within a year. But yeah if on day 364 you landed a job for 100k/year you owed them 17k and it was expected to be paid over your first 6 months working

So when I get close to 1 year I just wait to accept a job until day 366?

I mean sure, if you can go a year applying to jobs, taking interviews, etc nearly full time with no income and you just happen to get an off on day 366 then I guess you "win".

The incentives are generally pretty well aligned. And I've seen the founders admit to various edge cases where their model could be exploited. But for the most part people that attend want/need jobs and will find one within the time limit.

There is another bootcamp that pays students $10/hr to learn then they repay 20% for 2 years.

Commit history: this isn't a strong opinion, but clean up your commits before you put it into PR.
1. Your coworkers who are reviewing it don't care about your intermediate workflow steps when you worked on it, so present it to them as one commit (or for larger changes, I'll re-write my work into multiple commits, where each commit accomplishes one specific thing or has one specific logical grouping of code, for easier review)
2. It gives you a chance to write a commit message for your PR that describes your change/code for your PR audience, which will persist in the commit history when people look back on that commit in the future and are like "what is this doing"; plus, when you submit the PR, your well-written commit description is already filled in for you in the PR title/description

I think what matters for the purpose of code review is the result, not the process.

For an extreme example of #1, earlier this year I landed a large and complicated change that involved
- writing a code generation tool (like protobuf kinda)
- adding tests for it
- integrating it into our build system
- adding files to generate code
- writing some Go stuff that would depend on the generated code

I split it into about 9 commits, each of which did a distinct logical piece of the overall work, and told 3-4 different coworkers who were familiar with different parts of this stuff "hey, could you look at commits 1 and 4" (or 8 and 9, or whatever). By rewriting the commit history, people could look at the commits that dealt with areas they were familiar with and could safely ignore everything else, and I could take the commits that were basically just copying files/checking in generated code or whatever and tell everyone to ignore them (thus avoiding everyone's favorite kind of PR review, the kind with thousands of lines of boilerplate repetition to scroll through). Everyone reviewing that PR essentially got to look at the most minimal and relevant diff possible, which is a huge win for the rest of your team.

Submitting a PR like that with whatever commits you happened to make on your working branch and no cleanup? Good lord, what torture for your coworkers that would be.

Instead of organizing the commits and then asking reviewers to focus on only a few specific commits within one large PR, we'd typically just break it up into multiple PRs. Although I think the way you're suggesting has at least one potential advantage I can think of: no problem with coordinating merging multiple PRs at the same time to end up in a good final state.

ya we would break it up into multiple PR but not sure it matters.

another thing that I prefer is that during a PR, when addressing feedback, commit those separate from the initial commit. then squash everything right before you merge.

Yeah, gotta agree that separate PRs are the way to go with releases in between. Obviously lots depends on your specific build/release processes and tooling.

In this example feels like it could easily be:

- tooling + tests for generating code
- integrate into build system
- add newly generated code
- switch to using the new code

Maybe combining the last two depending on things like your scale and what types of releases you do.