<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 8, 2015 at 9:28 PM, Szilárd Páll <span dir="ltr"><<a href="mailto:pall.szilard@gmail.com" target="_blank">pall.szilard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I thought, those branches on the main <a href="http://git.gromacs.org" target="_blank">git.gromacs.org</a> are supposed to<br>
be long-term feature branches that are aimed at merging in the future,<br>
but I could be wrong.<br></blockquote><div><br></div><div>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 <a href="http://gerrit.gromacs.org">gerrit.gromacs.org</a>, or use git clone --single-branch. Being able to share some gromacs code and have it backed up is just plain useful :-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However, hosting non-gerrit feature branches on <a href="http://gromacs.org" target="_blank">gromacs.org</a> is<br>
something I support too!<br>
<br>
At some point in the past we discussed the question of keeping medium<br>
to long-term feature branches in some centralized location. IIRC the<br>
answer was that there's no need for a secondary server (like gitolite)<br>
and instead we sohuld use private branches in gerrit. Not sure if this<br>
ever worked, AFAIR I tried once and failed - the gerrit management<br>
interface is quite unfriendly (and that's an understatement).<br></blockquote><div><br></div><div>I used some kind of per-user sandbox section to share a commit with Michael, one time, but I forget the details.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would very much like to have reasonably easy way to keep such<br>
development branches maintained by (core?) devs on a central server. I<br>
can count at least a half dozen feature branches I worked with<br>
recently that live offline, in gerrit drafts, or in 100 PS long gerrit<br>
"review" changes (which isn't optimal either because history is<br>
impossible to follow). All these could have started out in such<br>
feature branches shared with a few devs with a lifetime of weeks to<br>
months.<br>
I myself keep ending up with dangling drafts and jungle of parents and<br>
dependent commits. Gerrit review and draft changes are clearly not a<br>
solution for such cases and keeping WIP branches offline is an obvious<br>
barrier to collaboration.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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...</div><div><br></div><div>Mark</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
--<br>
Szilárd<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Sat, Feb 7, 2015 at 3:47 AM, Mark Abraham <<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> Rossen is the guru here, but we administer <a href="http://git.gromacs.org" target="_blank">git.gromacs.org</a> via a gitolite<br>
> server. There are various private branches in gromacs.git to which people<br>
> have direct push access; only Gerrit can push to the main branches. So if<br>
> you let Rossen know what branch name would be good to create, and public<br>
> keys for whoever should have push access, that'll be fine.<br>
><br>
> Cheers,<br>
><br>
> Mark<br>
><br>
> On Sat, Feb 7, 2015 at 5:20 AM, Shirts, Michael R. (mrs5pt)<br>
> <<a href="mailto:mrs5pt@eservices.virginia.edu">mrs5pt@eservices.virginia.edu</a>> wrote:<br>
>><br>
>> Apologies if this should have been obvious and I could figure it out.<br>
>><br>
>> I want to create a new branch in the main repository so I can share a<br>
>> particular functionality that will never make it into the main repository<br>
>> (too much complication, only useable in some very restrictive cases, long<br>
>> story). I tried googling around, but couldn't find something that made<br>
>> sense. git push origin NEWBRANCH gave me a 'fatal: remote error: access<br>
>> denied or repository not exported: /gromacs.git' error - was this because<br>
>> my permissions weren't set up right? Should I just set up a private<br>
>> branch?<br>
>><br>
>> Thanks for any advice!<br>
>><br>
>> Best,<br>
>> ~~~~~~~~~~~~<br>
>> Michael Shirts<br>
>> Associate Professor<br>
>> Department of Chemical Engineering<br>
>> University of Virginia<br>
>> <a href="mailto:michael.shirts@virginia.edu">michael.shirts@virginia.edu</a><br>
>> (434) 243-1821<br>
>><br>
>> --<br>
>> Gromacs Developers mailing list<br>
>><br>
>> * Please search the archive at<br>
>> <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before<br>
>> posting!<br>
>><br>
>> * Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
>><br>
>> * For (un)subscribe requests visit<br>
>> <a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or<br>
>> send a mail to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
><br>
><br>
><br>
> --<br>
> Gromacs Developers mailing list<br>
><br>
> * Please search the archive at<br>
> <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before<br>
> posting!<br>
><br>
> * Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
><br>
> * For (un)subscribe requests visit<br>
> <a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or<br>
> send a mail to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.</div></div></blockquote></div><br></div></div>