3 ms·
> Git hews too closely to immutable history Is it a bad thing? How can you have a consistent decentralized system without an immutable history? If you alter a
by GuB-42 3y ago
> Git hews too closely to immutable history
Is it a bad thing? How can you have a consistent decentralized system without an immutable history?
If you alter a commit, you create a branch, it may not be explicit, it may be called another name, but there is no way around it. An altered copy of any kind is effectively a branch. In the same way, if I take your modifications to put them in my own workspace, then it is effectively a merge, no matter how you call it.
And long as you allow clones or even just backups, the history is immutable whether you like it or not. Changing a commit on your server won't change it from everyone's computers and tape backups, the real history is there, somewhere and no review is going to change that.
Git simply makes all that explicit. The history is immutable (it is effectively a blockchain), and every change is a branch.
Note: while the git history is immutable, the branch names are not, so you can simulate rewriting history by creating a new branch with the altered commit, and giving it the original branch name. The original branch will then be nameless, and may be removed from the server if garbage collection is active, but it won't make it disappear as it can still be present in clones.
As for change ids, it is not about commits, it is about tickets, something that git doesn't take care of, but it can be done at a higher level. Git only tracks changes, it doesn't care about your workflow. This is what Gerrit, GitHub, GitLab, Bitbucket/Jira, etc... are for.
- barrkel 3y agoThe link between revisions of a commit is not explicit. Actually immutable history is fine, as long as all history is captured. But git doesn't capture all history, instead making revisions to an earlier commit is done by "rewriting" history and orphaning the older commits, instead of referencing them as earlier revisions of a persistent mutable-until-committed unit of change. The only git-native way to capture revisions is to use separate commits for every edit, and avoid squashing on merge. But then you have a history full of work-in-progress commits, which isn't great either - especially not great for git bisect. And separate commits still doesn't help with continuing work asynchronously while waiting for review to complete - you still need rebases, or merges (yet more weird history)...
- GuB-42 3y agoYou can make a separate commit for each edit, and do it in its own branch, and when you are done, you make a merge commit in the release branch, the release branch would be made only of merge commits, with a clean history and making git-bisect possible. Git is a little quirky with that kind of workflow because when you are making a merge commit, you don't really know which parent is which. There is a convention however, and it is that the first parent is the branch being merged on, and the others are the ones you merge from. Commands like git-bisect and git-log come with the --first-parent to avoid having your history polluted by broken work-in-progress commits. As for your asynchronous work, same thing, you can use merge commits, making sure the first parent is your work branch and using the --first-parent option to make sense of that mess. The weird history problem is just a UI problem, which is actually the worst part of git. Its core is solid, but its UI, especially the command line is a mess.