[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 15:53:28 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

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).  Its drawback is
that it also reflects whitespace changes, but then it's easy to navigate
across them with the proper keybindings (usually A) until finding the
change one is looking for, then getting the corresponding log with l.

> Then I use VC history to look at the changes that are relevant to the
> issue.

I'm not saying that this is an "invalid" workflow.  However, the generic
VC support of Emacs allows, when coupled with a version control system
that is reasonably fast, to use alternate workflows that do not suffer
from significant drawbacks compared to the benefits from not having to
maintain manual ChangeLog files separately.

This is not specific to Git (actually, it was already available in CVS).
What is noticeable, however, is that Git's performance does not make
this a waiting game, and that Git is often able to track the origin of
lines even when material was rearranged beyond the renaming of files.

Git offers several options for the amount of history searching it should
perform: what is intransparent is just which options vc.el happens to be
using and how one can change them in case something goes wrong.

In general, it's more often than not the case that Git finds out more
than one expected, but when the reverse happens, vc-git does not make it
easily discoverable how one can tell Git to search more thoroughly.

I digress: what I wanted to say is that one gets a few tools (and with
an Emacs interface) that work reasonably well for addressing most of the
tasks one would otherwise use a ChangeLog to get done.

David Kastrup

reply via email to

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