This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi! On Mon, 16 Apr 2012 14:16:21 -0400, Mike Frysinger <vapier@gentoo.org> wrote: > On Monday 16 April 2012 13:37:48 Carlos O'Donell wrote: > > * If a port isn't maintained we should remove it from the tree. You > > can use source control to resurrect it. > > in general, i agree > > > * glibc v.s. glibc-ports is an artificial distinction that we should kill. > > would be nice I agree to both. > > * Move glibc-ports back into glibc under ports/ so I can stop dealing > > with two repos. > > i like this too, except i'm not sure if there's a way to do it without losing > history :( It goes like this: $ git fetch -n sourceware.org:/git/glibc-ports.git master:ports/master $ git merge --no-commit -s ours ports/master $ git read-tree -u --prefix=ports/ ports/master $ git commit -a The first command imports ports' history into ports/master. Then, this is merged into the current branch (but without really merging the files in the checked out tree, which would result in conflicts). Then, ports/master's content is (cumulatively) read into ports/. Next, commit it all, resulting in a merge commit that makes glibc-ports available in ports/. > > * Some day in the future we move all machines into ports/ leaving > > generic code outside of ports. If ports is good enough for ARM it's > > good enough for everything else, and using ports/ day-to-day will > > ensure it doesn't bit-rot. > > sounds reasonable Indeed does make some sense to me, too. All the different OSes/architectures are ports of glibc. GrÃÃe, Thomas
Attachment:
pgp00000.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |