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]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]