11
soull00t
121d

what a garbage day. i've spent almost the whole day merging shit and the rest was meetings (also talking about how i merge shit).

dear fucked up branching strategy, when I look at the torn beauty of your mutated stream graph that carries the taint of corruption, depictions of feculent gnarlmaws come to my mind:

"These disgusting trees ring with the sorrowful tolling of entropic chimes, belch clouds of daemonic spores, and shed rot-wet blossom to carpet the maggot-churned earth beneath their boughs. The few stunted branches that grow from it feature dismal bells, tentacles and more pustulent boils."

Comments
  • 0
    Apart from the beautiful yet verbose poetry, would you explain what went wrong with merging?
  • 1
    @asgs the first thing is that we have different product lines that have diverged from the main branch over the years and each new release will result in a new branch that is just branched from the prior release of that branch. so some lines haven't been on sync with main for years. merging changes from these lines to the main branch are kind of a thing, but not always. merging changes from main to these branches even less. there is no consistent strategy. the thing is that merging changes to another line, depending on the scope of these changes, might create the necessity for extensive regression tests, and so people decide not to do it, because it is too expensive to test. (you would have to run all tests for the 1st branch and then also for the 2nd branch). this will result in branches growing apart even more. also, some people use main as a garbage dump they just blindly merge their stuff into.
  • 1
    we need to maintain the same (or rather "kinda the same") features in different lines and often, on a smaller scale, noone really has an overview of what exactly exists in which line...
    when i merge changes from a release branch to main, files might be so far apart that i first need to study histories of files of both lines and also to some extent "understand" differences between files to reduce the probability that i destroy anything, which can be really time-consuming. it is not really save to say "it will be fine if there are no merge conflicts"... anyway, this doesn't stop people from working exactly this way. then, sometimes you don't know if people have forgotten to merge their stuff or if lines shall really work that differently. it's time consuming to play sherlock holmes all the time when all you wanna do is to merge your changes for a feature to another branch...
  • 1
    a colleague told me today i'm too sceptical, but the truth is, there is no guarantee that if everything builds, changes will be fine, everything will still work and nothing has been destroyed or corrupted... guess i have to live with the uncertainty.
    the good thing is that it will also take a while until somebody notices that something isn't working anymore, so I can lean back and work on other stuff in the meantime. /s
  • 1
    Reason why deprecation and maintaining a very small set of supported versions is better than trying to support a vast multiverse of versions....

    It would be marvelous if this would be a universal law.
  • 1
    It.is ridiculous to hear that main branch is a garbage dump yard. It is no main then. It is just an orphanized parent with no "meaningful" relationship to its dependents

    Plus the release branches should be cut from the so-called main branches in the first place and the back merging is only done to save the additional fixed that came through while regression testing unearthed a few bugs in staging or pre-prod

    Without this setup, one can never be sure what is what and which one works when. It is absolutely reasonable for you to stay pessimistic and skeptical in this case
Add Comment