Re: [lmi] Branching to replace XSL-FO

[Greg Chicares]

On 2017-10-13 15:34, Greg Chicares wrote:
> 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

[...we decided that '--ff' should be omitted...]

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

Suppose I now want to bring all the new '*.mst' files into my branch:
only them, and nothing more. I can imagine various ways of doing that,
as follows; which is best?

(1) Find the latest SHA1 for all these files. To identify the commits,
I can check out your branch:
  git checkout vz-no-xslfo
and search for '\.mst' here:
  git log --stat
It appears that these two commits should cover all '*.mst' files:
  982c9f0 Remove consecutive blank lines from a Mustache template
  2fd6a11 Use shorter and more consistent names for external templates
But 2fd6a11 brings in 'ledger_pdf_generator_wx.cpp', which I don't
really want to look at yet. Apparently I can exclude it this way:
  git checkout gwc-no-xslfo
  git cherry-pick --no-commit 2fd6a11
  git checkout HEAD ledger_pdf_generator_wx.cpp
  git commit --all -m'Cherry-pick only *.mst'
  git cherry-pick 982c9f0
Will that make the eventual final merge more difficult? When I later
want to bring in 'ledger_pdf_generator_wx.cpp', would I just do:
  git cherry-pick 2fd6a11
? Assuming that I've made changes to numerous '.mst' files in the
meantime, will that command update only that single '.cpp' file, in
a way that won't interfere with the final merge?

Let's try that and see what happens.
  git checkout gwc-no-xslfo
  git cherry-pick --no-commit 2fd6a11
  error: could not apply 2fd6a11c1... Use shorter and more consistent names for 
external templates
  hint: after resolving the conflicts, mark the corrected paths
  hint: with 'git add <paths>' or 'git rm <paths>'
That surprised me. Running 'git status' shows:
  deleted by us:   ledger_pdf_generator_wx.cpp
  added by them:   nasd_supp.mst
and many other "added by them" lines. But not all '.mst' files have
been added--I see only 26
  ls *.mst |wc -l
  26
but there should be 47 or so. Well, okay, the missing '.mst' files are
due to a mistake on my part--I needed commits 0ba1c32 and 7c0ff88 as
well. Still, I can't understand why the 'cherry-pick' command didn't
work: I would have expected that it would either succeed, or show all
files, including 'ledger_pdf_generator_wx.cpp', as "added by them".

(2) Instead, maybe I should just import everything from your branch,
all at once, creating a complete copy; and then work on it as I would
normally work on 'master'. In effect, I'd still be doing my work
linearly as always, except on a different line.

I'm guessing that, for method (1), I would eventually have to cherry-
pick everything anyway, and that appears to require a great deal of
labor, if it can even be made to work at all. I want to review sets
of files grouped the way I want (e.g., all '*.mst' in one batch),
which is different from the way git groups them (i.e., by commit);
perhaps these two viewpoints are simply irreconcilable?

The problem with this approach is that, while I can live with adding
all the new files at once, I do not want changed or renamed files yet.
I suppose I might revert such files selectively and later resurrect
their changes as I review them, but I'm not sure that would work.

(3) Alternatively, suppose I just put your branch into a subdirectory
of master, and then gradually move files into the main directory? If I
did that with 'git mv', would git be smart enough to recognize them,
so that their (your) history would be preserved? This way, we'd never
even need to do a 'git merge'.