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
* 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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.