>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.
