Hello,
Here is a brief git crash course for those who are used to CVS or SVN. The purpose of this crash course is to get you started, it describes basic operations that you will need to do simple changes in the sip-router git repository. You can find links to more documentation at the end.
First of all, you'll need to install git. The name of the corresponding Debian package is git-core. Debian Lenny contains version 1.5.6.5 which is sufficient. Newer git versions or packages for other distributions or architectures can be obtained from http://git-scm.com/.
As the second step you need to configure the git client. I have attached configuration files to this email for your convenience, save files .gitconfig and .gitignore in your home directory. File sip-router.org_CA.pem is optional, you will only need the file if you plan on accessing the repository over https (that's not the case for developers with write access).
Edit file ~/.gitconfig and configure your name and email address there. This is the name and email address that will be visible in git commits. Unlike CVS or SVN commits, git commits contain full name and email address of the commiter, this is the name and email that will be visible in git history. Note that the email address to be used in From header of commit logs sent to the development mailing list is configured separately on the server (there are technical reasons for this). Here is how I configured my name in email address in ~/.gitconfig:
[user] name = Jan Janak email = jan@iptel.org
The git configuration file in your home directory sets up a bunch of short aliases for most common git commands, so you do not have to type
$ git checkout
every time you are checking out a branch, you can just type 'git co' instead, and if you alias git to 'g' in your ~/.bashrc then it becomes just 'g co' which is much more convenient.
Another setting that is particular to our repository is the number of characters used for tabs in the git pager. Git uses less as the default pager and less is configured to use 8 spaces for tabs by default. We use 4 spaces in our sources and thus you might want to re-configure the git pager in your ~/.bashrc. The following setting makes the output of 'git diff' and friends look prettier:
export GIT_PAGER="less --tabs=4"
Now you can start working with git. The first command that you need to run is 'git clone', this is the command that is used to retrieve the sip-router repository from the server:
$ git clone ssh://<username>@git.sip-router.org/sip-router
Replace <username> with your real username. The contents of the repository will be stored in 'sip-router' subdirectory of your current working directory. This command is the git equivalent of cvs/svn checkout. Like cvs/svn it will make the most recent version of the sources available in the subdirectory.
UNLIKE cvs/svn, this command does not retrieve just the latest version of the sources, it copies the whole history of the project to your local hard drive, not just the latest revision, but all revisions that are stored in the repository, since tday 1. You do not have to be worried about the size of the repository, the full history of SER takes about 40MB only.
Also, you will need to run the command only once (or occassionally if you wipe your local copy out entirely). There are other git commands (covered later) that can be used to keep your local copy up-to-date. Those commands can figure out the difference between your local version of the repository and the version on the server and they will transfer only the data that has changed. In other words, 'git clone' is similar to the scp command, it creates a local identical copy of the remote repository by copying the whole remote repository to the local machine.
Once you have a local copy of the sip-router repository, you can try to see what is in there:
$ cd sip-router $ git branch
The command above shows a list of branches that are present in your local copy of the repository. Most likely you will see just one branch called 'master' marked with an asterisk. This means that your local repository contains only one branch called 'master' and the asterisk tells you that this is the branch that is currently checked out. So the sources that you see in that directory come from the master branch. The local master branch is an exact copy of the 'master' branch from the remote repository at git.sip-router.org and it contains latest sip-router sources.
Typically, the branch with the most up-to-date code is called 'master' in git. It is the git equivalent of CVS HEAD branch and SVN trunk branch.
NOTE: Branches are sometimes called 'heads' in git documentation, but you can just remember that 'branch' and 'head' refers to the same thing.
If you look at the remote version of the repository with gitweb at http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=heads you will notice that there are more branches than the 'master' branch which was created by 'git clone' in the local copy of the repository. The command 'git clone' only makes the master branch directly available in the local copy of the repository. For other branches it merely records the fact that the branches exist in the remote repository. To display branches from both the local and the remote repository you can run:
$ git branch -a
The output should look roughly like this:
* master origin/HEAD origin/MAIN origin/Maintainer origin/andrei/cvshead origin/andrei/sctp origin/andrei/sctp_fixes origin/andrei/sctp_one_to_one origin/andrei_sctp origin/cancel_fix origin/cvs-head origin/janakj/cvshead origin/janakj/doxygen origin/master
Branches that start with "origin/" are branches that exist in the remote repository. The string origin is just a short alias for the full URI of the remote repository, such as ssh://git.sip-router.org/sip-router. It is a convention that the repository you cloned from initially is called the origin.
Once you have the local repository, you can start making changes in it. Modifying the code on the master branch directly is really easy, because git clone already created the master branch for you in local repository and it checked out the master branch by default. Here is how can you make a simple change in one file and commit the result:
$ edit main.c $ git add main.c $ git commit
As you can see above you need to call 'git add' before you call 'git commit'. 'git add' marks your changes to be commited during the next commit, this is useful, for example, if you want to leave some local changes uncommited while you make the commit. Unlike CVS or SVN, git does not assume that all local changes should be commited during the next commit. It lets you explicitly select a set of changes to be commited. You can avoid the need to call two commands with 'git commit -a', see the git documentation for more details.
When you are done with the commit, you can display the list of changes in the repository with 'git log'. The command displays the history of changes in the whole repository, if you want to limit the list to main.c only then you can run 'git log main.c'.
If you look closely at the output of 'git log' then you will notice strange lines starting with "commit" followed by a long string of characters:
commit 0253726f99ac151f748712a5d39d71f42d9defc6
The long string is how commits in git are represented. This string is a SHA1 checksum of the commit and it is the git equivalent SVN revision numbers. Like SVN revision numbers and UNLIKE CVS versions, this identifier represents the state of the whole repository, not just individual files. Because such long identifier are tedious to type, git supports abbreviated format, you can type just the beginning of the string as long as the beginning of the string is unique. In other words, there must be at most one commit in the database of all commits with this prefix. For example the following two commands refer to the same commit:
$ git diff b0f6ec8784712e4c1436fc9a4a3b54296e94ba5c $ git diff b0f6e
If somebody creates another commit with an SHA1 id starting with b0f6e later then 'git diff b0f6e' would not longer work and git would complain that the prefix is ambiguous.
All changes, such as the commit above, that you do affect the local repository only. There is absolutely no communication with the the remote repository in any of the commands above (git add, git commit, git log). This is possible because we created a full copy of the remote repository with 'git clone'. This is also the reason why all the commands are so fast, unlike their equivalents in CVS or SVN.
The fact that you perform all actions/modifications on the local repository only and then you instruct git to do its black magic and synchronize your local changes with the remote repository is probably the biggest difference from CVS/SVN and one of the things that is hard to understand for people who are used to CVS/SVN. This is also why git falls into the category of distributed revision control systems.
When you are satisfied with your local changes/commits, you can decide to make them available to others. This can be done by uploading your local changes to the remote repository (the one you initially cloned from). In git terminology this operation is called 'push', so you can push your local changes to the remote repository with 'git push':
$ git push origin master:master
The first parameter is the name of the remote repository, the second parameter is the name of the local branch and the name of the remote branch, delimited by ':'. You can omit the 2nd parameter:
$ git push origin
and then 'git push' will upload all local branches to the remote repository. You can also omit the first parameter:
$ 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. 'git pull' downloads all changes (made by others) from the remote repository that are not yet in your local repository and integrates them into your local repository. You can run 'git pull' whenever you are online to fetch latest changes and keep your local copy of the repository up-to-date.
'git push' and 'git pull' are similar to rsync, they update either the local or the remote copy of the repository by tranferring only what is missing. 'git push' is the git equivalent of 'cvs ci' and 'svn ci'. 'git pull' is the git equivalent of 'cvs update' or 'svn update'.
If you make only small changes to the repository then you can modify the master branch directly, as described above. This approach is suitable only for small, trivial changes. If are working on a change which takes longer to implement, consists of many commits, then it is better to create a separate branch and do the development on a separate branch. Branches in git are cheap, remember that all operations, including branch creation, are local operations. You do not even have to push your local branches into the remote repository, you can just keep them in the local copy for your own purposes. You can create a new branch in your local repository with 'git checkout':
$ git checkout --track -b mybranch master
This command creates a new branch called 'mybranch', configures the branch to track the master branch and checks the new branch out. The word 'track' in this context means that the newly created branch will receive all updates from the master branch whenever you run 'git pull' with this branch checked out. In other words, the branch tracks another branch (master in this case) by merging all changes from the original branch. Command line option -b instructs git to to create a new branch. If this option was omitted then git would assume that 'mybranch' is an existing branch and it would try to check the branch out.
The newly created branch exists in the local repository only. If you want to push the branch to the remote repository then you can use 'git push' again:
$ git push origin mybranch:janakj/mybranch
Because mybranch is a private topic branch of mine, I am pushing it as janakj/mybranch to the remote repository at git.sip-router.org. The remote repository only permits new "username" branches. In other words their name must start with your username. If you try:
$ git push origin mybranch:mybranch
then git will report an error. The main reason why we have this restriction in place is because we wanted to make sure that people do not push all local branches to the remote repository by accident. This can easily happen if you run 'git push' without any parameters.
You can also delete a local branch that is no longer needed by running
$ git branch -D mybranch
This will delete the local branch only. If you pushed the branch to the remote repository then you might also want to delete the branch in the remote repository with 'git push':
$ git push :janakj/mybranch
This is a special syntax of 'git push', if you omit the name of the local branch then 'git push' deletes the remote branch whose name follows ':'.
Test Repository =============== We have a test repository at git.sip-router.org which you can use to test various git operations. Clone the repository with:
$ git clone ssh://username@git.sip-router.org/test
and there you can test whatever you want. The repository can also be browsed with gitweb at http://git.sip-router.org/cgi-bin/gitweb.cgi?p=test;a=summary
Further Reading =============== [1] Git related pages in the wiki: http://sip-router.org/wiki/git [2] http://eagain.net/articles/git-for-computer-scientists/ [3] Git SVN Crashcourse: http://git.or.cz/course/svn.html [4] http://git-scm.com/documentation
Jan Janak writes:
As the second step you need to configure the git client. I have attached configuration files to this email for your convenience, save files .gitconfig and .gitignore in your home directory.
jan,
i didn't find those attachements in your posting. perhaps the mailing list mailer eat them?
-- juha
Juha,
On 16-04 17:07, Juha Heinanen wrote:
Jan Janak writes:
As the second step you need to configure the git client. I have attached configuration files to this email for your convenience, save files .gitconfig and .gitignore in your home directory.
jan,
i didn't find those attachements in your posting. perhaps the mailing list mailer eat them?
Oops, I forgot to attach them again, I'll do that in a separate email. Thanks for letting me know.
Jan.
2009/4/16 Jan Janak jan@iptel.org:
Hello,
Here is a brief git crash course for those who are used to CVS or SVN. The purpose of this crash course is to get you started, it describes basic operations that you will need to do simple changes in the sip-router git repository. You can find links to more documentation at the end.
Great!
A suggestion, could this tutorial be added to SR wiki? I know there is already some pages about Git, but not this tutorial.
Regards.
On 16-04 16:07, Iñaki Baz Castillo wrote:
2009/4/16 Jan Janak jan@iptel.org:
Hello,
Here is a brief git crash course for those who are used to CVS or SVN. The purpose of this crash course is to get you started, it describes basic operations that you will need to do simple changes in the sip-router git repository. You can find links to more documentation at the end.
Great!
A suggestion, could this tutorial be added to SR wiki? I know there is already some pages about Git, but not this tutorial.
Here it is:
http://sip-router.org/wiki/git/crash-course
Jan.
Here are the attachments mentioned below.
Jan.
On 16-04 15:54, Jan Janak wrote:
Hello,
Here is a brief git crash course for those who are used to CVS or SVN. The purpose of this crash course is to get you started, it describes basic operations that you will need to do simple changes in the sip-router git repository. You can find links to more documentation at the end.
First of all, you'll need to install git. The name of the corresponding Debian package is git-core. Debian Lenny contains version 1.5.6.5 which is sufficient. Newer git versions or packages for other distributions or architectures can be obtained from http://git-scm.com/.
As the second step you need to configure the git client. I have attached configuration files to this email for your convenience, save files .gitconfig and .gitignore in your home directory. File sip-router.org_CA.pem is optional, you will only need the file if you plan on accessing the repository over https (that's not the case for developers with write access).
Edit file ~/.gitconfig and configure your name and email address there. This is the name and email address that will be visible in git commits. Unlike CVS or SVN commits, git commits contain full name and email address of the commiter, this is the name and email that will be visible in git history. Note that the email address to be used in From header of commit logs sent to the development mailing list is configured separately on the server (there are technical reasons for this). Here is how I configured my name in email address in ~/.gitconfig:
[user] name = Jan Janak email = jan@iptel.org
The git configuration file in your home directory sets up a bunch of short aliases for most common git commands, so you do not have to type
$ git checkout
every time you are checking out a branch, you can just type 'git co' instead, and if you alias git to 'g' in your ~/.bashrc then it becomes just 'g co' which is much more convenient.
Another setting that is particular to our repository is the number of characters used for tabs in the git pager. Git uses less as the default pager and less is configured to use 8 spaces for tabs by default. We use 4 spaces in our sources and thus you might want to re-configure the git pager in your ~/.bashrc. The following setting makes the output of 'git diff' and friends look prettier:
export GIT_PAGER="less --tabs=4"
Now you can start working with git. The first command that you need to run is 'git clone', this is the command that is used to retrieve the sip-router repository from the server:
$ git clone ssh://<username>@git.sip-router.org/sip-router
Replace <username> with your real username. The contents of the repository will be stored in 'sip-router' subdirectory of your current working directory. This command is the git equivalent of cvs/svn checkout. Like cvs/svn it will make the most recent version of the sources available in the subdirectory.
UNLIKE cvs/svn, this command does not retrieve just the latest version of the sources, it copies the whole history of the project to your local hard drive, not just the latest revision, but all revisions that are stored in the repository, since tday 1. You do not have to be worried about the size of the repository, the full history of SER takes about 40MB only.
Also, you will need to run the command only once (or occassionally if you wipe your local copy out entirely). There are other git commands (covered later) that can be used to keep your local copy up-to-date. Those commands can figure out the difference between your local version of the repository and the version on the server and they will transfer only the data that has changed. In other words, 'git clone' is similar to the scp command, it creates a local identical copy of the remote repository by copying the whole remote repository to the local machine.
Once you have a local copy of the sip-router repository, you can try to see what is in there:
$ cd sip-router $ git branch
The command above shows a list of branches that are present in your local copy of the repository. Most likely you will see just one branch called 'master' marked with an asterisk. This means that your local repository contains only one branch called 'master' and the asterisk tells you that this is the branch that is currently checked out. So the sources that you see in that directory come from the master branch. The local master branch is an exact copy of the 'master' branch from the remote repository at git.sip-router.org and it contains latest sip-router sources.
Typically, the branch with the most up-to-date code is called 'master' in git. It is the git equivalent of CVS HEAD branch and SVN trunk branch.
NOTE: Branches are sometimes called 'heads' in git documentation, but you can just remember that 'branch' and 'head' refers to the same thing.
If you look at the remote version of the repository with gitweb at http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=heads you will notice that there are more branches than the 'master' branch which was created by 'git clone' in the local copy of the repository. The command 'git clone' only makes the master branch directly available in the local copy of the repository. For other branches it merely records the fact that the branches exist in the remote repository. To display branches from both the local and the remote repository you can run:
$ git branch -a
The output should look roughly like this:
- master origin/HEAD origin/MAIN origin/Maintainer origin/andrei/cvshead origin/andrei/sctp origin/andrei/sctp_fixes origin/andrei/sctp_one_to_one origin/andrei_sctp origin/cancel_fix origin/cvs-head origin/janakj/cvshead origin/janakj/doxygen origin/master
Branches that start with "origin/" are branches that exist in the remote repository. The string origin is just a short alias for the full URI of the remote repository, such as ssh://git.sip-router.org/sip-router. It is a convention that the repository you cloned from initially is called the origin.
Once you have the local repository, you can start making changes in it. Modifying the code on the master branch directly is really easy, because git clone already created the master branch for you in local repository and it checked out the master branch by default. Here is how can you make a simple change in one file and commit the result:
$ edit main.c $ git add main.c $ git commit
As you can see above you need to call 'git add' before you call 'git commit'. 'git add' marks your changes to be commited during the next commit, this is useful, for example, if you want to leave some local changes uncommited while you make the commit. Unlike CVS or SVN, git does not assume that all local changes should be commited during the next commit. It lets you explicitly select a set of changes to be commited. You can avoid the need to call two commands with 'git commit -a', see the git documentation for more details.
When you are done with the commit, you can display the list of changes in the repository with 'git log'. The command displays the history of changes in the whole repository, if you want to limit the list to main.c only then you can run 'git log main.c'.
If you look closely at the output of 'git log' then you will notice strange lines starting with "commit" followed by a long string of characters:
commit 0253726f99ac151f748712a5d39d71f42d9defc6
The long string is how commits in git are represented. This string is a SHA1 checksum of the commit and it is the git equivalent SVN revision numbers. Like SVN revision numbers and UNLIKE CVS versions, this identifier represents the state of the whole repository, not just individual files. Because such long identifier are tedious to type, git supports abbreviated format, you can type just the beginning of the string as long as the beginning of the string is unique. In other words, there must be at most one commit in the database of all commits with this prefix. For example the following two commands refer to the same commit:
$ git diff b0f6ec8784712e4c1436fc9a4a3b54296e94ba5c $ git diff b0f6e
If somebody creates another commit with an SHA1 id starting with b0f6e later then 'git diff b0f6e' would not longer work and git would complain that the prefix is ambiguous.
All changes, such as the commit above, that you do affect the local repository only. There is absolutely no communication with the the remote repository in any of the commands above (git add, git commit, git log). This is possible because we created a full copy of the remote repository with 'git clone'. This is also the reason why all the commands are so fast, unlike their equivalents in CVS or SVN.
The fact that you perform all actions/modifications on the local repository only and then you instruct git to do its black magic and synchronize your local changes with the remote repository is probably the biggest difference from CVS/SVN and one of the things that is hard to understand for people who are used to CVS/SVN. This is also why git falls into the category of distributed revision control systems.
When you are satisfied with your local changes/commits, you can decide to make them available to others. This can be done by uploading your local changes to the remote repository (the one you initially cloned from). In git terminology this operation is called 'push', so you can push your local changes to the remote repository with 'git push':
$ git push origin master:master
The first parameter is the name of the remote repository, the second parameter is the name of the local branch and the name of the remote branch, delimited by ':'. You can omit the 2nd parameter:
$ git push origin
and then 'git push' will upload all local branches to the remote repository. You can also omit the first parameter:
$ 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. 'git pull' downloads all changes (made by others) from the remote repository that are not yet in your local repository and integrates them into your local repository. You can run 'git pull' whenever you are online to fetch latest changes and keep your local copy of the repository up-to-date.
'git push' and 'git pull' are similar to rsync, they update either the local or the remote copy of the repository by tranferring only what is missing. 'git push' is the git equivalent of 'cvs ci' and 'svn ci'. 'git pull' is the git equivalent of 'cvs update' or 'svn update'.
If you make only small changes to the repository then you can modify the master branch directly, as described above. This approach is suitable only for small, trivial changes. If are working on a change which takes longer to implement, consists of many commits, then it is better to create a separate branch and do the development on a separate branch. Branches in git are cheap, remember that all operations, including branch creation, are local operations. You do not even have to push your local branches into the remote repository, you can just keep them in the local copy for your own purposes. You can create a new branch in your local repository with 'git checkout':
$ git checkout --track -b mybranch master
This command creates a new branch called 'mybranch', configures the branch to track the master branch and checks the new branch out. The word 'track' in this context means that the newly created branch will receive all updates from the master branch whenever you run 'git pull' with this branch checked out. In other words, the branch tracks another branch (master in this case) by merging all changes from the original branch. Command line option -b instructs git to to create a new branch. If this option was omitted then git would assume that 'mybranch' is an existing branch and it would try to check the branch out.
The newly created branch exists in the local repository only. If you want to push the branch to the remote repository then you can use 'git push' again:
$ git push origin mybranch:janakj/mybranch
Because mybranch is a private topic branch of mine, I am pushing it as janakj/mybranch to the remote repository at git.sip-router.org. The remote repository only permits new "username" branches. In other words their name must start with your username. If you try:
$ git push origin mybranch:mybranch
then git will report an error. The main reason why we have this restriction in place is because we wanted to make sure that people do not push all local branches to the remote repository by accident. This can easily happen if you run 'git push' without any parameters.
You can also delete a local branch that is no longer needed by running
$ git branch -D mybranch
This will delete the local branch only. If you pushed the branch to the remote repository then you might also want to delete the branch in the remote repository with 'git push':
$ git push :janakj/mybranch
This is a special syntax of 'git push', if you omit the name of the local branch then 'git push' deletes the remote branch whose name follows ':'.
Test Repository
We have a test repository at git.sip-router.org which you can use to test various git operations. Clone the repository with:
$ git clone ssh://username@git.sip-router.org/test
and there you can test whatever you want. The repository can also be browsed with gitweb at http://git.sip-router.org/cgi-bin/gitweb.cgi?p=test;a=summary
Further Reading
[1] Git related pages in the wiki: http://sip-router.org/wiki/git [2] http://eagain.net/articles/git-for-computer-scientists/ [3] Git SVN Crashcourse: http://git.or.cz/course/svn.html [4] http://git-scm.com/documentation _______________________________________________ Serdev mailing list Serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
Hi *, I have uploaded at CPAN simple Perl library Ser::BinRPC (http://search.cpan.org/~tma/Ser-BinRPC-0.01/lib/Ser/BinRPC.pm) for communication with Ser using BinRPC. It's Perl equivalent of libBinRPC.so. It enables to develop e.g. monitoring script in perl or so. Usage is obvious from included sercmd.pl, which is equivalent of sercmd.
Tomas
On Friday 18 June 2010, Tomáš Mandys wrote:
I have uploaded at CPAN simple Perl library Ser::BinRPC (http://search.cpan.org/~tma/Ser-BinRPC-0.01/lib/Ser/BinRPC.pm) for communication with Ser using BinRPC. It's Perl equivalent of libBinRPC.so. It enables to develop e.g. monitoring script in perl or so. Usage is obvious from included sercmd.pl, which is equivalent of sercmd.
Hi Tomáš,
thank you! This will be definitely useful in order to develop your own scripts that interact with the server. Will this be available for installation in CPAN package directory as well, or do one need to download it from the quoted URL? In the latter case we should link it somewhere e.g. on our wiki.
Cheers,
Henning
On Friday 18 June 2010, Tomá Mandys wrote:
I have uploaded at CPAN simple Perl library Ser::BinRPC (http://search.cpan.org/~tma/Ser-BinRPC-0.01/lib/Ser/BinRPC.pm) for communication with Ser using BinRPC. It's Perl equivalent of libBinRPC.so. It enables to develop e.g. monitoring script in perl or so. Usage is obvious from included sercmd.pl, which is equivalent of sercmd.
Hi Tomá,
thank you! This will be definitely useful in order to develop your own scripts that interact with the server. Will this be available for installation in CPAN package directory as well, or do one need to download it from the quoted URL? In the latter case we should link it somewhere e.g. on our wiki.
I hope it's in CPAN. I tried
perl -MCPAN -e shell CPAN> install Ser::BinRPC
and installation passed correctly.
Cheers,
Henning _______________________________________________ Serdev mailing list Serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
On Thursday 16 April 2009, Jan Janak wrote:
[..] $ 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?
Cheers,
Henning
On Apr 16, 2009 at 16:25, Henning Westerholt henning.westerholt@1und1.de wrote:
On Thursday 16 April 2009, Jan Janak wrote:
[..] $ 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?
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).
Andrei
On 16-04 17:01, Andrei Pelinescu-Onciul wrote:
On Apr 16, 2009 at 16:25, Henning Westerholt henning.westerholt@1und1.de wrote:
On Thursday 16 April 2009, Jan Janak wrote:
[..] $ 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?
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).
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).
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.
Hi Jan,
yes, this is it!
git-config -l |grep "no-commit" branch.master.mergeoptions=--no-commit --no-ff
This is probably related to another problem i've got, after the remote repository changed and i've tried to push my changes back:
henning@ca:~/projects/openser/sip-router$ git push -v Pushing to ssh://git.sip-router.org/sip-router To ssh://git.sip-router.org/sip-router ! [rejected] master -> master (non-fast forward) error: failed to push some refs to 'ssh://git.sip-router.org/sip-router'
Thanks,
Henning
Henning,
On 16-04 17:14, Henning Westerholt wrote:
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).
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.
Hi Jan,
yes, this is it!
git-config -l |grep "no-commit" branch.master.mergeoptions=--no-commit --no-ff
This is probably related to another problem i've got, after the remote repository changed and i've tried to push my changes back:
henning@ca:~/projects/openser/sip-router$ git push -v Pushing to ssh://git.sip-router.org/sip-router To ssh://git.sip-router.org/sip-router ! [rejected] master -> master (non-fast forward) error: failed to push some refs to 'ssh://git.sip-router.org/sip-router'
Thanks for point this out. Everybody, if you have ~/.gitconfig, please check whether the file contains a line with --no-commit --no-ff and if yes, comment it out. Thanks.
Jan.
On Thursday 16 April 2009, Jan Janak wrote:
Thanks for point this out. Everybody, if you have ~/.gitconfig, please check whether the file contains a line with --no-commit --no-ff and if yes, comment it out. Thanks.
Jan,
just FYI, this is also present in the config you've posted, i already fixed it in the wiki.
Thanks,
Henning
On 16-04 17:25, Henning Westerholt wrote:
On Thursday 16 April 2009, Jan Janak wrote:
Thanks for point this out. Everybody, if you have ~/.gitconfig, please check whether the file contains a line with --no-commit --no-ff and if yes, comment it out. Thanks.
Jan,
just FYI, this is also present in the config you've posted, i already fixed it in the wiki.
Where? I thought I had commented it out?
Jan.
On Thursday 16 April 2009, Jan Janak wrote:
Thanks for point this out. Everybody, if you have ~/.gitconfig, please check whether the file contains a line with --no-commit --no-ff and if yes, comment it out. Thanks.
Jan,
just FYI, this is also present in the config you've posted, i already fixed it in the wiki.
Where? I thought I had commented it out?
Hi Jan,
sorry, i read your config to fast. It was present in the wiki, but your config was already correct.
Henning
On Apr 16, 2009 at 17:14, Henning Westerholt henning.westerholt@1und1.de wrote:
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).
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.
Hi Jan,
yes, this is it!
git-config -l |grep "no-commit" branch.master.mergeoptions=--no-commit --no-ff
^^^^^^^ This is debatable too.
This is probably related to another problem i've got, after the remote repository changed and i've tried to push my changes back:
henning@ca:~/projects/openser/sip-router$ git push -v Pushing to ssh://git.sip-router.org/sip-router To ssh://git.sip-router.org/sip-router ! [rejected] master -> master (non-fast forward) error: failed to push some refs to 'ssh://git.sip-router.org/sip-router'
Probably. In a normal case you would use either git rebase origin/master and then retry the push or git pull --ff origin/master and retry the pull (but since you used --no-commit, I don't know in what state you have your master branch so it might be dangerous, if you really want to try it, backup and try pushing to some tmp test branch, e.g. git push origin tmp/test).
Regarding --no-ff: sometimes is good (when merging some branch into master), ortherwise produces confusing merge messages (when updating master from origin/master with git pull origin master).
I think is much better to explicitely specify --ff and --no-ff each time you do a merge into master or a pull into _master_:
git pull --ff origin/master # always use fast forward when updating # master from the repository
git merge --no-ff origin/some_branch # always use non-fast-forward when # merging some branch into master
(--no-ff force a merge message even if the merge was a fast-forward, which is very helpfull to track merges with other branches)
Andrei
On 16-04 16:25, Henning Westerholt wrote:
On Thursday 16 April 2009, Jan Janak wrote:
[..] $ 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?
Yes, git pull does two things internally. First, it runs 'git fetch', this is a command which connects to the remote server, retrieves missing commit from the database there and stores them in the database in the local repository. 'git fetch' does not modify the source files in any way, it only retrieves commits from a remote repository.
After that 'git pull' runs 'git merge', which takes the newly received commits from the local database and merges them into the current branch. It takes all commits that are missing your your current branch and applies them one after another. This is why you see them in the history. At the end it will also create a special "merge commit" which records what was merged from where so that you can see what happened in the history.
Jan.
-
Andrei Pelinescu-Onciul -
Henning Westerholt -
Iñaki Baz Castillo -
Jan Janak -
jh＠tutpro.com -
tma＠iptel.org -
Tomáš Mandys