===Remigiusz Modrzejewski <[email protected]> wrote:===
"What is exactly the design idea that prohibits merging only a few files? It
would certainly be useful in this kind of untangling mess that I have to do
now. Which I have to do by having two open local copies and manual copying
:/"
====================================
Rather than a mechanism to merge a single file I think I'd prefer to see a
mechanism for breaking out changes into separate branches. I like my changes
to be nicely quantized and the full delta applied on a merge. With a single
file merge you now need some way of tracking and displaying in the timeline
what file(s) where changed. Yuk. Hideously confusing, at least for me.
You could go the down the path of adding a feature like git's "rebase" but a
lot of folks (myself included) are uncomfortable with history being
rewritten, although I admit that in my case it may be due to having not
fully mastered using rebase.
Most importantly though I think this kind of problem can be easily and
clearly solved using the existing power of fossil and the merge tool "meld".
I imagine your scenario is something like this:
--A1--A2--A3
\--B1-
And you want to merge a portion of "B1" into the trunk creating A4.
I suggest you branch at "A1" creating branches B1_change1, B1_change2 etc.
You use meld to update those branches with the desired changes. You then
merge B1_change1, B1_change2 etc. into B1_new where development on your B1
path would continue. The actual B1 branch would be closed. Now you can make
a clean and clear merge from B1_change1 into A4.
/--B1_change2--B1_new-
/ /
/--B1_change1--/
| \
--A1--A2--A3--A4--
|
\--B1-(closed)
Matt
-=-
On Sun, Jun 12, 2011 at 8:22 AM, Remigiusz Modrzejewski
<[email protected]>wrote:
> Hi,
>
> I've managed to create a lot of mess in a private branch. Now I want to get
> the useful parts of this mess into the trunk, one by one. Changes were made
> in a pretty chaotic sprint, so there is no logic in how and when commits
> were made. Thus cherrypick is useless.
>
> What would be perfect is merging a single file. There is no way to do that.
> Then, I merged the whole private branch into trunk and (after some cleaning)
> wanted to commit part of the files. Result:
> fl: cannot do a partial commit of a merge
>
> What is exactly the design idea that prohibits merging only a few files? It
> would certainly be useful in this kind of untangling mess that I have to do
> now. Which I have to do by having two open local copies and manual copying
> :/
>
> Kind regards,
> Remigiusz Modrzejewski
>
>
>
> _______________________________________________
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
