Thanks, Leo Yeah, being able to essentially "mark" a commit as NOT needing to be merged (in fact, merging is wrong in this case) to a newer branch is key, I think, to helping solve our branching issues.
On Fri, Oct 24, 2014 at 12:36 AM, Leo Simons <lsim...@schubergphilis.com> wrote: > Hey Mike, > > In git you accomplish these kinds of things with merge strategies. There’s > a lot to choose from. What you’re describing sounds a bit like a variant on > the “theirs” strategy. You can also do a recursive merge with a “theirs” > conflict resolution choice, and there’s many other options. (see below) > > I don’t think it should be used though; there isn’t a tool problem here, > it’s a communication problem and a priority problem causing a quality > problem. > > > cheers, > > > Leo > > ---- > 4 git merge --help > ... > MERGE STRATEGIES > The merge mechanism (git merge and git pull commands) allows the > backend merge strategies to be chosen with -s option. Some > strategies > can also take their own options, which can be passed by giving > -X<option> arguments to git merge and/or git pull. > ... > recursive > This can only resolve two heads using a 3-way merge algorithm. > When > there is more than one common ancestor that can be used for > 3-way > merge, it creates a merged tree of the common ancestors and uses > that as the reference tree for the 3-way merge. This has been > reported to result in fewer merge conflicts without causing > mismerges by tests done on actual merge commits taken from Linux > 2.6 kernel development history. Additionally this can detect and > handle merges involving renames. This is the default merge > strategy > when pulling or merging one branch. > > The recursive strategy can take the following options: > > ours > This option forces conflicting hunks to be auto-resolved > cleanly by favoring our version. Changes from the other tree > that do not conflict with our side are reflected to the > merge > result. For a binary file, the entire contents are taken > from > our side. > > This should not be confused with the ours merge strategy, > which > does not even look at what the other tree contains at all. > It > discards everything the other tree did, declaring our > history > contains all that happened in it. > > theirs > This is the opposite of ours. > ... > octopus > This resolves cases with more than two heads, but refuses to do > a > complex merge that needs manual resolution. It is primarily > meant > to be used for bundling topic branch heads together. This is the > default merge strategy when pulling or merging more than one > branch. > > ours > This resolves any number of heads, but the resulting tree of the > merge is always that of the current branch head, effectively > ignoring all changes from all other branches. It is meant to be > used to supersede old development history of side branches. Note > that this is different from the -Xours option to the recursive > merge strategy. > > subtree > This is a modified recursive strategy. When merging trees A and > B, > if B corresponds to a subtree of A, B is first adjusted to match > the tree structure of A, instead of reading the trees at the > same > level. This adjustment is also done to the common ancestor tree. > ... > > > On Oct 24, 2014, at 2:29 AM, 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>*™*
