As discussed previously, for some people rebase is the killer feature that makes git worthwhile. Yet we don't have it in Fossil, not with that name anyway. I admit my understanding of rebase is very limited, never having used git. But I gather it distills a branch down to the changes actually performed on that branch, not including merge contributors done for the purpose of updating its baseline, then plonks those changes on top of a new baseline as if that's where it started from in the first place.
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? One possible heuristic is to check whether or not the merge is coming from a closed leaf, though of course this is not guaranteed to be correct. So, how does this stack up against git rebase? Not ever having used git, let alone git rebase, I can't say. But this algorithm does work for me in my situation. If this algorithm were to be automated as a new merge type, what would the option be? "merge -rebase" doesn't satisfy me because (as far as I know) git rebasing is different than Fossil merging in that it operates on a branch rather than the current checkout. Perhaps "merge -isolate" because it isolates the changes made on the branch from the changes merged into the branch (while still keeping those integrated into the branch with -integrate). First, a little review. A multi-argument P-card signifies a vanilla merge, and it affects the baseline identification algorithm of future merges. Q-cards signify cherrypick and backout merges, denoted by use of "+" or "-", but they don't currently affect anything, not even the timeline display. How would an isolation merge Q-card look in the manifest? I suggest tagging it with "!" which resembles an "i" for isolation, and also resembles a vertical line with a hole in it, pictorially indicating a single branch but skipping a few things. Then of course follow the "!" with the check-in that was merged from. I'd like to say that if we decide to go with the "closed" heuristic I describe above, it's not necessary for the isolate Q-card to also identify which contributors to that branch were kept or backed out since Fossil can figure out which branches were opened and closed at the time the merge was performed. But that's actually not true since it's possible to close and open branches between performing the isolation merge and performing the actual check-in. So instead list the included merges too. (Or list the excluded merges. Or list both, preceded by "+" and "-". Just pick a convention and stick with it.) Here's a graphical example. G | .--->F |---->E<-. | | | D-' C | | | B--' | A--'-----' E was made by checking out B, merging C, integrating D (i.e. D is closed), then checking in on a branch. F was made by checking out D, doing an isolation merge of E, then checking in on another branch (since D is closed). F's manifest reads in part, where E and D are replaced with the 40-character artifact IDs of same: Q !E D meaning that it isolation-merges E, backs out C, but does not back out D. F includes the diff from B to E minus the diff from A to C. An alternate, backward-compatible approach would be using multiple cherrypick and backout Q-cards. In the above case, this would be: Q +E B Q -C A What would an isolation Q-card do? Probably nothing. If cherrypick and backout Q-cards do nothing, neither should isolation Q-cards. How should it be displayed? Other Q-cards aren't displayed, but that is something I definitely would like to see changed. I previously proposed using different colors, arrowheads, and dash patterns for cherrypicks and backouts. This idea could be extended, but I can't imagine a sensible way to graphically show inclusion or exclusion of contributors to the branch being merged. So I'm going to default to not showing that since the user can make a good guess based on which are opened and closed. By the way, until now I never considered the possibility of a range of versions being included in the cherrypick/backout merge, and I have no idea how how to show the range. Again I guess it's better to not try. It's very late, and I have a plane to catch tomorrow, so those are all the thoughts I can squeeze out for one night. -- 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
