Ã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? > 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 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'. > 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. > ... but then > again that would confuse the sort of users that need this the most. That is exactly why I phrased it this way. -- 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