[gmx-developers] creating a new branch in the main repository?
mark.j.abraham at gmail.com
Tue Feb 10 16:27:14 CET 2015
On Sun, Feb 8, 2015 at 9:28 PM, Szilárd Páll <pall.szilard at gmail.com> wrote:
> I thought, those branches on the main git.gromacs.org are supposed to
> be long-term feature branches that are aimed at merging in the future,
> but I could be wrong.
I don't think it matters too much, either way. If people want to clone and
don't want others' junk, they can clone from gerrit.gromacs.org, or use git
clone --single-branch. Being able to share some gromacs code and have it
backed up is just plain useful :-)
However, hosting non-gerrit feature branches on gromacs.org is
> something I support too!
> At some point in the past we discussed the question of keeping medium
> to long-term feature branches in some centralized location. IIRC the
> answer was that there's no need for a secondary server (like gitolite)
> and instead we sohuld use private branches in gerrit. Not sure if this
> ever worked, AFAIR I tried once and failed - the gerrit management
> interface is quite unfriendly (and that's an understatement).
I used some kind of per-user sandbox section to share a commit with
Michael, one time, but I forget the details.
> I would very much like to have reasonably easy way to keep such
> development branches maintained by (core?) devs on a central server. I
> can count at least a half dozen feature branches I worked with
> recently that live offline, in gerrit drafts, or in 100 PS long gerrit
> "review" changes (which isn't optimal either because history is
> impossible to follow). All these could have started out in such
> feature branches shared with a few devs with a lifetime of weeks to
> I myself keep ending up with dangling drafts and jungle of parents and
> dependent commits. Gerrit review and draft changes are clearly not a
> solution for such cases and keeping WIP branches offline is an obvious
> barrier to collaboration.
Gerrit's not great for collaborative development, as distinct from code
review. However, I'm not aware of an alternative that would also permit
using Jenkins. The knowledge that all the commits in the main branches
passed the tests of the day is very valuable, so even if we add some
merge-style development to our workflow, I think we should strive to keep
per-commit testing of the branch to be merged.
We can pick some upcoming feature and have a feature branch in gerrit and
see how it works, if you want. Probably we would want to prohibit any
rebasing of non-tip commits on that branch (else there's the
ripple-and-re-verify effect). But would that add value vs using a gerrit
topic branch? The latter is almost zero work...
> On Sat, Feb 7, 2015 at 3:47 AM, Mark Abraham <mark.j.abraham at gmail.com>
> > Hi,
> > Rossen is the guru here, but we administer git.gromacs.org via a
> > server. There are various private branches in gromacs.git to which people
> > have direct push access; only Gerrit can push to the main branches. So if
> > you let Rossen know what branch name would be good to create, and public
> > keys for whoever should have push access, that'll be fine.
> > Cheers,
> > Mark
> > On Sat, Feb 7, 2015 at 5:20 AM, Shirts, Michael R. (mrs5pt)
> > <mrs5pt at eservices.virginia.edu> wrote:
> >> Apologies if this should have been obvious and I could figure it out.
> >> I want to create a new branch in the main repository so I can share a
> >> particular functionality that will never make it into the main
> >> (too much complication, only useable in some very restrictive cases,
> >> story). I tried googling around, but couldn't find something that made
> >> sense. git push origin NEWBRANCH gave me a 'fatal: remote error: access
> >> denied or repository not exported: /gromacs.git' error - was this
> >> my permissions weren't set up right? Should I just set up a private
> >> branch?
> >> Thanks for any advice!
> >> Best,
> >> ~~~~~~~~~~~~
> >> Michael Shirts
> >> Associate Professor
> >> Department of Chemical Engineering
> >> University of Virginia
> >> michael.shirts at virginia.edu
> >> (434) 243-1821
> >> --
> >> Gromacs Developers mailing list
> >> * Please search the archive at
> >> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> >> posting!
> >> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >> * For (un)subscribe requests visit
> >> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> >> send a mail to gmx-developers-request at gromacs.org.
> > --
> > Gromacs Developers mailing list
> > * Please search the archive at
> > http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> > posting!
> > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> > * For (un)subscribe requests visit
> > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> > send a mail to gmx-developers-request at gromacs.org.
> Gromacs Developers mailing list
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> * For (un)subscribe requests visit
> or send a mail to gmx-developers-request at gromacs.org.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gromacs.org_gmx-developers