Hello,
Some people have reported that since the new version of git-review the had issue submitting patches. The symptom is:
<someone hack> <attempt to send the work by using `git-review`> Complaint:
You have more than one commit that you are about to submit. The oustanding commits are: <some changes you never did :-]>
The issue is because your last commit has been done based on a remote named 'origin' whereas git-review use the remote named 'gerrit'. Since most people update only the origin remote with git pull, the gerrit remote is lagging behind. So technically, git-review attempt to submit any commit between origin/master and gerrit/master hence the long message.
There are three ways to fix it:
1) always update all remotes by using either: - git fetch --all - git remote update
Side effect: you have to remember to use those commands instead of 'git fetch' or 'git pull origin'.
2) delete the remote named 'origin': - git remote rm origin
Side effect: 'git pull origin' does not work anymore :-) You need to use 'git pull gerrit'.
3) Tell .gitreview to use 'origin' by adding the following line:
defaultremote=origin
Make sure you have a remote named origin, if not rename the one named gerrit :D Side effect: I can not think of any.
I use (2) aka a remote named 'gerrit'. I recommend (3) make git-review use 'origin' and I think we should modify our .gitreview file to add that line. That will avoid confusion.
cheers,
On Fri, 13 Apr 2012 13:33:43 -0700, Antoine Musso hashar+wmf@free.fr wrote:
Hello,
Some people have reported that since the new version of git-review the had issue submitting patches. The symptom is:
<someone hack> <attempt to send the work by using `git-review`> Complaint:
You have more than one commit that you are about to submit. The oustanding commits are: <some changes you never did :-]>
The issue is because your last commit has been done based on a remote named 'origin' whereas git-review use the remote named 'gerrit'. Since most people update only the origin remote with git pull, the gerrit remote is lagging behind. So technically, git-review attempt to submit any commit between origin/master and gerrit/master hence the long message.
There are three ways to fix it:
- always update all remotes by using either:
- git fetch --all
- git remote update
Side effect: you have to remember to use those commands instead of 'git fetch' or 'git pull origin'.
- delete the remote named 'origin':
- git remote rm origin
Side effect: 'git pull origin' does not work anymore :-) You need to use 'git pull gerrit'.
- Tell .gitreview to use 'origin' by adding the following line:
defaultremote=origin
Make sure you have a remote named origin, if not rename the one named gerrit :D Side effect: I can not think of any.
What about the users who clone from their own GitHub fork as origin and push side-project branches there before merging and pushing finished projects to gerrit?
I use (2) aka a remote named 'gerrit'. I recommend (3) make git-review use 'origin' and I think we should modify our .gitreview file to add that line. That will avoid confusion.
cheers,
Daniel Friesen lists@nadir-seen-fire.com wrote:
What about the users who clone from their own GitHub fork as origin and push side-project branches there before merging and pushing finished projects to gerrit?
A proper fix in the works currently is to not need .gitreview file at all if one of the remotes ("origin", "gerrit" or whatever) is pointing to a valid Gerrit instance. Actually we don't need a new remote at all; but that's the behaviour git-review insisted on.
//Saper
I have run into that message before:
"You have more than one commit that you are about to submit."
If you do not want to commit, bust still will want to save revisions of your work, then
get stash
is your friend.
If you need to know Git very well, then this is a very helpful list of commands you need to know:
http://andyjeffries.co.uk/articles/25-tips-for-intermediate-git-users
Jeremy
On Sun, Apr 15, 2012 at 8:42 AM, Marcin Cieslak saper@saper.info wrote:
Daniel Friesen lists@nadir-seen-fire.com wrote:
What about the users who clone from their own GitHub fork as origin and push side-project branches there before merging and pushing finished projects to gerrit?
A proper fix in the works currently is to not need .gitreview file at all if one of the remotes ("origin", "gerrit" or whatever) is pointing to a valid Gerrit instance. Actually we don't need a new remote at all; but that's the behaviour git-review insisted on.
//Saper
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Le 16/04/12 19:18, Jeremy Postlethwaite wrote: <snip>
If you need to know Git very well, then this is a very helpful list of commands you need to know:
http://andyjeffries.co.uk/articles/25-tips-for-intermediate-git-users
Thanks for sharing this link! I have learned two new commands:
See X ways diff when having a merge conflict:
git diff --merged
Browse the blame history easily:
git gui blame
2012/4/13 Antoine Musso hashar+wmf@free.fr:
There are three ways to fix it:
1) always update all remotes by using either: - git fetch --all - git remote update
Side effect: you have to remember to use those commands instead of 'git fetch' or 'git pull origin'.
Two commands are worse than one, so probably no.
2) delete the remote named 'origin': - git remote rm origin
Side effect: 'git pull origin' does not work anymore :-) You need to use 'git pull gerrit'.
There's nothing wrong with it, as long as it is documented properly and everybody uses it.
3) Tell .gitreview to use 'origin' by adding the following line:
defaultremote=origin
Make sure you have a remote named origin, if not rename the one named gerrit :D Side effect: I can not think of any.
Side effect: As long as it's not standard, you have an uncommitted .gitreview file and it various git operations complain about it.
I use (2) aka a remote named 'gerrit'. I recommend (3) make git-review use 'origin' and I think we should modify our .gitreview file to add that line. That will avoid confusion.
So is there any decision about it?
Something is needed, and in the meantime the docs [1] don't address it.
[1] https://www.mediawiki.org/wiki/Git/Workflow
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
On 19/04/12 00:07, Amir E. Aharoni wrote:
- Tell .gitreview to use 'origin' by adding the following line:
defaultremote=origin
Make sure you have a remote named origin, if not rename the one named gerrit :D Side effect: I can not think of any.
Side effect: As long as it's not standard, you have an uncommitted .gitreview file and it various git operations complain about it.
Can't you override .gitreview in your git config?
On Wed, Apr 18, 2012 at 6:41 PM, Platonides Platonides@gmail.com wrote:
On 19/04/12 00:07, Amir E. Aharoni wrote:
3) Tell .gitreview to use 'origin' by adding the following line:
defaultremote=origin
Make sure you have a remote named origin, if not rename the one named gerrit :D Side effect: I can not think of any.
Side effect: As long as it's not standard, you have an uncommitted .gitreview file and it various git operations complain about it.
Can't you override .gitreview in your git config?
Not that I know of. The best solution is just updating our .gitreview files I guess.
-Chad
I thought I should mention here that I tried all of these suggestions and couldn't get any of them to work. In the end, "git rebase gerrit/master" did.
Krenair
On 13/04/12 21:33, Antoine Musso wrote:
Hello,
Some people have reported that since the new version of git-review the had issue submitting patches. The symptom is:
<someone hack> <attempt to send the work by using `git-review`> Complaint:
You have more than one commit that you are about to submit. The oustanding commits are: <some changes you never did :-]>
The issue is because your last commit has been done based on a remote named 'origin' whereas git-review use the remote named 'gerrit'. Since most people update only the origin remote with git pull, the gerrit remote is lagging behind. So technically, git-review attempt to submit any commit between origin/master and gerrit/master hence the long message.
There are three ways to fix it:
- always update all remotes by using either:
- git fetch --all - git remote updateSide effect: you have to remember to use those commands instead of 'git fetch' or 'git pull origin'.
- delete the remote named 'origin':
- git remote rm originSide effect: 'git pull origin' does not work anymore :-) You need to use 'git pull gerrit'.
- Tell .gitreview to use 'origin' by adding the following line:
defaultremote=origin
Make sure you have a remote named origin, if not rename the one named gerrit :D Side effect: I can not think of any.
I use (2) aka a remote named 'gerrit'. I recommend (3) make git-review use 'origin' and I think we should modify our .gitreview file to add that line. That will avoid confusion.
cheers,
On Fri, Apr 13, 2012 at 1:33 PM, Antoine Musso hashar+wmf@free.fr wrote:
The issue is because your last commit has been done based on a remote named 'origin' whereas git-review use the remote named 'gerrit'. Since most people update only the origin remote with git pull, the gerrit remote is lagging behind. So technically, git-review attempt to submit any commit between origin/master and gerrit/master hence the long message.
The *real* solution is to fix git-review so it fetches updates from the gerrit remote just before it checks your commits against it. I have submitted this as https://review.openstack.org/#/c/6741 .
Roan
wikitech-l@lists.wikimedia.org