On Fri, Jan 30, 2009 at 12:47 PM, Jeff King <peff@xxxxxxxx> 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
--
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
