[arch-general] CLI diffing tool other than Vim?
Hi guys, I run a couple of Arch servers, and I'm trying to teach someone how to go about maintaining it (for when I'm not around). The difficulty is that when it comes to package updates that require merging .pacnew files, I always use Vim to merge changes. That's quite a steep learning curve to impose on someone who's not all that familiar with a UNIX environment yet. Does anyone know of any good & simple(ish) alternative for merging files over SSH? Paul
On Tuesday 30 Jul 2013 09:43:02 Paul Gideon Dann wrote:
Does anyone know of any good & simple(ish) alternative for merging files over SSH?
nano, or mc with it's in-built editor. -- phani.
On Tuesday 30 Jul 2013 10:31:03 Paul Gideon Dann wrote:
nano, or mc with it's in-built editor.
They don't have a diffing/merging mode, do they?
no; i thought for somebody not used to managing arch, it would be better to do things manually, or not at all. often you can leave .pacnew files alone w/o anything bad happening. otherwise, before merging, it's better to read thru' the files and understand what's happening, was my idea. -- phani.
* phanisvara <listmail@phanisvara.com> [30.07.2013 11:41]:
On Tuesday 30 Jul 2013 10:31:03 Paul Gideon Dann wrote:
nano, or mc with it's in-built editor.
They don't have a diffing/merging mode, do they?
no; i thought for somebody not used to managing arch, it would be better to do things manually, or not at all.
often you can leave .pacnew files alone w/o anything bad happening. otherwise, before merging, it's better to read thru' the files and understand what's happening, was my idea.
Before you do nothing, it's better if you use e.g. pacnew_scripts (is in the AUR).
On Tuesday 30 Jul 2013 13:33:58 sekret@posteo.se wrote:
Before you do nothing, it's better if you use e.g. pacnew_scripts (is in the AUR).
interesting; didn't know about this AUR package/script and will look at it. nevertheless, doing nothing is safer than doing nonsense. i don't know about the level of knowledge or ignorance of this ad-hoc sysadmin, but if he can't deal with vim, i'm afraid it's not too good. -- phani.
On Tue, Jul 30, 2013 at 5:40 AM, phanisvara <listmail@phanisvara.com> wrote:
On Tuesday 30 Jul 2013 10:31:03 Paul Gideon Dann wrote:
nano, or mc with it's in-built editor.
They don't have a diffing/merging mode, do they?
no; i thought for somebody not used to managing arch, it would be better to do things manually, or not at all.
often you can leave .pacnew files alone w/o anything bad happening. otherwise, before merging, it's better to read thru' the files and understand what's happening, was my idea.
-- phani.
You'll still be manually merging the files with a merging tool, it will just give you context and an up-to-date delta as you go.
On 2013-07-30 09:43, Paul Gideon Dann wrote:
I run a couple of Arch servers, and I'm trying to teach someone how to go about maintaining it (for when I'm not around). The difficulty is that when it comes to package updates that require merging .pacnew files, I always use Vim to merge changes. That's quite a steep learning curve to impose on someone who's not all that familiar with a UNIX environment yet. Does anyone know of any good & simple(ish) alternative for merging files over SSH?
Well, what merge programs are they familiar with? If it is vimdiff that poses the problem for this user, you might consider running meld instead.
On Tuesday 30 Jul 2013 10:58:21 Chris Down wrote:
I run a couple of Arch servers, and I'm trying to teach someone how to go about maintaining it (for when I'm not around). The difficulty is that when it comes to package updates that require merging .pacnew files, I always use Vim to merge changes. That's quite a steep learning curve to impose on someone who's not all that familiar with a UNIX environment yet. Does anyone know of any good & simple(ish) alternative for merging files over SSH? Well, what merge programs are they familiar with? If it is vimdiff that
On 2013-07-30 09:43, Paul Gideon Dann wrote: poses the problem for this user, you might consider running meld instead.
Thanks Chris, but this is a headless server; Xorg is not installed, so meld is out. Paul
Thanks Chris, but this is a headless server; Xorg is not installed, so meld is out.
Hi Paul, what about using colordiff and tweaking its display settings to your liking? Greetings Oliver
[2013-07-30 10:32:40 +0100] Paul Gideon Dann:
On Tuesday 30 Jul 2013 10:58:21 Chris Down wrote:
I run a couple of Arch servers, and I'm trying to teach someone how to go about maintaining it (for when I'm not around). The difficulty is that when it comes to package updates that require merging .pacnew files, I always use Vim to merge changes. That's quite a steep learning curve to impose on someone who's not all that familiar with a UNIX environment yet. Does anyone know of any good & simple(ish) alternative for merging files over SSH? Well, what merge programs are they familiar with? If it is vimdiff that
On 2013-07-30 09:43, Paul Gideon Dann wrote: poses the problem for this user, you might consider running meld instead.
Thanks Chris, but this is a headless server; Xorg is not installed, so meld is out.
You could mount the server's filesystem locally using sshfs and run meld on that. But in my opinion learning to use a powerful text editor is really a must for system administrators... -- Gaetan
IMnsHO, teach this person to use the tools already available: both nano, diffutils and less are part of base. Teach person to use "diff -u" combined with less and to excersise some judgement about the difference between the working copies and the new files. Most of the time it is a matter of jotting down a couple of lines in a piece of paper (anathema!!!!) and edit the already working file to add a couple of lines or change a couple of settings to new defaults. Make sure to emphasize the use of "nano -w" and you won't have broken lines in the config files. On Tue, Jul 30, 2013 at 3:43 AM, Paul Gideon Dann <pdgiddie@gmail.com>wrote:
Hi guys,
I run a couple of Arch servers, and I'm trying to teach someone how to go about maintaining it (for when I'm not around). The difficulty is that when it comes to package updates that require merging .pacnew files, I always use Vim to merge changes. That's quite a steep learning curve to impose on someone who's not all that familiar with a UNIX environment yet. Does anyone know of any good & simple(ish) alternative for merging files over SSH?
Paul
On 30 July 2013 16:33, Pedro Alejandro López-Valencia <palopezv@gmail.com> wrote:
IMnsHO, teach this person to use the tools already available: both nano, diffutils and less are part of base. Teach person to use "diff -u" combined with less and to excersise some judgement about the difference between the working copies and the new files. Most of the time it is a matter of jotting down a couple of lines in a piece of paper (anathema!!!!) and edit the already working file to add a couple of lines or change a couple of settings to new defaults. Make sure to emphasize the use of "nano -w" and you won't have broken lines in the config files.
The only diff tool comparable to vimdiff that comes into my mind is emacs diff mode.
On Tue, 2013-07-30 at 20:05 +0200, Lukas Jirkovsky wrote:
On 30 July 2013 16:33, Pedro Alejandro López-Valencia <palopezv@gmail.com> wrote:
IMnsHO, teach this person to use the tools already available: both nano, diffutils and less are part of base. Teach person to use "diff -u" ...
The only diff tool comparable to vimdiff that comes into my mind is emacs diff mode.
You are correct, but both vimdiff and emacs diff mode are sophisticated crutches. You should learn the basic tools to be able to understand the sophisticated ones later and make good use of them. Of course there are situations where an automated merge tool is a godsend; FreeBSD mergemaster comes to my mind: Who wants to merge a hundred+ configuration files by hand when most have changed their SCM id strings if much? And then it stops and let's you resolve by hand each real difference between files. I've never used them but I'd guess pacnew_scripts operate that way.
On Tue, Jul 30, 2013 at 3:54 PM, P. A. <palopezv@gmail.com> wrote:
On Tue, 2013-07-30 at 20:05 +0200, Lukas Jirkovsky wrote:
On 30 July 2013 16:33, Pedro Alejandro López-Valencia <palopezv@gmail.com> wrote:
IMnsHO, teach this person to use the tools already available: both nano, diffutils and less are part of base. Teach person to use "diff -u" ...
The only diff tool comparable to vimdiff that comes into my mind is emacs diff mode.
You are correct, but both vimdiff and emacs diff mode are sophisticated crutches.
They're not "crutches", they offer an elegant presentation of the differences between the files, and you can merge the changes one-by-one without losing context. It only takes a few minutes to learn, and you'll be happy you did.
You should learn the basic tools to be able to understand the sophisticated ones later and make good use of them.
That's absolutely untrue, there's no secret knowledge you'll gain from torturing yourself with an awful tool. It's only useful for generating patches, not merging files.
On Tue, Jul 30, 2013 at 3:09 PM, Daniel Micay <danielmicay@gmail.com> wrote:
On Tue, Jul 30, 2013 at 3:54 PM, P. A. <palopezv@gmail.com> wrote:
On Tue, 2013-07-30 at 20:05 +0200, Lukas Jirkovsky wrote:
On 30 July 2013 16:33, Pedro Alejandro López-Valencia <palopezv@gmail.com> wrote:
IMnsHO, teach this person to use the tools already available: both nano, diffutils and less are part of base. Teach person to use "diff -u" ...
The only diff tool comparable to vimdiff that comes into my mind is emacs diff mode.
You are correct, but both vimdiff and emacs diff mode are sophisticated crutches.
They're not "crutches", they offer an elegant presentation of the differences between the files, and you can merge the changes one-by-one without losing context. It only takes a few minutes to learn, and you'll be happy you did.
Matter of opinion. I value learning from first principles. From that point of view: merging graphical tools are crutches if you don't have the foggiest idea of what is actually going on underneath. If you arrived at a later stage of the computer OS evolution game, graphical tools are what you know and that's the hammer you use to hit all nails. My hammer is vi, btw. Not vim; plain, old fashioned vi.
You should learn the basic tools to be able to understand the sophisticated ones later and make good use of them.
That's absolutely untrue, there's no secret knowledge you'll gain from torturing yourself with an awful tool. It's only useful for generating patches, not merging files.
See my answer above. Using CLI UNIX tools is alien to a person who is used to graphical tools. That doesn't mean they are actually awful, only alien. -- http://about.me/palopezv
On Tue, Jul 30, 2013 at 5:05 PM, Pedro Alejandro López-Valencia
Matter of opinion. I value learning from first principles. From that point of view: merging graphical tools are crutches if you don't have the foggiest idea of what is actually going on underneath. If you arrived at a later stage of the computer OS evolution game, graphical tools are what you know and that's the hammer you use to hit all nails. My hammer is vi, btw. Not vim; plain, old fashioned vi.
There's absolutely no part of the merging process `vimdiff` is hiding from you. You're enamoured with doing tedious, repetitive work but most of us would rather invest a few minutes in learning a more powerful tool or writing a bit of code than wasting our time.
On Tue, Jul 30, 2013 at 4:50 PM, Daniel Micay <danielmicay@gmail.com> wrote:
There's absolutely no part of the merging process `vimdiff` is hiding from you. You're enamoured with doing tedious, repetitive work but most of us would rather invest a few minutes in learning a more powerful tool or writing a bit of code than wasting our time.
And you are enamoured with trying desperately to prove random, unknown people in the internet that you are right, because you have being given the divine right to be always correct as dispensed to you by God. Child, I stopped doing that several decades ago. You win by default. -- http://about.me/palopezv
On Tue, Jul 30, 2013 at 5:57 PM, Pedro Alejandro López-Valencia <palopezv@gmail.com> wrote:
On Tue, Jul 30, 2013 at 4:50 PM, Daniel Micay <danielmicay@gmail.com> wrote:
There's absolutely no part of the merging process `vimdiff` is hiding from you. You're enamoured with doing tedious, repetitive work but most of us would rather invest a few minutes in learning a more powerful tool or writing a bit of code than wasting our time.
And you are enamoured with trying desperately to prove random, unknown people in the internet that you are right, because you have being given the divine right to be always correct as dispensed to you by God.
Child, I stopped doing that several decades ago. You win by default.
It's a mailing list, we don't care how many years of experience you claim to have. I only care that you're telling people to waste their time by suggesting they do merges with pen and paper instead of tools in the repositories supporting the workflow of a merge.
On Tue, 30 Jul 2013 18:11:05 -0400 Daniel Micay <danielmicay@gmail.com> wrote:
On Tue, Jul 30, 2013 at 5:57 PM, Pedro Alejandro López-Valencia <palopezv@gmail.com> wrote:
On Tue, Jul 30, 2013 at 4:50 PM, Daniel Micay <danielmicay@gmail.com> wrote:
There's absolutely no part of the merging process `vimdiff` is hiding from you. You're enamoured with doing tedious, repetitive work but most of us would rather invest a few minutes in learning a more powerful tool or writing a bit of code than wasting our time.
And you are enamoured with trying desperately to prove random, unknown people in the internet that you are right, because you have being given the divine right to be always correct as dispensed to you by God.
Child, I stopped doing that several decades ago. You win by default.
It's a mailing list, we don't care how many years of experience you claim to have. I only care that you're telling people to waste their time by suggesting they do merges with pen and paper instead of tools in the repositories supporting the workflow of a merge.
Please guys... you only add more work for the moderators. FWIW, in my experience for simple configuration files, merging .pacnew's is easiest with a usual "diff -u a.conf a.conf.pacnew | vim -". It gives you a nice colored diff similar to what you get from git or mercurial. On the other hand, for large updates, e.g. samba 3.x -> samba 4.x, it is much faster to just recreate your config. Cheers, L. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Tue, Jul 30, 2013 at 6:41 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
On Tue, 30 Jul 2013 18:11:05 -0400 Daniel Micay <danielmicay@gmail.com> wrote:
On Tue, Jul 30, 2013 at 5:57 PM, Pedro Alejandro López-Valencia <palopezv@gmail.com> wrote:
On Tue, Jul 30, 2013 at 4:50 PM, Daniel Micay <danielmicay@gmail.com> wrote:
There's absolutely no part of the merging process `vimdiff` is hiding from you. You're enamoured with doing tedious, repetitive work but most of us would rather invest a few minutes in learning a more powerful tool or writing a bit of code than wasting our time.
And you are enamoured with trying desperately to prove random, unknown people in the internet that you are right, because you have being given the divine right to be always correct as dispensed to you by God.
Child, I stopped doing that several decades ago. You win by default.
It's a mailing list, we don't care how many years of experience you claim to have. I only care that you're telling people to waste their time by suggesting they do merges with pen and paper instead of tools in the repositories supporting the workflow of a merge.
Please guys... you only add more work for the moderators.
FWIW, in my experience for simple configuration files, merging .pacnew's is easiest with a usual "diff -u a.conf a.conf.pacnew | vim -". It gives you a nice colored diff similar to what you get from git or mercurial. On the other hand, for large updates, e.g. samba 3.x -> samba 4.x, it is much faster to just recreate your config.
Cheers, L.
-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
You can use `git diff` on files not part of a git repository with `--no-index`. If you're already going to be using `vim`, you might as well be using `vimdiff` for a nicer representation of the deltas along with it updating as you merge. There are even keybindings to merge hunks automatically.
On Tue, 2013-07-30 at 18:41 -0400, Leonid Isaev wrote:
Please guys... you only add more work for the moderators.
Agreed.
[2013-07-30 18:41:00 -0400] Leonid Isaev:
Please guys... you only add more work for the moderators.
Thanks for caring. They were whitelisted, but not anymore. It's the prisoner's dilemma: when a discussion goes nowhere, the clever choice is to stop replying. Replying anyhow might get you the last word (which may seem important to people not used to discussing by email) but if more than one person replies then it's the worst for everyone... -- Gaetan
On Tue, 2013-07-30 at 18:11 -0400, Daniel Micay wrote:
It's a mailing list, we don't care how many years of experience you claim to have.
Exactly. I don't care about you either. But read below.
I only care that you're telling people to waste their time by suggesting they do merges with pen and paper instead of tools in the repositories supporting the workflow of a merge.
There is no single solution to all problems. If you only have to merge two lines, using something like meld or vimdiff is a waste. If you are merging a multi-file patch, you'd be mad to try to do it by hand if you can do it with an automation tool. Each problem has a proper solution and it is not necessarily yours. What is incredibly sad is your boorish, borderline behavior. If you know what is better for the health of this mailing list, you will stop now. And as I said before, you win by default. What else do you need?
On Tue, Jul 30, 2013 at 3:54 PM, P. A. <palopezv@gmail.com> wrote:
On Tue, 2013-07-30 at 20:05 +0200, Lukas Jirkovsky wrote:
On 30 July 2013 16:33, Pedro Alejandro López-Valencia <palopezv@gmail.com> wrote:
IMnsHO, teach this person to use the tools already available: both nano, diffutils and less are part of base. Teach person to use "diff -u" ...
The only diff tool comparable to vimdiff that comes into my mind is emacs diff mode. You are correct, but both vimdiff and emacs diff mode are sophisticated crutches. They're not "crutches", they offer an elegant presentation of the differences between the files, and you can merge the changes one-by-one without losing context. It only takes a few minutes to learn, and you'll be happy you did.
You should learn the basic tools to be able to understand the sophisticated ones later and make good use of them. That's absolutely untrue, there's no secret knowledge you'll gain from torturing yourself with an awful tool. It's only useful for generating patches, not merging files. I agree when I was starting out as a Jr. sys admin, I had only been use to using nano. My new boss kept giving me so much crap for using it and not vim that I finally broke down using it. I uninstalled nano and forced myself, within a day I was flying through the basics on vim. I
On 07/30/2013 01:09 PM, Daniel Micay wrote: think if the person can not play with it for a day or less and get the basics behind it especially vimdiff might not be the best person to trust when you are gone, but that is my personal opinion. Once I got use to vim I kept telling myself, why did I not start with it sooner.
participants (13)
-
Chris Down
-
Daniel Micay
-
Don deJuan
-
Gaetan Bisson
-
Leonid Isaev
-
Lukas Jirkovsky
-
Oliver Kraitschy
-
P. A. López-Valencia
-
Paul Gideon Dann
-
Pedro A. López-Valencia
-
Pedro Alejandro López-Valencia
-
phanisvara
-
sekret＠posteo.se