Last modified: 2013-11-25 10:03:19 UTC
Git can show of hundreds of commits when someone tries to make a simple commit and it's terrifying. I hit this issue as well. Clearly we need better docs or a better workaround for this issue. ---- Hmmm, I think I went through those steps, but when I got to git review, it listed 100s of commits, so I assumed I'd done something wrong. Thanks. ---- Source: https://gerrit.wikimedia.org/r/96810
This usually happens when you do a "git pull" or "git pull origin" by force of habit, instead of "git pull master". This means you are pulling in changes from remotes/origin/master, but git-review only cares about remotes/master/master (unless you changed its configuration, I guess). I don't really consider this behaviour a bug (and if it is, it's an upstream bug in git-review), but I'll leave that judgement up to others. Are you saying you are seeing this in some other scenario?
Maybe it's not a but, but it's not the expected behavior either. As of right now, I had to explain WTF was going on to three GCI students.
http://wikimedia.7.x6.nabble.com/git-review-wanting-to-submit-lot-of-changes-td4879828.html explains the three potential workarounds.
From that post, quoting Hashar: > 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. This sounds like the thing to do. It will be a mild nuisance to some of current developers (personally I've renamed my primary remote to 'gerrit' just like Antoine), but I think that git-review will actually handle that and create the other remote if it's missing.
Note that, for this to work in general, we'd have to either: * have git-review check if its remote is write-enabled (in other words, if it's an ssh:// URL with authentication, and not e.g. anonymous https:// URL which can also be used for cloning and pulling, but not for pushing) * ask people to run `git remote rm origin` before pushing any patches, which is a scary thing to do and which will break their repo if git-review's setup fails
(1) Does this happen only if you work on repository initially cloned in the (default) way that "origin" points to the proper repository and you have no "gerrit" remote? Another question: (2) does running "git-review -s" on the repository before you make any changes help?
(In reply to comment #6) > (1) Does this happen only if you work on repository initially cloned > in the (default) way that "origin" points to the proper repository > and you have no "gerrit" remote? Sort of yes, see below. > (2) does running "git-review -s" on the repository before you make > any changes help? No, it is run automatically on first `git review` if you don't run it yourself. (Internal implemention might differ, but that's the general result.) Basically the issue is that the user will have two remotes, 'origin' and 'gerrit', which will point to the same place (but possibly with different URLs, 'gerrit' will always be ssh://, while 'origin' can be git:, https:, whatever). Running `git review [whatever]` will always use the 'gerrit' remote for fetching and pushing changes, while `git pull` (no arguments) will pull from 'origin'. If: * the user's local copy of 'origin/master' contains commits newer than his copy of 'gerrit/master' (which is likely, since `git pull` only updates origin/master) * the user rebases some patch on master (==origin/master) Then `git review` will see some commits in current branch being pushed that are not in the 'gerrit/master' branch, and will assume they are new commits the user wants to push for review. When actually pushed, gerrit itself will figure it out and do the right thing, but the warning message that appears is very misleading, long (listing all of the commits) and scary.
Thanks Matma Rex, I just wanted to add that I meant running "git-review -s" *before* committing anything. I have a bug filed against git-review (https://bugs.launchpad.net/git-review/+bug/1097278) where I think we should check suitability of existing remotes instead always create a new one.
See <http://www.gossamer-threads.com/lists/wiki/wikitech/362702> for another workaround.
