Re: ucf: Diversion of /u/b/ucf by etcgit
On Sun, Feb 22 2009, Vincent Danjean wrote:
> Manoj Srivastava wrote:
>> I think the correct thing for the wrapper to do is
>> a) change branch to the upstram_version_branch, and commit the new
>> upstream.
>> b) Change back to the local branch
>> c) run ucf and let the user do their thing (replace, not replace, edit,
>> whatever).
>> d) Commit the result to the local_changed_branch.
>
> I also think this would be a good think.
>
> But perhaps, ucf can be improved to detect this situation (perhaps a new
> option that etcgit add before calling the real ucf) and can propose a
> new way to resolve the confict :
> - use old conffile
> - use new conffile
> - see diff
> - try experimental 3 way merge
> - ...
> - merge with etcgit <- new option for the user
I'll be happy to review and accept a patch adding such a
command-line option and a run-hook invovation to ucf.
> If selected, the new option will run a callback provided by etcgit
> that will merge the corresponding branches with git.
Sounds good.
> You will need to discuss between you to define properly the
> interfaces.
> It is also possible to improve ucf to propose new generic ways of
> handling merges (and perhaps storing the original file and the
> resulted file) just by installing callback scripts.
You know where to file wishlist bugs. Adding run-hook calls to
parts of the ucf processing should be easy; specifying those hooks only
slightly more complex.
> Then etcgit or other similar packages will be able to install their
> hooks without messing with provides/conflicts/diversions/... of ucf
I am always open to feature requests (preferably with
patches). However, I do not now, and do not plan in the future, to
personally use etckeeper. I already have bit of my /etc in git, but I
only keep files I have invested some effort into modifying in git, and
I mainly care about the history of the file o disk, as opposed to
upstream versions of the configuration file -- and I ma happy with this
subset of etckeeper functionality.
Given that, and my unfamiliarity with etckeeper internals, these
enhancements to ucf won't happen without collaboration with people with
knowledge of, and motivation for, things like etckeeper.
manoj
--
"There is no snooze button on a cat who wants breakfast."-Unknown
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: