Re: git merge algorithm question

[Bryan Turner]

On Tue, Sep 5, 2017 at 5:53 PM, Daniel Biran  wrote:
>
>>> I'm trying to better understand one of the merge algorithms as I had some 
>>> triumphs and tribulations with using a set of commands during a merge. 
>>> tldr: can a git merge -s recursive -X patience; // result in a fast-forward 
>>> merge? will --no-ff stop it
>>>
>>> So, the scenario is this:
>>>  - Merging a master branch into a feature branch that is 2+ years old
>>>  - We found this command was more beneficial when merging a large 20k 
>>> line text file:
>>>  - git merge -s recursive -X patience master
>>>  - In a recent merge using this approach the reflog shows that the 
>>> merge was performed using a fast-forward from the feature branch's head
>>>  - 082517-1, feature/branch) HEAD@{23}: merge feature/branch: 
>>> Fast-forward
>>>
>>>
>>> My question is, is it possible for that command to use a fast-forward like 
>>> this? (or did something else go horribly wrong? possibly an atlassian git 
>>> GUI tool corrupting the work):
>>>  - If it is possible for the command to fast-forward the merge when 
>>> making the commit does --no-ff force the command to never use fast-forward 
>>> in this case

Unless you specify --no-ff, git merge is always free to create a
fast-forward "merge", even when you request the recursive strategy
explicitly:

$ git init recursive-merge
Initialized empty Git repository in C:/Temp/recursive-merge/.git/

$ cd recursive-merge/

$ echo "Test" > file.txt

$ git add file.txt

$ git commit -m "Initial commit"
[master (root-commit) ad48617] Initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 file.txt

$ git checkout -b feature-branch
Switched to a new branch 'feature-branch'

$ echo "Edit" >> file.txt

$ git commit -am "Feature branch change"
[feature-branch b226557] Feature branch change
 1 file changed, 1 insertion(+)

$ git checkout master
Switched to branch 'master'

$ git merge -s recursive -X patience feature-branch
Updating ad48617..b226557
Fast-forward
 file.txt | 1 +
 1 file changed, 1 insertion(+)

With --no-ff:

$ git reset --hard ad48617
HEAD is now at ad48617 Initial commit

$ git merge --no-ff -s recursive -X patience feature-branch
Merge made by the 'recursive' strategy.
 file.txt | 1 +
 1 file changed, 1 insertion(+)

With fast-forwarding disabled, you can see the recursive strategy is
used as requested.

>>>
>>> Thanks for the help,
>>> Daniel
>>
>

git merge algorithm question

[Daniel Biran]

>> I'm trying to better understand one of the merge algorithms as I had some 
>> triumphs and tribulations with using a set of commands during a merge. tldr: 
>> can a git merge -s recursive -X patience; // result in a fast-forward merge? 
>> will --no-ff stop it
>> 
>> So, the scenario is this:
>>  - Merging a master branch into a feature branch that is 2+ years old
>>  - We found this command was more beneficial when merging a large 20k 
>> line text file: 
>>  - git merge -s recursive -X patience master
>>  - In a recent merge using this approach the reflog shows that the merge 
>> was performed using a fast-forward from the feature branch's head
>>  - 082517-1, feature/branch) HEAD@{23}: merge feature/branch: 
>> Fast-forward
>> 
>> 
>> My question is, is it possible for that command to use a fast-forward like 
>> this? (or did something else go horribly wrong? possibly an atlassian git 
>> GUI tool corrupting the work):
>>  - If it is possible for the command to fast-forward the merge when 
>> making the commit does --no-ff force the command to never use fast-forward 
>> in this case
>> 
>> Thanks for the help,
>> Daniel
>