-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BF: GitRepo.merge do not allow merging unrelated unconditionally #7312
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## maint #7312 +/- ##
==========================================
+ Coverage 88.71% 90.69% +1.98%
==========================================
Files 327 327
Lines 44533 44545 +12
Branches 5910 5911 +1
==========================================
+ Hits 39509 40402 +893
+ Misses 5009 4128 -881
Partials 15 15
... and 4 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
Appveyor and Travis are green, but the CrippledFS tests show
|
If that test failure is unrelated, this PR did not result in test failures - shall we take it out of draft mode? |
done -- ready for merge although someone really eager could have made a test so we carve in code that we do not merge unrelated histories by default ;) |
As it is user visible change, adding changelog |
added rudimentary unittest |
As @bpoldrack identified in datalad#7291 (comment) the 629e575 which was part of the datalad#4650 concerning introduction of minimal git version to be 2.19.1, and not removing that condition was was combined with argument to the merge function. That commit was released within good old 0.13.4. This change merely reintroduces "if" statement BUT unfortunately that allow_unrelated nowhere exposed in the API really, and used only once with allow_unrelated=True in some single test. So I expect some tests to fail here and most likely us needing to introduce similar option in "update" to finalize this PR.
82eaafe
to
b6d7b6d
Compare
I think this is a saner default that what is currently happening - so I'd be in favor of merging this. |
AFAIK: yes, yes ;-) the situation should be sufficiently rare to not bother with an explicit switch IMHO. We might though improve error/hint messaging and/or provide some config variable to allow for temporary change to this. |
PR released in |
As @bpoldrack identified in
#7291 (comment) the 629e575 which was part of the #4650 concerning introduction of minimal git version to be 2.19.1, and not removing that condition was was combined with argument to the merge function. That commit was released within good old 0.13.4.
This change merely reintroduces "if" statement BUT unfortunately that allow_unrelated nowhere exposed in the API really, and used only once with allow_unrelated=True in some single test. So I expect some tests to fail here and most likely us needing to introduce similar option in "update" to finalize this PR.