Julia Evans (@b0rk@jvns.ca)
social.jvns.ca
i've been trying to figure out why some people prefer merge and some people prefer rebase. I feel like there must be some systematic reasons, like "people in situation X tend to prefer rebase, people in situation Y tend to prefer merge” my only thought so far is that small short-lived changes work well with rebase, and longer-lived branches are maybe better to merge (not looking for why you think rebase/merge is better here or why the people who disagree with you are wrong) (1/?)

Julia Evans (@b0rk@jvns.ca) writes:

i’ve been trying to figure out why some people prefer merge and some people prefer rebase. I feel like there must be some systematic reasons, like "people in situation X tend to prefer rebase, people in situation Y tend to prefer merge”

my only thought so far is that small short-lived changes work well with rebase, and longer-lived branches are maybe better to merge

(not looking for why you think rebase/merge is better here or why the people who disagree with you are wrong)

similarly, I’m trying to figure out why some folks prefer a linear commit history and some folks prefer to preserve the history as it actually happened

I feel like there are also some systematic reasons for this (like in situation X a linear history is more appropriate but in situation Y it’s more appropriate to preserve what actually happened) but I haven’t worked it out

for example maybe “preserve what actually happened” is more appropriate for open source projects? not sure.

  • Ferk@kbin.social
    4·
    11 months ago

    Then check-out their due date, specially if they have been left out in a stack for too long, before you pop one out.