I don't recall any discussion of the status of existing svn non-release branches (most of which were named LUCENE-<Jira#>)... was it decided to just abandon them or are they hidden somewhere now in git/github?
And is the new policy to encourage such branches in git/github or that people should keep them in private forks? -- Jack Krupansky On Thu, Feb 4, 2016 at 1:32 AM, Shai Erera <[email protected]> wrote: > I think that all remote branches should be JIRA related. I.e. I don't see > myself pushing a remote branch like shaie/something. Since we do all > development through JIRA, then if someone experiments with something and > wants to push it to the Git repo, I think that should be done within the > context of a JIRA issue. > > Naming these branches *jira/lucene-XXXX* or *jira/solr-XXXX* (I don't > mind if we use hyphen or underscore) or dropping the *jira/* prefix -- > I'm fine w/ both. I personally don't think that we need the JIRA prefix, > since it's pretty obvious to tell by the name of the branch, but I can go > either way. > > Shai > > On Thu, Feb 4, 2016 at 12:01 AM [email protected] < > [email protected]> wrote: > >> Establishing conventions and adhering to them would be good. >> >> Some observations I have with your example: you suggested a hypothetical >> branch named "dweiss/jira3826". IMO that branch name isn't a great name >> because it is ambiguous with respect to it being for Lucene or Solr. Most >> of our branches in the past have been in the format for the JIRA issue; >> sometimes lowercased or sometimes with an underscore. It'd be nice to >> standardize that. I propose the form "solr_3626" but I care little and >> only would like to see something adhered to. Incorporating a branch for a >> JIRA issue with someone's user id is I think questionable, but I have no >> strong opinion. I think we should generally do it or not do it. >> >> ~ David >> >> >> On Wed, Feb 3, 2016 at 5:00 AM Dawid Weiss <[email protected]> wrote: >> >>> Hey folks. Just noticed new branches are being pushed to the Apache >>> repository. Having digested SVN's branches I'd like to suggest a >>> naming convention for branches so that they appear more palatable. For >>> example: >>> >>> $ git branch -r >>> origin/HEAD -> origin/master >>> origin/apiv2 >>> origin/branch_3x >>> origin/branch_4x >>> origin/branch_5x >>> origin/lucene-6835 >>> origin/master >>> origin/master-solr-8621 >>> >>> >>> The labels (branches and tags) in git can be pseudo-hierarchical. It >>> is therefore nice to see more "semantic" branches, like: >>> >>> origin/jira/solr8621 >>> origin/dweiss/fooBarExperiment >>> origin/staging/lucene-solr-x.y.z >>> >>> I don't think it's realistic to enforce any rigid convention, but I'm >>> sure you get the gist. >>> >>> These branches are no different to regular, they're just labeled with a >>> slash: >>> >>> # checkout a given branch/ commit (master here) and create a branch from >>> it. >>> git checkout master -b dweiss/jira3826 >>> # push this branch to origin and make it track changes on the origin's >>> pushed branch. >>> git push origin HEAD -u >>> >>> This is a suggestion only, not a requirement, but I'm sure you'll grow >>> to like it. The upside is that everyone then knows whether it's your >>> experimental stuff, something still being worked on, etc. >>> >>> Dawid >>> >>> P.S. There is always a way to "rename" a branch -- it is a label >>> attached to a commit after all -- I'll leave these commands for you to >>> digest: >>> >>> git checkout master-solr-8621 -b jira/solr8621-master >>> git push origin HEAD -u >>> # remove local branch >>> git branch -D master-solr-8621 >>> # remove remote branch (use *only* on the stuff you actually control >>> and merged back or abandoned) >>> git push origin :master-solr-8621 >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> -- >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >> http://www.solrenterprisesearchserver.com >> >
