Valentin Buira via QGIS-Developer <[email protected]>
writes:
> So, now that I have presented cases where I think we would benefit
> from a more linear history, how do we reduce the noise to signal ratio
> in our git history? I think we should tend towards atomic commits.
I agree, but linear and atomic are separable concerns.
Long ago I ran a (non-open-source, at work) project and what we evolved
was:
- branch must be a logical feature
- each commit must be self contained (your "logical change")
- when changes are needed to any of the commits, we use --fixup= to
mark them and then rebase -i
So of course it's messy on the branch, and then with the rebase we
construct the branch as if the final state was intended and produced
from the beginning.
Then, we use a merge commit to bring these in, with the first parent the
previous commit on master, and the 2nd parent the commits on the branch.
The branch commits' first parent chain will also go back to that
previous commit on master.
So it's not really linear, but it's close. The point of the merge
commit is that the commits (which might be one) on the branch are
attributed to the authors who created them, and the merge commit is
attributed to the person who authorized the branch to be merged. That
merge commit also has "Fixes #123." as appropriate.
Part of our practice, different from most open source projects, was that
before the final merge we expected the rebase cleanup and a fresh test
run (thus tests passing on this minute's master plus the branch). A
branch off master from a month ago might still have no merge conflicts,
but the test result is not valid. This kind of non-linear history is
not only confusing but actually problematic.
Having used this workflow, I really like it. I find that in open
source, asking contributors to clean up their branches doesn't go so
well.
This is a somewhat long way of strongly agreeing with your core point of
not having messy branches, but pointing out that strict linear (not
having merges at all) and squashing are not necessary for clarity.
_______________________________________________
QGIS-Developer mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
