The default branch is not a feature of GitHub, GitLab, etc. It's a feature of git itself. On the 'bare' repository, issue this command:
git symbolic-ref HEAD refs/heads/*mybranch* Effectively, this is what GitHub is doing. It should be possible to do with the Apache git host as well. On Thu, Aug 13, 2015 at 4:28 PM, Dan Bress <dbr...@onyxconsults.com> wrote: > Ah, I didn't realize that was a github only thing [1], I take-back my > early comment and can now see how this is confusing. > > [1] > http://mail-archives.apache.org/mod_mbox/nifi-dev/201501.mbox/%3CCALhtWke141nTsCdA4tHnZXOJ1UGhtZurLwvDsjBxH_G=86n...@mail.gmail.com%3E > > Dan Bress > Software Engineer > ONYX Consulting Services > > ________________________________________ > From: Joe Witt <joe.w...@gmail.com> > Sent: Thursday, August 13, 2015 4:22 PM > To: dev@nifi.apache.org > Subject: Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction > > Nope. That is just what is shown in github as the default. > On Aug 13, 2015 4:15 PM, "Dan Bress" <dbr...@onyxconsults.com> wrote: > > > +0. Our default branch is set to 'develop', so when you clone > apache-nifi > > from git, you are automatically looking at the 'develop' branch, right? > To > > me, this is a straight forward indicator of where I should be working. > > > > I thought we set this up a little while ago to avoid the confusion? > > > > Dan Bress > > Software Engineer > > ONYX Consulting Services > > > > ________________________________________ > > From: Ryan Blue <b...@cloudera.com> > > Sent: Thursday, August 13, 2015 4:04 PM > > To: dev@nifi.apache.org > > Subject: Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction > > > > +1 to removing the distinction. Master is the default branch in a lot of > > projects and I would argue that is the common expectation. It sounds > > like we can do gitflow without a separate develop branch (or at least it > > isn't too painful) so doing what new people tend to expect is a good > thing. > > > > rb > > > > On 08/13/2015 12:55 PM, Mark Payne wrote: > > > I think the issue here is less about gitflow being "hard" and more > about > > it being confusing. > > > We have had numerous people write to the dev list about why the thing > > that they checked out > > > doesn't have what they expect. > > > > > > Even being very experience with NiFi, I've cloned the repo a couple of > > times to new VM's > > > and forgotten to checkout develop before proceeding. > > > > > > I think that gitflow has its merits, but like any other avenue we go > > down, it's important to weigh > > > pros against cons. Frankly, I think that anything that leads to > > confusion for newcomers (thereby > > > discouraging community growth) had better have some very strong > benefits. > > > > > > That being said, I don't personally see a lot of benefit in this > > environment, so I would > > > be a +1 to remove the distinction between the two branches. > > > > > > > > > ---------------------------------------- > > >> Date: Thu, 13 Aug 2015 15:45:00 -0400 > > >> Subject: Re: [DISCUSS] Removal of the 'master' vs 'develop' > distinction > > >> From: a...@adamtaft.com > > >> To: dev@nifi.apache.org > > >> > > >> The difficulties of using the gitflow workflow and the release process > > can > > >> be significantly reduced with good tooling. I'm currently using the > > >> jgit-flow [1][2] maven plugin with very good success. It handles and > > >> manages feature, release, and hotfix branches seemlessly. And it > avoids > > >> common problems with the normal maven release plugin for gitflow. > > >> > > >> Before abandoning gitflow, the community should seriously consider > > tooling > > >> that makes it more usable. I'm not going to argue the merits of gitlab > > >> flow or any other workflows. But clearly, abandoning gitflow because > > it's > > >> "hard" is likely the wrong driver, if tooling exists to make it > better. > > >> > > >> [1] > > >> > > > http://blogs.atlassian.com/2013/05/maven-git-flow-plugin-for-better-releases/ > > >> > > >> [2] https://bitbucket.org/atlassian/jgit-flow/wiki/Home > > >> > > >> > > >> > > >> > > >> On Thu, Aug 13, 2015 at 2:58 PM, Bryan Bende <bbe...@gmail.com> > wrote: > > >> > > >>> If we worked on master and had a prod branch that was the last > release, > > >>> then we have the same thing we do now, just with different names. > This > > >>> would be GitLab Flow as Brandon pointed out. > > >>> > > >>> That being said, I don't have experience with the release process, > and > > >>> maybe the prod branch does not provide any value for us. The prod > > branch > > >>> would normally be used to create quick fix branches based off > > production, > > >>> or when doing automated/continuous deployments to a production > system, > > but > > >>> if we aren't doing either of those things then maybe it is not worth > > it. > > >>> > > >>> -Bryan > > >>> > > >>> On Thu, Aug 13, 2015 at 2:23 PM, Brandon DeVries <b...@jhu.edu> > wrote: > > >>> > > >>>> Personally, I still think GitLab Flow[1] is all we need for us to be > > >>> Really > > >>>> Useful Engines. > > >>>> > > >>>> [1] https://about.gitlab.com/2014/09/29/gitlab-flow/ > > >>>> > > >>>> Brandon > > >>>> > > >>>> On Thu, Aug 13, 2015 at 2:15 PM Joe Witt <joew...@apache.org> > wrote: > > >>>> > > >>>>> Resending > > >>>>> On Aug 13, 2015 12:22 PM, "Joe Witt" <joe.w...@gmail.com> wrote: > > >>>>> > > >>>>>> Team, > > >>>>>> > > >>>>>> It was proposed by Ryan Blue on another thread that we consider > > >>>>>> dropping the master vs develop distinction. In the interest of > his, > > >>>>>> in my view, very good point I didn't want it to get buried in that > > >>>>>> thread. > > >>>>>> > > >>>>>> [1] is the thread when we last discussed gitflow/develop/master on > > >>>>>> entry to the incubator. > > >>>>>> > > >>>>>> And from that thread here is the part I wish I had better > understood > > >>>>>> when the wise Mr Benson said it: > > >>>>>> > > >>>>>> "Another issue with gitflow is the master branch. The master > branch > > >>> is > > >>>>>> supposed to get merged to for releases. The maven-release-plugin > > >>> won't > > >>>>>> do that, and the jgitflow plugin is unsafe. So one option is to > 'use > > >>>>>> gitflow' but not bother with the master versus develop > distinction, > > >>>>>> the other is to do manual merges to master at release points." > > >>>>>> > > >>>>>> I think we should follow this guidance: "'use gitflow' but not > > bother > > >>>>>> with the master versus develop distinction". I say this from > having > > >>>>>> done the release management job now a couple of times including > > >>> having > > >>>>>> done a 'hotfix'. > > >>>>>> > > >>>>>> My comments here are not a rejection of that master/develop > concept > > >>> in > > >>>>>> general. It is simply pointing out that for the Apache NiFi > > >>> community > > >>>>>> it is not adding value but is creating confusion and delay [2]. > > >>>>>> > > >>>>>> Thanks > > >>>>>> Joe > > >>>>>> > > >>>>>> [1] http://s.apache.org/GIW > > >>>>>> [2] Sir Topham Hatt - Thomas and Friends (tm) > > >>>>>> > > >>>>> > > >>>> > > >>> > > > > > > > > > > > > -- > > Ryan Blue > > Software Engineer > > Cloudera, Inc. > > >
