[gmx-developers] creating a new branch in the main repository?
pall.szilard at gmail.com
Tue Feb 10 17:03:24 CET 2015
On Tue, Feb 10, 2015 at 4:27 PM, Mark Abraham <mark.j.abraham at gmail.com> wrote:
> 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 :-)
Sure, it does not matter us sitting right next to the git server, but
increasing the size of the repo will matter for devs across the
continent and will result in lots of !@$#%^ :) - especially as most
are likely used to simply do
git clone git://git.gromacs.org/gromacs.
I'm not saying that using clone --single-branch is too difficult, just
noting the drawbacks. A workaround would likely require setting up a
different git server.
>> 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.
Does anybody know how does that work - if it works at all? We need to
set up asap a couple of feature branches to do close collaborative
development and I'd like to decide weather it'll be bitbucket or
there's a chance to have them hosted in-house.
>> 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.
I don't think I need per-commit testing of my feature branches and I
think most others don't need it either. If we work with a couple of
others closely on a feature, we just want to have a branch where we
can push regularly without having to ditch commit history. Testing on
Jenkins is easy, I can simply upload a squashed commit of the branch
to gerrit as draft. As the feature branch is nearing its EOL, the same
way it can be pushed up as a single/few commits to gerrit.
> We can pick some upcoming feature and have a feature branch in gerrit and
> see how it works, if you want.
I'm not insisting on having it in gerrit, but I would very much like
to use feature branches. Using gerrit drafts for collaborative feature
development has proved to be awful and I really feel that it would be
much more productive to use branches and when the feature stabilizes
move the change to gerrit.
> 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...
I'm not sure I get this last part, I am admittedly a bit lacking in
advanced git knowledge.
To conclude, I'm not trying to force anyone to change their work
pattern, but there are a few smaller ongoing and about to start
projects that I'd like do differently - and there seems to be interest
from others in employing similar workflow.
The barrier to this would perhaps be the branch management and access
control, and AFAIR that's why it was the rather awkward gerrit-based
solution that some proposed.
Does anybody know of a reasonably simple alternative? One thing that
comes to my mind is that if a gitolite (web?) management interface
does exists, we could have that on top of git.gromacs.org.
>> 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
>> > gitolite
>> > 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
>> >> repository
>> >> (too much complication, only useable in some very restrictive cases,
>> >> long
>> >> 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
>> >> because
>> >> 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
>> >> or
>> >> 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
>> > or
>> > 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
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or
>> 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
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or
> send a mail to gmx-developers-request at gromacs.org.
More information about the gromacs.org_gmx-developers