Note that there are some explanatory texts on larger screens.

plurals
  1. POgit octopus merge 'silently' not merging some branches
    primarykey
    data
    text
    <p>I am having some unexpected results that seem to be based on the ordering of branches given to git merge when performing an octopus merge.</p> <p>The following script will replicate my situation</p> <pre><code>#!/usr/bin/env bash rm -rf TEMP # create area to work in mkdir TEMP cd TEMP/ git init # work on master echo "hello world" &gt; file git add file git commit -m "initial commit" # create branch which is at the same point as master git branch hasnt_moved # create another branch 1 commit ahead git checkout -b feature_branch_with_work echo "some interesting work" &gt; other_file git add other_file git commit -m "work on feature branch" git checkout master # always should also have some work ahead of master git checkout -b always echo "some work on always" &gt; other_other_file git add other_other_file git commit -m "work on always branch" # back to master git checkout master # now try a merge #git merge --no-edit --strategy=octopus always hasnt_moved feature_branch_with_work # however if I had ran this then it would be merged in #git merge --no-edit --strategy=octopus hasnt_moved always feature_branch_with_work # I would also expect this to give the same resutls #git merge --no-edit --strategy=octopus always feature_branch_with_work hasnt_moved </code></pre> <p>Here is the state of my git tree after running the above script <img src="https://i.stack.imgur.com/C295L.png" alt="branches before any merge"></p> <p>You can see the 3 commented out lines at the end, below is each line and the graph resulting from running that command on the tree (produced via <code>gitk --all</code>, after running each command you can get 'back' to the start via <code>git reset --hard hasnt_moved</code>)</p> <p>The following 2 cases are as expected (pay attention to the ordering of the branch arguments)</p> <p><code>git merge --no-edit --strategy=octopus hasnt_moved always feature_branch_with_work</code></p> <p><img src="https://i.stack.imgur.com/a2tQk.png" alt="expected results form merge"></p> <p><code>git merge --no-edit --strategy=octopus always feature_branch_with_work hasnt_moved</code></p> <p><img src="https://i.stack.imgur.com/cqYuw.png" alt="expected results form merge"></p> <p>This final case produces unexpected results, as the always branch is not included in the final merged master branch (pay attention to the ordering of the branch arguments).</p> <p><code>git merge --no-edit --strategy=octopus always hasnt_moved feature_branch_with_work</code></p> <p><img src="https://i.stack.imgur.com/W1wTV.png" alt="actual results from merge"></p> <p>If I run the merges one by one I get the expected result:</p> <pre><code>git merge --no-edit --strategy=octopus always git merge --no-edit --strategy=octopus hastn_moved git merge --no-edit --strategy=octopus feature_branch_with_work </code></pre> <p><img src="https://i.stack.imgur.com/z7BMP.png" alt="manual results given expected results"></p> <p>I am wondering why the ordering of the commits given to octopus merge can sometimes cause the <code>always</code> branch to not be merged into master.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload