<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 10, 2015 at 5:03 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Tue, Feb 10, 2015 at 4:27 PM, Mark Abraham <<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>> wrote:<br>
><br>
><br>
> On Sun, Feb 8, 2015 at 9:28 PM, Szilárd Páll <<a href="mailto:pall.szilard@gmail.com">pall.szilard@gmail.com</a>> wrote:<br>
>><br>
>> 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>
><br>
><br>
> I don't think it matters too much, either way. If people want to clone and<br>
> don't want others' junk, they can clone from <a href="http://gerrit.gromacs.org" target="_blank">gerrit.gromacs.org</a>, or use git<br>
> clone --single-branch. Being able to share some gromacs code and have it<br>
> backed up is just plain useful :-)<br>
<br>
</span>Sure, it does not matter us sitting right next to the git server, but<br>
increasing the size of the repo will matter for devs across the<br>
continent and will result in lots of !@$#%^ :) - especially as most<br>
are likely used to simply do<br>
git clone git://<a href="http://git.gromacs.org/gromacs" target="_blank">git.gromacs.org/gromacs</a>.<br>
<br>
I'm not saying that using clone --single-branch is too difficult, just<br>
noting the drawbacks. A workaround would likely require setting up a<br>
different git server.</blockquote><div><br></div><div>There is only a handful of non-release branches being used in that repo, and while I'd love to see that change, I can't see it on the horizon yet. If download volume becomes a problem someone actually complains about, them we can start by making a backup and pruning all the old development branches.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
>> 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>
><br>
><br>
> I used some kind of per-user sandbox section to share a commit with Michael,<br>
> one time, but I forget the details.<br>
<br>
</span>Does anybody know how does that work - if it works at all? We need to<br>
set up asap a couple of feature branches to do close collaborative<br>
development and I'd like to decide weather it'll be bitbucket or<br>
there's a chance to have them hosted in-house.<br>
<span class=""><br>
>><br>
>> 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>
><br>
><br>
> Gerrit's not great for collaborative development, as distinct from code<br>
> review. However, I'm not aware of an alternative that would also permit<br>
> using Jenkins. The knowledge that all the commits in the main branches<br>
> passed the tests of the day is very valuable, so even if we add some<br>
> merge-style development to our workflow, I think we should strive to keep<br>
> per-commit testing of the branch to be merged.<br>
<br>
</span>I don't think I need per-commit testing of my feature branches and I<br>
think most others don't need it either. If we work with a couple of<br>
others closely on a feature, we just want to have a branch where we<br>
can push regularly without having to ditch commit history. Testing on<br>
Jenkins is easy, I can simply upload a squashed commit of the branch<br>
to gerrit as draft. As the feature branch is nearing its EOL, the same<br>
way it can be pushed up as a single/few commits to gerrit.</blockquote><div><br></div><div>Sounds like you actually want a distributed version-control system, rather than a centrally-hosted feature branch. We can certainly do/set up something like</div><div><br></div><div>git push gerrit local-feature-branch:user/sandbox/feature-branch</div><div><br></div><div>so that people can just get the code. They can't browse it or comment on it in the style of code review, but it serves the need of a publishing a branch where someone can get it. Two people can collaborate in pull-request workflow quite happily... that's what git was designed for, of course.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> We can pick some upcoming feature and have a feature branch in gerrit and<br>
> see how it works, if you want.<br>
<br>
</span>I'm not insisting on having it in gerrit, but I would very much like<br>
to use feature branches. Using gerrit drafts for collaborative feature<br>
development has proved to be awful and I really feel that it would be<br>
much more productive to use branches and when the feature stabilizes<br>
move the change to gerrit.</blockquote><div><br></div><div>Sure - but from the point of view of the blessed central repo, that branch is a non-entity unless it is merged into master. So the work-in-progress branch can exist anywhere its collaborators would like.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> Probably we would want to prohibit any<br>
> rebasing of non-tip commits on that branch (else there's the<br>
> ripple-and-re-verify effect). But would that add value vs using a gerrit<br>
> topic branch? The latter is almost zero work...<br>
<br>
</span>I'm not sure I get this last part, I am admittedly a bit lacking in<br>
advanced git knowledge.<br></blockquote><div><br></div><div>It's a gerrit feature, not git. For example, someone (probably me) put a bunch of your recent CUDA work onto the cuda topic, e.g. <a href="https://gerrit.gromacs.org/#/q/topic:cuda">https://gerrit.gromacs.org/#/q/topic:cuda</a> which is potentially useful for someone finding related work that is past. All you do is fill in the box below project and branch on gerrit after you upload (or use the right secret sauce when uploading). On the main page you can see "master (cuda)" for the "branch" for the remaining commit from that group.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
To conclude, I'm not trying to force anyone to change their work<br>
pattern, but there are a few smaller ongoing and about to start<br>
projects that I'd like do differently - and there seems to be interest<br>
from others in employing similar workflow.<br>
<br>
The barrier to this would perhaps be the branch management and access<br>
control, and AFAIR that's why it was the rather awkward gerrit-based<br>
solution that some proposed.<br>
<br>
Does anybody know of a reasonably simple alternative? One thing that<br>
comes to my mind is that if a gitolite (web?) management interface<br>
does exists, we could have that on top of <a href="http://git.gromacs.org" target="_blank">git.gromacs.org</a>.<br></blockquote><div><br></div><div>Seems like the thing we want is a lightweight way to share a branch, and perhaps to be able to comment on it on some website. github makes this easy, but I'm not sure what the best solution is for us.</div><div><br></div><div>Cheers,</div><div><br></div><div>Mark</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Cheers,<br>
--<br>
Szilárd<br>
<div class=""><div class="h5"><br>
> Mark<br>
><br>
>> Cheers,<br>
>> --<br>
>> Szilárd<br>
>><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>><br>
>> 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<br>
>> > gitolite<br>
>> > server. There are various private branches in gromacs.git to which<br>
>> > people<br>
>> > have direct push access; only Gerrit can push to the main branches. So<br>
>> > 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<br>
>> >> repository<br>
>> >> (too much complication, only useable in some very restrictive cases,<br>
>> >> 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<br>
>> >> 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><br>
>> >> 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><br>
>> > 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<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>