On 02/07/12 09:30, Krinkle wrote:
Yep, this happens whenever a change is merged from the
gerrit interface.
What we use locally to pull from gerrit doesn't influence the repository.
Also, one doesn't need `git pull --rebase` if you
work in a topic branch
instead of master (which everybody should). Other wise pulling from
master mighit indeed cause a merge commit. But even then, git-review
will warn when trying to push for review because it'll have to push 2
commits
instead of one.
When I most find it annoying is when you're making a change on the tip.
Then you discover something minor to fix on the same file.
So you send two commits with the same parent and that will produce an
ugly merge, even though you don't really care about their order. Even
worse, you may need to make a topic branch merging both in order to
continue working.
(you _could_ send them as dependent changes, but at the cost of being
yelled by doing it that way)
Going back to the original issue about gitk, I'd like if there were an
option to view the changes produced in the first parent by the merge
(instead of empty file changes). Maybe someone knows an incantation for
that?