On Oct 08, 2013, at 12:39 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> though I'd generally expect you to only be pushing to upstream when creating branches for releases and whatnot, not pull requests (I'm not sure that you even _can_ create pull requests to the main repo from branches on the main repo).

Git has no concept of pull requests. It's basically a Git workflow. So no, you cannot create pull requests. But that might not be what you're saying?

--
/Jacob Carlborg

On 8 Oct 2013, at 13:54, Jacob Carlborg wrote:
> On Oct 08, 2013, at 12:39 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>
>> though I'd generally expect you to only be pushing to upstream when creating
>> branches for releases and whatnot, not pull requests (I'm not sure that you
>> even _can_ create pull requests to the main repo from branches on the main
>> repo).
> 
> Git has no concept of pull requests. It's basically a Git workflow. So no, you cannot create pull requests. But that might not be what you're saying?

Jonathan was talking about making GitHub pull request from one branch of the repo to another, and yes, you can do that (just use the "New Pull Request" button on the Pull Request tab).

David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Tuesday, October 08, 2013 11:35:37 Jacob Carlborg wrote:
> On Oct 08, 2013, at 10:18 AM, Walter Bright <walter@digitalmars.com> wrote:
> > Because I often need to amend a pull request, and I was told it was done with:
> > 
> > git --amend -a
> > git push -f
> > 
> > and I've been doing that successfully since I've been doing PR's.
> 
> I'm not sure how your workflow is but if you need to amend a pull request I would think you would do something like this:
> 
> 1. Merge the pull request on your local machine
> 2. Make your changes and amend
> 3. Push to your own fork at Github (origin) or push to upstream if the pull
> request should be merged into master. No need to use "push -f"

You need push -f if you rebased. Otherwise, you shouldn't need it. Certainly, you shouldn't be using -f unless you actually need to, otherwise you risk forcing pushes that you don't actually want to succeed.

- Jonathan M Davis
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 8 okt 2013, at 21:00, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> You need push -f if you rebased. Otherwise, you shouldn't need it. Certainly, you shouldn't be using -f unless you actually need to, otherwise you risk forcing pushes that you don't actually want to succeed.


I don't see why amending a pull request requires push -f. I mean, he won't have access to the repository where the pull request originated from. So he can only chose to push to upstream or he's own repository. In both of these cases he doesn't need push -f. Unless he merged the pull request via Github.

Or he's amending his own pull request. I didn't think of that. Then push -f will be necessary.

-- 
/Jacob Carlborg

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 10/8/13 12:46 PM, Jacob Carlborg wrote:
> On 8 okt 2013, at 21:00, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>
>> You need push -f if you rebased. Otherwise, you shouldn't need it. Certainly,
>> you shouldn't be using -f unless you actually need to, otherwise you risk
>> forcing pushes that you don't actually want to succeed.
>
>
> I don't see why amending a pull request requires push -f. I mean, he won't have access to the repository where the pull request originated from. So he can only chose to push to upstream or he's own repository. In both of these cases he doesn't need push -f. Unless he merged the pull request via Github.
>
> Or he's amending his own pull request. I didn't think of that. Then push -f will be necessary.
>

An amend is a history rewrite, even if a small one.  If the amended commit ever made it out of his tree into github, a -f is necessary.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 10/8/2013 4:36 AM, Jacob Carlborg wrote:
> On Oct 08, 2013, at 10:26 AM, Brad Roberts <braddr@puremagic.com> wrote:
>
>> The fix was merely repushing the commit id of the previously head of master back as the current head
>> of master. Something internal to github's management of pulls got confused at that point. So far,
>> no response to my support request.
>
> As I replied to Walter:
>
> I've learned that what's show in pull requests on Github is not always 100% accurate. I would suggest merging a pull request on a local machine and see what changes it actually contains.

I've done that and it appears to not be a problem.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Jacob Carlborg, el  8 de October a las 11:50 me escribiste:
> On Oct 08, 2013, at 10:25 AM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> 
> >That's perfectly fine as long as it's to your branch (which it normally would be for a PR). The problem is when it's done to master. However, I didn't know that you could get away with doing a push without listing the target branch. I always list the target branch, which is less error-prone, since you're never going to push -f to master.
> 
> It depends on your git settings. You can tell git to either push all your branches (that have a matching branch on the remote) when doing "git push" or just push the active branch. There are couple more alternatives as well.
> 
> See the first four examples here:
> 
> https://www.kernel.org/pub/software/scm/git/docs/git-push.html#_examples
> 
> Have a look at this as well:
> 
> https://www.kernel.org/pub/software/scm/git/docs/git-config.html
> 
> Search for "push.default". The default value of this setting was/will be changed in Git 2.0.

In latests versions of Git (1.8 I think) there is more support for the
"triangular-worflow" as used in GitHub (usually pulling from one place
but pushing to another).

Just do:
git config --global remote.pushdefault <your-fork-remote>
git config --global push.default current (not all the modes works with
					  the pushdefault option yet, so
					  this one is pretty safe, only
					  push the current branch)
Then use as the default remote in each repo the "blessed" repo:
git config branch.<name>.remote <official D repo remote>

With this configuration, when you do `git pull` it will fetch from the official repo and when you do `git push` it will push to your fork. If you need to push to the official repo, just use the remote name explicitly (git push <official D repo remote> <branch>).

Hope it helps.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
ADOLESCENTE MUERE DESNUCADO POR TRATAR DE AUTOCHUPARSE
	-- Cronista TV
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Brad Roberts, el  8 de October a las 01:26 me escribiste:
> >I don't know what exactly had happened or how Brad "fixed" this, but I'm pretty sure it's possible to correctly fix this without breaking the pull requests. Just reset back the history to the sate it was before the force push. Since you already made a push force, another push force is needed to fix the problem. Then correctly make the changes you wanted to make.
> 
> The fix was merely repushing the commit id of the previously head of master back as the current head of master.  Something internal to github's management of pulls got confused at that point.  So far, no response to my support request.

GitHub support is pretty crappy, at least according to my experience. I had a couple of very strange situations too, where things that shouldn't had happened, happened. And I never got an useful answer or explanation from them.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Americans, let's face it: We've been a spoiled country for a long time.
Do you know what the number one health risk in America is?
Obesity, obesity! They say we're in the middle of an obesity epidemic.
An epidemic, like it's polio. Like we'll be telling our grand kids about
it one day: The Great Obesity Epidemic of 2004.
"How'd you get through it grandpa?"
"Oh, it was horrible Johnny, but there was cheesecake
and pork chops everywhere."
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Oct 08, 2013, at 10:49 PM, Brad Roberts <braddr@puremagic.com> wrote:

> An amend is a history rewrite, even if a small one. If the amended commit ever made it out of his tree into github, a -f is necessary.

I know that amend rewrites history. What I was saying was that if he amends his own pull request push force is needed. But if he amends SOMEONE ELSE pull request push force isn't needed.

--
/Jacob Carlborg

On 10/8/2013 3:39 AM, Jonathan M Davis wrote:
> On Tuesday, October 08, 2013 01:56:21 Walter Bright wrote:
>> On 10/8/2013 1:25 AM, Jonathan M Davis wrote:
>>> On Tuesday, October 08, 2013 01:18:45 Walter Bright wrote:
>>>> Because I often need to amend a pull request, and I was told it was done
>>>>
>>>> with:
>>>>        git --amend -a
>>>>        git push -f
>>>>
>>>> and I've been doing that successfully since I've been doing PR's.
>>> That's perfectly fine as long as it's to your branch (which it normally
>>> would be for a PR). The problem is when it's done to master. However, I
>>> didn't know that you could get away with doing a push without listing the
>>> target branch. I always list the target branch, which is less
>>> error-prone, since you're never going to push -f to master.
>> I'm not really sure why that one time I did it it applied it to master
>> rather than the branch. Anyhow, what is the syntax to apply it only to a
>> branch?
> Assuming that your github repo is named origin (which is normally the case),
> it should be
>
> git push origin branch-name
>
> or for forcing it,
>
> git push -f origin branch-name
>
> and git will complain if you try and push it to a branch that doesn't have the
> same name as your local one. So, it should catch any mismatch. And the only
> reason that you'd risk pushing to the main repo that way is if you
> accidentally typed upstream instead of origin, and you'd have to combine both
> upstream and master to actually mess with master on the main repo (and since
> pull requests really should be coming from branches, not master, the odds of
> accidentally pushing to master on upstream should be quite low).
>
> If you have to actually push to the main repo, then presumably it would be
>
> git push upstream branch-name
>
> or
>
> git push -f upstream branch-name
>
> though I'd generally expect you to only be pushing to upstream when creating
> branches for releases and whatnot, not pull requests (I'm not sure that you
> even _can_ create pull requests to the main repo from branches on the main
> repo).
>
>

If I do:

    git commit --amend -a
    git push origin branchname

it fails. I have to add the -f.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals