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. Usually, you configure your central, 'blessed', repo so that you cannot drop commits there, and only add new ones, but this is a choice you make, and not something built into git itself. Example: Our integrators take pull requests (that have run their tests individually, of cource), and merge a set of those locally, without making the result visible to the dev population yet. Run tests on the result, and, since feature interaction is a thing, sometimes these tests break. In that case they drop the merge commits, and try with a different set of pull requests, and the original set gets lost. You can do this model in svn if you create a temporary branch for these integrations each time, and, after a successful build, merge that into trunk. Likewise, you *can* 'amend' a commit in svn by creating a new branch from the revision before, commit on that, delete the old branch and move the new branch to the old name. But it's so unwieldy that nobody bothers, the mergeinfo properties may quite probably bite you, and there is no usable way to visualize the result anyway, even with 'git svn'. And of course, in svn these antics stay in the revision history. Unless you manipulate the server. - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
