undefined | Better HN

0 pointsjonstewart3y ago0 comments

I once interviewed a junior-ish developer who told me that his then-current team had a dunce cap to be worn by whomever broke the build. I copied it immediately. There was no toxicity, it was a good laugh, and as manager I wore it more than once being a bit too liberal with my commits.

On another team I was on, in 2002 using CVS, we had an upside-down solo cup as a base for a small plastic pirate flag. If you were ready to commit, you grabbed the pirate flag as a mutex on the CVS server. Of course, this turned competitive… and piratical.

I despair about long-lived git feature branches and pull requests. The pull request model is fine for open source development, but it’s been a move backwards for internal development, from having a central trunk that a team commits to several times a day. The compensating factors are git’s overall improvements (in speed and in principled approach to being a content addressable filesystem) and all of the fantastic improvements in linters and static analysis tools, and in devops pipelines.

0 comments

7 comments · 2 top-level

thunky3y ago· 4 in thread

> I despair about long-lived git feature branches and pull requests

This comes up a lot - multiple people on this thread have even said that it's a bad idea to have a long running feature branch.

This seems like a case of the tool imposing it's will on workflows, rather than enabling them. Not all features are tiny. I don't see anything wrong with a long lived branch if the feature is in fact large. After all it may be completely redesigned multiple times over before being merged into the main branch. Or it may never make it.

And no I don't think it always works to break down a large feature into smaller ones, because your course may change as you go, and it's much easier not to have to revert incremental features when it does.

But people are so worried about having a perfect history. So they rebase. But if it's a long lived (shared) branch you don't want to do that. So now what? A merge would be ugly, can't do that. So now you've painted yourself in a corner for no good reason.

mook3y ago

A long lived branch was a pain even in the CVS days. I'm in particular thinking about the "aviary" branch (for Phoenix/Thunderbird) Mozilla had for quite a while.

Of course tooling can make it harder — there was no such thing as rebasing on CVS.

geon3y ago

A long lived feature branch is not a problem if you rebase it to master often. Move all refactoring to the beginning of the branch and merge them to master if they become too many.

thunky3y ago

> A long lived feature branch is not a problem if you rebase it to master often.

Yes but if it's a shared branch then you may have problems with this.

The safer way is to merge from master into the branch but nobody wants to do that because it's ugly.

1 more reply

rocqua3y ago

Can one merge master into tye feature branch often, and then interactive-rebase onto master removing all the merges?

Sohcahtoa823y ago· 1 in thread

> The pull request model is fine for open source development, but it’s been a move backwards for internal development

The more paranoid would claim that requiring PRs that then require approvals prevents a malicious engineer from adding an obvious back door to the code.

You would hope you can trust your co-workers, but sometimes a hack is an inside job.

jonstewartOP3y ago

There are all sorts of workflows that can be arranged to prevent that while still having optimistic continuous integration on trunk.

j / k navigate · click thread line to collapse