Re: [ANNOUNCE] EasyGit (eg) 0.97

[Elijah Newren <newren@gmail.com>]

On Fri, Jan 30, 2009 at 12:47 PM, Jeff King <peff@peff.net> wrote:
> As an aside, I found some related weirdness. In my git repo, if I do
> this:
>
>  $ git checkout next
>  $ eg log -p
>
> I get log output, but the diff is not colorized (and I have color.diff
> set to "auto" in my ~/.gitconfig). But if I detach my HEAD and show the
> log:
>
>  $ git checkout next^0
>  $ eg log -p
>
> then I _do_ get color in the patch. I also get this error:

Hmm, I had never turned color on before; I guess other eg users hadn't
either.  Anyway, the difference can be explained pretty easily:  eg
log tries to provide user-meaningful names for how commits relate to
the active branch (like git-name-rev but implemented internally in eg
to allow the common case to be fast); if there is no active branch
there's no special naming to do so I simply run git log without
reading and modifying its output.

Essentially, the difference in coloring here is much like the
difference you see between

$ git log
$ git log | less

Whenever I try to load the output in perl, git won't show the
colorization.  I guess I could manually add it when I am printing the
information, but it'd be nicer to just have git do the colorization
despite the fact that its output is not a tty.  Is there an easy way
to do that (without mucking with the user's config file)?

(It looks like eg status is also affected, for similar reasons.)

>  Use of uninitialized value $branch in concatenation (.) or string at
>  /home/peff/eg line 2854.
>  eg: command (git rev-parse refs/heads/) failed
>  eg: received signal 13
>
> The error is easy to explain. The offending code is:
>
>    my $branch = RepoUtil::current_branch();
>    my ($ret, $revision) =
>      ExecUtil::execute_captured("git rev-parse refs/heads/$branch");

Indeed, the latter two lines should have been after the if (!$branch) check.


Thanks,
Elijah