Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ptp-dev] Merge


On Mon, Nov 21, 2011 at 4:33 PM, Greg Watson <g.watson@xxxxxxxxxxxx> wrote:

On Nov 18, 2011, at 10:09 PM, Roland Schulz wrote:>

>
> Another question about merging. Suppose I make a commit, and 50 other people make commits which are all pushed upstream to the 5_0 branch. When I merge with master, I'm going to merge all 51 commits  right?

Yes

> That means I have to manually work out which of each of the 50 commits should merged and which shouldn't. Is that correct?

No. I suggest that anyone submitting to ptp_5_0 and not wanting to have it in master should immediate merge and revert so that this gets not forgotten.


So let me get this straight. Everyone who commits to ptp_5_0 also has to merge the change with master, then revert the change if it is not meant for master? i.e. they have to remember to take some action if they *don't* want something to happen, as opposed to taking action when they *do* want something to happen.
Yes. That was the policy I suggested. It is not  required by Git. The cherry-pick policy we used before is the other way around. The reason I suggested the new approach is that my understanding of the ptp_5_0 branch is that it includes mostly bug-fixes so that it makes much more sense to include all commits by default than the other way around. This prevents us from forgetting to include bugfixes. It is also the approach used by the other projects I'm involved with. Additionally, merge seems to be a bit better supported by Egit (with command line Git both work equally well). 

Sorry that it wasn't clear. We can always go back to the previous cherry-pick approach if you prefer that approach.

Roland
 
This needs to be documented somewhere since this arse-about nature is not intuitive and completely different from how CVS worked.

 

Greg




--
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309

Back to the top