* C-x v i bug @ 2009-12-03 15:37 Neal Becker 2009-12-03 16:04 ` Dan Nicolaescu 0 siblings, 1 reply; 19+ messages in thread From: Neal Becker @ 2009-12-03 15:37 UTC (permalink / raw) To: emacs-devel hg status test_front_end_spec.py *** failed to import extension rdiff: No module named rdiff ? test_front_end_spec.py The above warning confuses emacs. C-x v i report 'already registered'. After I fixed the above warning (removed rdiff from my .hgrc), then C-x v i worked correctly. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 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 0 siblings, 1 reply; 19+ messages in thread From: Dan Nicolaescu @ 2009-12-03 16:04 UTC (permalink / raw) To: Neal Becker; +Cc: emacs-devel Neal Becker <ndbecker2@gmail.com> writes: > hg status test_front_end_spec.py > *** failed to import extension rdiff: No module named rdiff > ? test_front_end_spec.py > > The above warning confuses emacs. C-x v i report 'already registered'. Indeed, vc-hg-status parses the result of "hg status test_front_end_spec.py" Is there are way to tell hg to ignore .hgrc ? I.E. something like emacs -q ? > After I fixed the above warning (removed rdiff from my .hgrc), then C-x > v i worked correctly. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 2009-12-03 16:04 ` Dan Nicolaescu @ 2009-12-03 16:35 ` Neal Becker 2009-12-03 18:28 ` Dan Nicolaescu 0 siblings, 1 reply; 19+ messages in thread From: Neal Becker @ 2009-12-03 16:35 UTC (permalink / raw) To: emacs-devel Dan Nicolaescu wrote: > Neal Becker <ndbecker2@gmail.com> writes: > > > hg status test_front_end_spec.py > > *** failed to import extension rdiff: No module named rdiff > > ? test_front_end_spec.py > > > > The above warning confuses emacs. C-x v i report 'already > > registered'. > > Indeed, vc-hg-status parses the result of "hg status > test_front_end_spec.py" > > Is there are way to tell hg to ignore .hgrc ? I.E. something like emacs > -q ? > > > After I fixed the above warning (removed rdiff from my .hgrc), then > > C-x v i worked correctly. HGRCPATH= hg showconfig ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 2009-12-03 16:35 ` Neal Becker @ 2009-12-03 18:28 ` Dan Nicolaescu 2009-12-03 18:37 ` Neal Becker 2009-12-03 19:25 ` Stefan Monnier 0 siblings, 2 replies; 19+ messages in thread From: Dan Nicolaescu @ 2009-12-03 18:28 UTC (permalink / raw) To: Neal Becker; +Cc: emacs-devel Neal Becker <ndbecker2@gmail.com> writes: > Dan Nicolaescu wrote: > > > Neal Becker <ndbecker2@gmail.com> writes: > > > > > hg status test_front_end_spec.py > > > *** failed to import extension rdiff: No module named rdiff > > > ? test_front_end_spec.py > > > > > > The above warning confuses emacs. C-x v i report 'already > > > registered'. > > > > Indeed, vc-hg-status parses the result of "hg status > > test_front_end_spec.py" > > > > Is there are way to tell hg to ignore .hgrc ? I.E. something like > emacs > > -q ? > > > > > After I fixed the above warning (removed rdiff from my .hgrc), > then > > > C-x v i worked correctly. > > HGRCPATH= hg showconfig So should we run HGRCPATH= hg status by default in vc-hg-state? If yes, where else should we do it? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 2009-12-03 18:28 ` Dan Nicolaescu @ 2009-12-03 18:37 ` Neal Becker 2009-12-03 23:01 ` Martin Geisler 2009-12-03 19:25 ` Stefan Monnier 1 sibling, 1 reply; 19+ messages in thread From: Neal Becker @ 2009-12-03 18:37 UTC (permalink / raw) To: mercurial-devel; +Cc: emacs-devel Dan Nicolaescu wrote: > Neal Becker <ndbecker2@gmail.com> writes: > > > Dan Nicolaescu wrote: > > > > > Neal Becker <ndbecker2@gmail.com> writes: > > > > > > > hg status test_front_end_spec.py > > > > *** failed to import extension rdiff: No module named rdiff > > > > ? test_front_end_spec.py > > > > > > > > The above warning confuses emacs. C-x v i report 'already > > > > registered'. > > > > > > Indeed, vc-hg-status parses the result of "hg status > > > test_front_end_spec.py" > > > > > > Is there are way to tell hg to ignore .hgrc ? I.E. something like > > emacs > > > -q ? > > > > > > > After I fixed the above warning (removed rdiff from my .hgrc), > > then > > > > C-x v i worked correctly. > > > > HGRCPATH= hg showconfig > > So should we run HGRCPATH= hg status by default in vc-hg-state? > > If yes, where else should we do it? Crossposting to mercurial devel. Anyone have suggestions? My gut reaction is to say always use HGRCPATH='', but not really sure. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 2009-12-03 18:37 ` Neal Becker @ 2009-12-03 23:01 ` Martin Geisler 2009-12-03 23:42 ` Brodie Rao 0 siblings, 1 reply; 19+ messages in thread From: Martin Geisler @ 2009-12-03 23:01 UTC (permalink / raw) To: Neal Becker; +Cc: mercurial-devel, emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 2060 bytes --] Neal Becker <ndbecker2@gmail.com> writes: > Dan Nicolaescu wrote: > >> Neal Becker <ndbecker2@gmail.com> writes: >> >> > Dan Nicolaescu wrote: >> > >> > > Neal Becker <ndbecker2@gmail.com> writes: >> > > >> > > > hg status test_front_end_spec.py >> > > > *** failed to import extension rdiff: No module named > rdiff >> > > > ? test_front_end_spec.py >> > > > >> > > > The above warning confuses emacs. C-x v i report 'already >> > > > registered'. >> > > >> > > Indeed, vc-hg-status parses the result of "hg status >> > > test_front_end_spec.py" >> > > >> > > Is there are way to tell hg to ignore .hgrc ? I.E. something > like >> > emacs >> > > -q ? >> > > >> > > > After I fixed the above warning (removed rdiff from my > .hgrc), >> > then >> > > > C-x v i worked correctly. >> > >> > HGRCPATH= hg showconfig >> >> So should we run HGRCPATH= hg status by default in vc-hg-state? >> >> If yes, where else should we do it? > > Crossposting to mercurial devel. Anyone have suggestions? My gut > reaction is to say always use HGRCPATH='', but not really sure. That will indeed turn off customizations in ~/.hgrc. But the user will also lose the ui.username setting which might not be what you want when you make a commit :-) Brodie Rao has been working on an a patch that will allow you to set HGPLAIN to make Mercurial revert to 'plain' behavior: http://bitbucket.org/brodie/mercurial-crew-mq/src/tip/script-mode It will disable localization and reset verbose mode. However, it will not help you here: the user has mis-configured Mercurial by asking it to load an extension that does not exist. The warning will still be issued with Brodie's HGPLAIN patch. I think the best solution is to teach your mode to ignore these warnings From Mercurial. -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. [-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 2009-12-03 23:01 ` Martin Geisler @ 2009-12-03 23:42 ` Brodie Rao 2009-12-04 5:34 ` Dan Nicolaescu 0 siblings, 1 reply; 19+ messages in thread From: Brodie Rao @ 2009-12-03 23:42 UTC (permalink / raw) To: Martin Geisler; +Cc: Neal Becker, mercurial-devel, emacs-devel On Dec 3, 2009, at 6:01 PM, Martin Geisler wrote: > Neal Becker <ndbecker2@gmail.com> writes: [snip] >> Crossposting to mercurial devel. Anyone have suggestions? My gut >> reaction is to say always use HGRCPATH='', but not really sure. > > That will indeed turn off customizations in ~/.hgrc. But the user will > also lose the ui.username setting which might not be what you want when > you make a commit :-) > > Brodie Rao has been working on an a patch that will allow you to set > HGPLAIN to make Mercurial revert to 'plain' behavior: > > http://bitbucket.org/brodie/mercurial-crew-mq/src/tip/script-mode This patch is still highly experimental. There are some things I need to rework, and it's not really a solution you can use right now because it's against hg itself. Setting HGRCPATH= is one option, but as Martin mentioned, you'll lose all user configuration: their username, ssh settings, diff options, merge settings, enabled extensions, etc. Another option is to run all commands like this: hg --config ui.debug=0 --config ui.quiet=0 --config ui.verbose=0 --config defaults.CMD= CMD You'll also want to set LANG=C and possibly deal with other LC_* envvars. For stderr output, perhaps diverting it to a buffer and ignoring it would be best. That particular extension warning won't change the return code of any command, which I assume is getting checked. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 2009-12-03 23:42 ` Brodie Rao @ 2009-12-04 5:34 ` Dan Nicolaescu 2009-12-04 9:37 ` Martin Geisler 0 siblings, 1 reply; 19+ messages in thread From: Dan Nicolaescu @ 2009-12-04 5:34 UTC (permalink / raw) To: Brodie Rao; +Cc: Martin Geisler, Neal Becker, mercurial-devel, emacs-devel Brodie Rao <dackze@gmail.com> writes: > On Dec 3, 2009, at 6:01 PM, Martin Geisler wrote: > > > Neal Becker <ndbecker2@gmail.com> writes: > > [snip] > > >> Crossposting to mercurial devel. Anyone have suggestions? My gut > >> reaction is to say always use HGRCPATH='', but not really sure. > > > > That will indeed turn off customizations in ~/.hgrc. But the user will > > also lose the ui.username setting which might not be what you want when > > you make a commit :-) > > > > Brodie Rao has been working on an a patch that will allow you to set > > HGPLAIN to make Mercurial revert to 'plain' behavior: > > > > http://bitbucket.org/brodie/mercurial-crew-mq/src/tip/script-mode > > This patch is still highly experimental. There are some things I need to rework, and it's not really a solution you can use right now because it's against hg itself. > > Setting HGRCPATH= is one option, but as Martin mentioned, you'll lose all user configuration: their username, ssh settings, diff options, merge settings, enabled extensions, etc. > > Another option is to run all commands like this: > > hg --config ui.debug=0 --config ui.quiet=0 --config ui.verbose=0 --config defaults.CMD= CMD 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? 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? [too bad that the status and version number are not available from a single command...] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 2009-12-04 5:34 ` Dan Nicolaescu @ 2009-12-04 9:37 ` Martin Geisler 2009-12-18 15:54 ` Dan Nicolaescu 0 siblings, 1 reply; 19+ messages in thread From: Martin Geisler @ 2009-12-04 9:37 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Neal Becker, emacs-devel, mercurial-devel 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: % 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. -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 2009-12-04 9:37 ` Martin Geisler @ 2009-12-18 15:54 ` Dan Nicolaescu 2009-12-18 16:49 ` Matt Mackall 0 siblings, 1 reply; 19+ messages in thread From: Dan Nicolaescu @ 2009-12-18 15:54 UTC (permalink / raw) To: Martin Geisler; +Cc: Neal Becker, mercurial-devel, emacs-devel 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... Thanks! ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 2009-12-18 15:54 ` Dan Nicolaescu @ 2009-12-18 16:49 ` Matt Mackall 2009-12-18 17:40 ` Dan Nicolaescu 0 siblings, 1 reply; 19+ messages in thread From: Matt Mackall @ 2009-12-18 16:49 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Neal Becker, mercurial-devel, emacs-devel 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'. You're probably thinking "but I actually want to report the last changeset this file was touched in to be more like CVS". No, you don't, that's not the Mercurial way. Trying to emulate CVS is doing your users a disservice. 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. -- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 2009-12-18 16:49 ` Matt Mackall @ 2009-12-18 17:40 ` Dan Nicolaescu 2009-12-18 18:16 ` Matt Mackall 0 siblings, 1 reply; 19+ messages in thread From: Dan Nicolaescu @ 2009-12-18 17:40 UTC (permalink / raw) To: Matt Mackall; +Cc: Neal Becker, mercurial-devel, emacs-devel 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. But "hg parents foo.txt" parse VERSION from there hg log -r VERSION foo.txt 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? _______________________________________________ Mercurial-devel mailing list Mercurial-devel@selenic.com http://selenic.com/mailman/listinfo/mercurial-devel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 2009-12-18 17:40 ` Dan Nicolaescu @ 2009-12-18 18:16 ` Matt Mackall 2009-12-18 19:09 ` Dan Nicolaescu 0 siblings, 1 reply; 19+ messages in thread From: Matt Mackall @ 2009-12-18 18:16 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Neal Becker, mercurial-devel, emacs-devel 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 2009-12-18 18:16 ` Matt Mackall @ 2009-12-18 19:09 ` Dan Nicolaescu 2009-12-18 19:38 ` Matt Mackall 0 siblings, 1 reply; 19+ messages in thread From: Dan Nicolaescu @ 2009-12-18 19:09 UTC (permalink / raw) To: Matt Mackall; +Cc: Martin Geisler, Neal Becker, mercurial-devel, emacs-devel Matt Mackall <mpm@selenic.com> writes: > 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. cat foo.txt foo $ hg parents foo.txt changeset: 0:1ac3a9e3757e user: blah@blah.com date: Thu Dec 17 08:06:39 2009 -0800 summary: Added foo.txt $ hg log foo.txt changeset: 1:6d88f588d323 branch: bar user: blah@blah.com date: Thu Dec 17 08:06:39 2009 -0800 summary: Changed foo to bar changeset: 0:1ac3a9e3757e user: blah@blah.com date: Thu Dec 17 08:06:39 2009 -0800 summary: Added foo.txt $ hg log -r . foo.txt $ env HGRC= hg log -r . foo.txt $ hg --version Mercurial Distributed SCM (version 1.4) Copyright (C) 2005-2009 Matt Mackall <mpm@selenic.com> and others This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This is on an up to date Fedora 12 machine. Is your output different. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 2009-12-18 19:09 ` Dan Nicolaescu @ 2009-12-18 19:38 ` Matt Mackall 2009-12-18 20:08 ` Dan Nicolaescu 0 siblings, 1 reply; 19+ messages in thread From: Matt Mackall @ 2009-12-18 19:38 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Neal Becker, mercurial-devel, emacs-devel On Fri, 2009-12-18 at 11:09 -0800, Dan Nicolaescu wrote: > Matt Mackall <mpm@selenic.com> writes: > > > 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. > > cat foo.txt > foo > $ hg parents foo.txt > changeset: 0:1ac3a9e3757e > user: blah@blah.com > date: Thu Dec 17 08:06:39 2009 -0800 > summary: Added foo.txt > > $ hg log foo.txt > changeset: 1:6d88f588d323 > branch: bar > user: blah@blah.com > date: Thu Dec 17 08:06:39 2009 -0800 > summary: Changed foo to bar > > changeset: 0:1ac3a9e3757e > user: blah@blah.com > date: Thu Dec 17 08:06:39 2009 -0800 > summary: Added foo.txt > > $ hg log -r . foo.txt > $ env HGRC= hg log -r . foo.txt There's no such environment variable. Perhaps you want HGRCPATH. > $ hg --version > Mercurial Distributed SCM (version 1.4) > > Copyright (C) 2005-2009 Matt Mackall <mpm@selenic.com> and others > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > This is on an up to date Fedora 12 machine. > > Is your output different. Yes. The following script: #!/bin/sh rm -rf a hg init a cd a echo foo > foo.txt hg add foo.txt hg commit -qm "Added foo.txt" hg branch -q bar echo bar > foo.txt hg commit -qm "Changed foo to bar" hg update -qr default echo frobozz > frobozz.txt hg add frobozz.txt hg commit -qm "Added frobozz.txt" hg annotate -r . foo.txt gives me: 0: foo -- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 2009-12-18 19:38 ` Matt Mackall @ 2009-12-18 20:08 ` Dan Nicolaescu 2009-12-18 20:26 ` Matt Mackall 0 siblings, 1 reply; 19+ messages in thread From: Dan Nicolaescu @ 2009-12-18 20:08 UTC (permalink / raw) To: Matt Mackall; +Cc: Neal Becker, mercurial-devel, emacs-devel Matt Mackall <mpm@selenic.com> writes: > On Fri, 2009-12-18 at 11:09 -0800, Dan Nicolaescu wrote: > > Matt Mackall <mpm@selenic.com> writes: > > > > > 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. > > > > cat foo.txt > > foo > > $ hg parents foo.txt > > changeset: 0:1ac3a9e3757e > > user: blah@blah.com > > date: Thu Dec 17 08:06:39 2009 -0800 > > summary: Added foo.txt > > > > $ hg log foo.txt > > changeset: 1:6d88f588d323 > > branch: bar > > user: blah@blah.com > > date: Thu Dec 17 08:06:39 2009 -0800 > > summary: Changed foo to bar > > > > changeset: 0:1ac3a9e3757e > > user: blah@blah.com > > date: Thu Dec 17 08:06:39 2009 -0800 > > summary: Added foo.txt > > > > $ hg log -r . foo.txt > > $ env HGRC= hg log -r . foo.txt > > There's no such environment variable. Perhaps you want HGRCPATH. > > > $ hg --version > > Mercurial Distributed SCM (version 1.4) > > > > Copyright (C) 2005-2009 Matt Mackall <mpm@selenic.com> and others > > This is free software; see the source for copying conditions. There is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > > This is on an up to date Fedora 12 machine. > > > > Is your output different. > > Yes. The following script: > > #!/bin/sh > > rm -rf a > hg init a > cd a > > echo foo > foo.txt > hg add foo.txt > hg commit -qm "Added foo.txt" > hg branch -q bar > echo bar > foo.txt > hg commit -qm "Changed foo to bar" > hg update -qr default > echo frobozz > frobozz.txt > hg add frobozz.txt > hg commit -qm "Added frobozz.txt" > hg annotate -r . foo.txt > > gives me: > > 0: foo I think we are miscommunicating. I have stated already that "-r ." works fine for "hg annotate". Please re-read the output I gave above it is for "hg log", NOT "hg annotate". With your script "hg log -r . foo.txt" does not show anything. The point here is that "-r ." CANNOT be used in all contexts to show information about a file. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@selenic.com http://selenic.com/mailman/listinfo/mercurial-devel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 2009-12-18 20:08 ` Dan Nicolaescu @ 2009-12-18 20:26 ` Matt Mackall 0 siblings, 0 replies; 19+ messages in thread From: Matt Mackall @ 2009-12-18 20:26 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Neal Becker, mercurial-devel, emacs-devel On Fri, 2009-12-18 at 12:08 -0800, Dan Nicolaescu wrote: > Matt Mackall <mpm@selenic.com> writes: > > > On Fri, 2009-12-18 at 11:09 -0800, Dan Nicolaescu wrote: > > > Matt Mackall <mpm@selenic.com> writes: > > > > > > > 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. > > > > > > cat foo.txt > > > foo > > > $ hg parents foo.txt > > > changeset: 0:1ac3a9e3757e > > > user: blah@blah.com > > > date: Thu Dec 17 08:06:39 2009 -0800 > > > summary: Added foo.txt > > > > > > $ hg log foo.txt > > > changeset: 1:6d88f588d323 > > > branch: bar > > > user: blah@blah.com > > > date: Thu Dec 17 08:06:39 2009 -0800 > > > summary: Changed foo to bar > > > > > > changeset: 0:1ac3a9e3757e > > > user: blah@blah.com > > > date: Thu Dec 17 08:06:39 2009 -0800 > > > summary: Added foo.txt > > > > > > $ hg log -r . foo.txt > > > $ env HGRC= hg log -r . foo.txt > > > > There's no such environment variable. Perhaps you want HGRCPATH. > > > > > $ hg --version > > > Mercurial Distributed SCM (version 1.4) > > > > > > Copyright (C) 2005-2009 Matt Mackall <mpm@selenic.com> and others > > > This is free software; see the source for copying conditions. There is NO > > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > > > > This is on an up to date Fedora 12 machine. > > > > > > Is your output different. > > > > Yes. The following script: > > > > #!/bin/sh > > > > rm -rf a > > hg init a > > cd a > > > > echo foo > foo.txt > > hg add foo.txt > > hg commit -qm "Added foo.txt" > > hg branch -q bar > > echo bar > foo.txt > > hg commit -qm "Changed foo to bar" > > hg update -qr default > > echo frobozz > frobozz.txt > > hg add frobozz.txt > > hg commit -qm "Added frobozz.txt" > > hg annotate -r . foo.txt > > > > gives me: > > > > 0: foo > > I think we are miscommunicating. I have stated already that "-r ." > works fine for "hg annotate". > Please re-read the output I gave above it is for "hg log", NOT "hg > annotate". > With your script "hg log -r . foo.txt" does not show anything. I see. > The point here is that "-r ." CANNOT be used in all contexts to show > information about a file. You might find 'hg log -fql1 <file>' helpful. -- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 2009-12-03 18:28 ` Dan Nicolaescu 2009-12-03 18:37 ` Neal Becker @ 2009-12-03 19:25 ` Stefan Monnier 2009-12-03 19:40 ` Dan Nicolaescu 1 sibling, 1 reply; 19+ messages in thread From: Stefan Monnier @ 2009-12-03 19:25 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Neal Becker, emacs-devel >> > > hg status test_front_end_spec.py >> > > *** failed to import extension rdiff: No module named rdiff >> > > ? test_front_end_spec.py >> > > The above warning confuses emacs. C-x v i report 'already >> > > registered'. >> > Indeed, vc-hg-status parses the result of "hg status >> > test_front_end_spec.py" >> > Is there are way to tell hg to ignore .hgrc ? I.E. something like >> > emacs -q ? >> > > After I fixed the above warning (removed rdiff from my .hgrc), >> > > then C-x v i worked correctly. >> HGRCPATH= hg showconfig > So should we run HGRCPATH= hg status by default in vc-hg-state? I haven't used Hg and don't know what you can put in .hgrc, so maybe I'm way off base, but at least for Bazaar and CVS I think it would be wrong to ignore the user's .cvsrc and .bazaar/bazaar.conf. Stefan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C-x v i bug 2009-12-03 19:25 ` Stefan Monnier @ 2009-12-03 19:40 ` Dan Nicolaescu 0 siblings, 0 replies; 19+ messages in thread From: Dan Nicolaescu @ 2009-12-03 19:40 UTC (permalink / raw) To: Stefan Monnier; +Cc: Neal Becker, emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > >> > > hg status test_front_end_spec.py > >> > > *** failed to import extension rdiff: No module named rdiff > >> > > ? test_front_end_spec.py > >> > > The above warning confuses emacs. C-x v i report 'already > >> > > registered'. > >> > Indeed, vc-hg-status parses the result of "hg status > >> > test_front_end_spec.py" > >> > Is there are way to tell hg to ignore .hgrc ? I.E. something like > >> > emacs -q ? > >> > > After I fixed the above warning (removed rdiff from my .hgrc), > >> > > then C-x v i worked correctly. > >> HGRCPATH= hg showconfig > > So should we run HGRCPATH= hg status by default in vc-hg-state? > > I haven't used Hg and don't know what you can put in .hgrc, so maybe I'm > way off base, but at least for Bazaar and CVS I think it would be wrong > to ignore the user's .cvsrc and .bazaar/bazaar.conf. At least for vc-hg-state using HGRCPATH= is justfied: 1. vc-hg-state needs to be very fast, so not having to initialize plugins should help. 2. the return value should not depend on whatever the user puts in .hgrc (I think, I've never written a .hgrc file, so...) ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2009-12-18 20:26 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
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).