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:
So one process would be...
Check out the branch you're merging to in your local clone via `git
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk