Re: [boost] [chrono] mac thread_clock support

Subject: Re: [boost] [chrono] mac thread_clock support
From: Chris Brown (ccbrown112_at_[hidden])
Date: 2013-12-13 04:34:31

On 12/13/13, 12:16 AM, Gavin Lambert wrote:
> On 13/12/2013 19:38, Quoth Vicente J. Botet Escriba:
>> I have tried to pull this PR doing
>>
>> git pull https://github.com/ccbrown/chrono mac-thread-clock
>>
>> but when I do
>>
>> git status
>>
>> there is nothing on the stage
>>
>> However I see the merged files
>>
>> git log  thread_clock.hpp
>> commit 143260daeb2703961448a0928d199747ca34dfca
>> Author: ccbrown <ccbrown112_at_[hidden]>
>> Date:   Wed Dec 11 21:38:34 2013 -0800
>>
>>      mac thread_clock implementation
>>
>> commit f5eb279eee0a28bc851abc24c41f293d95a71ba2
>> Author: Vicente J. Botet Escriba <vicente.botet_at_[hidden]>
>> Date:   Wed Jan 5 23:46:58 2011 +0000
>>
>>      Boost.Chrono: Moved to trunk
>>
>>      [SVN r67697]
>>
>> Could some one explain me what I did wrong?

Two extremely relevant links:

https://help.github.com/articles/merging-a-pull-request
https://help.github.com/articles/checking-out-pull-requests-locally

So one process would be...

Check out the branch you're merging to in your local clone via `git 
checkout develop`.

Then apply the changes via `git pull https://github.com/ccbrown/chrono 
mac-thread-clock`. Assuming no conflicts, everything will be merged 
locally. If there are conflicts, git will complain and if they're 
non-trivial, the author of the pull request will need to resolve them.

If the patch looks good / passes tests, push it to the remote repository 
via `git push origin develop`.

If it needs revision, reset your local clone via `git reset --hard 
origin/develop`.

> I could be wrong about this next part (since I haven't played too much
> with this end of things myself) but I think the idea is that you "pull"
> once you're happy with merging in the changes (and resolving any
> conflicts that might arise) -- but before that, you merely
> "switch/checkout" to test the changes (or otherwise review the patch,
> eg. within GitHub, or by using "fetch" and then log/diff between HEAD
> and FETCH_HEAD).

Personally I like to go ahead and merge the changes locally when I test 
/ review submissions. Especially on faster moving repositories. If 
another recent change causes problems in a patch, I'd rather catch it 
earlier than later in the review process.