Hi,
2014-01-30 Evan Huus <eapache@xxxxxxxxx>:
> I believe the simpler answer is that the submit type has been set to "Merge If Necessary" which means if changes are not submitted exactly on top of the change they were authored on, Gerrit will produce a merge automatically.
I suggested using "Cherry Pick" for "Change Submit Action" and I would
like to bring it up again.
BTW this is what is documented on our workflow page.
http://wiki.wireshark.org/Development/Workflow :
"After all the criteria are met any Core Developer can push the
"Submit Change" button; integration to the target branch does not
happen automatically.
Changes are cherry-picked to the target branch by Gerrit to keep the
history linear. The rationale behind this is that while merging would
reflect the history more accurately, linear history is easier to
interpret by humans. Changes with dependencies are cherry-picked after
all dependencies are cherry-picked, too. When a cherry-pick can't be
done without conflict, the change needs to be updated in the review. "
This is how I set up Gerrit at my previous job, too.
>
> I expect this was done to reduce rebase conflict when the repo is busy (which can happen) but means that in most cases, we should be rebasing once before submitting to avoid extraneous merges. There should be a "Rebase" button in the UI right next to the submit and cherry pick buttons.
This is not needed when we change the configuration to cherry-picking
as planned.
Cheers,
Balint
>
> Evan
>
>> On Jan 30, 2014, at 6:25 AM, Roland Knall <rknall@xxxxxxxxx> wrote:
>>
>> Hi
>>
>> I've noticed, that there are now quite a few merge commits in the main
>> wireshark repo:
>>
>> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=history
>>
>> All of them are trivial merges, which means, that local git branches
>> of the developer have been merged by a "git pull" with the global git
>> repo, and then pushed to the main repo, bypassing gerrit in the
>> process.
>>
>> As I have used gerrit for 2 years now in our company, I can say, that
>> those commits happen mostly because the workflow for pulling and
>> pushing changes has not been handled correctly.
>>
>> In general, people tend to work on the master branch and commit on
>> their local master branch. If they pull a patchset for review, this
>> will get merged into the master branch, therefore leading to automatic
>> merge commits by git. With the next push, this will be pushed as
>> "Merge" to gerrit.
>>
>> From my personal experience, we tend to keep the local master branches
>> clean, and allways do all our work in sub-branches. As soon as we need
>> to view a patchset, we can pull it with
>>
>> git fetch <gerrit_repo> refs/changes/xx/xx/x && git checkout -b
>> review_branch FETCH_HEAD
>>
>> into a new branch. This keeps the work branches clean and more
>> importantly the master branch clean as well.
>>
>> The remote branch you push to will allways be determined by the
>> refs/for/* tags. Therefore keeping a lot of local branches won't
>> pollute the online git repo.
>>
>> regards,
>> Roland
