> Cool thing with bzr's approach: you don't loose history at all, B is > there, exactly the way I've written it. Bad thing: it makes the > history (unnecessarily) complex. Git's philosophy is usually to clean > up the history before including it in the main repository.
I'd just like to add that bzr's way of logging is tailored for this: it focuses on the left (merged-into) ancestor of a merge, either skipping the right (merged-in) ancestor entirely (which is now the default), or at least indenting it's log. In a branch of yours, this means your revisions will be most prominent; in mainline, this will make the merge commits most prominent. In git, I believe the general idea is that nobody is supposed to care what order a merge commit's parents are in -- this order is certainly not treated as relevant by many tools once the merge is committed. _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
