There's a general feeling that dispatch-conf is better than etc-update. It is now included in portage, and has a man page, which makes it look better than it did a while ago. But etc-update allows the use of vimdiff. eg in etc-update.conf: pager="" diff_command="vim -d %file1 %file2" using_editor=1 There is no equivalent in dispatch-conf.conf - this doesn't work: diff="vim -d %s %s" pager="" Reproducible: Always Steps to Reproduce:
Here's a patch that works (with diff="vim -d %s %s", pager=""). It's kind of crude: diff="vim -d %s %s" pager="" $ diff dispatch-conf dispatch-conf.edited 162c162,166 < os.system((self.options['diff'] + '| %s') % (conf['new'], mrgconf, self.options['pager'])) --- > if self.options['pager']: > command_to_run = ((self.options['diff'] + '| %s') % (conf['new'], mrgconf, self.options['pager'])) > else: > command_to_run = ((self.options['diff']) % (conf['new'], mrgconf)) > os.system(command_to_run) 163a168 > 165c170,174 < os.system((self.options['diff'] + '| %s') % (conf['current'], newconf, self.options['pager'])) --- > if self.options['pager']: > command_to_run=(self.options['diff'] + '| %s') % (conf['current'], newconf, self.options['pager']) > else: > command_to_run=(self.options['diff']) % (conf['current'], newconf) > os.system(command_to_run)
Please use context diffs. diff -u
Thanks for the advice, but I'm not going to take it. diff -u is miles less use to me than vimdiff. With vimdiff I can actually work with the config files, merge the changes, see everything in nice highlighing if I like, etc etc. I'll stick to using either a patched dispatch-conf or etc-update (which supports vimdiff) unless someone feels like enhancing the gentoo dispatch-conf. And what if I wanted to use a graphical diff tool (lots of people do, according to the forums)? This request would support that too. Effectively, the request is to be allowed to use a diff tool without piping the output to a pager. I think it would be worth the effort, and perhaps the fact that it's been implemented in etc-update backs up this idea. On the other hand, if this doesn't ever get done, it's no big deal.
I think the reference to 'diff -u' was for your PATCH. http://bugs.gentoo.org/show_bug.cgi?id=73129#c1
i.e. use 'diff -u dispatch-conf dispatch-conf.edited'
How embarrassing. Sorry for the misunderstanding. Here it is again. $ diff -u /usr/sbin/dispatch-conf dispatch-conf.edited --- /usr/sbin/dispatch-conf 2004-12-03 12:53:22.000000000 +0000 +++ dispatch-conf.edited 2004-12-03 14:48:50.000000000 +0000 @@ -159,10 +159,19 @@ while 1: if show_new_diff: - os.system((self.options['diff'] + '| %s') % (conf['new'], mrgconf, self.options['pager'])) + if self.options['pager']: + command_to_run = ((self.options['diff'] + '| %s') % (conf['new'], mrgconf, self.options['pager'])) + else: + command_to_run = ((self.options['diff']) % (conf['new'], mrgconf)) + os.system(command_to_run) show_new_diff = 0 + else: - os.system((self.options['diff'] + '| %s') % (conf['current'], newconf, self.options['pager'])) + if self.options['pager']: + command_to_run=(self.options['diff'] + '| %s') % (conf['current'], newconf, self.options['pager']) + else: + command_to_run=(self.options['diff']) % (conf['current'], newconf) + os.system(command_to_run) print print '>> (%i of %i) -- %s' % (count, len(confs), conf ['current'])
No activity since February? Heck, I am going back to etc-update + vimdiff then until this gets resolved. Consider this an "annoying bump" to this issue, but I think it is well deserved, for vimdiff is an excellent merging tool.
a silly question - how do i incorporate the patch supplied here into my dispatch-conf? Also if there is no problem with the patch offered, can it be a part of the standard dispatch-conf on portage?
It is not a good idea to use vim to edit config files when using it as the diff command. 2.0.51.20 brings in a "merge" config option which may be usable however.
>It is not a good idea to use vim to edit config files when using >it as the diff command. This might be a matter of opinion. My opinion is that it's an excellent idea. I've been doing it ever since I started using Gentoo and realised that etc-update was unusable (for me) without using vimdiff. I still don't use dispatch-conf because of the lack of support for a diff command that can be used without being piped to a pager. Note that the original problem is the insistence on paging (all the patch does is check the pager variable, and not try to pipe to it if it's empty), not any design decision that prevents the diff command from editing the file.
It is a design decision - regardless of the pager enforcement. Merging of files happens at another stage, which I've recently made into a configuration option. Put it this way, if dispatch-conf's three-way diffing/automatic updating ever eats all your config files because you're editing when it expects you to be viewing then don't post any bugs.
> It is a design decision - regardless of the pager enforcement. OK, I accept that it's a design decision - but it isn't enforced at all except (it seems) by accident. > Merging of files happens at another stage, which I've recently > made into a configuration option. Fair enough. I'll give it a go when I get hold of it. > Put it this way, if dispatch-conf's three-way diffing/automatic > updating ever eats all your config files because you're editing > when it expects you to be viewing then don't post any bugs. I won't. I only post bugs when I think there's something I reckon I should be able to do but can't.
(In reply to comment #9) > It is not a good idea to use vim to edit config files when using it as the diff command. 2.0.51.20 brings in a "merge" config option which may be usable however. I emerged gentoolkit-0.2.1_pre2 which should contain the most recent version of dispatch-conf. How can i set vim to control the merge function?
dispatch-conf is part of portage rather than gentoolkit.
(In reply to comment #14) > dispatch-conf is part of portage rather than gentoolkit. Oops. Thanks for correcting this out. I was looking for a way to use vimdiff as the merging agent, when i came across a remark on the env-update.conf file: # NOTE_1: Editors such as vim/vimdiff are not usable for the merge_command # because it is not known what filenames the produced files have (the user can # choose while using those programs) And indeed, i cannot give vim the name of the output file as an option. If only dispatch-conf would have been able to give the merging agent a duplicated version of the new file, it would have been very easy to merge on that file. Do you find such an idea reasonable, or can you suggest some other method?
Another suggestion: Currently the parameters for both the old file, the new one and the output file are %s. If it was possible to change them into three different indicative parameters, say %out for out, %new for new and %old for old, then it would have been possible to use something other than 'sdiff' to do the merging. Please respond to this suggestion, as this issue has been waiting for a long time.
The form is not so easy to change. People will likely be using dispatch-conf to update dispatch-conf.conf so a change in syntax has the ability to break itself.
Fixed on or before 2.0.51.22-r1
Looking through the batch of bugs, I'm not sure that some of these are actually fixed in stable. Others, the requirements have possibly changed after the initial fix was committed. If you think this bug has been closed incorrectly, please reopen or ask that it be reopened.
Looks like it's possible to use diff="vim -d %s %s" And it doesn't break. I can't see how to make the merge work with vimdiff, but I think that the functionality of etc-update is replicated OK, so I'm happy with this.
(In reply to comment #20) > Looks like it's possible to use > diff="vim -d %s %s" > And it doesn't break. I can't see how to make the merge work with vimdiff, but > I think that the functionality of etc-update is replicated OK, so I'm happy > with this. I find using vim as the diff tool disturbing, in view of Jason's comment #11. I would still like to use vim as the merging tool, as it offers a much better environment for comparison and fine editing. Other solutions are to use dispatch-conf only for the auto-updating of config files, and to manually vimdiff all the rest. The issue that Jason raised in response to my suggestion can be solved in many different manners - one of them is to add a flag in the config file indicating usage og the "new merger command line parameters". I would like to ask that this bug be reopened, so that this tool will be changed in a manner that properly allows using vimdiff as the merger tool. I think it will be better than opening a new bug for the same issue.
Okay.
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
Are you saying that having many open bugs in the bugzilla is a problem for the portage project? How will this feature request be noticed unless this entry stays open? If you will review my idea for solving this issue, i guess i could try and write a patch for it myself and offer it here. Will this help to advance this issue?
patches always help. Re: how will features get implemented without feature bugs, well, frankly was this being implemented now? It's been open for 7 months... The later change on bugs comes down to trying to focus on addressing core portage problems, and address stable bugs; stuff isn't blown off, but it is being marked as what it is, later (core lib rewrite needs to be finished before more stuff is jammed into portage).
(In reply to comment #25) > patches always help. > Re: how will features get implemented without feature bugs, well, frankly was > this being implemented now? It's been open for 7 months... Just came across this thread whilst looking at how to configure dispatch-conf here. After reading all the comments, it seems to me this can be addressed fairly easily in the dispatch-conf.conf file. Here's what I've hacked together: merge="out='%s'; old='%s'; new='%s'; cp \$old \$out ; vimdiff \$out \$new"
Reopening for consideration (per comment #21)
This is how to use emacs' ediff: (first, the complex way, which doesn't make permanent changes until you save) merge='emacs "%s" --eval "(progn (rename-buffer \\"merge\\") (insert-file \\"%s\\") (find-file \\"%s\\") (rename-buffer \\"clean-new\\") (toggle-read-only 1) (ediff-buffers \\"merge\\" \\"clean-new\\") )"' Here's a simpler alternative: (that I have not tested) merge='out="%s"; old="%s"; new="%s"; cp "$old" "$out"; emacs --eval "(ediff \"$out\" \"$new\")" '
Comment #28 appears to present some solutions that use the 'merge' config option as it was designed to be used. Should we include one of those as an example in the config file? If that approach isn't sufficient then please explain why. Please do not post any more suggestions that involve abuse of the 'diff' config option to modify files.
I love the solution provided, but I find that it makes for a more "logical" flow if I swap old and new like so: merge="out='%s'; old='%s'; new='%s'; cp $new $out; vimdiff $out $old" The biggest benefit here is that if you enter the merge and then immediately quit vim with ":qa", the diff you see in dispatch-conf remains unchanged. Also, the flow feels cleaner, since instead of taking your old config and adapting bits of the updated config into that, you adapt the bits of your old config into the new one, which helps promote smaller future merges, since you then tend towards smaller and more discrete changes wherever possible. This also makes sense logically since in "merge" you're not updating the current config, you're actually updating the "new" config which is then provided as a diff against the current config and offered for "use-new". I also think it's worth noting that the line in the wiki (http://wiki.gentoo.org/wiki/Dispatch-conf#Use_.28g.29vimdiff_to_merge_changes) really leads to a somewhat unpleasant experience (especially since when I was playing with it, it broke the automatic vimdiff folding). So I'm +1 on some variation of this simpler form being added as an example somewhere prominent, such as a comment in the conf file. :)
