Martin Sandve Alnæs <[email protected]> writes:
> You can't use "merge" to get a single changeset in git
Well, you can use 'merge' to get one commit _if_ you already have the
ancestors of that commit. The identity of a commit includes its
ancestry, so if you want a commit _without_ its ancestry, you need to
rewrite the commit ('git cherry-pick' or 'git rebase'). This is why it
is good to start bug-fix topic branches at the oldest relevant state:
they can be merged to any more recent branch without other changes
beyond the bug fix.
> I guess this is why gitworkflows mandates all changes to be made in branches,
> which can then be cleanly merged into multiple places, making it clearer that
> the change has made its way into both next and master.
Yes, this way commits appear only once and can be merged to the maximum
number of places (if desired). Cherry-picking is not categorically bad,
but it's confusing to base your workflow on it because it leads to
multiple versions of the same commit, which is more confusing to audit.
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
