Re: [lmi] Branching to replace XSL-FO

[Vadim Zeitlin]

On Fri, 13 Oct 2017 15:34:50 +0000 Greg Chicares <address@hidden> wrote:

GC> Let's work through a simple, concrete example together. I want to import
GC> your 'test_coding_rules.cpp' changes first, because git commit hooks make
GC> everything depend on that file. With my personal branch checked out, I
GC> look at the log for all branches:
GC> 
GC> $git log --branches test_coding_rules.cpp
GC> 
GC> and find that you've made only one change, 08984bb, since the branch
GC> point, so I do this:
GC> 
GC> $git cherry-pick 08984bb87061a3be67226c36db5046f674f10eb2 --ff
GC> 
GC> Now 'git log' shows your change, with your log message, but with a
GC> different SHA1. I think that's exactly what we want.

 Yes. And we want it because you may wish to make changes to this commit or
additional changes after cherry-picking it, so preserving exactly the same
commit (with the same SHA-1) is not an option anyhow and this is the
closest we can get to it.

GC> I looked over all the git-cherry-pick options and figured that most
GC> of them aren't useful here. For example, we don't need '-x' to write
GC> the picked-from SHA1 into the commit message, because eventually we
GC> will merge the branches together.

 Typically "-x" is useful when cherry-picking between two long-lived
branches, e.g. in wxWidgets we use it when cherry-picking master commits to
3.0.

GC> But I tried '--ff' because it seems like a good idea when it works,
GC> though I can't see why it did work.

 I admit that I had no idea about --ff option to this command, so I could
be wrong, but I think it just doesn't work in the way you think it does:
it's "--ff" but not "--ff-only", i.e.

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

This doesn't say what happens if the current HEAD is not the same as the
parent of the cherry-pick'ed commit and my understanding is that it then
just does a normal cherry-pick, as if --ff were not specified.

 Of course, this will practically always be the case because why would you
cherry-pick something if you can just fast-forward to it. So I don't think
this option is particularly useful. But it's definitely harmless.

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

 I am almost certain that exactly the same thing would have happened if you
didn't use it in this situation.

GC> I have one more-general question on this topic. Yesterday we put an
GC> urgent enhancement into master. Since the cherry-picking above is the
GC> first change I'll be making  on a branch, would it be okay if I removed
GC> my "gwc" branch and recreated it from current master?

 Yes, but why? What do you gain from this?

GC> Or is it necessary
GC> for both the "gwc" and "vz" branches to be rooted at the same commit?

 No, but then simple "git diff" between these branches would should the
changes in master present in gwc but not in vz which might be inconvenient
(you'd have to diff with respect to the merge-base to see the differences
you're really interested in).

GC> IOW, now that you've rebased your branch on M1 in the diagram below,
GC> and I've recreated a "vz-no-xslfo" branch that corresponds to your
GC> (rebased) remote...
GC> 
GC>                  *--- ... ---*--> "vz-no-xslfo"
GC>                 /
GC>        ---M0---M1---M2---M3---M4 master
GC>                 \         \
GC>                  \         \
GC>                   \         *--- ... ---*--> NEW gwc-no-xslfo
GC>                    \
GC>                     \
GC>                      *--- ... ---*--> OLD "gwc-no-xslfo"
GC> 
GC> ....must I use my existing "OLD" branch that's based on the same M1,
GC> or can I delete that and recreate it based on a later M3?

 Again, you can, there is no problem with rebasing as long as you do it for
your private branches. It definitely wouldn't be a good idea to do it,
especially without an advance warning, once you push it to Savannah. But
right now, yes, you can do it. I just don't think it's necessary, there is
no real gain and you will have to accept that the history is not linear any
more in any case.

 Regards,
VZ