[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

From: David Kastrup
Subject: Re: PROPOSAL: Move to git, now that bzr is no longer a req.
Date: Mon, 06 Jan 2014 19:07:02 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Date: Mon, 06 Jan 2014 15:53:28 +0100
>> Richard Stallman <address@hidden> writes:
>> >     I never consult changelog files if I have the full VCS history.
>> >
>> > I do.  I use the ChangeLog files to see what changes affected a
>> > certain function.
>> I tend to use C-x v g for that (it maps to git blame).
> This can be annoyingly slow (and with git is slower than with bzr).
> E.g., try xdisp.c: it takes git more than 4 minutes to display
> anything in response to "C-x v g" (2 minutes if done from the shell).

Oh wow.  Impressive.  Not my average experience, but certainly a
sobering outlier.

> Someone, I think it was you, once told me that the slow operation of
> 'git blame' was a deliberate design decision of the git developers.

Yes and no.  The information is reconstructed rather than stored, but in
general the information is reconstructed rather fast.

git blame also has an incremental mode.  For cases such like this, it
might make sense trying to find a way to integrate this into the
operation of C-x v g though I have to admit that I am somewhat at a loss
regarding how to do this in a pleasant way.

> So it doesn't sound like this is supposed to be the first tool to be
> used for such jobs.  FWIW, I use that only after I already have some
> idea about what I'm looking for and in which time period.

In general, it works pretty well for me.  I have to admit that xdisp.c
is convincingly bad in that regard.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]