I also agree with separate branches for each library. For one thing, it takes less effort to make the branch stand alone, and there is less chance of messing things up.
Also, they don't get in the way as you are not forced to read the list, and can choose to track as many or few remote branches as they like.
How about using one branch per library, and tags for versions? That way everyone can track the development and even add things, but the versions are the things that 'lib and others like it go for.
The only thing I'm wondering about branches for libraries is: how do you find them if you're trying to fetch them via 'lib? I think only major changes need to be in their own branches, like the hygienic macro system. Everything else should either be hosted separately or in the lib folder.
The only thing I'm wondering about branches for libraries is: how do you find them if you're trying to fetch them via 'lib?
I can think of three scenarios:
1. You're using the public, published version of a library that also happens to be in your git repository.
2. You're using an unpublished version of a library in your git repository: for example, you're testing your code against the latest development version of a library to see if they work together.
3. You're working on a library.
For #3, I presume you'd just be using 'load.
For #2, if you want to for example get the latest version of a file "foo.arc" in the "foo" branch, you can use git for that, e.g.:
git show foo:foo.arc
For #1, you don't need to get the library out of git, you can use whatever mechanism we're all using to fetch and use a published library.
I was hoping to use a modified version of 'lib that would allow me to type
(lib binary)
when I meant
(load "lib/binary.arc")
It has the advantage of less typing, and hopefully the concept that functions are not reloaded unless the file has changed. If I'm trying to test a new version of a function, I would rather selectively reload that function than the whole library.
