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 Date: Wed Dec 11 21:38:34 2013 -0800

mac thread_clock implementation

commit f5eb279eee0a28bc851abc24c41f293d95a71ba2 Author: Vicente J. Botet Escriba 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.

On 12/13/13, 1:07 PM, Vicente J. Botet Escriba wrote:

Le 13/12/13 10:34, Chris Brown a écrit :

...

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 Date: Wed Dec 11 21:38:34 2013 -0800

mac thread_clock implementation

commit f5eb279eee0a28bc851abc24c41f293d95a71ba2 Author: Vicente J. Botet Escriba 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`. This is what I did.

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`. The problem is that I don't see nothing to push. git status don't shows any commit.

$ git reset --hard origin/develop HEAD is now at 824a12e Try to fix undefined int32_t with msvc

$ git pull --no-commit https://github.com/ccbrown/chrono mac-thread-clock From https://github.com/ccbrown/chrono * branch mac-thread-clock -> FETCH_HEAD Updating 824a12e..143260d Fast-forward include/boost/chrono/config.hpp | 1 + .../chrono/detail/inlined/mac/thread_clock.hpp | 80 +++++++++++++++++++- 2 files changed, 79 insertions(+), 2 deletions(-)

The --no-commit flag doesn't do anything for fast-forward pulls. It only effects merges. So you actually are pulling the commits. If you `git log` you'll see the new commits there. `git status` only shows files that have been modified but not committed. It won't tell you what commits will be pushed. To see that, you can run `git log origin/develop..HEAD`.

These are the two files that want to merge. There is no conflict. BTW, what does .../mean in .../chrono/detail/inlined/mac/thread_clock.hpp | 80 +++++++++++++++++++- ?

I don't think I've ever seen that, but I'd guess it's just a way of collapsing the file path for readability.

$ git status # On branch develop # Your branch is ahead of 'origin/develop' by 1 commit. # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # .gitignore nothing added to commit but untracked files present (use "git add" to track)

$ git diff include/boost/chrono/config.hpp

No difference

`git diff` without any other flags will show you the unstaged and uncommitted changes in your working directory. It shows nothing in this case because the changes are committed. To compare to the remote branch you could use something like `git diff origin/develop -- include/boost/chrono/config.hpp` or just `git diff origin/develop`.

Could I show something else that can be useful? Should I clone the full repository and start again?

I don't think there's anything wrong with your clone. I think it's just a matter of getting acquainted with the commands. Doesn't hurt anything to clone again though.

On 14/12/2013 09:51, Quoth Vicente J. Botet Escriba:

Le 13/12/13 09:16, Gavin Lambert a écrit :

...

By default, pull and merge in git will auto-commit if they don't see any conflicts. You can tell them not to by using --no-commit. I don't see the file changes in https://github.com/boostorg/chrono/commits/develop.

The auto-commit is to your own local repository, not the origin remote. You have to push the commits upstream to make them public. The way that status/diff/log/commit etc work in git is a bit different than in SVN, partly due to philosophical differences and partly out of necessity as a distributed VCS. You should probably read some tutorials. Also you might want to consider using a GUI front-end (eg. TortoiseGit, on Windows) -- while this does hide some of the plumbing (which you sometimes need to know) it's often an easier way to get used to the behaviour and to visualise changes.