<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 10, 2015 at 7:55 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"><div class=""><div class="h5">On Tue, Feb 10, 2015 at 6:52 PM, Mark Abraham <<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>> wrote:<br>
><br>
><br>
> On Tue, Feb 10, 2015 at 5:03 PM, Szilárd Páll <<a href="mailto:pall.szilard@gmail.com">pall.szilard@gmail.com</a>><br>
> wrote:<br>
>><br>
>> 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>><br>
>> 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>><br>
>> > 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<br>
>> > 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<br>
>> > git<br>
>> > clone --single-branch. Being able to share some gromacs code and have it<br>
>> > backed up is just plain useful :-)<br>
>><br>
>> 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.<br>
><br>
><br>
> There is only a handful of non-release branches being used in that repo, and<br>
> while I'd love to see that change, I can't see it on the horizon yet. If<br>
> download volume becomes a problem someone actually complains about, them we<br>
> can start by making a backup and pruning all the old development branches.<br>
<br>
</div></div>It has been an issue, and people have complained.<br></blockquote><div><br></div><div>OK. As already described, there are other solutions besides exacting a non-binding promise that any proposed branch in gromacs.git will lead to code added to the main repo. I just want people to write code and be happy :-)</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">
(Off topic, but: I don't believe in the "[it] becomes a problem<br>
someone actually complains about" -- IMO it does not work, especially<br></blockquote><div><br></div><div>If something's a problem for someone, but not so much of a problem that they can't write a polite request for something better, then it's not a problem for them that we need to solve in advance.<br></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">
with the increasingly internalized/private dev channels.)</blockquote><div><br></div><div>:-) Letting people have branches somewhere promotes collaboration.</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"><div><div class="h5">
>> >> 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<br>
>> > Michael,<br>
>> > one time, but I forget the details.<br>
>><br>
>> 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>
>><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<br>
>> > keep<br>
>> > per-commit testing of the branch to be merged.<br>
>><br>
>> 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.<br>
><br>
><br>
> Sounds like you actually want a distributed version-control system, rather<br>
> than a centrally-hosted feature branch. We can certainly do/set up something<br>
> like<br>
<br>
</div></div>More or less, but I personally only want the which is share-able part.<br>
I don't care where is it hosted, I just considered a benefits to have<br>
it stored centrally by gmx servers.</blockquote><div><br></div><div>Roland's /refs/privates suggestion does that, and nobody but the author and their friends need to know where to go get the code or how to set up a branch (I think), so that sounds perfect.</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="">
> git push gerrit local-feature-branch:user/sandbox/feature-branch<br>
><br>
> so that people can just get the code. They can't browse it or comment on it<br>
> in the style of code review, but it serves the need of a publishing a branch<br>
> where someone can get it.<br>
<br>
</span>Sure, but last time I tried I failed miserably at setting up such a<br>
private branch. Perhaps it's only challenging to me, but honestly, I<br>
have not heard many people use it. :)<br>
<span class=""><br>
> Two people can collaborate in pull-request<br>
> workflow quite happily... that's what git was designed for, of course.<br>
<br>
</span>I don't think pull requests are ideal for close collaboration, pull<br>
requests seems to be tailored for the high latency very distributed<br>
collaborative development. There it's often the receiver's problem if<br>
e.g. the branch has already moved on and extra conflict resolution is<br></blockquote><div><br></div><div>High latency is just a problem for merge resolution, e.g. the many rebases of the work to remove md-vv iterated constraints. The choice of merge vs rebase vs whatever workflow doesn't matter.</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">
needed while merge issues in close collaboration can typically be<br>
resolved easier/quicker.</blockquote><div><br></div><div>I'm confused. If the collaboration is close, more than one person will commit, merging will somehow be a pain, and you don't want to rebase patch series gerrit-style, how are you actually planning to collaborate? Shared code development is intrinsically difficult; a plan for how to do it can reduce the pain, but the lunch just cannot be free.</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<br>
>> > and<br>
>> > see how it works, if you want.<br>
>><br>
>> 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.<br>
><br>
><br>
> Sure - but from the point of view of the blessed central repo, that branch<br>
> is a non-entity unless it is merged into master. So the work-in-progress<br>
> branch can exist anywhere its collaborators would like.<br>
<br>
</span>Exactly. I as a "collaborator" asked if we could host such a repo on<br>
the gmx infrastructure.</blockquote><div><br></div><div>Sure, we have them already in gerrit's /refs/private, now that Roland's prompted my memory.</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>
>> I'm not sure I get this last part, I am admittedly a bit lacking in<br>
>> advanced git knowledge.<br>
><br>
><br>
> It's a gerrit feature, not git. For example, someone (probably me) put a<br>
> bunch of your recent CUDA work onto the cuda topic, e.g.<br>
> <a href="https://gerrit.gromacs.org/#/q/topic:cuda" target="_blank">https://gerrit.gromacs.org/#/q/topic:cuda</a> which is potentially useful for<br>
> someone finding related work that is past. All you do is fill in the box<br>
> below project and branch on gerrit after you upload (or use the right secret<br>
> sauce when uploading). On the main page you can see "master (cuda)" for the<br>
> "branch" for the remaining commit from that group.<br>
<br>
</span>I knew about "topic"s but not sure what's "branch" about them. I guess<br>
I'll chew on this and get back later.<br></blockquote><div><br></div><div>As you know, a branch is a basic git feature - you have a series of parent-child commits and you can choose to give it a name. A gerrit topic is a set of patches that have a common theme. Often, both will go together, because later things in the theme depend on other things in the theme, thus "gerrit topic branch." For example, I used one called g-tune-pme-reform, but the low of enthusiasm for reviewing the code changes meant it went nowhere.</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">
Re: "value vs using a gerrit topic branch"<br>
In gerrit I see branches as inherently single-commit length (you can't<br>
post a fix without squashing it) with any additional dependent changes<br>
chained exponentially increasing the pain of maintaining things - at<br>
least this is my experience.</blockquote><div><br></div><div>OK, but if you don't want to use pull requests or gerrit-style patch updates, how are you going to work collaboratively?</div><div><br></div><div>Mark</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="">
><br>
>> 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>
><br>
><br>
> Seems like the thing we want is a lightweight way to share a branch, and<br>
> perhaps to be able to comment on it on some website. github makes this easy,<br>
> but I'm not sure what the best solution is for us.<br>
<br>
</span>Commenting is not a deal-breaker feature - at least not to me. Sure,<br>
github work, so does bitbucket.<br>
--<br>
Szilárd<br>
<div class=""><div class="h5"><br>
> Cheers,<br>
><br>
> Mark<br>
><br>
>><br>
>> Cheers,<br>
>> --<br>
>> Szilárd<br>
>><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.<br>
>> >> > So<br>
>> >> > if<br>
>> >> > you let Rossen know what branch name would be good to create, and<br>
>> >> > 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<br>
>> >> >> out.<br>
>> >> >><br>
>> >> >> I want to create a new branch in the main repository so I can share<br>
>> >> >> 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<br>
>> >> >> made<br>
>> >> >> sense. git push origin NEWBRANCH gave me a 'fatal: remote error:<br>
>> >> >> 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><br>
>> >> >> 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>
>> >> >><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><br>
>> >> > 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>
>> >> ><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><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>