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
