all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Dan Nicolaescu <dann@ics.uci.edu>
Cc: Neal Becker <ndbecker2@gmail.com>,
	mercurial-devel@selenic.com, emacs-devel@gnu.org
Subject: Re: C-x v i bug
Date: Fri, 18 Dec 2009 12:16:10 -0600	[thread overview]
Message-ID: <1261160170.4629.331.camel@calx> (raw)
In-Reply-To: <200912181740.nBIHexE9018620@godzilla.ics.uci.edu>

On Fri, 2009-12-18 at 09:40 -0800, Dan Nicolaescu wrote:
> Matt Mackall <mpm@selenic.com> writes:
> 
>   > On Fri, 2009-12-18 at 07:54 -0800, Dan Nicolaescu wrote:
>   > > Martin Geisler <mg@lazybytes.net> writes:
>   > > 
>   > >   > Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > >   > 
>   > >   > > Let's first talk about the original problem that started this
>   > >   > > discussion.
>   > >   > >
>   > >   > > When a file in a directory that is under mercurial control is opened
>   > >   > > in emacs, emacs runs "hg status FILE" so that it knows if it's
>   > >   > > registered or not, if it's modified, etc.
>   > >   > >
>   > >   > > Any user settings in .hgrc should be irrelevant to the above. Right?
>   > >   > 
>   > >   > Right. Many people use the color extension to get better feedback from
>   > >   > 'hg status', but if Emacs sets TERM=dumb, then the extension will
>   > >   > disable itself. I'm just mentioning color to say that there are useful
>   > >   > extensions out there that modify even basic commands like 'hg status'.
>   > >   > 
>   > >   > > It's desirable that this is as fast as possible, so processing .hgrc,
>   > >   > > initializing plugins will just waste time.
>   > >   > > After that emacs will want to know the version number for the file, for that
>   > >   > > it runs "hg log -l1 FILE", and parse it from the output.
>   > >   > > Any user settings in .hgrc should be irrelevant for this command.  Right?
>   > >   > 
>   > >   > Right, and it's even quite important that you disable localization (run
>   > >   > hg with LANGUAGE=C in the environment). Otherwise you'll end up parsing:
>   > >   > 
>   > >   >   % hg log -l1 README
>   > >   >   ændring:     9586:a41f2840f9c6
>   > >   >   bruger:      Lee Cantey <lcantey@gmail.com>
>   > >   >   dato:        Tue Oct 13 12:27:50 2009 -0700
>   > >   >   uddrag:      README: revert accidental commit
>   > >   > 
>   > >   > The user could also very well have installed a different default style
>   > >   > by setting ui.style. On the command line it's done line this:
>   > > 
>   > > Thank you, this was very useful in taking care of some issues in emacs.
>   > > 
>   > >   >   % hg log -l1 README --style=compact
>   > >   >   9586   a41f2840f9c6   2009-10-13 12:27 -0700   lcantey
>   > >   >     README: revert accidental commit
>   > >   > 
>   > >   > > [too bad that the status and version number are not available from a
>   > >   > > single command...]
>   > >   > 
>   > >   > Well, you know, files don't really have a version number with modern
>   > >   > version control systems. The entire tree has a version number... You can
>   > >   > of course ask about when a file was last touched, but I think that
>   > >   > information is getting more and more irrelevant these days.
>   > > 
>   > > In emacs the generic Version Control layer needs a version number in some case.
>   > > Here's an example from a bug report:
>   > > 
>   > > cd  /tmp
>   > > mkdir hgtest2
>   > > cd hgtest2
>   > > hg init
>   > > echo foo > foo.txt
>   > > hg add foo.txt
>   > > hg commit -m "Added foo.txt"
>   > > hg branch bar
>   > > echo bar > foo.txt
>   > > hg commit -m "Changed foo to bar"
>   > > hg update -r default
>   > > echo frobozz > frobozz.txt
>   > > hg add frobozz.txt
>   > > hg commit -m "Added frobozz.txt"
>   > > 
>   > > 
>   > > now open the file mkdir /tmp/hgtest2/foo.txt and ask to see the
>   > > annotated version, emacs does that by running
>   > > 
>   > > hg annotate -r REVISION foo.txt
>   > >
>   > > How can REVISION be obtained in this case?
>   > > It should be "0", but
>   > > hg log -l1 foo.txt
>   > > does not show that...
>   > 
>   > Version numbers are not per-file in Mercurial. The number you should use
>   > is the global number (or numbers!) reported by hg parents. This revision
>   > is also known as '.', eg 'hg annotate -r . foo.txt'. 
> 
> . is not usable in all cases.   For the example above:
> 
> hg log -r . foo.txt 
> 
> does not work, it does not show anything.

I just tested it with the above commands and it works at least as far
back as 1.0.

> works.
> 
> So it seems that getting the result of hg parents is TRTD.
> 
>   > You're probably thinking "but I actually want to report the last
>   > changeset this file was touched in to be more like CVS". 
> 
> Nope, not at all.  Nothing is trying to be like CVS here.
> 
>   > As a side note, if you want history relative to the working directory
>   > (and not just all of history), you'll want the -f flag to log.
> 
> What's the more useful version that gives the user a better idea what
> happened to the file in question?

Depends.

-- 
http://selenic.com : development and support for Mercurial and Linux


_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@selenic.com
http://selenic.com/mailman/listinfo/mercurial-devel

  reply	other threads:[~2009-12-18 18:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-03 15:37 C-x v i bug Neal Becker
2009-12-03 16:04 ` Dan Nicolaescu
2009-12-03 16:35   ` Neal Becker
2009-12-03 18:28     ` Dan Nicolaescu
2009-12-03 18:37       ` Neal Becker
2009-12-03 23:01         ` Martin Geisler
2009-12-03 23:42           ` Brodie Rao
2009-12-04  5:34             ` Dan Nicolaescu
2009-12-04  9:37               ` Martin Geisler
2009-12-18 15:54                 ` Dan Nicolaescu
2009-12-18 16:49                   ` Matt Mackall
2009-12-18 17:40                     ` Dan Nicolaescu
2009-12-18 18:16                       ` Matt Mackall [this message]
2009-12-18 19:09                         ` Dan Nicolaescu
2009-12-18 19:38                           ` Matt Mackall
2009-12-18 20:08                             ` Dan Nicolaescu
2009-12-18 20:26                               ` Matt Mackall
2009-12-03 19:25       ` Stefan Monnier
2009-12-03 19:40         ` Dan Nicolaescu

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=1261160170.4629.331.camel@calx \
    --to=mpm@selenic.com \
    --cc=dann@ics.uci.edu \
    --cc=emacs-devel@gnu.org \
    --cc=mercurial-devel@selenic.com \
    --cc=ndbecker2@gmail.com \
    /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.