3 ms·

The 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 hist

The 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 ago
You 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.

GuB-42 3y ago

You 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.