On 5/17/2016 12:54 PM, Ron W wrote: > On Tue, May 17, 2016 at 4:21 AM, Andy Goth <andrew.m.g...@gmail.com > <mailto: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.
That's actually good news. It means I don't have to feel bad about not having a foolproof heuristic. (Contradiction in terms, I know.) I'll have to think about how to mechanize the user specifying which contributors to keep and which to disregard as noise. One consideration is what the default behavior should be. When another branch was merged with -integrate, that's a pretty good indication it should be included. However, half the time I forget to use -integrate and instead close the branch manually sometime later. So the test should be whether a close event happened between the merge and the next (if any) check-in on the branch (could have been reopened). Backing up a step, I think this automatic behavior should be optional, though the question is whether the option would be to enable it or disable it. The next consideration is whether or not the list of inclusions and exclusions should be finalized when the merge command is run. They would be command-line options, of course, but I'm wondering if there should also be commands that can be run later to amend the list of inclusions and exclusions. The trouble with that is the success of the result may depend on the order of operations, so each amendment might trigger backing out and rerunning the entire merge, which will wreak havoc with any conflicts that were in the process of being resolved, including conflicts with edits that were made prior to commanding the merge in the first place. Maybe undo is good enough, but I don't know. > The core devs never said anything about my changes being only single > commits. Possibly git limitations meant they couldn't tell the difference, haha. Actually I mean that two ways. One, git might not have made it clear one way or the other, or perhaps it even loses track of the distinction. Two, the git model may have compromised its users' thought processes to the point where they don't realize they're missing anything, basically a combination of Sapir-Whorf and Stockholm Syndrome. -- Andy Goth | <andrew.m.goth/at/gmail/dot/com>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
