Re: [PATCH] perl/Git.pm: add rev_parse method

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

Lea Wiemann <lewiemann@gmail.com> writes:

> Should I perhaps stay on my branch with these changes, and then merge
> when it has stabilized (in 1-3 months)?
>
> One thing I'd be concerned about is that I might introduce fundamental
> issues in my API, since I'm neither a Git nor a Perl expert (yet
> ^^). What's the best way to avoid discovering such issues only at the
> Big Merge?

First of all, we do not do "Big Merge".  We merge small and we merge
often.  Nobody has perfect foresight, so you shouldn't be too afraid of
contaminating the public history with experiments that did not pan out
well.

> Is there anyone who'd be willing to monitor my commits and
> give me feedback on a semi-continuous basis?

Isn't it what your GSoC mentor is for ;-)?

You can seek wider exposure in various different ways:

 * Send [RFC] patches to the list; that's how this community is supposed
   to work, although I do not see as much reviews as I would personally
   want to see from other people these days for some reason [*1*].

   I may pick up "next" worthy ones to "next", and perhaps other ones to
   "pu" as time permits.

 * Have your repository on repo.or.cz (I thought GSoC student project for
   git were supposed to be hosted there?)  People interested in Perl
   interface in general and Gitweb in particular can try your progress
   out.


[Footnote]

*1* I suspect that maybe there is a misconception that patch submission
and review on the list is a dialogue between the submitter and the
maintainer.  It is _NOT_ the case.  I'd rather stay back, sipping my
Caipirinha, listening to _other_ people argue and improve the submitted
patches, while occasionally giving some guidance to the course of the
discussion.  And when the polished result emerges finally, apply it to my
tree, taking all the credit.  _That_ is how the community is supposed to
work, isn't it? ;-)