[klodolph]

If Git were purely functional, you would expect rebase not to modify the existing data in any way, and indeed that is exactly what happens. You can create, delete, or modify only the top-level pointers: branch names, reflog, etc. Instead, rebase creates a completely new set of commits, and points the current branch at a new one. This is exactly how functional data structures work in e.g. Haskell, where "inserting" an element into a dictionary means that you get a new copy of the dictionary, and all existing references to the original are unmodified.

[_0w8t]

Git rebase alters the structures that are relevant for me, like heads of named branches. In Haskell let bindings are immutable. To reference to the results one has to put them into new bindings. I.e. if Git was purely functional, the rebase would create new names for branches.

[tathougies]

You can easily shadow a name in a let binding in Haskell

For example,

let x = 5 in let x = 6 in putStrLn (show x)

would print 6. Unless you turn on compiler warnings, there is never a need to choose new names for variables if the old version is no longer needed.

[catnaroek]

Shadowing isn't the same thing as redefining. Try evaluating the following expression:

    let x = 4 ; f y = x + y in let x = 6 in f 10

[rootlocus]

If you want immutable branches, you can use tags https://git-scm.com/book/en/v2/Git-Basics-Tagging

[masklinn]

> In Haskell let bindings are immutable.

Haskell has mutable refs. That's what Git branches are.

[catnaroek]

But the contents of a mutable ref aren't let-bound.

[fiatjaf]

So your entire point amounts to naming?