Geert Janssens <[email protected]> writes:
>> One more note on that: E may very well end up looking nothing like D
>> because B-C may have been enough of a change that a different
>> approach is required, but it's still necessary for it to be a
>> multi-parent commit.
>>
> Absolutely. The extreme case being if commit D is not even wanted on
> the trunk branch (like a product version number increase for
> example). It would still have to be merged. You could choose to do it
> on commit D, resulting in an empty commit with two parents, or you can
> wait for commit H, and make sure the changes from commit D are
> reverted during the later merge.
This is going to be important as we make new stable releases. We're not
going to want the e.g. 2.6.0 -> 2.6.1 -> 2.6.2 commits to merge back
into trunk. So when the branches are merged after stable releases these
commits will need to be omitted (or reverted) during the merge.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[email protected] PGP key available
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
