In our app, the user can navigate between pages using the toolbar, and Page 1 is shown by default. I'm modifying Page 3a, which is only accessible through a couple of toolbar clicks. This is annoying to do during debugging, so in main.cpp I've set the default to be Page 3a, but I definitely do not want to check this in. However, Mercurial is constantly telling me that main.cpp is modified (of course), and this interferes with things like merges.
I would like to move main.cpp into a special list within Mercurial that is basically, "yes, I know this file is modified, don't worry about it". Note that the Shelf extension isn't quite what I want, because main.cpp will be reverted back to its original state. I also don't want to "forg开发者_Python百科et" the file. Does anyone have a solution for this?
(mods: feel free to edit this question to be more concise)
If this were shorter, I would have added it as a comment to pyfunc's answer, since it's just adding a bit of info.
There are two issues, apparently:
- Allow commit without committing main.cpp
- Allow pulls without losing the modifications to main.cpp
To add to the commit exclude suggestion for (1), if you can use TortoiseHg, it offers a commit exclude list without the drawback of the defaults section and without needing to remember whether you need to use an alias on this particular project. You can read about my experience with it here.
There is no answer for (2). While shelve takes a couple steps, you're going to have to put in some work because Mercurial will fail to pull with local changes, it's that simple. I would recommend mq since Tortoise provides nice integration with the commit dialog, but it's really not any simpler than shelve in the one-file-changed case.
It's really not hard to use shelve or mq, though, so I wouldn't worry too much about it.
There are no extensions that allows you to ignore a file that is already tracked by Mercurial.
How ever, there are few approaches which you can follow.
As Ry4an suggest, block commits that include the file and then do a explicit
hg commit file1, file2, ...
Another elegant approach is to tell the commit method to ignore certain types of file while committing files.
I like this approach better.
hg commit --help
.......
-X --exclude PATTERN [+] exclude names matching the given patterns
Example:
say I have two files a.py, b.py in my repo. I have changed them both.
hgt $ hg status
M a.py
M b.py
hgt $ hg commit -X a.py -m "Added new line to b.py"
hgt $ hg status
M a.py
This is actually a fairly common usage pattern. For just one file, either the -X
option or shelving and unshelving as needed is probably the simplest method, but as usual for DVCS, the more general solution involves creating another branch. An example of that (for bzr, but the principles apply) is found here.
Essentially, you start with your public branch that mirrors the upstream branch. From there, you branch off a "local changes" branch, which is where you make the change to main.cpp. From that "local changes" branch, you create your feature branch, which is where you do your normal daily work, committing as normal.
When you're ready to share your changes, you cherry pick them back into your first branch, thereby getting the changes you just made without the local changes to main.cpp. Using this method, you can even make public fixes to main.cpp without your local debug hack getting checked in. The downside is some extra complexity on pulls and merges, as they have to go through the upstream and local changes branches first in order to keep the cherry pick clean.
As Chris pointed out in the comments the quick and dirty way to do this is using the mechanism I suggested in another question. The better way to do it is a commit hook that prevents commits including that file:
[hooks]
pretxncommit.nomain = sh -c "! hg log -r tip --template '{files}' | grep -q /main.cpp"
You still have to remember not to include main.cpp in your commit line, but when you forget the commit will refuse to commit.
精彩评论