On Thu, Feb 24, 2011 at 01:57, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Ãvar ArnfjÃrà Bjarmason <avarab@xxxxxxxxx> writes: > >> And then there's the issue that unlike the C patches these will not be >> a no-op that'll be optimized away by the compiler. We'll be calling an >> external program for displaying messages. While this is a trivial cost >> on Unix (especially in the context we're using it, i.e. not in tight >> loops) it's more expensive on Windows. >> >> I don't see any way to deal with that short of implementing some >> pre-processor, but I think the cost is worth it, but others might >> disagree of course. > > Count me one of the others then. ÂDon't we already preprocess our scripts > before installing anyway? Yes, but only for simple variable substitution. Substituting all the gettext calls out when we're not compiling with them would be way more complex than what we do now, but possible. Anyway I'm not going to do it. >> Anyway, I can submit these patches (around 53) real soon, or wait >> until the current series settles. It's the same to me, which would you >> prefer? > > One thing at a time is of course preferred. I'll wait then. No point in submitting them if you won't be merging them down until the other things cool down. > I actually want to stagger the current 70+ patches into two batches. ÂHave > the first handful, after polishing them really shiny, merged to master, > and possibly rebase topics that are only in 'pu' and that are not meant > for 'maint' on top of the result (so that they can use _() in newly added > messages), and then merge "mark strings in git-foo with _()" patches in. > > I suspect it won't be the same to you. ÂAt least, it shouldn't. > > Other topics that fix real bugs or add features continue to trickle down > from 'next' to 'master' and you would need to re-roll what you have today. > If you wait (or if we have you wait) for too long, the re-roll would > become just as unpleasant as my merging the i18n topic to 'pu'. Right, once we're confident (which at least I am) that the first few patches really are no-op's I think it would be easier for everyone to merge them down sooner than later. >>   Warning: you are leaving 1 commit behind that are not connected to >>   any of your branches: >> >> For the singular this should be "1 commit behind which is not >> corrected to any of your branches". > > Heh, thanks. ÂI would think "s/ that are /, /" would fix it rather > nicely. s/corrected/connected/ also :) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html