This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: reject merges on gdb release branches?
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 22 Jan 2014 11:37:09 +0400
- Subject: Re: reject merges on gdb release branches?
- Authentication-results: sourceware.org; auth=none
- References: <20140122051133 dot GB4762 at adacore dot com> <52DF5B39 dot 1020209 at codesourcery dot com>
> > I propose we do the same for the gdb-7.7 branch, and generally
> > speaking on all GDB release branches, just to make sure that
> > people don't accidently push a merge when they meant to cherry-pick.
> > Thoughts?
>
> My git knowledge is too poor to understand this. How does people push
> a merge? My workflow is to cherry-pick approved patches from one branch
> to master, and git push. I thought that is the only way to push
> commits to master. Am I missing something?
You are doing thing correctly. Another way to do things, if you have
a large number of commits to push, is to "git rebase your-branch master;
git checkout master; git merge your-branch", which should result in
a "fast-forward merge" (which is actually not technically a merge).
For more info, I really recommend you read a book such as "Pro Git",
as understanding the models behind git is a worthwhile investment.
The purpose of this proposal is to make sure that people don't do
"git merge my-commit-on-master" and push that to the release branch.
This would have catastrophic consequences, as it would bring into
the branch all commits on master since we created the release branch.
Not what the contributor wanted, but very easy to do if you don't
know git well enough.
--
Joel