Sorry for the confusion.
By “merge from trunk” I mean I’m in branch ‘trunk’ and from there I’m doing the 
merge.
And, I’m merging the “check-in from the ... [other] branch”  I mean the 
check-in which is part of the other part.

I think I’m beginning to understand what’s going on.  If I do a full merge (no 
cherry pick) there are no conflicts.
So, it seems the fact that the SRF_OUT label was renamed in an earlier check-in 
that the one I’m cherry picking is confusing it.
What should have happened actually (what I expected with the cherry pick) is 
not exactly what I mentioned earlier.
The ‘puts’ change being part of the check-in I cherry picked should have merged 
in and the SRF_OUT rename (being from an older check-in) in the development 
branch should have stayed out.

This is a conflict if you look at this line of code as one piece (i.e., you 
either merge the whole line or none of it).
But, in reality the diff of the cherry picked check-in with its previous 
version has only the ‘puts’ change for that line, since the label was renamed 
much earlier.
And, that’s what I had expected would merge in the trunk.  Besides, since the 
rename hasn’t yet occurred in the trunk, I wouldn’t want that yet.

So, there is some problem there.  Now whether this is a bug, or just a merge 
algorithm limitation, I don’t know.
But, what is certainly confusing to figure out what may have happened is the 
common ancestor merge message line which shows content that never existed in 
the trunk version.  So, how can that be considered common?

(Then again, maybe I’m having a misconception of which the common ancestor is.)

Thanks.

From: Scott Robison 
Sent: Friday, November 13, 2015 5:53 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Unexpected merge conflict

On Nov 13, 2015 8:20 AM, "Tony Papadimitriou" <to...@acm.org> wrote:
>
> Here’s a merge conflict I thought should have been resolved automatically:
>  
> I have the trunk version from where the symbol RF_OUT is renamed to SRF_OUT 
> in the branch version.  It has never been renamed to SRF_OUT in the trunk 
> version (yet).
>  
> When trying to merge (--cherrypick, actually) from trunk the specific 
> check-in (either by giving the branch name or the actual check-in ID) from 
> the development branch that has the needed change, I got the following 
> unexpected merge conflict:

I am confused. You say merge "from trunk" & "from the development branch" in 
the same sentence. Is it possible you are going the wrong direction?

The common ancestor should not be the cherry picked commit, but there doesn't 
seem to be enough context here to positively identify which way is which or the 
common ancestor.

>  
> <<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<<
>                     @?status  RF_OUT,#?MsgOn,#?MsgOff,fWriteZ
> ======= COMMON ANCESTOR content follows ============================
>                     @?status  SRF_OUT,#?MsgOn,#?MsgOff,fWriteZ
> ======= MERGED IN content follows ==================================
>                     @?status  SRF_OUT,#?MsgOn,#?MsgOff,puts
> >>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>  
> As you can see, the common ancestor content shows the SRF_OUT label when that 
> label was named so only in the (under development) branch version.
>  
> Additional info that may help determine what went wrong:
> The SRF_OUT is renamed in the first node of the new branch several check-ins 
> before the cherry picked one.
> There have been two merged from the trunk (after the rename) but are 
> unrelated to this change and there were never any merge conflicts.
>  
> I expected the merged-in content to have completely replaced the local 
> version.
> Is there something I’ve done wrong that got fossil confused, is this a bug, 
> or simply a case of merge algorithm imperfection?  But, what confused it?  It 
> seems like a very simple change.
>  
> Thanks.
>
> _______________________________________________
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>




--------------------------------------------------------------------------------
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
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