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? _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
