This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Merging glibc-ports repo
On 22/06/12 20:57, Joseph S. Myers wrote:
> On Fri, 22 Jun 2012, Allan McRae wrote:
>
>> Firstly, we need to prepare glibc-ports:
>>
>> git clone git://sourceware.org/git/glibc-ports.git
>> cd glibc-ports
>> mkdir ports
>> git mv Banner ChangeLog* data/ Makefile README sysdeps/ ports
>> git commit -a -m "Move all files into ports/ subdirectory in preparation
>> for merge with glibc"
>> git push
>>
>> At the stage, the glibc-ports repo should be closed for further commits.
>
> I don't like any approach that involves rearranging things inside the
> ports repository like that; that just seems likely to complicate things
> unduly for people with local changes in their ports checkouts (for
> example). Do this on a branch of the ports repository if you wish, but
> not on master.
>
> On master, just add a README.ports-moved-to-libc file explaining that
> master is now closed for new commits, and update the repository hooks to
> disallow further commits to master (while allowing commits to all other
> branches).
Sure. That can all be done on a local copy of the glic-ports repo. No
need to push the rearrangement at all.
> For whatever merge approach is used: after the merge, will "git shortlog
> glibc-2.16..HEAD" and similar give reasonable results (showing changes
> made since 2.16, including changes to the ports subdirectory after the
> 2.16 release of ports, but not all the older changes to the ports
> subdirectory that were made in the ports repository)? If not, is there a
> good way to set up tags so that it is easy to get a clear view of what has
> changed during 2.17 development, and to get the list of contributors for
> the 2.17 release announcement?
As far as I can tell... no. I will look into this further but I am not
hopeful as the tag names in the glibc and glibc-ports repos overlap.
One workaround would be if this merge was done _immediately_ after the
glibc-2.16 tag. Then the commit bringing in glibc-ports could just be
given its own tag. Not ideal, but it would only have to be used for a
single release.
Allan