1

I have a local mercurial repository with some site-specific changes in it. What I would like to do is set a couple files to be un-commitable so that they aren't automatically committed when I do an hg commit with no arguments.

Right now, I'm doing complicated things with mq and guards to achieve this, pushing and popping and selecting guards to prevent my changes (which are checked into an mq patch) from getting committed.

Is there an easier way to do this? I'm sick of reading the help for all the mq commands every time I want to commit a change that doesn't include my site-specific changes.

Geoffrey Zheng
  • 6,562
  • 2
  • 38
  • 47
Jim Hunziker
  • 14,111
  • 8
  • 58
  • 64

3 Answers3

2

I would put those files in .hgignore and commit a "sample" form of those files so that they could be easily recreated for a new site when someone checks out your code.

Toni Ruža
  • 7,462
  • 2
  • 28
  • 31
  • I think that would only work if I had control of the upstream repository. However, adding them to .hgignore anyway might still work... It's still not ideal, though. Maybe the answer is to just have scripts that patch and unpatch the files in question. – Jim Hunziker Sep 23 '08 at 23:01
1

I know that bazaar has shelve and unshelve commands to push and pop changes you don't want included in a commit. I think it's pretty likely that Mercurial has similar commands.

Josh Matthews
  • 12,816
  • 7
  • 36
  • 39
  • Thank you! That's exactly what I needed. Here's a link to the extension: http://www.selenic.com/mercurial/wiki/index.cgi/ShelveExtension – Jim Hunziker Sep 24 '08 at 02:36
0

I'm curious why you can't have another repo checked out with those specific changes, and then transplant/pull/patch to it when you need to update stuff. Then you'd be primarily working from the original repo, and it's not like you'd be wasting space since hg uses links. I commonly have two+ versions checked out so I can work on a number of updates then merge them together.

nlucaroni
  • 47,556
  • 6
  • 64
  • 86