Re: Gerrit Merge "<gerrit topic>" commits

[Alexis La Goutte <alexis.lagoutte () gmail com>]

On Thu, Jan 30, 2014 at 3:17 PM, Bálint Réczey <balint () balintreczey hu>wrote:

> Hi,
>
> 2014-01-30 Evan Huus <eapache () gmail com>:
> > 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.
>
> What is the process for -core to review/valid a commit ?

Because for the moment, a commit with Submit Type "Merge if Necessary"

   - Click in Review,
   - Check the commit log and diff,
   - set Code-Review +2 and Verified +1
   - Click on Publish and Submit

It is not good ?

Regards,
Alexis



> Cheers,
> Balint
>
> > Evan
> >
> > > On Jan 30, 2014, at 6:25 AM, Roland Knall <rknall () gmail com> 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
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe