2013/12/30 Junio C Hamano <gits...@pobox.com>:
> Roman Kagan <rka...@mail.ru> writes:
>> I'd like to note that it's IMO worth including in the 'maint' branch
>> as it's a crasher. Especially so since the real fix has been merged
>> in the subversion upstream and nominated for 1.8 branch, so the
>> workaround may soon lose its relevance.
> I do not quite get this part, though.
> If they refused to fix it for real, it would make it likely that
> this workaround will stay relevant for a long time, in which case it
> would be worth cherry-picking to an older maintenance track. But if
> this workaround is expected to lose its relevance shortly, I see it
> as one less reason to cherry-pick it to an older maintenance track.
I thought it was exactly the other way around. By the time the next
feature release reaches users, chances are they'd already have
subversion with the fix. OTOH the workaround would benefit those who
get their maintenance release of git (e.g. through their Linux distro
update) before they get their maintenance release of subversion.
Documentation/SubmittingPatches also suggests to submit bugfixes
But I might have got it wrong...
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html