One thing I just noticed when looking at the git history via gitk (on Ubuntu) is that the history looks totally spaghetti and it is hard to make sense of the history. This seems to have happened since the switch to git and post-commit review workflow. It might be worth considering this as well. git pull --rebase (which I assume is being used) usually helps eliminate noisy merge commits, but I suspect something else is going on -- post-review commit might be one reason. Is this something that is worth fixing and can be fixed? Is there some gerrit config that lets gerrit rebase before merge to let fast-forwarding and eliminate noisy merges?
Subbu.
On Sun, Jul 1, 2012 at 5:30 PM, Subramanya Sastry ssastry@wikimedia.org wrote:
One thing I just noticed when looking at the git history via gitk (on Ubuntu) is that the history looks totally spaghetti and it is hard to make sense of the history. This seems to have happened since the switch to git and post-commit review workflow. It might be worth considering this as well. git pull --rebase (which I assume is being used) usually helps eliminate noisy merge commits, but I suspect something else is going on -- post-review commit might be one reason. Is this something that is worth fixing and can be fixed? Is there some gerrit config that lets gerrit rebase before merge to let fast-forwarding and eliminate noisy merges?
Yes, this can be configured in Gerrit on a per-repo basis. I seem to recall we had a reason for not enabling this but I don't remember that discussion very well or whether it took place at all.
Roan
On Jul 2, 2012, at 2:30 AM, Subramanya Sastry wrote:
One thing I just noticed when looking at the git history via gitk (on Ubuntu) is that the history looks totally spaghetti and it is hard to make sense of the history. This seems to have happened since the switch to git and post-commit review workflow. It might be worth considering this as well. git pull --rebase (which I assume is being used) usually helps eliminate noisy merge commits, but I suspect something else is going on -- post-review commit might be one reason. Is this something that is worth fixing and can be fixed? Is there some gerrit config that lets gerrit rebase before merge to let fast-forwarding and eliminate noisy merges?
Subbu.
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.
So best to always work in a topic branch, keep master clean, and do simple pulls from gerrit/master.
-- Krinkle
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?
Le 02/07/12 02:30, Subramanya Sastry a écrit :
One thing I just noticed when looking at the git history via gitk (on Ubuntu) is that the history looks totally spaghetti and it is hard to make sense of the history. This seems to have happened since the switch to git and post-commit review workflow. It might be worth considering this as well.
<snip>
You can have git log ignore the merge commit by passing --no-merges.
We have deployed a new version of Gerrit that bring a [Rebase] button to easily rebase a change before merging it. We could enforce fast-forward on our repos but then we will also have to click that button every time :)
wikitech-l@lists.wikimedia.org