Re: [lmi] Branching to replace XSL-FO

[Greg Chicares]

On 2017-10-06 21:51, Vadim Zeitlin wrote:
> On Fri, 6 Oct 2017 20:53:37 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> Should I...
> GC> 
> GC> - cherry-pick these from "your" branch into "mine", change them there, and
> GC> push to savannah?
> 
>  This would work and is arguably the best way forward because this change
> is just like any other change you'd like to do and, as we extensively
> discussed in the past, I think you should do all these changes on your
> (gwc-no-xslfo) branch, push them to Savannah to let me update my branch
> with your changes and then merge both branches at the end.

[...the other options discussed were less good, so I'll use this one...]

Let's work through a simple, concrete example together. I want to import
your 'test_coding_rules.cpp' changes first, because git commit hooks make
everything depend on that file. With my personal branch checked out, I
look at the log for all branches:

$git log --branches test_coding_rules.cpp

and find that you've made only one change, 08984bb, since the branch
point, so I do this:

$git cherry-pick 08984bb87061a3be67226c36db5046f674f10eb2 --ff

Now 'git log' shows your change, with your log message, but with a
different SHA1. I think that's exactly what we want.

I looked over all the git-cherry-pick options and figured that most
of them aren't useful here. For example, we don't need '-x' to write
the picked-from SHA1 into the commit message, because eventually we
will merge the branches together. But I tried '--ff' because it seems
like a good idea when it works, though I can't see why it did work.
The documentation says:

https://git-scm.com/docs/git-cherry-pick
| If the current HEAD is the same as the parent of the cherry-pick’ed
| commit, then a fast forward to this commit will be performed.

Already I'm confused. The HEAD of my branch just before this commit is

$git rev-parse HEAD~1
f79cec2b455693b9ccf81ce4a0116e88f7d6bf64

(which happens to be HEAD~3 in master). That SHA1 precedes 08984bb by
many commits, so I'd say it's an ancestor, but not "the parent"--so
why did '--ff' succeed? IOW, I'm interpreting "the parent" to mean the
immediately preceding commit. Does it instead mean the last preceding
commit that changed this particular file?

For '--ff', thus, is it sufficient that my branch already contains
the parent of this change on your branch?

Now the HEAD of my branch has advanced due to this cherry-picked
change. Does that mean that '--ff' will fail on the next change I
cherry-pick?

Would anything bad happen if I didn't use '--ff', or is that just a
question of efficiency?

I have one more-general question on this topic. Yesterday we put an
urgent enhancement into master. Since the cherry-picking above is the
first change I'll be making  on a branch, would it be okay if I removed
my "gwc" branch and recreated it from current master? Or is it necessary
for both the "gwc" and "vz" branches to be rooted at the same commit?
IOW, now that you've rebased your branch on M1 in the diagram below,
and I've recreated a "vz-no-xslfo" branch that corresponds to your
(rebased) remote...

                 *--- ... ---*--> "vz-no-xslfo"
                /
       ---M0---M1---M2---M3---M4 master
                \         \
                 \         \
                  \         *--- ... ---*--> NEW gwc-no-xslfo
                   \
                    \
                     *--- ... ---*--> OLD "gwc-no-xslfo"

....must I use my existing "OLD" branch that's based on the same M1,
or can I delete that and recreate it based on a later M3?