Re: What's cooking in git.git (Feb 2011, #05; Wed, 23)

On Thu, Feb 24, 2011 at 00:26, Junio C Hamano <gitster@pobox.com> wrote:

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?

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.

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.

I like it.

Agreed.

Looks good, and maybe I'll debug the Perl one of these days.

I really like this as noted elsewhere. But it seems that it would go down better if the helper was submitted later on.

I like the new name.

Yeah, but fix up the typo in the subject. Should be "environments" :)