bug#17189: Sort bug #2

[Eric Blake]

On 04/09/2014 02:57 AM, Nikos Balkanas wrote:

> 
> Here are both the patches, ascii-sort.diff and man-sort.diff. Sorry,
> couldn't get git to produce the correct output, according
> to the "HACKING" instructions (it listed 3 differenet files from the
> commit, but no sort.c among them) so I am sending them
> the traditional way. I am no git guru, and can't loose more time over git.

I'm sorry you feel that way, but sending patches as a .tgz file instead
of directly inline means more work for the maintainer.  We can help you
figure out the correct git instructions, and doing so will help you on
your contributions to future projects.  Following a project's preferred
submission policies shows that you have initiative and gives your
patches more clout; failing to do so makes your patches that much harder
to read and that much less likely to be applied.

As is, your patches are COMPLETELY broken.  You sent them in 'ed'
format, but we REQUIRE patches to be in unified [diff -u] format (or at
a minimum, context [diff -c] format); git defaults to unified format for
a reason.  'ed' format is useless because it lacks metadata about the
patch, and without that context, it is more likely to be misapplied or
fail to apply, particularly if the recipient starts from a different
version of the file than the sender.

$ patch < ./man-sort.diff
patch: **** Only garbage was found in the patch input.

We can't work with a patch if we can't even apply it.

Since YOU have the correct starting point, the best way is to apply your
'ed' patches with 'patch', then do 'git commit -a' to commit them to
your git repository, then 'git format-patch --stdout -1' to produce the
patch in the format that we can read.  Bonus points if you use 'git
send-email -1' instead of 'git format-patch', although getting 'git
send-email' set up to work correctly takes more work on your side.


> The ascii patch introduces the -a, --ascii option

How many times do I have to repeat myself?  Can you point to prior art
for '-a' meaning to enforce 'LC_ALL=C' collation in any other sort
implementation?  If not, then I prefer that the initial version only
supply the long option.  Furthermore, I am 90-10 against including any
new --ascii option, as LC_ALL=C is already the standardized method for
achieving the same effect.

> and modifies the man page, while the man patch moves the warning to the
> top, under the Description and adds a couple of
> examples of using sort.

Moving the blurb may indeed make sense; but I can't see where you are
proposing to move it, because your patch was broken.  Would you mind
resubmitting, please?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature