Re: [lmi] Branching to replace XSL-FO

[Vadim Zeitlin]

On Wed, 25 Oct 2017 01:00:02 +0000 Greg Chicares <address@hidden> wrote:

GC> Okay, then I won't do that. I'll use a branch originating from the same
GC> SHA1 as yours. It seemed natural to me to integrate my branch with master
GC> often, but that would make my branch deviate from your branch in every
GC> SHA1--whereas our strategy is to keep our parallel branches coordinated,
GC> then merge one into the other, and only then merge the result into master.

 Thanks!

GC> <digression>
GC> 
GC> I was about to ask a question, and I wrote it out in great detail, but
GC> then I was able to answer it myself, and my first answer is that this:
GC> 
GC> $git rev-list --boundary vz-no-xslfo...master | sed -e '/^-/!d' -e 's/^-//'
GC> f79cec2b455693b9ccf81ce4a0116e88f7d6bf64

 OK, I wouldn't have been able to write a command like this myself...

GC> $git merge-base master vz-no-xslfo 
GC> f79cec2b455693b9ccf81ce4a0116e88f7d6bf64

... but I do know and use this one.

GC> Well, at least now you know why this is taking me so long.

 In my defense, I did mention "git merge-base" before, searching lmi web
archives finds http://lists.nongnu.org/archive/html/lmi/2017-10/msg00004.html
and it's also mentioned in passing in
http://lists.nongnu.org/archive/html/lmi/2017-10/msg00012.html

GC> </digression>
[...]
GC> After all, lmi's history hasn't been perfectly linear
GC> since the accident documented here:
GC> 
GC> http://lists.nongnu.org/archive/html/lmi/2016-12/msg00016.html
GC> 
GC> ....and, as you pointed out then, the departure from linearity can be
GC> seen thus, even today:
GC> 
GC> $git log --graph --oneline 802eb23c6^..675ea31bf
GC> * 675ea31b Install vim in chroot
GC> *   8f40291f Merge branch 'master' of git.sv.gnu.org:/srv/git/lmi
GC> |\  
GC> | * 07781293 Disable clang warnings about mismatched struct/class
GC> | * c1c9c1af Fix linking of mc_enum unit test when using autotools
GC> * | fd65f393 Improve rate-table accuracy
GC> * | 77218530 Test for CR and VT separately
GC> * | 4f35f0c5 Use extension '.rates' for rate tables; enforce coding rules 
for them
GC> * | eb8fbb62 Revert "Allow empty comments in rate tables"
GC> |/  
GC> * 802eb23c Refactor for simplicity
GC> 
GC> ....yet that hasn't inconvenienced us in the slightest. It wasn't linear
GC> in that tiny neighborhood, but that's in the distant past and it might
GC> as well be linear today. Will the final outcome of the much larger merger
GC> now under way be the same? I.e., will we be able to go back to working
GC> just as though we had a purely linear history, except of course if we
GC> want to examine the multiple histories of this xsl-fo-replacement task?

 Yes, of course. Linear history is really not such a big deal, I think it's
mostly considered valuable because anything else created multiple problems
with the poor tools we had before.

GC> Now there's some more work that I really need to do on the master branch:
GC> not today, but within the next week or two. Should I just
GC>   git checkout master
GC>   git commit [some changes]
GC>   git push
GC> at that time?

 Yes, absolutely.

GC> Will that make our eventual no-more-xsl merge harder?

 If you modify the same files that are also modified in the branch in the
same places it touches -- then possibly yes. But considering that the
changes you plan to do are probably completely unrelated to the changes on
this branch, in practice I don't think it's going to be the case.

GC> [git-worktree seems like a reasonably simple command, as git commands
GC> go, but I really don't want to learn "just one more" git facility at
GC> this time, and I think the git-checkout command above is all I need.]

 Yes, git-worktree is just an optimization and not such an important one
for the relatively small lmi repository. To be honest, I've mostly advised
it to you in an attempt to avoid provoking branch-related traumas due to
the need to use "git checkout" to switch between branches. But if you're
comfortable with using it, I agree that you don't really need git-worktree.
Just don't forget to commit (possibly using "git commit -am 'WIP'" if
they're not ready to be committed yet, or "git stash" if you want to
discover another very useful git command) all your changes before switching
branches.

 Good luck!
VZ