cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: commits on 4.5
Date Fri, 24 Oct 2014 06:36:38 GMT
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.



4 git merge --help
       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.
           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:

               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.

               This is the opposite of ours.
           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

           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.

           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 <> wrote:

> Maybe we need something like this in Git (maybe it's already there?):
> 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 <
>> 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 <> wrote:
>>> On Thu, Oct 23, 2014 at 10:05 AM, Daan Hoogland <>
>>> 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

View raw message