The git repo is now populated with the new tag and branch names. The ASF repo is here:
https://git-wip-us.apache.org/repos/asf/incubator-daffodil.git The GitHub mirror is: https://github.com/apache/incubator-daffodil You can now create a GitHub fork of the mirror and add your fork and the ASF repo as remotes to your existing repo. As a reminder, the code contributor workflow for is available here: https://cwiki.apache.org/confluence/display/DAFFODIL/Code+Contributor+Workflow - Steve On 10/25/2017 09:47 AM, John D. Ament wrote: > The writable URL is > https://git-wip-us.apache.org/repos/asf/incubator-daffodil.git > > John > > On Wed, Oct 25, 2017 at 9:46 AM John D. Ament <[email protected] > <mailto:[email protected]>> wrote: > > You should have access. I believe I created it upon request. > > John > > On Wed, Oct 25, 2017 at 8:07 AM Steve Lawrence <[email protected] > <mailto:[email protected]>> wrote: > > It looks like someone has already created an empty repo for us: > > https://git-wip-us.apache.org/repos/asf?p=incubator-daffodil.git > > And the github mirror: > > https://github.com/apache/incubator-daffodil > > I haven't tried pushing anything yet so I'm not sure if we have > permissions. > > - Steve > > On 10/25/2017 08:04 AM, John D. Ament wrote: > > All, > > > > Do you want to aim to get a repo created on the ASF side? > > > > John > > > > On Wed, Oct 25, 2017 at 7:10 AM Steve Lawrence > <[email protected] > <mailto:[email protected]>> wrote: > > > >> Yes, branches/tags are essentially renamed. All commit hashes > stay the > >> same. I've made the changes and pushed a test repo to my github: > >> > >> https://github.com/stevedlawrence/daffodil-new.git > >> > >> If you want to test this, you should be able to add this as a new > remote > >> and see the new branch names/tags. > >> > >> This renames all version branches to 'support/vN.N.x', all > release tags > >> to 'rel/vN.N.N', and all pre-release tags to 'vN.N.N'. Tags are > also now > >> signed in accordance with the tag/branch workflow. > >> > >> If this looks good, I can push it to the ASF repo and we can start > >> transitioning to that + github for the new workflow. > >> > >> - Steve > >> > >> On 10/25/2017 01:26 AM, Mike Beckerle wrote: > >>> So branches can just be renamed right? > >>> > >>> What I care about is the branches and the commit hashes. If > those are > >> preserved, then the tags don't matter much to me. > >>> > >>> > >>> > >>> -------- Original message -------- > >>> From: Steve Lawrence <[email protected] > <mailto:[email protected]>> > >>> Date: 10/24/17 12:01 PM (GMT-07:00) > >>> To: [email protected] <mailto:[email protected]>, > Mike > Beckerle <[email protected] <mailto:[email protected]>> > >>> Subject: Re: Import of Code to ASF Infrastructure > >>> > >>> The problem is you really can't delete tags in git, so now is > really the > >>> best time to do it since we're moving repos. > >>> > >>> Is the disruption having to move your local review branches from > one > >>> repo to another? If so, I think I found a decent solution to > make a > >>> clean cut over with just a handful of commands: > >>> > >>> Make sure all your changes are committed to a review branch in > your old > >>> repo. Move your current repo to a backup location: > >>> > >>> $ mv daffodil.git daffodil-ncsa.git > >>> > >>> Now clone the ASF git repo that will contain only the new > tags/branches, > >>> this will be the new git repo: > >>> > >>> $ git clone ${PATH_TO_APCHE_REPO_TBD} daffodil.git > >>> $ cd daffodil.git > >>> > >>> Add your local backup daffodil NCSA repo as a remote, specifying > no > tags > >>> and all the review branches you want via the -t option. There > should be > >>> one -t option for each branch: > >>> > >>> $ git remote add --no-tags -t review-sdl-123 -t review-sdl-456 > -t > >>> review-sdl-789 local-daffodil-ncsa ../daffodil-ncsa.git/ > >>> $ git fetch local-daffodil-ncsa > >>> > >>> Create a local branch for each of the fetched review branches: > >>> > >>> $ for BRANCH in `git branch -r`; do git branch `echo $BRANCH | > cut -d/ > >>> -f2` $BRANCH; done > >>> > >>> Now remove the old local-daffodil-ncsa remote: > >>> > >>> $ git remote remove local-daffodil-ncsa > >>> > >>> You should just be left with all the new tags/branches and your > review > >>> branches. > >>> > >>> Does that seem like a reasonable way to cutover without too much > >>> disruption? I could turn this into a script that will do the > cutover > >>> automatically if that would make things easier? > >>> > >>> - Steve > >>> > >>> On 10/24/2017 01:19 PM, Mike Beckerle wrote: > >>>> This will be massively disruptive to me. I have like 7 or 8 > >> outstanding branches right now. > >>>> > >>>> > >>>> How about we add the new tags and branches and leave the old > ones > there > >> for now. > >>>> > >>>> > >>>> > >>>> ________________________________ > >>>> From: Steve Lawrence <[email protected] > <mailto:[email protected]>> > >>>> Sent: Tuesday, October 24, 2017 11:48:35 AM > >>>> To: [email protected] <mailto:[email protected]> > >>>> Subject: Import of Code to ASF Infrastructure > >>>> > >>>> An issue came up on the Apache Legal bug tracker that has a > similar > >>>> situation to ours. > >>>> > >>>> https://issues.apache.org/jira/browse/LEGAL-339 > >>>> > >>>> Apache Heron is in a similar stage to us in incubation. They are > working > >>>> to transition over to the ASF infrastructure. Their original > code is > >>>> under a permissive license (Apache v2), but they do not have > SGAs in > >>>> place yet, and they wanted to know if they could import their > code to > >>>> ASF. The result of the issue is that since the code is under a > >>>> permissive license, it is okay to import the code to the ASF > git, and > >>>> just not change any license headers yet. Once the remaining SGAs > are in > >>>> place we can change the headers. We can even do releases, but > it will > >>>> prevent graduation, but I suspect we'll have SGAs in place > before our > >>>> first ASF release. > >>>> > >>>> Related, I was thinking that if we were to do it, now would be > a good > >>>> time to rename all the old branches and tags to use the new > Branch > & Tag > >>>> workflow [1] so that all future tags/branch are consistent with > the old. > >>>> This would just mean that all rc/alpha tags would have a 'v' > prepended > >>>> (e.g. 1.0.0-rc1 -> v1.0.0-rc1), all other tags have 'rel/v' > (e.g. > 1.0.0 > >>>> -> rel/v1.0.0), and all branches have a 'support/v' prepended > and the > >>>> last digit becomes an 'x' (e.g 1.0.0 -> support/v1.0.x). This > won't > >>>> change what the tags/branches point to, just changes their > names. > >>>> > >>>> Since this would mean the tags change (which git tends to > avoid), this > >>>> will mean that we should all clone the new repo and work out of > that, no > >>>> longer using our old clones. This will ensure no old tags stick > around. > >>>> For any ongoing work, something like git format-patch would be > a good > >>>> method to get the changes to the new repo. > >>>> > >>>> Any thoughts/concerns with this? > >>>> > >>>> - Steve > >>>> > >>>> > >>>> [1] > >>>> > >> > > https://cwiki.apache.org/confluence/display/DAFFODIL/Branch+and+Tag+Workflow > >>>> > >>> > >>> > >> > >> > > >
