On Wed, Jun 4, 2014 at 12:07 AM, Andy Bradford <amb-fos...@bradfords.org> wrote:
> Thus said Andy Bradford on Tue, 03 Jun 2014 21:59:21 -0600: > > > Does the Q-card here not imply any relation with c14a4a93d5a3 which will > > be picked up in trunk? > > It seems I did not understand this very well: > > A Q-card is similar to a P-card in that it defines a predecessor > to the current check-in. But whereas a P-card defines the > immediate ancestor or a merge ancestor, the Q-card is used to > identify a single check-in or a small range of check-ins which > were cherry-picked for inclusion in or exclusion from the > current manifest. > > Which I suppose means that there is no ancestral relationship. > Right. Q-cards are informational only and are not used by merge logic, or currently for any other purpose. At some point it would be nice to show cherry-pick lines in the timeline graph, and for that the Q-cards will be used. > > > $ fossil merge c14a4a > > MERGE file > > "fossil undo" is available to undo changes to the working checkout. > > Should a merge in this case result in a conflict? Or is it correct to > merge in the content a second time? Or should it recognize that the > Q-card UUID and the UUID of the version being merged in are the same and > include a warning or even error? > The merge logic in Fossil recognizes when the same exact change is merged more than once and avoids conflicts in that case. The Q-cards are not necessary for this. -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
