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.

https://wizardzines.com/comics/head-and-heads/ - source

https://wizardzines.com/comics/meet-the-branch/ - source

https://wizardzines.com/comics/every-git-command/ Not OC

CC @ubernauten

Meine (nicht-öffentliche) Nextcloud und bald bestimmt mehr ist auf (A)steroiden, cause proudly hosted by uberspace.de. (Steroide sind natürlich nur für Maschinen OK, und auch nur so lange, wie sie sich nicht gewerkschaftlich organisieren, wie bei Stanislav Lem.)

Außerdem nutze ich @writefreely, @WordPress, @Codeberg,@cryptpad,#searx, @mxlinux,@keepassxc,#vnc+#ssh,@git,#gittfs,#gitcrypt,@libreoffice,#clawsmail, @librewolf@chaos.social,@librewolf@lemmy.ml,@fdroidorg,@libretube,@AntennaPod,#opencamera,@anysoftkeyboard,#quickdic,#transportr,@torproject,@signalapp,#jitsi,@Tusky,#mgit,#markor,#PilfershushJammer,#fosswarn,#vlc,#doublecmd,#powershell,#autohotkey,#xca,#openssl,#zapp,@privacybrowser,#UntrackMe,@veracrypt,#AuthPass,@newpipe,#radiodroid,#edslite,#SecScanQR,#sqlitedbbrowser,#avnc,@k9mail,openstreetmap.org,inv.nadeko.net,u.V.m., überhaupt privat fast nur und im Job so viel wie geht #floss , im Netz und lokal.

–––

Warum FLOSS? U.A. deshalb:

KI – Macht – Ungleichheit. https://media.ccc.de/v/ce4743cc-50ad-4597-bcc8-58e1a7e53c20

So I've just learned that git rebase -i allows users to merge individual commits in the middle of a branch's history. For that,

$ git rebase -i

This should bring a list of all commits in reverse order, similar to the one listed below:

pick 2361d4d implements something
pick a700451 fixes a bug
pick 79f9d04 fixes a bug again
pick 3172f07 implements some other thing

# Rebase 484d6d2..3172f07 onto 484d6d2 (4 commands)
#
# Commands:
# p, pick  = use commit
# r, reword  = use commit, but edit the commit message
# e, edit  = use commit, but stop for amending
# s, squash  = use commit, but meld into previous commit
# f, fixup [-C | -c]  = like "squash" but keep only the previous
#                    commit's log message, unless -C is used, in which case
#                    keep only this commit's message; -c is same as -C but
#                    opens the editor
# x, exec  = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop  = remove commit
# l, label  = label current HEAD with a name
# t, reset  = reset HEAD to a label
# m, merge [-C  | -c ]  [# ]

It's possible to merge commit 79f9d04 with a700451 by updating the list of commands to set squash instead of pick in the commit you want to flatten onto the previous one, such as:

pick 2361d4d implements something
pick a700451 fixes a bug
squash 79f9d04 fixes a bug again
pick 3172f07 implements some other thing

(...)

Once we save the commit, Git opens an editor to rework the new commit message for the squashed commits, and you're set.