16 Apr
2009
16 Apr
'09
6:10 p.m.
On 16-04 17:01, Andrei Pelinescu-Onciul wrote:
On Apr 16, 2009 at 16:25, Henning Westerholt
<henning.westerholt(a)1und1.de> wrote:
Now I realize that Henning was probably asking something else. Yes, what
Henning describes can happen if you use --no-commit (which was on by default
for the master branch in one of my .giconfig files).
In this case git pull performs the merge but does not commit it, so you end up
with modified files in the branch and you have to run git ci to commit them.
I had this option turned on in the first .gitconfig I circulated, because I
found it useful when I was merging changes from the svn repository into
kamailio-3.0. In the second .gitconfig file (attached to the crash-course
email) this option is already commented out.
Jan.
On Thursday 16 April 2009, Jan Janak wrote:
No, it's not normal (I've never seen it). You should not see anything in
git diff after a git pull, if you haven't made any local changes (you
should see only local changes).
Same for git status (you should see only local changes or untracked
files). [..]
$ git push
and in that case repository 'origin' is used.
The opposite of 'git push' is 'git pull'. This is the operation that you
can use to synchronize your local repository with the remote repository.
Hi Jan,
i've one question to the usage of git pull. I've encountered it a few times,
everytime when somebody commited something to the repository, i did a git
pull to update my repo as well. This merged the changes into my repository,
as wanted, no problem here.
But, it also show this changes as new commits, as changed files for example
when i do git status, or git diff, where i clearly did not changed anything.
Perhaps this is just normal, do you've an explanation for this?