Re: Install issues
Show 22 quoted lines
> On Mon, 10 Nov 2008 18:51:23 +0100, Miklos Vajna
> <vmiklos@frugalware.org> wrote:
>
>> On Mon, Nov 10, 2008 at 05:31:01PM +0100, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
>>> --- Makefile.org 2008-11-10 17:29:53.000000000 +0100
>>> +++ Makefile 2008-11-10 17:29:39.000000000 +0100
>>> @@ -1329,6 +1329,10 @@ check-sha1:: test-sha1$X
>>> ./test-sha1.sh
>>>
>>> check: common-cmds.h
>>> + @`sparse </dev/null 2>/dev/null` || (\
>>> + echo "The 'sparse' command is not available, so I cannot make the 'check' target" ;\
>>> + echo "Did you mean 'make test' instead?" ;\
>>> + exit 1 )
>>> for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
>> Please read Documentation/SubmittingPatches, your patch lacks a signoff
>> and a commit message.
>
> You're not making things easier for people that do not use git from a
> git repo, something that happens quite a lot when you build from a
> released tarball.
>
I think it's assumed that most git developers will clone the git repo so they can send their patches against the very latest code. Usually, that's part of "how to submit patches" of all projects.
Show 8 quoted lines
> git-1.6.0.4 $ git format-patch -M
> fatal: Not a git repository
> Exit 128
>
> I don't like this at all. How much more work is it for you to add the
> subject and sign-off yourself, instead of requiring that from people
> that like to help?
>
"Ask not what a bunch of oss devs can do for you, but what you can do for them. Especially if you want your changes accepted".
The harsh reality is that this is your itch. Noone else cares very much either way, so if you want your change included, you'll have to do it the way the project maintainer wants it.
> In the perl development, the only thing we *require* is a diff that
> either uses unified (preferred) or context diff.
>
Nothing's required here, but since nobody else seems to have problems with the check/test stuff here, noone else will fix it up for you.
Besides that, I'm sure you require a teensy bit more than that. If I send you a 14k line patch without a reasoning behind it, you won't just go ahead and apply it, will you? If I send an algorithm for a new hash that might actually be proprietary code from an anonymous email address, wouldn't you want some sort of verification that I'm actually allowed to send that algorithm to you?
In git, those two steps are formalized into "Sign your patches!" and
"Write a proper commit message!". Since they *are* formalized, we
provide handy tools for doing just that. It's up to you if you want to
use them. Dictating the patch submission (or rather, acceptancy policy)
is not. Patches submitted incorrectly will have one of the following
things happen to them:
1. The patch is forgotten entirely, since nobody cares about it enough
to make it a "proper" patch (by git standards).
2. The patch author resubmits it in the proper format.
3. Someone else resubmits it in the proper format.
4. Junio accepts it anyway.
4 is the least likely to happen, and will pretty much only occur if someone finds some really horrible bug that absolutely and obviously has to go in the git code. Even in those cases, 3 usually happens before Junio wakes up.
3 is not very likely to happen unless the feature you're suggesting is of interest to a lot of people.
Ofcourse, *after* the patch has been submitted in the proper format, it can still get rejected. Submitting it properly is only the first step towards getting any kind of review on it (basically).
Show 17 quoted lines
> I did follow the ideal patch flow so far:
> --8<---
> An ideal patch flow
>
> Here is an ideal patch flow for this project the current maintainer
> suggests to the contributors:
>
> (0) You come up with an itch. You code it up.
>
> (1) Send it to the list and cc people who may need to know about
> the change.
> -->8---
>
> Code speaks louder than words, so I proposed a patch.
> This might be my last patch. git is not just another project I want to
> loose so much time in.
>
That would be sad. We're a tad short on perl folks, although I guess that's not much of an issue since we're rewriting most of it in C anyways.
If you should decide to relent though, I seriously suggest using the tools git provides for sending patches. If you do, you'll be able to able to send (properly formatted) patches very easily indeed.
Rant aside, thanks for the re-send. I'm sure Junio can sed s/Author/From/ on the mail and have git accept it properly in case he accepts it. Otherwise, I'll resubmit it, faking you as the author.
Show 27 quoted lines
> --8<---
> Author: H.Merijn Brand <h.m.brand@xs4all.nl>
> Date: Mon, 10 Nov 2008 17:31:01 +0100
>
> Make check needs sparse. If sparse is not available, it might as
> well be a user error who really wanted make test.
>
> Signed-off-by: H.Merijn Brand <h.m.brand@xs4all.nl>
> ---
>
> diff --git a/Makefile.org b/Makefile
> index becd008..718ddf2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1329,6 +1329,10 @@ check-sha1:: test-sha1$X
> ./test-sha1.sh
>
> check: common-cmds.h
> + @`sparse </dev/null 2>/dev/null` || (\
> + echo "The 'sparse' command is not available, so I cannot make the 'check' target" ;\
> + echo "Did you mean 'make test' instead?" ;\
> + exit 1 )
> for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
>
> remove-dashes:
> -->8---
>
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
H.Merijn Brand
