You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think that the best way to address this is to choose the base commit wisely ;-)
The problems in your case stem from the fact that you based your patch directly on top of Git for Windows' master, but actually targeted Git's master (and due to the merging rebases, they are quite far apart from one another).
If you choose a tagged revision as base that is reachable from both, it is much easier to use one branch that targets both Git's and Git for Windows' master. In your current case, I would use v2.21.0 as base revision. That should make it possible to merge your branch into both, without merge conflicts.
In other cases, it is not that easy: Git for Windows' master diverges from the latest version quite a bit, especially since v2.22.0 is so close (but Git for Windows' master is still based on v2.21.0, as I am not sure whether we need a v2.21.1 before v2.22.0 comes out, which might take a bit longer than anticipated). For example, I had to resolve merge conflicts when rebasing #223, and I used a different branch name (i.e. appending -gfw) for the corresponding PR git-for-windows#2203.
Unfortunately, this is not something that can be addressed in general, I think... so I am not sure that anything can be done about this ticket, except to close it.
It is tricky playing both sides against each other for commit diffs that should transferable between the two code bases (gfw <-> git), as seen in #237
Not sure if GitHub could support this?
The text was updated successfully, but these errors were encountered: