Re: [PATCH 1/2] http.c: prompt for SSL client certificate password

[Junio C Hamano <gitster@pobox.com>]

Mark Lodato <lodatom@gmail.com> writes:

> On Fri, Jun 12, 2009 at 8:14 PM, Junio C Hamano<gitster@pobox.com> wrote:
>> Mark Lodato <lodatom@gmail.com> writes:
>>
>>> If this patch series is accepted, I
>>> will make a cleaner version that includes this change.
>>
>> Sorry, but I do not understand this part of your message.
>
> Sorry about that.  I meant that I have cleaned up the code as you
> suggested (see diff below), and that if you decide to include the
> patch series into git.git (I see now you included it in pu), I can
> either submit an additional patch to perform the cleanup, or submit a
> new "v2" patch series incorporating these changes.  Is one preferred
> over the other?

Ah, I see.

Here is how we do things around here.

Reviewers are usually faster to comment and offer improvement suggestions
than I pick up patches and apply them to my tree (in any branches).  While
a patch is under active discussion with suggestions that make the code
obviously better with simple changes, the submitter is expected to send
new "v$n" (n>=1) patches incorporating suggested improvements.  It often
is simpler and cleaner if such "replacement" patches are sent for anything
that hasn't landed on 'next' (or 'master/maint' for that matter), and I
make sure not to merge something that still has iffiness to 'next' (iow,
keeping it on 'pu') to help this process.

After the initial dust settles and reviewers agree that the patch is in a
good testable state, it lands in 'next', and if there are further
improvements and bugfixes, they are expected to be sent as incremental
patches.  That way, we do not have to record obvious shortcomings that
tend to appear in the initial submission in our history, while keeping the
record of incremental updates on top of what has been judged as "basically
sound" (aka "advances to 'next'").

So in this case, v2 is very much preferred.  There is no point recording
"Mark originally sent a code with #ifdef sprinkled heavily and then later
realized that the code becomes easier to read if #ifdef part is separated
out to only define the constants used in the code" as part of our official
history.

By the way, I forgot to say this even though I noticed you are new:
welcome to git development community.