Mercurial's only true "plugin" extension: inotify... and can it be done in Git?

When reading "Distributed Revision Control with Mercurial"[1] to see how Mercurial differs from Git, in the chapter 14 "Adding functionality with extensions" there is description (in section 14.1) of one interesting extension (see also [2]), namely 'inotify' extension.

This extension[3][4] optimises "hg status" command by asking file notification daemon about changed files instead of doing stat. I'm not sure how useful this extension is: inotify is Linux specific, and Linux has fast stat... nevertheless this is one example where extension (plug-in) framework shows that it can do more than good scriptability.

I wonder if, and how, such 'extension' could be done with Git...

References: =========== [1] http://hgbook.red-bean.com [2] http://www.selenic.com/mercurial/wiki/index.cgi/UsingExtensions [3] http://hgbook.red-bean.com/hgbookch14.html#x18-31700014.1 [4] http://www.selenic.com/mercurial/wiki/index.cgi/InotifyExtension

On Sun, 9 Mar 2008, Jakub Narebski wrote:

By the way, when browsing list of available Mercurial extensions http://www.selenic.com/mercurial/wiki/index.cgi/UsingExtensions inotify extension was single extension which doesn't have less or more direct equivalent in Git, or cannot be easy done in Git.

See the table below for details:

Mercurial extension | git equivalent (or proposal)
--------------------+------------------------------------
acl                 | update-paranoid contrib hook
alias               | alias.<cmd> config
bisect              | git-bisect
bugzilla            | possible as hook
children            | possible command, cf. git-name-rev
convert (!)         | <possible, would be nice to have>
extdiff             | diff.external / GIT_EXTERNAL_DIFF
fetch               | git-pull (sic!)
gpg                 | signed tags
graphlog            | <possible, see: tig, git-forest>
hgk (*)             | gitk
imerge              | see git-mergetool
keyword expansion   | check possible gitattributes
mq                  | Guilt, StGit
notify              | post-receive-mail contrib hook,
                    | default update hook
graphviz            | <can be done>
send                | <possible, wrapper around git-bundle>
rdiff (!)           | <a trick for local repo in GitTips>
localbranch (*)     | git-branch, git-checkout
parentRevspec (*)   | rev^, rev^1 or rev^2, rev~n
patchbomb           | git-send-email
record              | git add -i, git commit -i
transplant          | git-rebase
win32ext            | core.autocrlf config
churn               | see git-shortlog
purge               | git-clean
cvscommit           | see git-cvsexportcommit, git-cvsserver
config              | compare git-config
digest              | see git-ls-remote for bundle
diffstat            | git diff --diffstat, default for git-pull
easy*               | see tig
forest              | git-submodule
hgcia               | CIA hook mentioned on GitWiki
inotify (!!!)       |

Footnotes: ========== (*) Directly inspired by git feature (!) No direct equivalent, would be quite a work to add (!!!) No equivalent, don't know if possible

Jakub Narebski wrote:

IIRC, bisect should have a star here (or five, as it's a killer feature).

Andreas Ericsson <ae@op5.se> writes:

Heh, why do we even care? It is a norm that good features cross pollinate across systems and who borrows ideas from whom does not really matter much.

Junio C Hamano wrote:

Because companies such as the one where I work pride themselves in using the most innovative tools. Clearly, git is the most innovative tool here, since its developers managed to cook up something so immensely useful as "git bisect" (which by the way is well-nigh single-handedly responsible for reducing our average bugreport-to-fix time from 4 days to 6 hours).

Andreas Ericsson wrote:

I was not sure if bisect extension didn't come to Mercurial from/via BitKeeper; IIRC it was added at request of Linux kernel, but I might be mistaken...

So in short: the star isn't here because I was not sure.

On Mar 9, 2008, at 09:59, Jakub Narebski wrote:

FWIW, OS X 10.5 has a similar functionality, called "fsevents", as well as a much slower stat.

   -Geert

Geert Bosch <bosch@adacore.com> wrote:

Windows NT on NTFS has a file monitor system that works somewhat like an inotify, but different enough that you gotta write totally different code for it. It also has a much slower stat.

I have wanted to put something like this into git-gui, so that a running git-gui session can see changes made to your working dir "live". But I haven't gotten around to writing it. I did do some early experiments on Windows NT + NTFS with a small C daemon that watches the working directory, but it ran into issues about also need to know what is inside .gitignore to properly avoid sending events that git-gui doesn't want to know about. Like say build object files. :-)

I think the reason Git has never had such an "extension" is we are just that freaking fast when it comes to comparing the working tree to the index. hg wasn't in the early days and that may have been what gave rise to the plugin.

On Mon, Mar 10, 2008 at 06:43:18PM -0400, Shawn O. Pearce wrote:

NFS is an exception there; a git diff takes about 12 seconds for me. It's easy to see why--ping time to the server is about a quarter of a millisecond, so with some 24000 files to stat, and a roundtrip to the server required for each, it would take at least 6 seconds even if there was no other contribution to the stat latency.

But of course there's not much by way of file change notifications in the current NFS protocol either, so that doesn't help.

At some point I tried patching git to do the stat's in parallel (the totally lazy way--instead of modifying the existing code I just did an extra parallel stat of everything first, then threw the results away, so the real work would be done with a hot cache on the client). I could get it down to about 3.5 seconds that way, better though still annoying.

--b.

[Cc: git mailing list, mercurial mailing list]

On Thu, 13 March 2008, Zdeněk Vráblík wrote:

First, a word of warning. I use Git (and sometimes even contribute
to it), and watch its mailing list; I know Mercurial only from 
documentation and a few discussions on #revctrl IRC channel. So now you 
should know which way I tend to be biased ;-)
 

On http://www.selenic.com/mercurial/wiki/index.cgi/UsingExtensions

   cvscommit            | Push changesets to CVS

But on the link on its wiki page we have

  From: Simon 'corecode' Schubert
  Imbeault, Jean-Christian wrote:
  >
  > Are there any tools available that can push an hg repository
  > into CVS? 
  I've written the cvscommit extension, but it might be outdated and
  maybe could use some structural changes, but I've used it for some
  commits.

There is no documentation for this extension, unfortunately, so I don't know what exactly it does.

From listed git "equivalents"

  git-cvsexportcommit  (1)  - Export a single commit to a CVS checkout
  git-cvsserver        (1)  - A CVS server emulator for git

it looks like git-cvsexportcommit is more equivalent to hg.ext.cvscommit Mercurial extension.

I don't know of such extension / tool

You are welcome.