On Mon, Jun 22, 2020 at 7:51 AM Andreas Krey <a.k...@gmx.de> wrote: > > On Sun, 21 Jun 2020 17:53:49 +0000, Aaron B. wrote: > ... > > ...if it's not final, why is it called a "commit"? > > Commits in git are immutable - given the commit id you can even verify its > contents. But since they start their existence in your local repository > it's much easier to just drop them - undo the commit, and commit a > different set of changes instead. > > If git didn't offer this on itself (git commit --amend), you could just > tar your local repo beforehand, and restore it if you messed up a commit. > > So, commits are final in that you cannot change them, but they can be > forgotten, so you can fix mistakes after an accidental commit.
git follows a snapshot like approach to version control. but this view of history bites you as can be seen in "merge commits". requiring "rebasing" things and actually "rewriting history". this is what i dislike about the design of git. it is just a hash based object store. maybe that's the reason why the cli is cluttered with lots of details. merge commits call for trouble and for rebase, this is why i consider the design of git as VCS broken at best. another approach e.g. is using a partial order of patches as utilized by darcs, or pijul. an example on the difference of darcs vs git can be found there: https://darcsbook.acmelabs.space/chapter01.html#why-darcs unfortunately you can run into computational complexity issues which are kind of relaxed in dacrcs v2 if i'm correct. i wish they had written darcs in idiomatic straight line c/c++. haskell, and in case of pijul rust are kind of show stoppers for me. i routinely run into issues with git when using it in the advocated "decentralized" manner. but this is probably my fault. best, al3x.