README: Update git subrepo pull with --force flag
#24
Conversation
There was a problem hiding this comment.
(non-blocking, just answering my own question of "why was there a merge conflict?")
I was hoping that merge conflicts could be avoided if commits were applied sequentially from the last time the remote was pulled, but now I realize that's not what git subrepo is doing (it doesn't store the last commit pulled from the remote). For example, if 6e955d7 and 6f196f7 were applied in that order, there should be no merge conflict. However, it looks like the latest contents are fetched and attempted as a single commit, thus failing on any conflicts.
There was a problem hiding this comment.
Yeah, I don't fully understand why there was a merge conflict. I just pulled in nextstrain/rsv#40 without the --force flag and did not run into any conflicts.
There was a problem hiding this comment.
Hmm, must have something to do with the parent commit in the monkeypox repo. I was able to pull in without the --force flag after changing the parent commit in this test branch.
There was a problem hiding this comment.
@joverlee521 that's weird! A manual search reveals that setting parent to anything nextstrain/mpox@f96fa06 or later prevents merge conflict.
I'd think it's related to my force-push in nextstrain/mpox#175, but the commit where it starts having conflicts is slightly off...
$ git log --oneline --graph # with my own annotations in parentheses
…
* 3037946 (WORKS) update parent
* b766498 (WORKS) Merge pull request #175: Use centralized scripts for NCBI Virus
|\
| * 871817b (WORKS) Use centralized scripts for NCBI Virus
| * afeec9c (WORKS) git subrepo pull (merge) ingest/vendored
* | f96fa06 (WORKS) Merge pull request #176: Update CI workflow triggers
|\ \
| |/
|/|
| * 00f324e (CONFLICTS) Update CI workflow triggers
|/
* fb81750 (CURRENT-CONFLICTS) Merge pull request #173: Use default config and partial overrides
|\
| * 4140aff (CONFLICTS) Set hmpxv1-focused defaults
| * 55f7569 Move common values to default config, allow partial overrides
|/
* 12ccb42 Merge pull request #170 from nextstrain/remove-augur-recursion-limit
…
There was a problem hiding this comment.
This is making me think that we don't need to use --force as default, but maybe just document it as a work-around for merge conflicts.
There was a problem hiding this comment.
That sounds fine to me.
Now that we're actively using git subrepo, looks like it's not as seamless as we initially hoped... but I think still fine to use for now.
There was a problem hiding this comment.
Maybe it'd be better to centralize the currently decentralized usage snippets by putting it in nextstrain/ingest and linking to it from pathogen repo READMEs. That way we only need to make these doc updates in one place.
There was a problem hiding this comment.
Force pushed with --force as a documented workaround instead of the default.
There was a problem hiding this comment.
Maybe it'd be better to centralize the currently decentralized usage snippets by putting it in nextstrain/ingest and linking to it from pathogen repo READMEs. That way we only need to make these doc updates in one place.
Done (I think):
In walking through `git subrepo pull` with @j23414 for monkeypox, we ran into unexpected merge conflicts.¹ Reading through the git subrepo docs,² I found that we can just make a clean "reclone" of the subrepo with the `--force` flag. Instead of working through the conflict resolution, the forced reclone made sense for just getting the latest version of the ingest repo. ¹ https://gist.github.com/joverlee521/b00739c3dcbff66ca99828d43cb80a42 ² https://github.com/ingydotnet/git-subrepo#commands
joverlee521
force-pushed
the
git-subrepo-force
branch
from
750c6dc
to
fb8b17d
Compare
Point users to the centralized usage docs of the vendored ingest repo instead of maintaining a different copy of snippets that may become out of sync. Originally suggested by @victorlin in a nextstrain/ingest PR comment¹ ¹ nextstrain/ingest#24 (comment)
In walking through
git subrepo pullwith @j23414 for monkeypox, we ran into unexpected merge conflicts.¹Reading through the git subrepo docs,² I found that we can just make a clean "reclone" of the subrepo with the
--forceflag. Instead of working through the conflict resolution, the forced reclone made sense for just getting the latest version of the ingest repo.If we are operating on a "pull-only" model for vendoring the ingest repo, using the
--forceflag seems like a reasonable default.¹ https://gist.github.com/joverlee521/b00739c3dcbff66ca99828d43cb80a42
² https://github.com/ingydotnet/git-subrepo#commands
Checklist