Re: [lmi] Branching to replace XSL-FO

[Vadim Zeitlin]

On Sat, 28 Oct 2017 18:11:19 +0000 Greg Chicares <address@hidden> wrote:

[...]
GC> How can I do this while preserving your commit history?

 Sorry, I feel like we're going in circles. I think we have established the
following 2 facts multiple times already:

1. There is no way to preserve the commit history in your
   integration/review branch because it's fundamentally incompatible with
   the way you need to make your changes.

2. This is not a problem as long as you end up by doing the merge at the
   end as discussed before because the original history will be preserved
   in my branch (which will eventually be merged into master) and the
   changes done by you will be visible as the diff between the merge commit
   and the last commit of my branch.

GC> >   $ git checkout vz-no-xslfo '*.mst'
GC> >   $ git commit -m 'Create template files'
GC> [...]
GC> >  Of course, this loses all the history of the changes to these files,
GC> > including their renaming (granted, this is not very important), but you
GC> > probably don't care about this anyhow (in this branch, at least).
GC> 
GC> That seems like a fatal flaw. The roadmap we've established is for me to
GC> create my own branch G that accepts and modifies the contents of your
GC> branch V, and then IIRC to git-merge V into G and then G into M. If G
GC> loses the history of V, then M won't have that history either.

 No, it will, because of the merge. This merge, which will actually discard
the contents of the branch V, is rather unusual, but it will still preserve
the history of changes and, again, this is really the best we can do.

 So I still think you should just use the commands above.


GC> In both (2) and (3), I'm suggesting that we "import" your entire branch
GC> all at once, into a branch, a subdirectory, or whatever as long as it's
GC> kept distinct from master. I don't know the git terminology for this, but
GC> conceptually it gives me all of your changes as a single, indivisible blob.

 This is simple to do (git merge --squash), but I really don't see why
would it be useful. You *already* have all my changes in the vz-no-xslfo
branch and you can do everything you could do with the files in a
subdirectory with the files in this branch.

GC> IOW, our plan had been:
GC> 
GC>     M0 ------------------------------> M1
GC>     |\                                 ^
GC>     | \                               /
GC>     \  --> GWC1 -> ... -> GWCm ---> GWC*
GC>      \                              ^
GC>       \                            /
GC>        ---> VZ1 -> ... -> VZn  --->
GC> 
GC> but now that seems unworkable,

 It still seems workable to me.

GC> so instead I'm suggesting
GC> 
GC>     M0 -----------------------------------------------------------> M1
GC>      \                                                              ^
GC>       \                                                             /
GC>        ---> VZ1 -> ... -> VZn  --->                                /
GC>                                    \                              /
GC>                                     \                            /
GC>                                      ---> GWC1 -> ... -> GWCm -->

 This is not a problem for Git, of course, and is actually how _I_ would do
my integration, because I typically apply my changes/fixes on top of the
original changes done by someone else. But I just don't see how is it
remotely compatible with your approach. I.e. what would be the contents of
the commit GWC1? It would need to start with the last state of my branch
and do... what?

GC> >  Anyhow, I think my method in the very beginning should satisfy your
GC> > requirements -- but please let me know if it doesn't.
GC> 
GC> This method:
GC>     $ git checkout vz-no-xslfo '*.mst'
GC>     $ git commit -m 'Create template files'
GC> "loses all the history of the changes", and that's not what we want.

 It loses them in your branch. This is still not ideal IMO because you will
have trouble cherry-picking any commits from now on, but if you don't plan
on doing this, then it's not a problem.

GC> Ideally, I'd like to do something like what I was trying to describe
GC> in (3), but let me restate it here and call it (5):
GC> 
GC>     M0 -----------------------------> M1/no-xslfo
GC>      \                               <^>
GC>       \                               /
GC>        ---> VZ1 -> ... -> VZn  --->  /
GC> 
GC> where <^> signifies a hypothetical git operation that merges your
GC> branch into master as a subdirectory, preserving all your history,
GC> while leaving master otherwise intact. If this operation can be
GC> performed within git,

 It can, by rewriting the branch history, but I won't even give the command
to do it because you really, really don't want to go there and I don't want
to waste your time on reading more git man pages by triggering your
curiosity about how to do it.

 I think we wasted too much of your time already with this and it's just my
own fault for telling you about all the different things git can do when we
actually don't need them. Let's just put in place the original plan: please
integrate the changes in your GWC branch in whichever you see fit, without
caring about the history, and then let's do the merge with the VZ branch
using "ours" strategy at the end to graft the original history of these
changes. This should really be acceptable to both of them and I don't think
it's worth spending more time on discussing even more complicated ways to
do something else when this approach is straightforward and should allow
you to integrate the changes in the way you see fit.

 Regards,
VZ