Re: [fossil-users] git rebase, and what it looks like in Fossil

[Andy Goth]

On 5/17/2016 12:54 PM, Ron W wrote:
> On Tue, May 17, 2016 at 4:21 AM, Andy Goth  > 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 | 



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

Re: [fossil-users] git rebase, and what it looks like in Fossil

[Ron W]

On Tue, May 17, 2016 at 4:21 AM, Andy Goth  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

[fossil-users] git rebase, and what it looks like in Fossil

[Andy Goth]

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 | 



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