Ludovic Rousseau wrote: > So I used the OpenSC documentation at [2] and rebased my staging > branch (from [3]) onto gerrit/staging.
Note that gerrit/staging is a so-called remote tracking branch, and it's best not to commit to those to avoid conflicts if other changes arrive from the remote than those you have made. It's best to do something like this before committing: git checkout -b staging gerrit/staging This creates a branch in the local repo called "staging" (the -b arg.) and then make new commits on that branch (or another, it's easy to make many of them). These branches are never touched by git unless of course it is specifically told to, but the remote tracking branches are used by git to synchronize with the remote, so it's better to not manually add commits to them. > The commit "pkcs15-profile.xml: remove empty SYNOPSIS section" is now > the first one on gerrit/staging. Ok, and git status says that you are 1 ahead? > I edited the commit message to add a line: > Change-Id: Id824eb62bc41f8f714bd6d67b6333ea07a527d70 > to tell gerrit it is the same patch. Sounds good. > Now I want to push this commit to gerrit. How do I do that? You can push the currently checked-out HEAD using: git push gerrit HEAD:refs/for/staging HEAD:refs/for/staging has local:remote format, so what is HEAD locally will be pushed into refs/for/staging remotely. HEAD locally always means "what is currently checked out" and refs/for/staging is gerrit magic that means proposed commit for the staging branch. > [2] only says: > "Push your changes to be included in the "staging" branch > > git push <changes> gerrit:refs/for/staging > git push some/branch gerrit:refs/for/staging > git push <one-commit> gerrit:refs/for/staging " This is backwards. gerrit is the remote and comes after push. Then there's the local:remote specifier where local can be a branch or a commit or HEAD, and remote should always be refs/for/staging. > What is the correct command to push only one patch? I hope the above answers about the command, but this brings me to an important point: git push (and git in general) almost never operates on individual commits, but always on the commit including all of it's history. In practise this means that when you git push something you will not push only the commit you identify (using HEAD, commit hash or branch name) but in fact you will push also all ancestor commits which the remote repository (gerrit) does not already have. When pushing multiple commits at once gerrit records a dependency between the commits, which (with the current gerrit config on opensc-project.org) means that these commits must be submitted in gerrit in the exact order and in the exact version that they were orignally pushed to gerrit. Keep this in mind, and create separate branches locally for making changes which are unrelated. The way gerrit is currently configured it is however neccessary to serialize locally before pushing; before an unrelated change can be submitted in gerrit it must be rebased onto the current latest state of the gerrit repository. This is the awkward part I refered to yesterday. //Peter _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
