[racket-dev] Splitting the Racket repository

On Sat, Nov 29, 2014 at 8:30 PM, Sam Tobin-Hochstadt
<samth at cs.indiana.edu> wrote:
> On Sat, Nov 29, 2014 at 8:16 PM, Eli Barzilay <eli at barzilay.org> wrote:
>> On Sat, Nov 29, 2014 at 7:14 PM, Sam Tobin-Hochstadt
>> <samth at cs.indiana.edu> wrote:
>>>
>>> All the history for the code has been preserved, and for code that
>>> dates back before 2005, the history is extended back to the original
>>> CVS repository. See https://github.com/racket/games/ for an example of
>>> this.
>>
>> There's a failure in the import -- if you look at the commits of this
>> repo (https://github.com/racket/games/commits/master), then starting
>> from Robby's commit from Jul 17 ("add a contract to make-card...") and
>> going back, the "original commit" references are all bogus.
>
> For packages with old history, the shas are in reference to
> https://github.com/samth/old-plt-new/ (which should maybe have a
> better name).

Yeah, very bad name but an even worse location...  Since this is a major
reorganization it would also be a reasonable to do a forced push of that
thing to the main repository so the references make sense.  (This is
assuming that you cannot refer to the proper commits in the current repo
for some reason.)  If all else fails, you should at least include in the
commits some pointer to a repo that has it.

(Sounds picky, but having no reliable history is one thing that can make
a company avoid using it.)


>> Any reason they are not git modules?  (They've improved a lot, and
>> they're even supported in github as links as long as they point to
>> other GH repos.  See for example:
>> https://github.com/elibarzilay/test)
>
> The goal is to have packages that are in the main distribution not
> have a particular special status, beyond being in the list of things
> that gets put in the distribution.

I'm not talking about the distribution here -- just some meta repository
that has everything in it in a convenient way for the people who have
code in there.  (And assuming that this meta repository will build with
all of these packages that still not be related to a distribution.)

(A different issue is organizing distributions: at some point in the
past I pointed at the fact that git modules could be used for this,
essentially being a collection of pointers to code that is included.
But that bus has long gone, so I'm definitely not talking about that.)


> Also, a situation where you have to update two things when you do a
> commit is not ideal.

I absolutely agree with that.  Probably even more than you do, and
certainly for a much longer time (that's the essense of my
bundle-related rants years ago about spaghetti dependencies).

I suppose that you're worrying about modules making it easy to do such
cross-repo commits -- but it's no easier than just having a bunch of
repos and doing a commit over them simultaneously.  So it's as doable,
and in both cases will be awkward enough to make it clear to the
committer that something is wrong.


>>> To clone individual repositories, use the new `--clone` option for
>>> `raco pkg`, such as:
>>> [...]
>>
>> This is very obscure.  Is there a compact description of what to do
>> when you want to make a change in a file that is not on the main
>> repo?
>
> You just need to edit and change the relevant repository -- nothing
> else is required. You don't have to use --clone or any other
> mechanism.  [...]

This doesn't answer my question -- so I think that I wasn't clear
enough.  Say that I have some change to a specific file.  I want to know
how to do it in the following two ways:

1. Get the equivalent of the whole distribution in the form of a bunch
   of repositories, including the repository that I want to change.  I
   make the change in the file, re-build, test things out, and
   eventually push.

   This is the way that is more relevant for internal people, and I
   suppose that there would be some script that will do all of that.
   (The equivalent of a toplevel `make').

2. The thing that is more relevant for others (and that's the important
   one): I have a normal installation, I find a bug -- what do I do now?
   I can't just report the bug, the file, and my patch since that's
   using a path in the distribution that is mostly unrelated to the
   source repo for the file.

   Ideally, there would be some way to turn some containing directory
   into a repository so I can commit my change, and push it to a fork to
   do a PR.  But that's a little extreme -- so what I'm talking about is
   more like a way to say: get this repository and use it instead of the
   stuff in my distribution, so I can work and push from that.

   I'm guessing that this is the intention behind that command, but it's
   obscure since it's not obvious what to do.  (And obviousness is
   important to encourage contributions.)

   As a concrete example: I find a bug in a file like
   "share/pkgs/games/gcalc/gcalc.rkt" and want to fork, edit, and push a
   fix.  What do I do?

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