Could you revert the regeneration of the patches that do nothing but change the dates/names? It makes it kind of more bloated than needed.

In D10148#209715, @rezny wrote:

Update again with hopefully just the right files this time. Arcanist's failure to show the files it will act on until after it's done is VERY annoying...

Well, you can use svn status it will tell you what files will arcanist run svn diff on.

Also, please, while regerating the patches to see if changes is needed is good, never commit changes that only affect the first two lines of a patch (the --- and +++ lines)

In D10148#209706, @tcberner wrote:

Could you revert the regeneration of the patches that do nothing but change the dates/names? It makes it kind of more bloated than needed.

I'd appreciate firm guidelines on when is and isn't the right time to use makepatch. I had been told many times to just use makepatch, so I did anytime patches were changed/added, but now a few people say not to not touch the existing patches. So are patches that don't conform to be left until they must be touched, perhaps when they no longer apply? Should the patches with non-preferred names be left as-is entirely, renamed but content left as-is, or should those also remain untouched? I assume the reason to run makepatch is to keep things like the line numbers up to date so that it is easier to fix a patch when it does fail to apply. Perhaps makepatch should get a little smarter to not change the patch if it's only the dates that change? Or, even better idea, how about not putting any dates in the patch file? What purpose does the date in the patch file serve other than to bloat both the patch and all diffs thereof?

In D10148#209739, @rezny wrote:

In D10148#209706, @tcberner wrote:

Could you revert the regeneration of the patches that do nothing but change the dates/names? It makes it kind of more bloated than needed.

I'd appreciate firm guidelines on when is and isn't the right time to use makepatch. I had been told many times to just use makepatch, so I did anytime patches were changed/added, but now a few people say not to not touch the existing patches. So are patches that don't conform to be left until they must be touched, perhaps when they no longer apply? Should the patches with non-preferred names be left as-is entirely, renamed but content left as-is, or should those also remain untouched? I assume the reason to run makepatch is to keep things like the line numbers up to date so that it is easier to fix a patch when it does fail to apply. Perhaps makepatch should get a little smarter to not change the patch if it's only the dates that change? Or, even better idea, how about not putting any dates in the patch file? What purpose does the date in the patch file serve other than to bloat both the patch and all diffs thereof?

A patch is composed of a header, and of hunks, each hunk has a header, and data. In this:

--- kinfocenter/Modules/base/info_fbsd.cpp.orig        2015-08-12 07:03:15 UTC
+++ kinfocenter/Modules/base/info_fbsd.cpp
@@ -15,8 +15,6 @@
  */
 
 #include "config-infocenter.h" // HAVE_DEVINFO_H
-#include <sys/types.h>
-#include <sys/sysctl.h>
 
 #ifdef HAVE_DEVINFO_H
 extern "C" {
@@ -60,9 +60,13 @@ bool GetInfo_IRQ(QTreeWidget* tree) {
 
 bool GetInfo_DMA(QTreeWidget* tree) {
 #ifdef HAVE_DEVINFO_H
-        /* Oh neat, current now has a neat little utility called devinfo */
         if (devinfo_init())
-        return false;
+                return false;
+
+        QStringList headers;
+        headers << i18n("DMA-Channel") << i18n("Used By");
+        tree->setHeaderLabels(headers);
+
         devinfo_foreach_rman(print_dma, tree);
         return true;

The header is:

--- kinfocenter/Modules/base/info_fbsd.cpp.orig        2015-08-12 07:03:15 UTC
+++ kinfocenter/Modules/base/info_fbsd.cpp

It is metadata, if it is the only thing that changes, it is unimportant, so, never include it.

This is a hunk:

@@ -60,9 +60,13 @@ bool GetInfo_IRQ(QTreeWidget* tree) {
 
 bool GetInfo_DMA(QTreeWidget* tree) {
 #ifdef HAVE_DEVINFO_H
-        /* Oh neat, current now has a neat little utility called devinfo */
         if (devinfo_init())
-        return false;
+                return false;
+
+        QStringList headers;
+        headers << i18n("DMA-Channel") << i18n("Used By");
+        tree->setHeaderLabels(headers);
+
         devinfo_foreach_rman(print_dma, tree);
         return true;

It starts with a @@ -xx1,yy1 +xx2,yy2 @@ <function name> line, which is its header, it says where in the file it is supposed to be applied (patch will, of course, look around in case things move).

If you want some details about what the numbers are:

• xx1 : the line number the hunk starts to apply to
• yy1 : the number of lines the hunk applies to
• xx2 : the line number the hunk starts after it is applied
• yy2 : the number of lines the hunk generates

If the numbers in the hunk header change, they are important, because it tells patch where to look for the lines to patch in the file, so even if they are the only thing that change, the patch must be committed. The <function name> is generated by diff using the C function name the patch is in, it is only helpful for us humans, when reading the patch, to figure out in an easier way where the patch is being applied. It is metadata, and if it is the only thing that changes, it should be discarded.

The you have the actual content of the hunk, every change in it is important.

• lines starting with a single space are context, and they help patch figure out where to patch when the file is updated and things have moved around.
• lines starting with a minus sign are lines that are supposed to go away.
• lines starting with a plus sign are lines that are going in.

In D10148#209718, @mat wrote:

In D10148#209715, @rezny wrote:

Update again with hopefully just the right files this time. Arcanist's failure to show the files it will act on until after it's done is VERY annoying...

Well, you can use svn status it will tell you what files will arcanist run svn diff on.

Actually, that is not true, unless there has been a change of behavior from the first time I used (and was thoroughly surprised by) arcanist. When not in the root of the repo, svn status shows what has changed in the current directory and sub-directories while ignoring parent and sibling directories, whereas arc diff grabs any change in the repo regardless of current directory. So, I must always give some list of paths/files to arcanist, different from svn. That is only a slight annoyance, though I'd be very pleased to hear there is some way to change that behavior (I admit to not having looked closely at the available options).

The real problem is that it does not show the list of files below the message template as svn does when composing a commit message, so if I have made a mistake and over-selected (say, a stray space between a path and an asterisk), I do not know until it is too late. That's just poor UI, and while running svn status with the same list is a work-around, it is just silly to have to rely on that extra step. Speaking of poor UI, I really need to figure out how to make the diff view and input area text on phabricator pages lager than 6pt. The summary, comments, and file names between diff sections are a comfortable size, but the most important part, the actual diff content and anything I type, is half the size and weight. At least I see some icons instead of the invalid unicode characters today. Maybe I'll try to improve arcanist when I get through the rest of the to-dos, but no promises (it's PHP).

In D10148#209742, @rezny wrote:

In D10148#209718, @mat wrote:

In D10148#209715, @rezny wrote:

Update again with hopefully just the right files this time. Arcanist's failure to show the files it will act on until after it's done is VERY annoying...

Well, you can use svn status it will tell you what files will arcanist run svn diff on.

Actually, that is not true, unless there has been a change of behavior from the first time I used (and was thoroughly surprised by) arcanist. When not in the root of the repo, svn status shows what has changed in the current directory and sub-directories while ignoring parent and sibling directories, whereas arc diff grabs any change in the repo regardless of current directory. So, I must always give some list of paths/files to arcanist, different from svn. That is only a slight annoyance, though I'd be very pleased to hear there is some way to change that behavior (I admit to not having looked closely at the available options).

Let me rephrase what I said, you can see what arcanist will use by doing cd <rootdir of checkout>; svn status

The real problem is that it does not show the list of files below the message template as svn does when composing a commit message, so if I have made a mistake and over-selected (say, a stray space between a path and an asterisk), I do not know until it is too late. That's just poor UI, and while running svn status with the same list is a work-around, it is just silly to have to rely on that extra step. Speaking of poor UI, I really need to figure out how to make the diff view and input area text on phabricator pages lager than 6pt. The summary, comments, and file names between diff sections are a comfortable size, but the most important part, the actual diff content and anything I type, is half the size and weight. At least I see some icons instead of the invalid unicode characters today. Maybe I'll try to improve arcanist when I get through the rest of the to-dos, but no promises (it's PHP).

I'm going to say that I don't use svn at all unless I am committing a patch that moves files, and then, only to do the actual commit to the ports tree.
I exclusively use git for all my ports work, and it does not have that problem wrt arcanist, because you put each thing you work on a separate branch, and you actually commit the files before running arc diff.

Mat, thanks for the thorough explanation! The details of the line numbers is a known, I regularly adjust those by hand. What I needed is basically this: commit data changes (hunk contents and offsets), discard metadata changes (dates, offset trailers, etc).

I'm going to say that I don't use svn at all unless I am committing a patch that moves files, and then, only to do the actual commit to the ports tree.
I exclusively use git for all my ports work, and it does not have that problem wrt arcanist, because you put each thing you work on a separate branch, and you actually commit the files before running arc diff.

Sparse svn clones with only the affected ports works also just great :) -- and it's also extremely fast, as a bonus.

Thanks for the patch-reverts, now this looks much nicer.

Apologies for the breakage in the first place, I should have asked for an exp-run before landing the kdelibs4 update. The .pyo changes in the pkg-plists should be reverted: I'm testing a new build here reintroducing patch to kdelibs4 that makes sure those files are built and installed.

I'm testing a new build here reintroducing patch to kdelibs4 that makes sure those files are built and installed.

Landed in rP437020.