Re: [lmi] PATCH: wxGrid-based census view

[Vadim Zeitlin]

On Tue, 14 Jul 2020 22:17:52 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> I was thinking of something like this:
GC>   git branch -d xanadu/census-view-only-grid
GC> or the same with a capital '-D' if necessary.

 Just for the record, this won't work because the argument here is not a
local branch and you can only delete local branches.

GC> As long as I have a local copy of that remote branch, there's
GC> a chance that I'll type 'git some-command census-view<Tab>'
GC> and do something regrettable.

 You always have references to all the remote branches, but you can't
modify anything on the remote side until you do "git push" -- and you won't
be able to push anything to this particular remote without a GitHub
account.

GC> In practice, I'd just "merge" the whole branch and review the changes
GC> in aggregate, using some non-web-based tool of my own choice. I'd
GC> look at individual commits only if I couldn't understand some change.
GC> IOW, I'd merge #143, but review the net effect of all the changes
GC> together, in effect squashing them myself, just as though I were
GC> examining #144.

 IME this is not quite the same. No tool (that I'm aware of, anyhow) will
show you the new code as diff with an existing one as long as the existing
code remains too and for some parts of these changes this could be useful.
Of course you don't have to use GitHub web UI for viewing this diff, you
can also use plain "git diff xanadu/census-view-only-grid" or anything
based on it.

GC> I'm more concerned about regressions in wxWidgets than in wxPdfDoc,
GC> because wxWidgets is a bigger project with more developers making
GC> more changes.

 Yes, me too. We hope to have more testing being done before 3.1.4 but, of
course, this is not a guarantee of anything.

GC> Okay, I'll cherry-pick that now. And then on Monday or so I'll plan
GC> to cherry-pick the later version (of wxWidgets at least) that you
GC> are currently working on. This way, I can at least get started on
GC> testing it.

 Very good, thanks. I've already rebased my PRs on your cherry-pick, and I
won't need to do it again even if/when you upgrade to even newer version on
Monday as all the changes there compile and work correctly with the commits
currently used by lmi master (and any later commits can only improve things
or leave them unchanged, but not break anything -- I'll ensure this).

GC> The sequence that's best for us is:
GC>  - cherry-pick and push 2f38b532d5b to savannah now; later...
GC>  - cherry-pick a similar change (incorporating wx pull 1941) at
GC>     the beginning of next week, and push it to savannah then; later...
GC>  - merge the remainder of #143, perhaps all at once
GC> Then we can test after each of those three steps.

 It seems a bit of a waste to test 2f38b532d5b now and a later wx commit
integrating PR 1941 later, but this certainly works for me.

GC> Since you're planning to rebase PR #143 anyway, could you just
GC> wait for Monday,

 I've decided not to wait because I really don't think it's going to make
any difference, so I've rebased and pushed both branches. You will just
need to run "git fetch xanadu" to update your local view of them, and it
should tell you that there was a "(forced update)", but, again, this just
means that I've rewritten them and not a problem as long as you know about
it.

GC> and then give me two tasks:
GC>  - one that only updates wx{Widgets,PdfDoc} for wx pull 1941
GC>      (I needn't trouble you to make a PR for this, because
GC>      it's just a matter of altering two SHA1s, which I can
GC>      do by hand...and if I mistype them, a script failure will
GC>      inform me of my mistake very quickly)

 Sure.

GC>  - a new incarnation of PR #143, rebased on those updated SHA1s

 I won't even need to do this (although I could) because if you merge PR
143, the merge commit will include both its changes and the changes to
install_wx*.sh, so everything will already be correct.

GC> Then, locally, I'll blow away my local 'xanadu' branches and
GC> re-fetch on Monday. (There's probably a simpler one-step method,
GC> but doing 'git-branch -d' first rules out a possibility for error,
GC> and it can't hurt.)

 Well, it can't hurt, but as I explained above, it won't do anything useful
neither and just give you an error.

GC> Call me superstitious, but I'd rather remove my local copies of
GC> those branches, and then 'git fetch xanadu' in anticipation of
GC> a simple, clean fetch with no forced-update warnings.

 If you want to avoid these warnings, you'd need to destroy the entire
remote and then recreate it. It certainly can be done, but is absolutely
not worth it IMO.

 Worse, Git uses garbage collector instead of removing unused commits
immediately, so unless you use some cryptic commands (git-fsck etc), you
will still have the old commits somewhere in your .git/objects directory,
even if you won't have symbolic references to them any longer.

 Regards,
VZ

pgpFDJQlWcQay.pgp
Description: PGP signature