[JIRA] (JENKINS-58756) Extend git merge before build options to support --allow-unrelated-histories

21 views
Skip to first unread message

VictorMartinezRubio@gmail.com (JIRA)

unread,
Aug 1, 2019, 8:29:03 AM8/1/19
to jenkinsc...@googlegroups.com
Victor Martinez created an issue
 
Jenkins / New Feature JENKINS-58756
Extend git merge before build options to support --allow-unrelated-histories
Issue Type: New Feature New Feature
Assignee: Mark Waite
Attachments: image-2019-08-01-13-27-39-454.png
Components: git-plugin
Created: 2019-08-01 12:28
Priority: Minor Minor
Reporter: Victor Martinez

I'd like to open a discussion on extending the flags to be used when using the git merge before build as I'd like to see whether `--allow-unrelated-histories` could be added to the list of flags. 

 

So far I see:

Do you think there is a genuine case to extend the current configuration to support some extra flags? 

 

Thanks

Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 5, 2019, 8:30:02 AM8/5/19
to jenkinsc...@googlegroups.com
Mark Waite commented on New Feature JENKINS-58756
 
Re: Extend git merge before build options to support --allow-unrelated-histories

I'm quite hesitant to add more flags to an already quite confusing dialog. If you're investing the effort to add better merge facilities, wouldn't it benefit more people if a general purpose capability were added to run a git command with necessary environment for authentication? Then the user could decide if they wanted to perform a merge (since authentication is required for git merge when the repository includes large file support), perform a fetch, or some other git operation.

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 5, 2019, 8:30:03 AM8/5/19
to jenkinsc...@googlegroups.com

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 23, 2019, 8:40:02 AM8/23/19
to jenkinsc...@googlegroups.com
 
Re: Extend git merge before build options to support --allow-unrelated-histories

Since git merge --unrelated histories could be performed from an sh or a bat or a powershell step immediately after checkout, I would not support adding that option to the git plugin merge facility.

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 23, 2019, 8:41:02 AM8/23/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on New Feature JENKINS-58756
Since {{git merge --unrelated - histories}} could be performed from an {{sh}} or a {{bat}} or a {{powershell}} step immediately after checkout, I would not support adding that option to the git plugin merge facility.

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 23, 2019, 8:41:03 AM8/23/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on New Feature JENKINS-58756
Since {{git merge -- allow- unrelated-histories}} could be performed from an {{sh}} or a {{bat}} or a {{powershell}} step immediately after checkout, I would not support adding that option to the git plugin merge facility.

VictorMartinezRubio@gmail.com (JIRA)

unread,
Aug 23, 2019, 8:55:04 AM8/23/19
to jenkinsc...@googlegroups.com

Even though I understand the current flags are a bit confusing, the approach of using sh might not work for the specific use case. Let me explain it though.

A multibranch pipeline project, which its triggers on PR basis, does trigger a Downstream pipeline, which does checkout the repo with something like the below code:

def extensions = []

extensions.add([$class: 'CloneOption', depth: 5, noTags: false, reference: "${reference != null ? reference : '' }", shallow: true])
extensions.add([$class: 'PreBuildMerge', options: [mergeTarget: "${mergeTarget}", mergeRemote: "${mergeRemote}"]])
checkout([$class: 'GitSCM', branches: [[name: "${branch}"]],
        doGenerateSubmoduleConfigurations: false,
        extensions: extensions,
        submoduleCfg: [],
        userRemoteConfigs: [[
          refspec: '+refs/heads/*:refs/remotes/origin/* +refs/pull/*/head:refs/remotes/origin/pr/*',
          credentialsId: "${credentialsId}",
          url: "${repo}"]]])

 

The idea is, to use the PR commit and do a merge with the mergeTarget branch.

In some cases, normally when the PR got obsoleted then the above snippet causes:

Branch not suitable for integration as it does not merge cleanly: Command "git merge --ff 2e9655537626c4c340770ada2ea7d36bd5632132" returned status code 128
...
fatal: refusing to merge unrelated histories

 

That's the reason I'd like to add that particular flag. Or maybe I've misunderstood how to solve that particular use case.

 

Cheers

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 23, 2019, 9:00:05 AM8/23/19
to jenkinsc...@googlegroups.com

Are the branches in that case actually from unrelated histories?

I assume that the root issue is in the choice to perform a shallow clone with depth 5. If the proposed merge has more than 5 commits, isn't there a risk that Git will assume the histories are unrelated, when they are actually related but the necessary commits to show the relationship have not been pulled?

VictorMartinezRubio@gmail.com (JIRA)

unread,
Aug 23, 2019, 9:09:02 AM8/23/19
to jenkinsc...@googlegroups.com

That's indeed a good point.

Those branches are coming from the traditional PR/master branch git flow. The target branch is normally by default the master one, and origin one is the commit sha from the PR, therefore, it might happen, as you just said, that the shallow clone with depth 5 might be causing that issue

I actually though to tackle the issue more wildly with the flag --allow-unrelated-histories which sounds a bit drastic but on the other hand in a controlled environment might be useful as the shallow cloning can be used anyway.

Thanks for the hints

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 23, 2019, 9:09:03 AM8/23/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on New Feature JENKINS-58756
Are the branches in that case actually from unrelated histories?

I assume that the root issue is in the choice to perform a shallow clone with depth 5.  If the proposed merge has more than 5 commits, isn't there a risk that Git will assume the histories are unrelated, when they are actually related but the necessary commits to show the relationship have not been pulled?


If that is your case, then this [stackoverflow article|https://stackoverflow.com/questions/27059840/how-to-fetch-enough-commits-to-do-a-merge-in-a-shallow-clone] may be useful as well.

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 23, 2019, 9:12:02 AM8/23/19
to jenkinsc...@googlegroups.com

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 23, 2019, 9:12:03 AM8/23/19
to jenkinsc...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages