Re: [lmi] Branching to replace XSL-FO

[Vadim Zeitlin]

On Fri, 6 Oct 2017 20:53:37 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-10-06 19:30, Greg Chicares wrote:
GC> [...]
GC> > For an assuredly safe trial run, I started this way:
GC> > 
GC> > $ pushd /tmp
GC> > $ git clone git://git.savannah.nongnu.org/lmi.git
GC> > $ cd lmi
GC> 
GC> I guess this was a common practice before 'git-worktree'.

 Not really because "git-new-workdir" existed for a long time before it and
worked just fine under systems with symlink support. But there is no real
problem with having multiple clones if you're prepared to push/pull between
them, reusing the same one as git-worktree does is basically just a
convenient optimization (that personally I see no reason to do without).
The only thing I'd definitely recommend changing is the URL: you should
clone your existing local repository instead of the remote one. Not only
accessing local disk is much faster than retrieving data from network, but
it also saves space because git is smart enough to use hard links in this
case instead of copying files.

GC> Having set it up already, I think I might just continue working there,
GC> so that I can focus on replacing XSL-FO instead of studying yet another
GC> git facility at this time.
GC> 
GC> Now I have "my" XSL-FO-replacement branch, and "yours":

 BTW, I didn't reply to the previous message because I have nothing to say
except that all commands in it are correct. The only unanswered question
there was:

GC> Later, while I'm working on the 'gwc-no-xslfo' branch, from time to time
GC> I'll want to get any updates you've made to the remote.

 The command to do that is just

        $ git fetch vz-remote

(you could add the branch name to fetch just the direct-pdf-gen-branch, but
it doesn't cost much to omit it). This doesn't modify your local branches
in any way but it does update vz-remote/direct-pdf-gen-master branch.
Typically after running the above you would do

        $ git log vz-no-xslfo..vz-remote/direct-pdf-gen-master 

to see the new commits since your last update ("A..B" notation means "all
commits reachable from B not not reachable from A" which, in case of linear
history, is exactly the semi-open interval ]A,B]) and/or

        $ git diff vz-no-xslfo vz-remote/direct-pdf-gen-master 

to see the changes since it. And if/when you want to update vz-no-xslfo to
correspond to the latest remote branch state you would do

        $ git checkout vz-no-xslfo
        $ git merge --ff-only vz-remote/direct-pdf-gen-master


 I'd also like to mention that to see the changes really done on my branch
you would need to do the diff between this branch fork point from master
and its latest tip because when you do:

GC> $ git diff --stat gwc-no-xslfo vz-no-xslfo
GC>  94 files changed, 7894 insertions(+), 2019 deletions(-)

You actually also get the changes done on master since this branch forked
off which can be returned by "git merge-base" command, so I see:

% git diff --shortstat `git merge-base direct-pdf-gen-master master` 
direct-pdf-gen-master
 75 files changed, 7865 insertions(+), 1872 deletions(-)

You could also make a (local) tag for this base commit to be able to refer
to it in a more convenient way. Or I could also rebase the branch on the
latest master if you'd like, then the merge-base would become "master"
itself (but only until it's changed again).


GC> I think this should be the command to do that, but I also thought it
GC> would work now, yet it doesn't:
GC> 
GC> $ git merge --ff-only vz-remote/direct-pdf-gen-master
GC> fatal: Not possible to fast-forward, aborting.

 I think it doesn't work because you're not on the right branch, i.e. your
current branch is "gwc-no-xslfo", which can't be fast-forwarded because
this branch forks off from the latest master while vz-no-xslfo starts from
slightly earlier master, and not "vz-no-xslfo" for which this really should
work.

 BTW, I strongly advise adding display of the current git branch in your
shell prompt. The exact way to do it depends on your current prompt, but
here is a simple shell function which returns the current branch in
parentheses or empty string:

---------------------------------- >8 --------------------------------------
git_prompt_info () {
        ref=$(git symbolic-ref HEAD 2> /dev/null) || return
        echo "(${ref#refs/heads/})"
}
---------------------------------- >8 --------------------------------------

You then need to just add $(git_prompt_info) somewhere in your PS1 and, if
you don't have it on yet, do "setopt promptsubst". I do both in my .zshrc.
You can also find much fancier prompts with colours, Unicode symbols and
what not on the web if you'd like, this is just the simplest possible way
to do it. But, again, it's very useful to see you current branch in the
prompt all the time, otherwise you would need to regularly use "git branch"
to find it out.

 
GC> $ git checkout vz-no-xslfo
GC> $ make srcdir=/opt/lmi/src/lmi -f /opt/lmi/src/lmi/GNUmakefile 
check_concinnity 2>&1 |less -S
GC> 
GC> If you haven't addressed the output yourself yet,

 I planned to do it as part of my final review but I indeed haven't done
this yet. I can/will do it soon, but probably not before Monday.

GC> As another example...
GC> 
GC>   File 'ledger_pdf_generator_wx_test.cpp' exceeds 31-character file-name 
limit.
GC> 
GC> I would suggest removing '_wx' from that file name.

 This would be unfortunate because it would break the symmetry with all the
other "_wx.cpp" files, such as group_quote_pdf_gen_wx.cpp and
pdf_writer_wx.cpp etc. I'll probably use ledger_pdf_gen_wx_test.cpp, but
this 31-character limit is really, really annoying, especially because of
its complete arbitrariness (no OS or file system in common use imposes such
limit).


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.

GC> - change them in my working copy of "your" branch, and send them to you as
GC> a git bundle?

 This would be by far the least convenient option because it's basically
the same thing as the approach below but uses extra files.

GC> - change them in my working copy of "your" branch, and somehow attempt to
GC> push them to savannah, which I suspect won't work unless I push "your"
GC> branch to savannah first?

 This would work too (when you push your local branch to Savannah, it will
push all commits in it not already present on Savannah, i.e. both your new
ones and my existing ones, and you don't have to do anything special for
this to happen). But it supposes that we work in lockstep, i.e. I shouldn't
do any changes until you do yours on this branch and then you shouldn't do
any more changes until I integrated yours. This is not very convenient nor
efficient IMO.

GC> For the changes I'd make to 'test_coding_rules.cpp', should I use one of
GC> the methods above? Is there any reason why I shouldn't just push them to
GC> savannah/master now, which would actually be more convenient for me?

 This wouldn't make much sense, why should there be any mention of
.mustache files in master without any such files present there? But it's
still possible, of course.

 My preferred solution would be to actually for me to do all these changes
and update my branch and let you get the fixes from it, but it's preferred
only because I think I should be responsible for fixing the problems I've
created and not somebody else, not for any technical reasons.

 If you don't tell me _not_ to do it during the week-end, I'll do this on
Monday.
 
 Please let me know if you have any other questions,
VZ