i don't think i've had that confusion ... whenever i rebase i always make sure that i tag/copy the current branch though, so that i can go back and try again when the rebase screws up (because there were merge-commits with changes or similar)

I think I am confused because it switches position when you rebase vs when you merge

so I can never remember which is which :S

Yes! So much this!

oh wow - i had never noticed that... tbh i have only used the auto-resolve strategies once or twice ever - i mostly page through conflicts manually with magit

it's as if ours and theirs always mean the reverse thing you would expect, even if you would take that into account

Yes!

Git's law

Same with ln -s until someone told me it's analogous to cp old new

That's a good rule of thumb

vscode uses "current" and "incoming" which kinda feels natural for both merge and rebase. i don't use vscode though 🙃

I think my mental model is “The stuff that I want to rebase onto is the tree trunk, ‘our base’/`ours`, and the stuff that I want to rebase is the branch, ‘it’/`theirs`“. I even visualise it with a tree and a branch. But I’m unsure if I’m even remembering it right.

My aide-memorie is when I do a rebase, I imagine all my commits just flying off into the ether, somewhere in a holding pattern, then the point from when I branched from is brought up to date with whatever I'm rebasing from (normally master), then my commits come into land on top of the rebase afterwards.

@U0AQ3HP9U that’s wrong

you’re thinking of merge

hahaha great

that’s the issue, it is the other way around depending on rebase and merge for no obvious reason 😛

I refer to Git’s Law 😛

hehe

It’s such a shame that the git ux is generally confusing

git is a great tool with bad ux, same with the Clojure CLI really 😛

Stockholm syndrome. Yes Linus is Swedish.

Self-blaming energy is strong in this 🧵

Unlike others I think git is genuinely terrible

Swedish-speaking*, not Swedish

what do you prefer instead, @U04V5V0V4 ? Tbh I've tried little else

ha - I'm just complaining cos I'm hoping that git is not the end of code version tools

I’m finding it hard to imagine that anything else will take the lead within our careers, but of course, there’s always room for improvement 🙂

i would think something else would need a model which was much superior to git's ... in the way that git's model is superior to subversion, CVS &c ... aiui git's model wasn't particularly original (following in the footsteps of bitkeeper), although its implementation was, but is there even any newer/different model of revision control which is better than git's ?

for me, semantic awareness will be big

I think there are a few. I went from mercurial to git (simply because I had to, due to external demands). I really liked mercurial. I think also there is something in "fossil" that is intersting - unlike git - you can never ever rewrite history.

i seem to recall using hg once or twice... it's got a very similar model to git doesn't it @U11EL3P9U ?

(For a brief stint in my career I even had to use IBM Rational Clearcase - now that was the worse version control system I had ever used - and I've used CVS 🙂 )

Yeah, hg and git paradoxially were created at roughly the same time by different people. Git just gained more traction because the author was more famous 🙂

I would like to try out fossil more

what dyu mean by rewriting history in git @U11EL3P9U? you can write a new history (and point a branch at the new history), but you can't rewrite history - can you ?

yah, easily. Any rebase rewrites history (commit hashes change) also nothing stopping you from doing a force push

I can check out the codebase, force reset to an eariler part in time, modify some code, force push it

rebase creates new commits - it doesn't change any existing commits - and a force-push just changes the branch pointer - all the old commits are still there and can be reverted to

but changing the branch-pointer is definitely more "rewrite" like than a merge...

Git is ntorious for the ease on which you can rewrite history. There are numerous articles (even on the official scm book) on rewriting git history

For example, even if you do a force push and even if you think you can get to it via the prior SHA1, if you force a garbage collection using fsck, then poof gone.

true - garbage collection can mess your life up! what does fossil do differently ?

Not quite sure of the internals of fossil, but that question I believe is answered here: 2.7 What you should have done vs. What you actually did from the link

ah, so - primarily fossil gets rid of rebasing and squashing, which i guess leaves a pure merge-based workflow

I would seriously consider switching to fossil for some of my stuff that I do

but one thing that I would need to sort out - which github/lab gives you - is a build pipeline.

natch, I could cobble something together to perform a pipeline on commits, but I'm too lazy 🙂