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

[Vadim Zeitlin]

On Sat, 14 Jul 2018 01:19:36 +0000 Greg Chicares <address@hidden> wrote:

[...snipping everything except "the command above"...]
GC> > GC> and figured out how to list the commits in that branch:
GC> > GC>   git log xanadu/pdf-pagination ^master |grep '^commit'
[...]
GC> >  Also, "git log" is insanely flexible and if you really want to get 
exactly
GC> > the same output as the command above produces from it, you can do it using
GC> > its --format="commit %H" option, but in case you just need compact output,
GC> > --oneline option is IMO more useful
GC> [...thus...]
GC> >   git log --oneline @..xanadu/pdf-pagination
GC> 
GC> It took me quite a lot of effort to find even the command above.
GC> I started with
GC>   git show-branch xanadu/pdf-pagination

 I'm not as knowledgeable as Уголёк (typing fast compensates for lack of
knowledge), so I admit I hadn't ever heard about this command before I read
this message. Now that I did hear about it, I still have no idea why would
I ever use it, its output looks rather messy and I don't see any advantages
of it compared to "git log --graph --oneline" (whose output might be a bit
difficult to parse too sometimes, but at least it does show something useful).

GC> because, well, I want to "show" a "branch" called "pdf-pagination".

 git-show-branch shows all branches (by default), not just a single one.
I have no idea why was the "es" at the end of the command name omitted.

GC> I suppose you could say it did that, in a manner of speaking, but
GC> then I figured out that I'd need to tell git that 'xanadu' is a
GC> remote (because...git doesn't know that?!):
GC>   git show-branch --remotes xanadu/pdf-pagination

 It does know that, otherwise it would tell you that it didn't know about
this revision. However, git-show-branch only shows local branches by
default, which is consistent with git-branch behaviour, and you need to use
the "-r" option to show remotes branches too.

GC> but then I couldn't scroll back into the present century, so I
GC> paged it manually (because, oddly, git doesn't):
GC>   git show-branch --remotes xanadu/pdf-pagination |less -S
GC> and at that point I just fell back on 'grep' because I know what
GC> that tool does.

 I could be missing something, but as of right now I think there is never
any need to use git-show-branch. If you want to see all branches history,
just use "git log --graph". BTW, as usual, I have my own alias which is
more compact and that I find more visually pleasing, so if you ever want to
try out, you could run

        git config alias.glog 'log 
--pretty=format:"%x1b[33m%h%x20%x1b[32m%d%x1b[0m%x20%s" --graph --branches'

and then use "git glog" instead.

 But as long as you keep lmi master history linear, you don't need either
of these commands anyhow, of course.


GC> > GC> would it spoil some vast eternal plan if I were
GC> > GC> to "merge" it by cherry-picking each of the thirteen
GC> > GC> commits in order from bottom to top? (In the past, I've
GC> > GC> cherry-picked whole branches in a single operation, but
GC> > GC> I've never cherry-picked individual commits as such.)
GC> > 
GC> >  Cherry-picking doesn't really work on whole branches, it just 
cherry-picks
GC> > all commits present in that branch but not in HEAD one by one. So I don't
GC> > see how would what you propose differ from "cherry-picking a branch" to be
GC> > honest and I suspect that we might be meaning something different here.
GC> 
GC> You overestimate my understanding of git. I can cherry-pick the branch
GC> by name, and get thirteen commits at once. With difficulty, I can find
GC> the thirteen SHA1s and commit them individually. That's all I know.

 The point I was trying to make was that there is really no difference
between the two. But I didn't think about testing the intermediate steps
and it's true that if you want to test each commit in isolation, it's
better to cherry pick them individually.

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

 I understand this now and am not (well, much less) worried, thanks.

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

 Personally, I'd indeed do it like this and just test everything once, at
the end.

 BTW, speaking about testing, I've found that my changes fixing restoring
maximized window position had broken IsMaximized() behaviour in some cases.
I've fixed it back, but the fix is not included in the commit upgrading
wxWidgets included in this PR. I don't think this particular problem
affects lmi, but it could be still better to update to the latest wxWidgets
master with these fixes (and perhaps also those from
https://github.com/wxWidgets/wxWidgets/pull/854). I'd have to rebuild it
with MinGW 7 (to check that it doesn't break anything right now) and 8 (as
I hope we'll upgrade to it relatively soon) if we want to do it -- please
let me know if I should.

 Thanks,
VZ