On Sun, Oct 11, 2009 at 8:42 PM, Laszlo Papp <[email protected]> wrote: > On Sun, Oct 11, 2009 at 10:09 PM, Xavier <[email protected]> wrote: > >> On Sun, Oct 11, 2009 at 10:02 PM, Dan McGee <[email protected]> wrote: >> > On Wed, Sep 30, 2009 at 9:49 PM, Laszlo Papp <[email protected]> >> wrote: >> >> Pacman's long option parsing used hardcoded numbers to identify them. >> >> This is not good practice, so replace them with enumeration constants. >> >> >> >> Signed-off-by: Laszlo Papp <[email protected]> >> >> --- >> > >> > I can't apply this (or your other patches), the lines are wrapped in >> > the patch. Please use git-send-email or some other method that doesn't >> > wrap the lines. Other than that, this patch looks good. >> > >> > For the general audience, is there any reason not just to make these >> > OP_* constants? PM_LONG_OP_ seems a bit excessive for something that >> > isn't in the API or anything. >> > >> >> OP_* sounds good to me. >> >> > If you see into the ./src/pacman/conf.h file, you will see the existing > operations enumeration start with PM_OP_*. > What could I take in this case, is PM_OP_* and that enumeration okay to > extend ?
Those opts have a bit of a different meaning, so I don't think that is a wise idea. I'd just make it it's own enum. I'm much more worried about getting the patch in an appliable format than anything else; sorry I got cut off by my wonderful internet connection on IR earlier. Your patch definitely seems to have had newlines in it. I believe you claimed you used git send-email; that does not appear to be the case or these two email headers would be a dead giveaway (and they were not in your patch, this is from a patch Allan sent): Message-Id: <[email protected]> X-Mailer: git-send-email 1.6.4.4 -Dan
