That would be way better than cherry picking since we could then trace related commits across branches easily.
On Thu, Oct 23, 2014 at 6:30 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > If we had something like that, then we could still have the general rule: > > Everything put in 4.5 must be merged to master (but the person to merge > would have to decide if they just need to do a --record-only kind of merge). > > On Thu, Oct 23, 2014 at 6:29 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> Maybe we need something like this in Git (maybe it's already there?): >> >> >> http://stackoverflow.com/questions/18074697/subversion-mark-as-merged-without-changing-anything >> >> The ability to record a commit has having been merged to another branch, >> but nothing was really merged. >> >> Then when you checked code into 4.5 that shouldn't be in master, you >> simply do a merge --record-only (in SVN terminology). >> >> On Thu, Oct 23, 2014 at 3:37 PM, Mike Tutkowski < >> mike.tutkow...@solidfire.com> wrote: >> >>> If we just did merges (instead of cherry picks) to 4.5, does Git allow >>> us to ONLY merge that particular (merge) commit from 4.5 to master? >>> >>> In other words, I'd want to make sure we were only merging from 4.5 to >>> master what we want to (and, as I mentioned earlier, not bring along >>> commits to 4.5 that should not be in master). >>> >>> In SVN you could do a sort-of "empty" merge from branch x to a later >>> branch (or set of branches), which basically told SVN that that commit was >>> not supposed to be brought forward. Then when the next person came along >>> and committed to branch x and merged forward, SVN would not take your >>> changes along for the ride. >>> >>> On Thu, Oct 23, 2014 at 3:30 PM, David Nalley <da...@gnsa.us> wrote: >>> >>>> On Thu, Oct 23, 2014 at 10:05 AM, Daan Hoogland < >>>> daan.hoogl...@gmail.com> wrote: >>>> > not nice, so merge back is no longer an option. I think I am almost >>>> > ready to admit to that. >>>> > >>>> > >>>> >>>> I came to that conclusion a week or so ago. >>>> If we could keep master as the release branch until we were imminently >>>> releasing, it might not be an issue. But people don't seem to want to >>>> treat master as a release branch under feature freeze. So we end up >>>> branching - and the two start diverging (rapidly) - at best we can >>>> cherry-pick to keep the two similar. >>>> >>>> --David >>>> >>> >>> >>> >>> -- >>> *Mike Tutkowski* >>> *Senior CloudStack Developer, SolidFire Inc.* >>> e: mike.tutkow...@solidfire.com >>> o: 303.746.7302 >>> Advancing the way the world uses the cloud >>> <http://solidfire.com/solution/overview/?video=play>*™* >>> >> >> >> >> -- >> *Mike Tutkowski* >> *Senior CloudStack Developer, SolidFire Inc.* >> e: mike.tutkow...@solidfire.com >> o: 303.746.7302 >> Advancing the way the world uses the cloud >> <http://solidfire.com/solution/overview/?video=play>*™* >> > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the cloud > <http://solidfire.com/solution/overview/?video=play>*™* > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
