Re: [boost] [git] Near future.. How do we deal with git-native libraries?

Subject: Re: [boost] [git] Near future.. How do we deal with git-native libraries?
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2013-12-03 23:26:21

PS. I should say that it's rather important we come up with a good solution
for people to follow on this as it will likely be the standard way to move
newly accepted libraries into boost.

On Tue, Dec 3, 2013 at 9:48 PM, Rene Rivera <grafikrobot_at_[hidden]> wrote:

> On Tue, Dec 3, 2013 at 2:58 AM, Daniel James <daniel_at_[hidden]>wrote:
>
>> On 2 December 2013 19:47, Rene Rivera <grafikrobot_at_[hidden]> wrote:
>> > On Mon, Dec 2, 2013 at 2:44 AM, Daniel James <daniel_at_[hidden]>
>> wrote:
>> >
>> >> This has been discussed in the past. The existing repo will need to
>> >> remain as the super module refers to the hash values of its commits.
>> >> The suggested fix was to combine the two repos, since a git repo can
>> >> contain two separate trees. The old branches will need to be kept
>> >> alive by tagging them.
>> >>
>> >> I'd rather have kept the two separate by using a different name for
>> >> the converted repo (e.g. svn-predef), but no one agreed with me.
>> >>
>> >
>> > Since it seems that we need to BoostOrg repo.. My preference would be to
>> > slam the BoostOrg one with my canonical repo and only keep the BoostOrg
>> > repo around. Since the canonical one has more, and more accurate,
>> history
>> > than the BoostOrg one. But I don't know what the ramifications of such a
>> > move are.
>>
>> Sorry, I don't understand what you mean. Although what I wrote above
>> wasn't particularly comprehensible either. What I was trying to get at
>> is something like the following which stores both histories in a
>> single repo, but keeps them separate and makes yours the main
>>
>
> I think I understand that.. I can't "remove" the existing history (by
> replacing the repo with my other one) because the history is being used by
> tags. And hence the option you are proposing is to merge the two repos
> together and hiding away the SVN imported one. Which seems like a
> reasonable option for Predef since it doesn't have a long git history (but
> slightly longer and more detailed than the svn history).
>
>
>
>> branches. Afterwards the super-repo will need to be updated
>> accordingly. Maybe someone has a better idea?
>>
>> # Create clone containing both repos:
>> git clone git_at_[hidden]:boostorg/predef.git
>> cd predef
>> git remote add grafik git_at_[hidden]:grafikrobot/boost-predef.git
>> git fetch grafik
>>
>> # Save old branches, so old checkouts of the main module
>> # will still work:
>> git tag svn-develop origin/develop
>> git tag svn-master origin/master
>> git push --tags
>>
>> # Replace master, keeping some files from the old repo:
>> # (-B overwrite the local branch)
>> git checkout grafik/master -B master
>> git checkout svn-master -- .gitattributes index.html
>> git commit -m "Add files required for boost"
>> git push --force origin master
>>
>> # Replace develop with master as well,
>> # as grafik/predef doesn't have a develop branch
>> git checkout -b develop
>> git push --force origin develop
>>
>
> I must confess I don't understand the git commands.. But I do understand
> your comments of them. Am I to assume you've mostly tried them? I ask
> because I'm ok blindly following them once. But will likely fall flat on my
> face if something goes wrong :-)
>
>
>
> --
> --
> -- Grafik - Don't Assume Anything
> -- Redshift Software, Inc. - http://redshift-software.com
> -- rrivera/acm.org - grafik/redshift-software.com
> -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
>

-- 
-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo