[SR-Dev] git:master: Merge branch 'master' of ssh://jh at git.sip-router.org/sip-router

[Jan Janak]

On 17-04 13:02, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
> 
>  > I think all is ok. Those are my commits from yesterday to make K default 
>  > config work with SR. Probably the message is autogenerated, do not know 
>  > what caused that.
> 
> the course of events was like this:
> 
> - i edited modules_k/dialplan/dp_repl.c and committed the change.
> 
> - then i tried to push the changes, but got an error that jan explained
>   was due to that my local repo was not anymore up to date.
> 
> - so i went and pulled the up to date version of the repo.
> 
> - after that i did the push again and this time it worked ok, but as
>   result, an email was send by git that claimed i had done those other
>   things too, which was scary.
> 
> perhaps it mattered that i did the commit before i did the pull which
> brought my local repo up to date.

Yes. It really hasn't done anything wrong, it only merged your local changes
with the changes that Daniel did on the remote branch. And the merge commit
message only lists the commits made by Daniel in the commit log message, but
they already existed in the master branch.

There is an easy remedy to this problem which I didn't realize when I told
you to do git pull first.

Next time your 'git push' fails like this because somebody else modified the
remote branch, you can instruct git to "rebase" your changes on the top of the
remote branch, instead of merging them. In other words, you tell git to first
"undo" your local changes, save them in a temporary area, then pull latest
changes from the remote branch, and re-apply your local changes again.

This can be done with 'git pull --rebase' (instead of just 'git
pull'). Without the rebase command line option, the history of the branch
looks like this:

  A--B--C--D--E--F--+
           |        M--
           +--1--2--+

This is what happened in your case. "D" is where you cloned the repository,
commits "E" and "F" are the commits done by Daniel after you cloned
it. Commits "1" and "2" are your local commits (there was only one to be
precise).

"M" is the merge commit, this is the one which scared you, the one that had a
long list of other commits in its commit log message.

With 'git pull --rebase', the result would have looked like this:

 A--B--C--D--E--F--1--2--

I.e. there is no merge commit and your changes are aplied on top of changes
done by Daniel. In this case, 'git pull --rebase' would have removed your
commits "1" and "2" from the local branch, the it would have downloaded
commits "E" and "F" from the remote repositorie and applied them to the local
branch. After that it would have re-applied your commits "1" and "2", which
were saved in a temporary directory during the process.

> in svn world i am used to the convention that if i do commit in a
> particular directory, it will not affect anything else.  with git looks
> like everything i have in my repo gets pushed no matter where i issue
> the command.

You didn't push the changes made by Daniel, they were already there, only the
single merge commit which listed them in the commit log message. Unless the
numbe of commits is really big, the commit log script sends one email
notification per commit. So there would have been more email messages if you
pushed unexpected stuff, but in your case there were only two emails, one for
the merge commit and one for the new commit.

But, don't worry about all this too much, we can always fix the repository if
something bad happens and there are daily backups. It takes a while to get
used to a slighly different philosophy behind git, but it pays of at the end
and you learn something new.

  Jan.