On Thu, Jan 30, 2014 at 3:17 PM, Bálint Réczey <bal...@balintreczey.hu>wrote:
> Hi, > > 2014-01-30 Evan Huus <eapa...@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 <rkn...@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-requ...@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-requ...@wireshark.org?subject=unsubscribe
