On Sun, Oct 17, 2010 at 12:18:20PM -0400, Richard Hipp wrote: > On Sun, Oct 17, 2010 at 4:06 AM, Wolfgang <rat...@stumvolls.de> wrote: > > > Hello > > > > I don't know, if the following behaviour is a feature, a bug or if this > > solution > > would be a feature request. > > > > I like to work with branches. Asuming: > > > > 1. i have a trunk development, using version 1, 2, 3 > > 2. i started a branch name b1 at 1 and committed some changes 1.1.1, 1.1.2, > > 1.1.3 > > 3. i started a second branch named b2 on the branch 1 at 1.1.2 using > > versions > > 1.1.2.1.1, 1.1.2.1.2 > > > > The above version numbers are given in CVS notation. > > > > If i decide to merge branch 2 to main trunk, i would expect, that merge b2 > > apllies patches 1.1.2.1.1, 1.1.2.1.2. But fossil merges the complete patch > > sequence starting from 1.1.1 to 1.1.2.1.2 to my trunk version 3. > > > > Fossil reads the commandline argument b2 and searches for the newest > > version > > with this tag and apllies all patches from the common base 1.1 until the > > found > > branch version. > > > > My expactation: > > Only diffs occuring on the branch should be apllied. > > > > I see only one chance: > > Applying all patches from the branch p2 using --cherrypick. > > > > Is this intended? > > > > The behavior is as intended.
I like this behaviour intended. I just had the case of having a branch from trunk, and it had some changes I wanted to merge in to trunk, but I did not want all of them. So I can create a subbranch of 'branch', prepare it as I want it merged into trunk, and from trunk I can do: fossil merge subbranch But I wonder if a later merge in trunk like this will work fine: fossil merge branch Regards, Lluís. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
