Skip to content

@dependabot recreate does not actually recreate the commit #4652

Closed
Closed
@dependabot recreate does not actually recreate the commit#4652
Assignees
v-kbukum1
Labels
T: bug 🐞Something isn't workingservice 💁Relates to Dependabot features GitHub provides

Description

@jeffwidman
jeffwidman
opened on Jan 20, 2022

I had a dependabot PR that I was munging around with trying to see what additional changes were required to get CI to pass.

However, I accidentally fat-fingered some git commands and dropped the original commit from Dependabot, both locally and on the remote.

So I did a @dependabot recreate since the description of that command says:

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

However, when Dependabot recreated the PR, it didn't reset the commit title or description. It merely reset the code changes of the commit.

I think this is a bug because recreating the PR should recreate the commit metadata, title, description, etc. Honestly, that's a big part of the usefulness of Dependabot, is the detailed commit messages listing what changed and links to more info. Very useful for later git blame spelunking when trying to figure out what may have caused a problem.

Notes:

  • No Job ID that is publicly accessable since this is a recreate of a specific PR.
  • commit hash that was force-pushed by Dependabot is f8bc0a02b4678cae09505a27eb8805b6ca1739ed
  • It was on a go-based repo. However, I suspect this is generic dependabot behavior that would repro for any language.

Activity

  1. jeffwidman
    added
    T: bug 🐞Something isn't working
    on Jan 20, 2022

  2. mctofu commented on Jan 26, 2022

    @mctofu
    mctofu
    on Jan 26, 2022
    Contributor

    I think this happens because a recreate triggers an update of the PR and we currently expect that we can re-use the message from the previous commit: https://github.com/dependabot/dependabot-core/blob/main/common/lib/dependabot/pull_request_updater/github.rb#L186

    In this case the original commit was lost so it probably used the description from another commit in the PR?

  3. jeffwidman commented on Jan 26, 2022

    @jeffwidman
    jeffwidman
    on Jan 26, 2022
    MemberAuthor

    In this case the original commit was lost so it probably used the description from another commit in the PR?

    Yep, that's exactly what happened.

    And that code section is what needs updating. But before opening a PR to fix, wanted to make sure we were all in agreement on what the desired behavior here should be.

  4. mctofu commented on Jan 27, 2022

    @mctofu
    mctofu
    on Jan 27, 2022
    Contributor

    I do think the ideal behavior here would have been to have the proper message on the commit. However, I'm seeing that in the spot that we are calling the PR updater internally we don't have the metadata available... We'd need to track down why that is the case and adjust it first.

  5. solvaholic commented on Oct 3, 2022

    @solvaholic
    solvaholic
    on Oct 3, 2022

    In this case the original commit was lost so it probably used the description from another commit in the PR?

    Yep, that's exactly what happened.

    And that code section is what needs updating. But before opening a PR to fix, wanted to make sure we were all in agreement on what the desired behavior here should be.

    In what scenarios do y'all envision @dependabot would re-use a commit message from a different pull request?

    My Ruby fu is weak. Unless Ruby does something surprising with this bit of code, tho, I think any commit commit_being_updated returns should be from the same pull request where @dependabot recreate was run:

                commit =
              commits.find { |c| c.sha == old_commit } ||
              commits.find { |c| c.commit.author.name.include?(author_name) } ||
              commits.first

  6. bdragon commented on Oct 20, 2022

    @bdragon
    bdragon
    on Oct 20, 2022
    Contributor

    As of #5913 we'll now fall back to using the PR title as the commit message if the old commit has been lost. This is an interim solution until we have the capability to recreate the commit message for PR updates (context)

  7. jeffwidman
    added
    service 💁Relates to Dependabot features GitHub provides
    on Mar 2, 2023

  8. codecholeric commented on Feb 26, 2024

    @codecholeric
    codecholeric
    on Feb 26, 2024

    I ran into something similar today. Had an action that force-pushed something onto the original Dependabot commit (a version update of the project). However, whenever I tried a @dependabot recreate afterwards it would be incapable of creating a proper commit description and just write Dependabot couldn't find the original pull request head commit, $SHA.
    I think this is really unfortunate, because the description of @dependabot recreate really sounds like the Dependabot PR will be recreated from scratch. Having this rely on some old commit message that could vanish from the repo is quite surprising.

  9. jglick commented on Oct 30, 2025

    @jglick
    jglick
    on Oct 30, 2025

    It would really be better IMO if recreate did what it sounds like: close the current PR and create a new PR from scratch targeting the same dependency (at whatever version would be appropriate if it were running an update and there were no existing PR for this dependency). This has been requested elsewhere.

    My organization encountered a curious case today. We have a repo with branch protection which prohibits pushing unsigned commits. We needed to import (think git subtree) historical commits from another repo, long predating the requirement to sign commits, so the PR doing this was merged while temporarily disabling the rule, which was then immediately enforced again. Fine so far. But there were a number of DB PRs open previously which we would like to update to the current base branch to rerun CI. @dependabot rebase cannot work in this case because it would involve (force-)pushing to the DB PR branch; this branch is in the origin repo, not a fork, and the rule sees that the delta from the previous branch head to the new branch head “includes” a bunch of unsigned commits, which it thus rejects. But @dependabot recreate will not work either, for the same reason. And if we simply close the doomed PR, DB will decline to open a new one for that version, so if the dependency component does not change very often, we would need to manually refile the PR.

  10. yeikel commented on Nov 21, 2025

    @yeikel
    yeikel
    on Nov 21, 2025
    Contributor

    I noticed this today, and I also thought it was a bug #13606

    I also think that Dependabot should simply close the pull request and create a new pull request with the updated information

    For people who squash and merge like my team, this unfortunate defect can cause considerable confusion

  11. v-kbukum1 commented on Apr 24, 2026

    @v-kbukum1
    v-kbukum1
    on Apr 24, 2026
    Contributor

    The fix applied. One the fix PR is #14808.

  12. v-kbukum1
    closed this as completedon Apr 24, 2026
  13. v-kbukum1
    self-assigned this
    on Apr 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

T: bug 🐞Something isn't workingservice 💁Relates to Dependabot features GitHub provides

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions