Re: [lmi] Branching to replace XSL-FO

[Greg Chicares]

On 2017-10-25 01:24, Vadim Zeitlin wrote:
> 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...

Me neither. I got it from the same place where I learned that I should eat
thirty bananas a day. That works well if you supplement it with negative
twenty-nine bananas to avoid potassium poisoning...

> GC> $git merge-base master vz-no-xslfo 
> GC> f79cec2b455693b9ccf81ce4a0116e88f7d6bf64
> 
> .. but I do know and use this one.

....or you could just eat one banana. (I had guessed that positives and
negatives could be cancelled, but it helps to work with a tutor who
can validate conclusions like that.)

> 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

I'm glad you pointed this out, because it helps me to understand why
I'm going down these blind alleys. If the exercises in a math textbook
seem too difficult, then it's a good idea to read the chapter again.

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

Yes, I'm pretty sure the two sets of changes will be disjoint.

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

Okay, thanks. Even with cvs and svn, I always strove to work this way,
by "stashing" my work-in-progress in a separate directory. I already
think of git-checkout as meaning "obliterate work in progress", so
facilities like git-stash and git-worktree are mere conveniences that
I might adopt someday--but for now I'm going to focus my git studies
on branching because that's where I still have conceptual difficulties.