> On Dec 6, 2016, at 10:33 AM, Rainer Müller wrote:
>
>> On 2016-12-06 14:36, Mojca Miklavec wrote:
>>
>> When someone submits a pull request (let's assume that it's already
>> perfect) and a committer fetches it, rebases it and commits it to the
>> master, then the PR is not automatically linke
On 2016-12-06 14:36, Mojca Miklavec wrote:
> When someone submits a pull request (let's assume that it's already
> perfect) and a committer fetches it, rebases it and commits it to the
> master, then the PR is not automatically linked to the commit (if
> rebasing happens in the meantime). Alternati
On Tuesday December 6 2016 14:36:25 Mojca Miklavec wrote:
>> It would be very good to get more committers involved in the revision
>> process.
>
>While I agree with that, it's all voluntary work.
Of course it is, probably shouldn't be anything else either.
>The huge difference is that people in
On 6 December 2016 at 10:34, René J.V. Bertin wrote:
> On Monday December 5 2016 22:52:51 Lawrence Velázquez wrote:
>
>> Fetching from a fork does not download the full history. Only the
>> objects that are not in your repository are fetched.
>
> That implies adding the fork as another remote with
On Tuesday December 06 2016 12:56:22 Rainer Müller wrote:
> curl -sLS https://github.com/macports/macports-ports/pull/79.patch \
That's maybe the most interesting tidbit yet :)
> Why would I want to avoid local commits? That would throw away the
> commit messages and author information.
Why w
On 2016-12-06 12:42, René J.V. Bertin wrote:
> On Tuesday December 06 2016 11:39:22 Rainer Müller wrote:
>
>> You do not even need any other repository:
>>
>> git fetch origin refs/pull/89/head
>> git checkout -b pull-89 FETCH_HEAD
>> git rebase origin/master
>
> Interesting, does that only
On Tuesday December 06 2016 11:39:22 Rainer Müller wrote:
> You do not even need any other repository:
>
> git fetch origin refs/pull/89/head
> git checkout -b pull-89 FETCH_HEAD
> git rebase origin/master
Interesting, does that only change things you can later clean up by deleting
the to
On 2016-12-06 02:34, Joshua Root wrote:
> From what I understand, what we'd really like for that case is a
> "squash, rebase and merge" option. Unless we've misunderstood what
> "squash and merge" does and it doesn't actually create a merge commit?
No, "squash and merge" will not create a merge co
On 2016-12-06 10:34, René J.V. Bertin wrote:
> On Monday December 5 2016 22:52:51 Lawrence Velázquez wrote:
>
>> Fetching from a fork does not download the full history. Only the
>> objects that are not in your repository are fetched.
>
> That implies adding the fork as another remote with the a
On Monday December 5 2016 22:52:51 Lawrence Velázquez wrote:
> Fetching from a fork does not download the full history. Only the
> objects that are not in your repository are fetched.
That implies adding the fork as another remote with the associated
house-keeping afterwards? If so, I'd still pr
> On Dec 5, 2016, at 7:37 AM, René J.V. Bertin wrote:
>
> I guess we all have better things to do than this kind of task.
Our commit history is essentially communication with future committers
about what we did and why. Like any other communication, it should be
clear and useful.
Much like writ
> On Dec 5, 2016, at 10:38 AM, René J.V. Bertin wrote:
>
>> On Monday December 05 2016 14:58:08 Rainer Müller wrote:
>>
>> What would be easier than just checking out the updated Portfile? You
>> can also just download the patch and apply it. Open for suggestions.
>
> In this case that would pr
> On Dec 5, 2016, at 8:57 PM, Zero King wrote:
>
>> From what I understand, what we'd really like for that case is
>> a "squash, rebase and merge" option. Unless we've misunderstood what
>> "squash and merge" does and it doesn't actually create a merge
>> commit?
>
> No, it doesn't. See https://
> On Dec 5, 2016, at 5:14 AM, Mojca Miklavec wrote:
>
> Usually "larryv" is the one who takes most care to split commits
Hey now, why the scare quotes? :)
vq
From what I understand, what we'd really like for that case is a
"squash, rebase and merge" option. Unless we've misunderstood what
"squash and merge" does and it doesn't actually create a merge commit?
- Josh
No, it doesn't. See https://github.com/blog/2141-squash-your-commits.
--
Zero Kin
On 2016-12-6 12:13 , Eric A. Borisch wrote:
On Mon, Dec 5, 2016 at 6:56 PM, Joshua Root mailto:j...@macports.org>> wrote:
On 2016-12-6 11:49 , Eric A. Borisch wrote:
I'm going to throw in my 2c again asking for the 'squash and commit'
button to be activated. I'm much more
On Mon, Dec 5, 2016 at 6:56 PM, Joshua Root wrote:
> On 2016-12-6 11:49 , Eric A. Borisch wrote:
>
>> I'm going to throw in my 2c again asking for the 'squash and commit'
>> button to be activated. I'm much more likely to wander through and
>> commit some cut-and-dried PRs if it is something I ca
On 2016-12-6 11:49 , Eric A. Borisch wrote:
I'm going to throw in my 2c again asking for the 'squash and commit'
button to be activated. I'm much more likely to wander through and
commit some cut-and-dried PRs if it is something I can do drive-by, or
even from my phone.
And by cut-and-dried, I m
I'm going to throw in my 2c again asking for the 'squash and commit' button
to be activated. I'm much more likely to wander through and commit some
cut-and-dried PRs if it is something I can do drive-by, or even from my
phone.
And by cut-and-dried, I mean PRs from a prior contributor updating chec
On Monday December 05 2016 14:58:08 Rainer Müller wrote:
>
> What would be easier than just checking out the updated Portfile? You
> can also just download the patch and apply it. Open for suggestions.
In this case that would probably rather be downloading the patch since checking
out the portf
On 2016-12-05 13:37, René J.V. Bertin wrote:
> Mojca Miklavec wrote on 20161205::11:14:46 re: "Re: PR final steps
> (to squash or not to squash)"
>> We discussed this quite a bit (I'm not sure where) and the
>> conclusion was that: - we want a linear history (
Mojca Miklavec wrote on 20161205::11:14:46 re: "Re: PR final steps (to squash
or not to squash)"
This was meant to be a public reply, sending again.
>We discussed this quite a bit (I'm not sure where) and the conclusion was that:
>- we want a linear history (therefore
Hi,
On 5 December 2016 at 09:46, René J.V. Bertin wrote:
> Hi,
>
> This has come up on the QtCurve PR and I cannot seem to find an explicit
> answer in the wiki (https://trac.macports.org/wiki/WorkingWithGit#pr)
>
> If a pull request has seen some evolution and thus commits due to the review
> p
Hi,
This has come up on the QtCurve PR and I cannot seem to find an explicit answer
in the wiki (https://trac.macports.org/wiki/WorkingWithGit#pr)
If a pull request has seen some evolution and thus commits due to the review
process and/or somehow related reasons (for instance, because the proce
24 matches
Mail list logo
