I would appreciate if anyone on the list can clarify if the following is a bug 
or expected behaviour. I hope the diagrams will come out OK when this is posted.

I'm developing some features in 'x' branch, with a plan to merge periodically 
in another branch 'y', when stable. So I have added some files in 'x' to 
checkpoint (0), merged to 'y'.

X       Y
|       |
(0) ----M(0)

Next, I've added several more files in a check-in (1) to a branch 'y', but 
realised they had issues. I've edited that check-in (1) to be a start on new 
'mistake' branch, and modified the files in subsequent check-in (2) there. I 
merged 'mistake' back to my 'y', all good - commit to (3) on 'y'.

X       Y
|       |
(0) ----M(0)    mistake
        |       (1)
        |       |
        (3)M----(2)     

Then I realised changes in (3) shouldn't be in 'y', but in 'x'.  No probs - 
I'll just do a baseline merge and put them there, I thought.

1. This is the first surprise. When doing 'f merge --baseline (1)' in branch 
'x' checkout, I get the message 'no unmerged forks of branch "x"'. What does 
this mean? I thought it would have pulled (1), (2)/(3) into branch 'x'.

So instead, I did two cherry-pick merges, one on top of the other: from (1), 
then (2) to 'x' - (3) was a no-op - committed, all good. Or so I thought.

X       Y
|       |
(0) ----M(0)    mistake
|       |       (1)-----|
|       |       |       |
|       (3)M----(2)     |
|               |       |       
(12)CM----------|-------|
        
2. Later, I had some more changes committed in 'x' (4)  and tried to merge them 
to 'y'. Another surprise: when doing 'f merge x' in branch 'y' checkout, I get 
'no common ancestor' warnings on *all* files that I have added previously in 
both (0) *and* (1). Why is this?

X       Y
|       |
(0) ----M(0)    mistake
|       |       (1)-----|
|       |       |       |
|       (3)M----(2)     |
|               |       |       
(1,2)CM---------|-------|
|       |
(4)---M(warnings)

So I lost modifications on some of those files that were committed in (4). 
However, the *new* file I committed in (4) was successfully 'added_by_merge'.

This does not make sense to me. I thought that files that have been merged into 
'y'(3), and then later cherry-pick merged to 'x'(1,2), would have had the 
common ancestors in (1) and (2). I also don't understand why am I receiving 
such warnings for files that have been committed in 'X' in (0) and successfully 
merged to 'Y' at the beginning.

Is this a bug?

Fossil 1.32 [6c40678e91] downloaded from Fossil site, Windows.

Cheers,
Steve
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to