ignore local changes

[Milian Wolff]

We host a web forum with bzr on launchpad which works quiet nicely. The most annoying issue with bzr is that there is no option to ignore changes on a local file. Let me explain:

* The forum must be installable after checking it out
* The forum software makes some changes to a settings file afterwards
* The forum software requires you to remove the install file

So after installing bzr reports these "uncommited" changes which are not wanted ever to be committed! If we'd commit these the next person could no longer install the forum. It becomes a PITA since you always need to specify which files you want to commit...

What I want is this:

bzr ignore --changes file

So the file stays in bzr for future checkouts but `bzr status`, `bzr diff` etc. wont report the file as changed. This should also support deleted files.

Would be great to see this feature!

[John A Meinel (jameinel)]

Interesting idea. I don't know of this feature in other systems, but perhaps it is useful enough to include.

I will say that *most* people work around it by having a "template" file, which people then copy into the final value. Something like:

project.settings.template <= this file is versioned
project.settings <= this file is ignored (bzr ignore project.settings)

And you are expected to:
cp project.settings.template project.settings

as part of the setup process. If you already have a build step, you could hook in a:
if [ ! -e project.settings ]; then cp project.settings.template project.settings; fi

Or at least something like that.

[Jacek Sieka (arnetheduck)]

I have another use case for this - visual studio solution / project files. Unfortunately, with each new version of visual studio, they are migrated to a new format, so it would be nice to filter them out from the normal commit flow to make it easier to work with multiple versions (while I realize that this essentially is bad behavior by VS, it can't really be worked around with the above mentioned template trick)

As a bonus, it would probably be nice if the commit / status etc had flags to include the ignored files.

[Joakim Stai (ximo)]

This is a missing feature that's really annoying.

In git you have a number of options for ignoring files on different levels (see http://tech.puredanger.com/2008/05/17/git-ignore-files/). As for the situation described in this issue, an entry to the local repository's "$GIT_DIR/info/exclude" file would do the trick.

It would be great to have a similar file in Bazaar, e.g. "$BZR_DIR/checkout/exclude", preferably coupled with a --local flag to the "bzr ignore" command to easily ignore files only in the local repository.

A workaround for now is to add absolute path entries to your global ignore file in "~/.bazaar/ignore", though that can quickly become polluted and chaotic with a number of projects.

My reason for wanting this feature is over on Stack Overflow:
http://stackoverflow.com/questions/2176530

[Raumkraut (raumkraut)]

I could also use something like this for local/test server config changes which shouldn't be propagated back into the trunk.

Perhaps as an alternative solution: the ability to specify non-merging (ignored) local commits, so that a generic merge by another branch will not include that ignored commit? The only way to merge such an otherwise ignored revision would be to explicitly specify the single revision in the merge command.
This could possibly also reduce the amount of work needed to merge back and forth, when there are changes to those files which should indeed be propagated.

[Martin Pool (mbp)]

On 4 February 2010 06:57, Joakim Stai <email address hidden> wrote:

> A workaround for now is to add absolute path entries to your global
> ignore file in "~/.bazaar/ignore", though that can quickly become
> polluted and chaotic with a number of projects.

Sorry I don't see how this is a workaround. The global ignores are
applied in just the same way as ignores in .bzrignore, and neither
applies to files already marked as versioned.
--
Martin <http://launchpad.net/~mbp/>

[Joakim Stai (ximo)]

You're right, it didn't solve the problem. If anybody do have a workaround for this, I'd be very happy to hear it. We need a temporary solution for this scenario until it is solved in Bazaar.

[Martin Pool (mbp)]

On 11 March 2010 00:07, Joakim Stai <email address hidden> wrote:
> You're right, it didn't solve the problem. If anybody do have a
> workaround for this, I'd be very happy to hear it. We need a temporary
> solution for this scenario until it is solved in Bazaar.

I _think_ you can create a view with that config file excluded, and
then put your own copy of it in place? See bzr help view etc.

--
Martin <http://launchpad.net/~mbp/>

[Jelmer Vernooij (jelmer)]

I wonder if looms would be usable here - ie having an upstream branch and a local thread with your configuration that gets "rebased" every time you pull in a new upstream.

[Biji (biji)]

would be great for local application.ini in PHP zend for example

[Biji (biji)]

bzr view solves this issue :D
there should be option to remove file from view,
bzr view --name=x application
bzr view --name=x --remove application/application.ini