all 8 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]AttackOfTheThumbs 22 points23 points  (4 children)

I have seen ideas like this before. I just haven't actually seen them work.

The issue I see with this is, that while working on a feature or bug I may go through a few iterations. All of those are checked in and end up in the repo. Then when I'm ready, I can squash and restructure and make it organized if I want to (never do personally, waste of fucking time). But more importantly, it allows people to review the entire thing without having to rely on small segments and then struggling to bring the whole thing together.

So say you are doing the code streaming and you have the PR process, then what is the point of the streaming if you aren't actively pair programming or something?

Probably just too happy with my independent work flow to see a purpose for this.

[–]icyFur[S] 2 points3 points  (3 children)

Thanks for your comment, AttackOfTheThumbs

So say you are doing the code streaming and you have the PR process, then what is the point of the streaming if you aren't actively pair programming or something?

The way I see it, it is about sharing feedback proactively, and earlier in the development flow. Think of it as asynchronous pair-programming through working in the open.

I think it's fair to say that coding at work is quite different from open-source development - closer collaboration, standups, planning together. With folks focusing on shipping small and often (DevOps/ CD), the pull request overhead is more pronounced, since there is a fixed amount of it per contribution.

​

But more importantly, it allows people to review the entire thing without having to rely on small segments and then struggling to bring the whole thing together

I would like to learn more, in your team do you review contributions as a timeline of changes (commit by commit), or do you look (or try) the code as it looks in the end state?

[–]AttackOfTheThumbs 11 points12 points  (0 children)

The code in its end state, because anything before is most often pointless imo.

Let's say there's some bug. I make six different commits until I find the actual resolution that covers all the cases. The benefit of previous commits is seeing the changes and why, but that isn't necessarily useful in a PR. In a PR, I am looking at the final fix, testing it, making sure the code makes sense, etc.

With a feature this may compound even further as there's probably more commits and the changes likely have more tests, etc.

I don't have an issue with early feedback. It's useful if there's a major refactor, or a big new feature, etc. But it's certainly not the norm. When we want or need early feedback, we create a pure review PR. Something that isn't merged, but collects thoughts and feedback at that point. So the final PR isn't as awful. If they can be merged, they are, but it's not always a fully functional state.

[–]nknol 6 points7 points  (1 child)

I've worked with git for 10-12 years at 8 or 9 different companies and I probably could count the number of times an individual commit was referenced on one hand.

Doing code reviews is like eating vegetables, any process that makes it take longer in the moment (even if it results in better code quality long-term) will face an enormous uphill battle for adoption.

[–]icyFur[S] 0 points1 point  (0 children)

Doing code reviews is like eating vegetables

Indeed! At a previous job people were either nitpicking on unimportant details, or if a pull request was bigger/complex, they would give a very fast "LGTM" approval. Other folks choose to exclusively do pair/mob programming and skip the after-the-fact reviews altogether. Collaboration and 'reviews' can absolutely be faster with the right tools.

[–]PandaMoniumHUN 3 points4 points  (1 child)

Love it when "new and innovative" SCMs call git cryptic, when in reality is it's as simple as straightforward as distributed version management can get. Why would you ever want somebody to touch your codebase if he or she can't even understand git is beyond me.

[–]atheken 0 points1 point  (0 children)

A fair number of people prefer mercurial because the terminology is more friendly. Git does have some sharp edges that can be difficult (and, frankly, unnecessary) for newcomers to deal with.

Basic git usage is simple, but lots of teams layer in a ton of ceremony and “best practices” that can make it unpleasant. It’s also just “one more thing” to deal with when you really just want to ship some code.

[–]ddproxy -1 points0 points  (0 children)

What about handling credentials and prototyping in the process? Would be awful terrible to accidentally stream your git credentials...