this post was submitted on 23 Nov 2023
219 points (96.2% liked)

Programmer Humor

32721 readers
395 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] wisplike_sustainer@suppo.fi 26 points 1 year ago (1 children)

I almost got a bingo by checking off things I've muttered to myself.

[–] xmunk@sh.itjust.works 8 points 1 year ago (2 children)

I would've... but mercurial isn't better.

As an aside, stop merging into in-progress private branches.... it makes the absolute worst conflicts.

[–] Dirk@lemmy.ml 2 points 1 year ago

[rebase needed]

[–] steph@lemmy.clueware.org 0 points 1 year ago* (last edited 1 year ago) (1 children)

I've had that kind of reaction - on rebases also - and most times it was in fact a code smell pointing to a case of spaghetti code.

If you get to the point that you fear upstream merges/rebases into your WIP, stop for a second and ask yourself if maybe that might be an issue with too much interpendencies inside the code itself. Code should be as close to an directed acrylic graph as possible. (doesn't count, I was not speaking of git! :b )

[–] eclectic_electron@sh.itjust.works 2 points 1 year ago (1 children)

What's your workflow that merging into other people's WIP is normal? I'm so confused

[–] steph@lemmy.clueware.org 2 points 1 year ago

A merge from upstream once a day, at the beginning of the day.

I'm working on a DevOps setting, and even though we're a small team, we have about two to three changes going through the pipeline a day.

If you keep your fork too long without syncing, it just get more complicated to merge, and more importantly if you need help from the upstream change author they'll have moved on to another subject and the change won't be as fresh in their mind as if you had merged the day after they pushed it.