Steffen Prohaska <[EMAIL PROTECTED]> writes:
> The patches are not included in 1.5.5. The patch series by Linus
> (tip is 1102952b4) is on Junio's next branch, so I guess it will
> become available in Git 1.5.6.
Because I do not use Windows for development myself, unless and until I
hear from people who have exercised the code and ironed out the kinks on
Windows, either:
(1) The series does not graduate to 'master' by the time 1.5.6 happens,
because the series is unnecessary on POSIX systems; and/or
(2) It is included in 1.5.6, but what I can guarantee stops at "this does
not hurt POSIX systems when it is not activated". IOW, if activated,
it may not work on Windows at all.
How would you guys want to proceed from here?
If msysgit people can try it out and resolve potential issues while it is
still on 'next' in my tree, we can have a 'tested and seems to work even
on Windows' version in 'master' when the series is included in a tagged
release of git, perhaps in 1.5.6 or 1.6.0.
On the other hand, if msysgit people do not start their work on anything
but my 'master', then the current Linus's code, which may or may not work
on Windows, will be in a tagged release of git (be it 1.5.6 or 1.6.0)
first (not because it is useful, but because I hate carrying unmerged
patches in my tree), and it is very likely that a msysgit release based on
that tagged release will have to be delayed while you guys fix the fallout
from the new code. After that, fixup patches need to be fed back to the
mainline, cooked in 'next' for a while to prove that they do not break
other people on POSIX systems. Which means that a release of msysgit that
carries minimum "Windows-only workaround" patches on top of the official
git release will have to wait one cycle later, when the fixup fed back to
the mainline graduates out of 'next'.
To me personally, it does not make much difference either way, but it
feels that the former approach treats the development track of msysgit
fork more "official" and an integrated part of git development. A new
feature is proposed, cooked in 'next' and all parties involved, not just
POSIX people, tests and sends in fixes while it still is on 'next' until
it is polished enough and shines. The latter approach feels more like
treating msysgit fork a second class citizen, from the point of view of
the development workflow.
IOW, there should be more "that series on 'next' needs to be updated with
these patches to work on Windows, please do not merge them to 'master'
before the issue is resolved", and less "the newly released git, which
contains this and that features that have been cooking for a few weeks on
'next' that have recently graduated to 'master', do not work on Windows".
The latter is a sure sign that the Windows people are not participating
enough (and I think you know which change in 1.5.5 I am talking about).
