Re: [lmi] First version of the illustrations pagination patch

[Greg Chicares]

On 2018-07-13 15:32, Vadim Zeitlin wrote:
> On Thu, 12 Jul 2018 22:32:12 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2018-06-23 21:35, Vadim Zeitlin wrote:
> GC> > 
> GC> >  Here is the long-promised version of the pagination patch:
> GC> > 
> GC> >                 https://github.com/vadz/lmi/pull/86
> GC> 
> GC> Having set up a "remote" to track your repository:
> GC>   git remote add xanadu https://github.com/vadz/lmi.git
> GC> and figured out how to list the commits in that branch:
> GC>   git log xanadu/pdf-pagination ^master |grep '^commit'
> 
>  Just for the record (and in case Ugoljok hasn't learnt this yet), I find

Of course he knows it. But you'd use as few characters as possible too,
if you typed as clumsily as he does.

> "A..Z" notation more intuitive than "^A" one as the former one looks like
> the usual mathematical interval notation and you just need to remember that
> Git intervals are semi-open on the left, i.e. "A..Z" means B, C, D, ... Z,
> and that either "A" or "B" may be omitted and they default to the current
> HEAD (a.k.a. "@") in this case, i.e. "A.." == "A..@" == all commits in the
> current branch not present in "A", and "..Z" == "@..Z" == all commits in Z
> not present in the current branch. The latter may be confusing, but nothing
> forces you to actually omit "@", it costs nothing to write it if it helps.

Thanks, this is really helpful: the syntax for ranges of references is
abstruse, but maybe I can learn some subset that is actually rational.

>  Also, "git log" is insanely flexible and if you really want to get exactly
> the same output as the command above produces from it, you can do it using
> its --format="commit %H" option, but in case you just need compact output,
> --oneline option is IMO more useful
[...thus...]
>       git log --oneline @..xanadu/pdf-pagination

It took me quite a lot of effort to find even the command above.
I started with
  git show-branch xanadu/pdf-pagination
because, well, I want to "show" a "branch" called "pdf-pagination".
I suppose you could say it did that, in a manner of speaking, but
then I figured out that I'd need to tell git that 'xanadu' is a
remote (because...git doesn't know that?!):
  git show-branch --remotes xanadu/pdf-pagination
but then I couldn't scroll back into the present century, so I
paged it manually (because, oddly, git doesn't):
  git show-branch --remotes xanadu/pdf-pagination |less -S
and at that point I just fell back on 'grep' because I know what
that tool does.

> GC> would it spoil some vast eternal plan if I were
> GC> to "merge" it by cherry-picking each of the thirteen
> GC> commits in order from bottom to top? (In the past, I've
> GC> cherry-picked whole branches in a single operation, but
> GC> I've never cherry-picked individual commits as such.)
> 
>  Cherry-picking doesn't really work on whole branches, it just cherry-picks
> all commits present in that branch but not in HEAD one by one. So I don't
> see how would what you propose differ from "cherry-picking a branch" to be
> honest and I suspect that we might be meaning something different here.

You overestimate my understanding of git. I can cherry-pick the branch
by name, and get thirteen commits at once. With difficulty, I can find
the thirteen SHA1s and commit them individually. That's all I know.

>  As for the main question itself, as always, for me just merging this
> branch (possibly after making some other changes on top of my commits and
> before merging) would be ideal. But if you absolutely want to preserve
> linear history, then cherry-picking works too.

Yes, I do prize linearity.

> The worst, from my point of
> view, would be to cherry-pick the first commit, make some changes to the
> code modified by it, then cherry-pick the second one, then make some more
> changes and so on

Don't worry, I know that would make a mess. I'm not even sure it would work,
as intermediate changes might make later diffs difficult to apply.

> even able to see clearly which changes have you made on top of mine). As I
> suspect that this is exactly what your plan is, could I please ask why do
> you want to do it like this and if there is any crucial difference compared
> to doing your changes after my commits instead?

The first two commits upgrade two libraries, which is always a perilous
undertaking. After examining only them, I thought I might want to apply
them separately and test before proceeding. That's why I asked the
original question.

But later I looked at the other eleven commits, and they seem really
minor. So now I think I should
  git cherry-pick ..xanadu/pdf-pagination
and then consider whether I'd want to change anything (and my initial
impression is that I wouldn't change much, if anything at all).