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]> 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]> > > Date: 10/24/17 12:01 PM (GMT-07:00) > > To: [email protected], Mike Beckerle <[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]> > >> Sent: Tuesday, October 24, 2017 11:48:35 AM > >> To: [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 > >> > > > > > >
