[opensc-devel] gerrit and Project policy requires all submissions to be a fast-forward.
Hello git experts :-) I try to update change 6 [1] so that gerrit is happy. For now the error is: Gerrit Code Review 4:21 PM Project policy requires all submissions to be a fast-forward. Please rebase the change locally and upload again for review. So I used the OpenSC documentation at [2] and rebased my staging branch (from [3]) onto gerrit/staging. The commit pkcs15-profile.xml: remove empty SYNOPSIS section is now the first one on gerrit/staging. I edited the commit message to add a line: Change-Id: Id824eb62bc41f8f714bd6d67b6333ea07a527d70 to tell gerrit it is the same patch. Now I want to push this commit to gerrit. How do I do that? [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 So I tried: $ git push 70852d9733e045df2dce4a85f3e50e66aa2195bc gerrit:refs/for/staging fatal: '70852d9733e045df2dce4a85f3e50e66aa2195bc' does not appear to be a git repository fatal: The remote end hung up unexpectedly What is the correct command to push only one patch? I found git - pushing specific commit [4] but it looks a bit overkill for now. Maybe something simpler is possible. Thanks [1] https://www.opensc-project.org/codereview/#change,6 [2] https://www.opensc-project.org/opensc/wiki/SourceCode [3] git://github.com/LudovicRousseau/OpenSC.git [4] http://stackoverflow.com/questions/3230074/git-pushing-specific-commit -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] gerrit and Project policy requires all submissions to be a fast-forward.
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
Re: [opensc-devel] gerrit and Project policy requires all submissions to be a fast-forward.
Le 14 mars 2012 18:56, Peter Stuge pe...@stuge.se a écrit : 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? No. Because I also have all the other patches from Opensc/staging that need to be rebased. $ git log --pretty=oneline --abbrev-commit --graph --decorate * 3196f95 (HEAD, staging) Display the flags argument of C_Initialize() * 085e83c Fix extra spaces and tabs issues * 5960efb pkcs15-init tool: fix for pin auth_type comparison * 491ba2c Use the short form sc_log() instead of sc_debug() * 285ca8e Remove extra spaces and tabs at end of lines * b8de8f0 Fix compilation error on Windows * c2003cf Add support for PACE-enabled readers * 1b5fe75 Fix lookup_enum_spec() prototype * 36f6733 pkcs11: coding style * c1369d2 pkcs11: win32 compilation error * 56cc676 Reformat: remove extra spaces and tabs * e4a60ea libopensc: Add 'paranoid-memory' setting for behavior when mlock() fails * f938be6 libopensc: Don't fail to allocate memory when mlock fails * 6e0f46b Adding default accessflags to the do_store_private_key function in the same way do_generate_key has those accessflags This seems the right thing to do, when you look at the initial commit which added the flags in do_generate_key and the ticket http://www.opensc-project.org/opensc/ticket/198 * 31e4ee2 Display the ASCII equivalent of a hex dump * 26943ed Fix compiler warning and real problem * c7d5436 Changing default usage from sign to verify, because verify is the public key opposite of sign for the private key * 5add841 Setting usage flags for the public key when storing a private key * f25ca60 iso7816.c: clean up iso7816_restore_security_env() * ae800db iso7816.c: slightly clean up iso7816_delete_file() * 1296f86 westcos-tool.1.xml: sort options alphabetically * 7ecc7a7 pkcs15-tool.1.xml: sort options alphabetically * 7244bb4 pkcs15-init.1.xml: sort options alphabetically, slight rewording * 833e389 pkcs11-tool.1.xml: sort options alphabetically * 96832df opensc-tool.1.xml: sort options alphabetically * a607e3b netkey-tool.1.xml: sort options commands alphabetically * b745fc4 eidenv.1.xml: sort options alphabetically * f311d70 cryptoflex-tool.1.xml: sort options alphabetically * c1ebdf7 cardos-tool.1.xml: sort options alphabetically * 7cf22c4 westcos-tool.1.xml: slight rewording * 5186e95 opensc-explorer.1.xml: sort options commands alphabetically * 0b7e75a pkcs15-crypt.1.xml: sort options alphabetically * 34e050c piv-tool.1.xml: more harmonization, slight re-wording * 0de1be6 opensc-explorer.1.xml: fix typos, more harmonization * f2f37bb tools.xml: use 2 reference sections: tools file formats * 0ae8b37 doc/tools/*.xml: more consistent formatting * 0717dac doc/tools/Makefile.am: substitute @pkgdatadir@ * d4fd70b doc/tools/Makefile.am: new Makefile template for autotools * fe3dce9 doc/tools/*.xml: include manpage sections in file names * fe48e96 doc/Makefile.am: get rid of api.work kludge * 19e2c34 doc/tools/*.xml: add refmiscinfo class attributes * e1356f1 doc/tools/*.xml: use citerefentry in See also sections * 3cee29f doc/tools/*.xml: harmonize complete refmeta sections * 796e604 doc/tools/*.xml: use refsynopsisdiv sections * edabae1 piv-tool.xml: fix typo * 9c1285f pkcs15-profile.xml: remove empty SYNOPSIS section -- the patch I would like to push * a2624e5 (gerrit/staging) Remove svnignore file which is not needed with Git-- gerrit is here 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
