Alon Ziv [off-list ref] writes:
I am referring, for example, to the changes from commit dc380d6, which
were reverted in Git mainline (actually in "next", they never reached
Git's "master"). Or to the changes from 4493e36, which had the same
fate.
MinGW repository bases its work on my 'next', so it will not be
pulled wholesale to my 'master'. The plan is to trickle down
the platform independent bits of fixes and refactoring to the
mainline, as well as #ifdef __MINGW32__ and $(findstring MINGW)
parts, but that will most likely happen as a series of bite
sized patch series to the list with public reviews.
I do not know if you mistyped dc380d6 (I do not find it there),
but reverting 4493e36 (merge of jc/3way) was intentional. The
work in that commit that deviates from the mainline is the
jc/3way topic, which turned out to be incomplete and not very
usable. MinGW tree might not have synchronized with the latest
from the mainline in which case it might not have merged the
revert from me yet, and that may be why you are seeing the
differences.
On Wed, 2007-05-16 at 12:09 -0700, Junio C Hamano wrote:
I do not know if you mistyped dc380d6 (I do not find it there),
I did; it was dc3806d. I don't know how it slipped... I usually
cut'n'paste commit IDs :-/
but reverting 4493e36 (merge of jc/3way) was intentional. The
work in that commit that deviates from the mainline is the
jc/3way topic, which turned out to be incomplete and not very
usable.
I know it was intentional; but the revert happened on Feb 13, and the
MinGW port is supposed to be merged up to v1.5.1. The revert of dc3806d
("in_merge_bases(): optimization") and 40e0e66 ("merge_base(): move
traversal into a separate function.") also happened on Feb 13, and both
of there commits are still present in the MinGW master branch.
Maybe I'll just try cherry-picking the port's commits on top of the
latest master, and see if anything breaks :)
-az
Junio C Hamano wrote:
Alon Ziv [off-list ref] writes:
quoted
I am referring, for example, to the changes from commit dc380d6, which
were reverted in Git mainline (actually in "next", they never reached
Git's "master"). Or to the changes from 4493e36, which had the same
fate.
MinGW repository bases its work on my 'next', so it will not be
pulled wholesale to my 'master'. The plan is to trickle down
the platform independent bits of fixes and refactoring to the
mainline, as well as #ifdef __MINGW32__ and $(findstring MINGW)
parts, but that will most likely happen as a series of bite
sized patch series to the list with public reviews.
I do not know if you mistyped dc380d6 (I do not find it there),
but reverting 4493e36 (merge of jc/3way) was intentional. The
work in that commit that deviates from the mainline is the
jc/3way topic, which turned out to be incomplete and not very
usable. MinGW tree might not have synchronized with the latest
from the mainline in which case it might not have merged the
revert from me yet, and that may be why you are seeing the
differences.
Sometime around 1.5.0 I decided to merge only 'master' into MinGW and I
didn't notice that there were some more or less important reversals in
'next'. (Note to myself: Pull 079f7cb27b into mingw before next update.)
-- Hannes