Prevent accidental commit of a versioned and localy changed file

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jelmer Vernooij wrote:
> Am Montag, den 07.07.2008, 09:59 -0500 schrieb John Arbash Meinel:
>> Sabin Iacob wrote:
>>> Marius Gedminas wrote:
>>>> On Fri, Jul 04, 2008 at 07:26:57PM +0300, Panagiotis Papadakos wrote:
>>>>  
>>>>> Lets say that I have a file on my local branch,
>>>>> which is under version control. I need to make
>>>>> some changes to this file so that the code of the branch
>>>>> can work using my personal options (lets say
>>>>> this is a config file). And I don't want to accidentally
>>>>> commit the changes I have made to the central branch.
>>>>> Is there any way I can somehow 'lock' the file?
>>>>>     
>>>> I've been missing this sort of thing in Subversion.  It would be nice if
>>>> Bazaar had a way to mark files "uncommittable".
>>>>   
>>> I seem to remember something like this in tla (Gnu Arch): there was a
>>> kind of files called "precious" which were copied if a new branch was
>>> created, but weren't taken into account when committing (tla didn't
>>> recognise them as source files).
>>>
>>>
>> I don't think this is quite what he wants. He wants a "version, but do not
>> commit". The idea is basically when you have a config file, and you want to
>> run out of the source tree.
>>
>> The way I've always seen it done elsewhere is that you have a:
>>
>> config.template
>>
>> which you then copy to "config" and edit.
>>
>> IMO, it is a much cleaner way of doing it.
>>
>> That said, you could certainly put something like this together in a plugin. A
>> simple pre-commit check should be able to do it. As a first draft, you could
>> just abort if it tries to commit the file. A further version might just try to
>> skip the file if it is being committed as part of a recursive commit.
>>
>> Unfortunately, the point at which our current logic does a pre_commit check,
>> doesn't let you modify the commit. Only abort it.
> The start_commit hook I added a while ago for the etckeeper plugin does
> allow modification of the commit. etckeeper uses it to modify
> the .etckeeper file.
> 
> Cheers,
> 
> Jelmer

Unfortunately you don't pass in the arguments to the commit itself. So you
can't inspect the commit that is about to happen to figure out what should and
shouldn't be included.

Specifically, I see:

        for hook in MutableTree.hooks['start_commit']:
            hook(self)

And what *I* would want for something like this would be to pass in the commit
message and arguments, and allow them to also be mutated.

I guess you could use 'start_commit' and 'post_commit' to revert all the
changes to that file, let the commit go through, and then restore it to your
saved state. A bit ugly, but it would work.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIcjL4JdeBCYSNAAMRAgHIAJ4sR4cSAZ6ri1DqJRo2ZUJLoblHmgCfeNkR
Ky/jNwZDxugRFtMgQ694W4A=
=XkAd
-----END PGP SIGNATURE-----