On Tue, May 17, 2016 at 4:21 AM, Andy Goth <andrew.m.g...@gmail.com> wrote: > > So what would a Fossil analogue be? For simple cases, merge -baseline > root:branch does the trick. > > But if the branch being merged also includes merges from other branches > for the purpose of updating its baseline, those merges need to be backed > out as well. > > Yet there could be other merges into the branch that need to be kept > since they're coming from other branches that themselves will never be > merged into the target of the first merge. > > How to distinguish between the last two cases?
I don't think git rebase automates this. As best I've been able to discern, it automates certain types of sequential merges to help in relocating a branch from one baseline to another. The hard work of determining what to back out and/or cherry pick still requires a lot of human direction. However, I've never actually had to use rebase, The projects I've contributed to that use git have only asked me to rebase against trunk (what git users call "master"). For the changes I did, All I had to do was update trunk from git, merge truck to my branch (which I did in Fossil (or SVN before I discovered Fossil)), then either make a patch against trunk or do a git merge to trunk, push to my repo on github and make a pull request. The core devs never said anything about my changes being only single commits.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
