There is a functional limitation in the hgignore mechanism: once an RE is in place it cannot be refined. Example: there is no straightforward way to express "ignore *.mumble but not a/**/b/*.mumble. Turns out this is straightforward to do. A rough, concrete proposal is at http://www.selenic.com/mercurial/wiki/index.cgi/IncludeExcludeProposal. If there is consensus to try it, I might be willing to take a whack at it.
added nosy from issue534
I think this is a good idea, and for what it's worth, it was also requested here: http://stackoverflow.com/questions/1079342/ I have not yet looked at the wiki page in detail. The correct URL for the page is now: http://mercurial.selenic.com/wiki/IncludeExcludeProposal
I'll just add that this looks like a must-have feature to me. I also just brought this up on IRC after having many issues with trying to make hg work. I am working on the Android OS, and so I have the source code for the entire thing on my computer. I'd like to ignore most of that, and just track the changes to the areas where I am working, so I put the whole thing in the .hgignore file, and then tried to add back the directory where my work is. Unfortunately though, that's not possible. Being a new user with hg, this took me an hour to sort out, with the help of IRC people, and now, like the proposal says, I'm "Robust to fail," meaning that sooner or later this setup will fail.
mlissner: it sound like you are describing another situation. You have a large clone, but want to ignore most of it on commit? The .hgignore file is not for that, it only deals with files *not* already under revision control. You might be talking about a partial clone instead, but that is not supported.
I *think* it's the same situation. The Android code I'm working on is not under revision control, but I want one directory of it to be. To make it more concrete (hopefully), the folders are roughly: --> Android (listed in .hgignore, containing the whole OS) \ |---> Library1 (automatically ignored as a subdir of Android) |---> Library2 (automatically ignored as a subdir of Android) |---> Library3 (where I'm doing my work, I'd like to have revision control here) |---> LibraryX (imagine 50 more large libraries I want to ignore) So, I *can* add Library3 by removing the Android folder from .hgignore, doing "hg add Android/Library3", and then putting Android back in the .hgignore. But if I create a new file in Library3, I can count on it not being tracked without it being explicitly added. This is problematic. A better solution would be an .hgignore such as: #.hgignore file syntax: glob ignore: Android dontIgnore: Android/Library3 Hopefully that clarifies what I'm trying to do. In other words, I'm not trying to do a partial clone. I'm trying to put only some of my directories in revision control because to put all of them in would create a monster of a repository, which I don't particularly want to do. Sorry if too much detail - I'm hoping a use case will garner some support for this bug.
Mark, thanks for the clarification! I agree that you commented on the right issue and that an 'include' syntax would help you. However, when I raised this on IRC some days ago, Matt said that he disliked this idea -- he once made such a systen for a router and spend much longer explaining the include/exclude rules than actually building the system :-) So he has first-hand evidence that suggests that it causes more problems than it solves. You could look into writing it as an extension, though.
If the include/exclude idea seems to be too complicated, we could consider introducing third alternative 'syntax' instead. We'd have 'glob', 'regex' and say, 'path-regex'. The last one would mean: apply the regex to the full path of a file only and behave as if parent dirs were not ignored. Power of this construct would be similar to that of include/exclude. Nevertheless I feel the include/exclude concept is very simple compared to many existing features.
I'm new to hg, but I'm with dawidtoton: this seems quite simple compared to some of the existing features I've already run into. I think the spec makes it pretty clear how this would work, but an extension does seem like a good first step to scope it out. Sadly though, I am not skilled enough to make such an extension happen. Maybe somebody else is...
I've taken a look at the code, and it seems to me that Mercurial already has support for the basic functions of this feature: --include and --exclude options on the command line. Internally, the .hgignore handling uses the same code as is used to support those options. (Why the command line option is --exclude while the file is .hgignore rather than .hgexclude is probably historical...) Essentially, there's a way to make --exclude rules permanent (and self- documenting), but not for --include. Enabling this feature request would really be either a matter of parsing different sections of .hgignore to trigger the include filter, or parsing a new .hginclude file to do the same thing. I don't know enough to say whether that's possible as an extension or whether it would require a patch to the core of Mercurial.
This is an ancient and recurring feature request, which I turned down well before this bug was created. I've written and supported a couple include/exclude file syntaxes and have decided I would rather say "no, you can't do that" once to 1% of users than "no, you're reading the docs wrong" repeatedly to 20% of users.
OK. Is the handling of the .hgignore file susceptible to an extension being written? Then the code would be available for those who want it, but not installed by default. It may be worth noting that both Git and Bazaar implement this by having a negation operator at the start of a line, which takes precedence over any exclude rules, no matter where they come: # Ignore everything .* # Except: !\.hgignore !^Work/
Much to my surprise, I've stumbled upon my past self. Back in 2009, I looked for this feature when I needed it then, but then moved on and figured out some other way. I'm again at a point where this would be very useful. I see four advantages, and think this should be in core, not an extension: 1. self-documentation 2. feature parity with git and bazaar 3. it's useful when you have a LOT of files that you want to exclude and a few you need to include. It's much easier to say: "Here are the five directories that I care about." 4. It's permanent. Being able to share an hginclude/ignore file is very useful if you're using Hg to track files in similar ways in similar systems. Would love to see this feature.
--- Bug imported by bugzilla@serpentine.com 2012-05-12 08:43 EDT --- This bug was previously known as _bug_ 712 at http://mercurial.selenic.com/bts/issue712