Re: [lmi] Branching to replace XSL-FO

[Greg Chicares]

On 2017-10-13 23:57, Vadim Zeitlin wrote:
> On Fri, 13 Oct 2017 15:34:50 +0000 Greg Chicares <address@hidden> wrote:
[...]
> 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.

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

<digression>

I was about to ask a question, and I wrote it out in great detail, but
then I was able to answer it myself, and my first answer is that this:

$git rev-list --boundary vz-no-xslfo...master | sed -e '/^-/!d' -e 's/^-//'
f79cec2b455693b9ccf81ce4a0116e88f7d6bf64

is the common point where both our branches begin. I think that means
we form the disjunctive union
  vz-no-xslfo △ master
which in this context means the set of every SHA1 in your branch that
isn't in master; then add the '--boundary' flag to add the proximate
parent of the first member of that set; then delete every element
except that parent.

But one might be forgiven for hoping that a more direct solution could
be found, and indeed:

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

Well, at least now you know why this is taking me so long. Having
attained some fluency with git for managing a linear repository and
then trying to learn branching feels like having learned the basic
algebra of real numbers and then trying to relearn everything in the
context of complex numbers.

</digression>

> 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.

My heart sank when I read that, because expulsion from Eden is usually
cause for regret, and simplicity lost is seldom regained: I worry that
all my customary commands might break in astonishing ways. But is that
fear reasonable? After all, lmi's history hasn't been perfectly linear
since the accident documented here:

http://lists.nongnu.org/archive/html/lmi/2016-12/msg00016.html

....and, as you pointed out then, the departure from linearity can be
seen thus, even today:

$git log --graph --oneline 802eb23c6^..675ea31bf
* 675ea31b Install vim in chroot
*   8f40291f Merge branch 'master' of git.sv.gnu.org:/srv/git/lmi
|\  
| * 07781293 Disable clang warnings about mismatched struct/class
| * c1c9c1af Fix linking of mc_enum unit test when using autotools
* | fd65f393 Improve rate-table accuracy
* | 77218530 Test for CR and VT separately
* | 4f35f0c5 Use extension '.rates' for rate tables; enforce coding rules for 
them
* | eb8fbb62 Revert "Allow empty comments in rate tables"
|/  
* 802eb23c Refactor for simplicity

....yet that hasn't inconvenienced us in the slightest. It wasn't linear
in that tiny neighborhood, but that's in the distant past and it might
as well be linear today. Will the final outcome of the much larger merger
now under way be the same? I.e., will we be able to go back to working
just as though we had a purely linear history, except of course if we
want to examine the multiple histories of this xsl-fo-replacement task?

Now there's some more work that I really need to do on the master branch:
not today, but within the next week or two. Should I just
  git checkout master
  git commit [some changes]
  git push
at that time? Will that make our eventual no-more-xsl merge harder?

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