>In addition, I would imagine that you have this:
>
> F+B
> /
> ---X---F
> \
> F+A
>
>(...)
> F+B
> /
> ---X---F
> \
> F+A
>
Hi,
Thank you for your answer :)
I don't understand the difference between the two diagrams. I can see the branch points are different but why is it relevant?
I probably should have included diagrams in my original post. Here is what I have, with your notations, and with Ai, Bi, Fi denoting commits that introduce changes in product A, product B and the framework respectively:
--F1----B1----A1----A2----F2----B2=X
What I wish I had
A1 ---- A2----+=A
/ /
--F1----------------F2=F
\ \
B1---------------+-----B2=B
Thanks to your post, I now realize that merges should only bring new framework stuff into product specific branches and not the other way around (ie. If I happened to have fixed a framework issue in a branch derived from product A, I should rebase it onto the framework, merge it in the framework and then merge the framework into the product A branch, it makes perfect sense).
I don't really care if I can rewrite the history this way (unless it turns out to be super easy) as long as I can set up the repository so that I can work this way from now on. So here is my attempt from the current history, introducing the framework branch and the new product branches with their respective "initial_removal" commits: Ax means remove product A specific code, same for Bx.
Bx---------+=A (now contains Ax, which is not suitable)
/ \ /
--F1----B1----A1----A2----F2----B2---+---F3=F
\ / \
Ax--------+=B (now contains Bx, which is not suitable)
Notice that I applied Ax and Bx to F in order to clear it from the product specific code. Yet, doing so will eventually bring Ax to branch A and Bx to branch B, killing them. I can't find a way to avoid this while clearing the F branch other than cherry-picking F3 or any rebase solutions.
Now I believe you're suggesting not to apply Ax and Bx to F, and hence have the product specific code remain in a dead state in F. That will do and it probably is what I will end up doing, unless another idea comes out.
Thank you
Yohann
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�