Am 24.07.2014 19:15, schrieb James Holsenback:
> On 07/24/2014 01:10 PM, clipka wrote:
>> Am 24.07.2014 17:47, schrieb James Holsenback:
>>
>>> Hmmmm ... when I'm looking at:
>>> https://github.com/UberPOV/UberPOV/tree/develop
>>>
>>> I see this hash:
>>> 784444e26b841d91118af7ca26a5f1ffefe60dbc
>>>
>>> with this description:
>>> Merge branch 'release/v1.37.0.0-beta.6' into develop
>>>
>>> time stamped 13hrs ago
>>
>> Yes - that's indeed when I did the merge...
>> .. Locally.
>>
>>> so doing 'git pull develop develop' /should/ have done trick.
>>
>> if you had pulled right from my local computer, then yes :-P
>>
>
> ruh???

Okay, I take this as an indication that you're not /too/ familiar with 
the distributed nature of the Git revision control system. ;-)

In contrast to Perforce, where you only have one central repository, in 
Git you have plenty of them. And none of them is any more authoritative 
than the other.

When you do a "git pull", you're actually performing a (unidirectional) 
sync of a local repository on your machine with whatever repository you 
told git to typically sync with; that means you apply to your local repo 
all the commits to the remote ("origin") repo since the previous pull. 
(Note that this requires that you haven't made any changes to the 
respective branch in your local repo. If that happens, you need to 
reconcile the two repos by applying a merge to both.)

(Note that your local working directory is /not/ your local repo. The 
local repo instead resides in the ".git" directory therein.)

Likewise, I also have a local repo on my machine (I actually can't avoid 
that). When I make changes to the code, I first commit them to the local 
repo. I can also merge branches in the local repo. Only when I'm happy 
with it all, I will "push" the local changes to the remote repo on 
GitHub, i.e. apply all the local commits to the "origin" repo. (Again 
this requires that nobody else has made any changes to the respective 
branch on the origin repo. If that happens, a reconciliatory merge is 
required again.)

It's also possible to propagate commits between repos "sideways", i.e. 
without one of the repos being the "origin" of the other, provided that 
there is /some/ common history in both repos; any history in between 
will automatically be propagated as well.

When changes are propagated from one repo to another, the original 
information of that change is propagated as well, including the time and 
date of the commit.

Post a reply to this message