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

[Vadim Zeitlin]

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

 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 and I have aliased "lg" to "log
--oneline" a long time ago, as I'm using this one all the time.


 TL;DR summary: I would write the command above myself as

        git lg ..xanadu/pdf-pagination

while the way I'd recommend writing it to the others would be

        git log --oneline @..xanadu/pdf-pagination


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.

 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. 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, as this would make rebasing my branch over master later
very difficult and I'd basically just have to throw it away (and won't be
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?

 Of course, I might have misunderstood you completely, sorry in advance if
this is the case.

 Regards,
VZ