[racket-dev] [plt] Push #26989: master branch updated

An hour and a half ago, Matthew Flatt wrote:
> 
> [...]

(Sorry, I meant it to just be informative, not to argue a point...  I
should have written a conclusion that it's fine to not redo the
reorganization commit.)


> >   pkgs/gui-pkgs/gui-lib/mred/installer.rkt
> >   pkgs/gui-pkgs/gui-lib/racket/gui/installer.rkt
> 
> This strikes me as actual history loss (due to many changes in a
> small file).

There could be a similar loss of lots of useful stuff: I'm guessing
that much of the stuff in pkgs/plt-services/meta/build will go away
soon, and if it's deleted before the repository split then it would be
lost -- and there are lots of small edits due of subtle OS related
things that would be very useful to keep around.

> > Going from the other direction, these are the files that existed
> > before the rename commit that do not appear anywhere in the lists
> > of rename chains:
> 
> Some are truly gone, and some are covered above. I don't understand
> why most of them are in the list, though, since `git follow --log'
> on each new location works for me (for the handful that I tried).

What I did was run a log with --follow over each file in the
repository, collect the results with these name histories in one file,
and the paths in this least are ones that don't appear anywhere in
this resulting file.  (I can put the file out somewhere if it'll help;
it took a long time to produce.)


> > I didn't do more of this because I realized that this is not too
> > useful now, with most (or all) of the bad detections happening in
> > the past.
> 
> Well, exactly.

(I think that these bad detections should be addressed, but not in
this commit.)


> So, for the big reorganization of the tree, we seem to be losing
> history (that separate move and change commits would clearly
> preserve) on only a couple of 40-line files. I am more than
> satisfied with that result, compared to what we get from day-to-day
> use of git --- and particularly compared to the pain of trying to
> stage moves before edits in the reorganization.

My worry about this commit is mostly gone.  There are some problematic
places but it's obviously better than past commits.  So no need to
re-do it (this commit).  I still disagree on the pains of moving
before splitting -- but not strongly and definitely not worth it to
discuss it again.

------

But one thing that I think is important is to still do the manual
thing: extract all the information before the split in some human
read-writeable way, manually go over it and identify proper renames
for all the obvious cases, then do the split based on this edited
information.  For example, the whole history of collects/meta/build
would be preserved in the distro-build even when the files are not
actually there.

And BTW, I can obviously do much of this work when the time for a
split comes.  It's going to be very tedious, but my guess is that for
anyone else it will be even more tedious and error prone.  (And BTW#2,
it's still something that I'm doing mostly because I got burned in the
past when I suggested and/or did things that lost history
information.)

But again: this is all for the future split, not for now, and I'm
definitely not saying that the reorganization should not be done.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!