Archive:Development/Tutorials/Git/Pushing

    From KDE TechBase
    Revision as of 14:09, 1 March 2011 by Odysseus (talk | contribs)
    Warning
    This page is yet to be reviewed for changes required by the migration to Git. Information and commands on this page may no longer be valid and should be used with care. Please see the KDE Git hub page for more details.


    TODO: write intro?

    Getting an account on Gitorious

    Since nearly all of KDE's git repositories are hosted on gitorious, this is rather important. Fortunately, this part is relatively easy:

    Deciding whether to push directly or make a merge request

    There are two basic ways to get code into KDE's project repositories: you can push it there yourself or make a merge request to have someone else do it for you. While that might make merge requests seem pointless, there are some reasons where you will want to use merge requests instead of direct pushes:

    • Code review: Having your code looked at by another person (one who knows the project code better maybe) can be useful to keep easily preventable mistakes from entering the repository.
    • First time commits: The first time you write code for a project, it is polite to use a merge request instead of pushing the code directly. This is a good way to make sure that you are on the same page as the other developers (and the maintainers) of the project which you are working on.
    • Non-KDE developers: If you aren't a KDE deveoper (eg. you aren't in the kde-developers group on gitorious), and you want to get a quick fix included in a KDE program, a merge request is a simple way to get this done, since you do not have the ability to push directly. If you find yourself doing this frequently, you might want to consider "making it official" and applying to be a KDE Developer, it isn't that difficult to do.

    Pushing directly

    Pushing in git is the act of adding commits from your local repository to a remote one. It's only possible to write to git remotes which are writable. In the KDE/Gitorious setups, the git://gitorious.org/... remotes are read only, while the SSH ([email protected]:...) ones are readable and writable.

    Whatever remote repository you cloned originally is named by default "origin". So if you wanted to push the contents of the current branch to origin's master branch, you would be able to simply run: git push origin master

    If you cloned a git:// repo originally, you won't be able to push to it. You can add another remote by running: git remote add origin-rw [email protected]:... Where origin-rw is whatever name you want to call it, and you use the actual path to the remote, not the placeholder.

    Then you too can push: git push origin-rw master

    Using merge requests

    In order to request a merge, you need to put your commits somewhere where other people can get them. The easiest way to do this is to clone the repository on gitorious and push to that personal clone. Instructions:

    • Find the project on gitorious whose repository you wish to clone
    • Click on the link for the repository, which is often named the same as the project itself
    • find the "Clone this repository on Gitorious" button in the right sidebar, and use it

    Now that you have a clone of the repository, you need to push to it. You'll need to add a remote for it: git remote add myclone [email protected]:~username/projectname/clonename.git Where myclone is whatever you wish to call it and the path is the one listed as the push url for your clone of the repository.

    Now, you can push: git push myclone master

    Now that your commits are on gitorious, you can file a merge request for them. From the gitorious page for your clone, find the button in the right sidebar labeled "Request merge" and follow it. The form for filling out information about your request is relatively simple, and once complete, will notify the developers for the project for your changes. If your request is accepted, a kde developer will merge the commits in to the master repository. If it isn't accepted initially, a developer will probably comment on what needs to be done/is wrong/is controversial.