[mpiwg-tools] Changes from Bordeaux to MPIR

Jeff Squyres (jsquyres) jsquyres at cisco.com
Fri Oct 9 08:12:30 CDT 2015


I think Wesley and I didn't talk about this specific case, to be honest.

(+Wesley)

Wesley: got any good ideas here?  I.e., how does a working group manage a bunch of individual Forum tickets internally, and then push them up -- individually -- up to the main mpi-forum repo?

I think it would be desirable for the working group to be able to make a PDF that represents all their collectively-agreed-upon PRs, but also be able to push those PRs individually up to the Forum (vs. pushing the entire union of all changes up to the Forum en masse).


> On Oct 9, 2015, at 8:34 AM, Marc-Andre Hermanns <hermanns at jara.rwth-aachen.de> wrote:
> 
> Hi Jeff,
> 
> oops. Fingers were faster than my brain. :/
> 
> I deleted all the things that I did _not_ screw up in my first email a
> minute ago.
> 
>>> It's common to make a new branch for every pull request that you file.
>>> 
>>> More specifically: it's a common Github newbie mistake to *not* make a separate branch for every PR.
>> 
>> So I can create a new branch. Say:
>> 
>> mpiwg-tools/mpir:issue_5_being_debugged
>> 
>> and then have your pull request be funneled into that new branch
>> instead of mpiwg-tools:mpir:mpir-1.x?
> 
> You basically already answered this below, sorry. So no, not possible. :-/
> 
>>> Consider: a PR is a request to pull in a bunch of commits to the
>>> target branch.  How do you specify *which* commits that you want to
>>> be pulled?  You make a branch.  *All* the commits on that branch --
>>> i.e., all the commits from the point where the branch was made to
>>> the tip of that branch -- are part of the PR.  Github is even smart
>>> enough such that *if you change the branch while the PR is open,
>>> the commits listed on the PR will automatically update*.  E.g., if
>>> you add more commits.  Or you rebase.  Or you squash commits.  Or
>>> rewrite the branch to have entirely new commits (vs. when you first
>>> created the PR).  ...and so on.
>>> 
>>> Hence, the branch I made is in *my* fork of the mpir repo.  If/when
>>> my PR is accepted (i.e., merged in), my commits will show up in the
>>> mpir repo on the mpir-1.x branch.
>>> 
>>> Make sense?
>> 
>> This is (I think what I want to prevent). I would like your changes to
>> _not_ show up in the mpir-1.x branch, but rather in
> 
> this is how this sentence should have ended:
> 
> ... mpiwg-tools/mpir:issue_5_being_debugged.
> 
> So then we directly have a branch that we can use for the pull request
> against mpi-forum/mpir:mpir-1.x
> 
> Cheers,
> Marc-Andre
> 
> 
> 
> -- 
> Marc-Andre Hermanns
> Jülich Aachen Research Alliance,
> High Performance Computing (JARA-HPC)
> Jülich Supercomputing Centre (JSC)
> 
> Schinkelstrasse 2
> 52062 Aachen
> Germany
> 
> Phone: +49 2461 61 2509 | +49 241 80 24381
> Fax: +49 2461 80 6 99753
> www.jara.org/jara-hpc
> email: hermanns at jara.rwth-aachen.de
> 
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools


-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/




More information about the mpiwg-tools mailing list