镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Benchmark runners may commit results that contain merge conflicts #323

Open

Description

@mpage

Benchmark runners may commit results that contain merge conflicts. We ran into this recently:

It looks like we try to handle this situation:

# Another benchmarking task may have created results for the same
# commit while the above was running. This "magic" incantation means
# that any local results for this commit will override anything we
# just pulled in in that case.
git pull -s recursive -X ours --autostash --rebase

However, the approach that we're using doesn't work. It looks like -X ours doesn't apply to resolving merge conflicts that result from applying stashed changes. I verified this locally by:

  1. Creating a new repo containing a single markdown file.
  2. Cloning the repo into a new directory.
  3. Editing the markdown file in a way that would generate a merge conflict.
  4. Ran git pull -s recursive -X ours --autostash --rebase. The merge conflicts are left for resolution.

I'm not sure if this is a behavior that changed in git recently. I've tested this using git versions 2.39.5 and 2.47.1.

Activity

  1. mpage commented on Dec 23, 2024

    @mpage
    CollaboratorAuthor

    @mdboom - How large/invasive of a change would it be to store the results for each job in a unique file?

  2. mdboom commented on Jan 3, 2025

    @mdboom
    Contributor

    It would be pretty invasive to use a unique name for each job -- plus it's occasionally useful to re-run a job that failed for some external reason (e.g. a network outage) and replace any existing results.

    I wonder if there is a magic incantation that would always replace any upstream changes (e.g. like this line but that actually works). I'll poke around and see if I can find something that works...

  3. added a commit that references this issue on Jan 7, 2025
    ce657e4
  4. added 3 commits that reference this issue on Jan 9, 2025
    21d3626
    b269de4
    8009f44
  5. reopened this on Jan 9, 2025
  6. mdboom commented on Jan 9, 2025

    @mdboom
    Contributor

    Ugh, the solution I arrived at broke on Windows... Back to the drawing board for a bit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions