From: Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr>
Cc: Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr>,
Andre Spiegel <spiegel@gnu.org>,
emacs-devel@gnu.org
Subject: Re: Limitations of Emacs' vc when using modern backends
Date: Thu, 15 Dec 2005 15:59:12 +0100 [thread overview]
Message-ID: <7ihd9a76f3.fsf@lanthane.pps.jussieu.fr> (raw)
In-Reply-To: <87wti73ue7.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Wed, 14 Dec 2005 22:37:06 -0500")
>> (3) Darcs identifies revisions by a 65-character long hash of a bunch
>> of data, which is not something you want to type. Because of that,
>> vc-darcs allows identifying a revision by a number of different means
>> (see vc-darcs-rev-to-hash if you want the gory details).
> Is this specific to vc-darcs or to darcs? Could you show what it
> does concretely?
Right now, the penultimate revision of vc-darcs.el happens to be
20051116215244-4cc09-4d8edc6c60cacc62a56bb4480ee9cd80be414c18
Obviously, we don't require the user to remember this; what we do is
that we allow the user to type:
- any prefix of the revision hash;
- any prefix of the log message.
If multiple revisions match, the latest one is chosen.
(I'm simplifying somewhat, but that will do for the discussion at hand.)
So I'd usually type ``Update version number to 1.6'', or ``Update
version'' or even just ``Update''. With the current version of
vc-darcs, I end up with multiple buffers called
vc-darcs.el~Update
vc-darcs.el~Update version
etc.
What I'm asking is the means to have vc-darcs.el normalise such
non-canonical revision identifiers to the canonical hash.
Juliusz
next prev parent reply other threads:[~2005-12-15 14:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-15 1:42 Limitations of Emacs' vc when using modern backends Juliusz Chroboczek
2005-12-15 3:37 ` Stefan Monnier
2005-12-15 14:59 ` Juliusz Chroboczek [this message]
2005-12-15 17:33 ` Stefan Monnier
2005-12-15 17:55 ` Juliusz Chroboczek
2005-12-15 20:24 ` Stefan Monnier
2005-12-15 14:37 ` Andre Spiegel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7ihd9a76f3.fsf@lanthane.pps.jussieu.fr \
--to=juliusz.chroboczek@pps.jussieu.fr \
--cc=emacs-devel@gnu.org \
--cc=spiegel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).