On Thu, Feb 24, 2011 at 00:26, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> * ab/i18n (2011-02-22) 73 commits
> [...]
>
> Re^4-roll, coordinated between Ãvar and Jonathan.
>
> I'd like to fast-track the basics (especially the bottom 3 patches), and
> am even tempted to rebase other patches on 'pu' that are not yet in 'next'
> on top of them, to make the transition easier, so please lend extra sets
> of eyeballs on an earlier ones to make sure they are sane (I thought they
> were, but I am far from perfect).
Great that we're moving this forward. After this has made it to next
(or master) I'm going to fix this up a bit and submit the shellscript
i18n-ize patches:
https://github.com/avar/git/compare/5bd8b10...8fd2407
Open issues:
* Write documentation for git-sh-i18n.sh and git-sh-i18n--envsubst
like we have for git-sh-setup (already in WIP form).
* git-sh-i18n--envsubst is still too fat:
$ ldd -r git-sh-i18n--envsubst
linux-vdso.so.1 => (0x00007fffc60fd000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f25cff9e000)
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8
(0x00007f25cfbfd000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f25cf9e0000)
libc.so.6 => /lib/libc.so.6 (0x00007f25cf67f000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f25cf47b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f25d01c0000)
It only needs to link to libc, but I didn't find out when I last
checked how to convince the Makefile to only link against
that. Help welcome :)
* Deal with the changes in 92c62a3f4f93432c0c82e3031a9e64e03ba290f7:
$ git --no-pager grep -A1 abomination *.sh
git-pull.sh: # XXX: This is an abomination
git-pull.sh- require_clean_work_tree "pull with
rebase" "Please commit or stash them."
The changes Ramkumar Ramachandra made in 92c62a3f4f, while good,
are hard to square with i18n.
I think I'll just leave those bits untranslated for now and deal
with them later, since I'm trying to keep this minimal.
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.
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?
> * gr/cvsimport-alternative-cvspass-location (2011-02-18) 1 commit
> Â- Look for password in both CVS and CVSNT password files.
Given that this solves someone's problem I don't think there's any
harm in letting it through. The code and overall behavior is somewhat
nasty, but then so is the rest of git-cvs*.perl, so meh.
> * jc/checkout-orphan-warning (2011-02-18) 1 commit
> Â- commit: give final warning when reattaching HEAD to leave commits behind
I like this sort of thing.
Generally speaking I don't mind Git being more friendly and verbose
about this sort of thing. I.e. for common pitfalls print a few lines
of help because it'll help more than it hurts. I think we've been to
conservative about that in the past.
There's a grammar error here though if I'm not mistaken:
w git ((f11f53c...) $%) $ ./git co 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".
We're also being somewhat inaccurate by omission here, since we won't
give this warning if the commit is reachable from any named referenc,
i.e. if the user just tagged it. So perhaps this should say something
about "not reachable from any named reference" or something, but then
again that would confuse the sort of users that need this the most.
> * jh/maint-do-not-track-non-branches (2011-02-17) 1 commit
> Â- branch/checkout --track: Ensure that upstream branch is indeed a branch
I like it.
> * jk/merge-rename-ux (2011-02-20) 6 commits
> Â- pull: propagate --progress to merge
> Â- merge: enable progress reporting for rename detection
> Â- add inexact rename detection progress infrastructure
> Â- commit: stop setting rename limit
> Â- bump rename limit defaults (again)
> Â- merge: improve inexact rename limit warning
>
> The above three all seemed sensible improvements.
Agreed.
> * jn/test-terminal-punt-on-osx-breakage (2011-02-17) 1 commit
> Â(merged to 'next' on 2011-02-23 at d754139)
> Â+ tests: skip terminal output tests on OS X
Looks good, and maybe I'll debug the Perl one of these days.
> * jk/tag-contains (2010-07-05) 4 commits
> Â- Why is "git tag --contains" so slow?
> Â- default core.clockskew variable to one day
> Â- limit "contains" traversals based on commit timestamp
> Â- tag: speed up --contains calculation
>
> The idea of the bottom one is probably Ok, except that the use of object
> flags needs to be rethought, or at least the helper needs to be moved to
> builtin/tag.c to make it clear that it should not be used outside the
> current usage context.
I really like this as noted elsewhere. But it seems that it would go
down better if the helper was submitted later on.
> * jh/push-default-upstream-configname (2011-02-16) 1 commit
> Â(merged to 'next' on 2011-02-23 at b5c25fa)
> Â+ push.default: Rename 'tracking' to 'upstream'
>
> This is not "renaming" in the sense that breaks existing practice, but
> giving a new official name and deprecating the existing one.
I like the new name.
> * mo/perl-bidi-pipe-envfix (2011-02-15) 1 commit
> Â(merged to 'next' on 2011-02-15 at c36e816)
> Â+ perl: command_bidi_pipe() method should set-up git environmens
>
> Looked reasonable.
Yeah, but fix up the typo in the subject. Should be "environments" :)
--
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