git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Petr Baudis <pasky@suse.cz>
To: Lea Wiemann <lewiemann@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] perl/Git.pm: add rev_parse method
Date: Fri, 30 May 2008 11:59:38 +0200	[thread overview]
Message-ID: <20080530095938.GE18781@machine.or.cz> (raw)
In-Reply-To: <483FA6B3.4070607@gmail.com>

On Fri, May 30, 2008 at 09:03:15AM +0200, Lea Wiemann wrote:
> I wrote:
>> [Commit:] The rev_parse method translates a revision name to a SHA1 hash, 
>> like
>> the git-rev-parse command.
>
> Oh, here's one problem: I'll probably do a lot of changes to Git.pm, and it 
> might be handy for me to be able to change my own methods later.   I 
> definitely wouldn't like to see Git.pm end up in some release while I'm in 
> the middle of a major refactoring.
>
> Should I perhaps stay on my branch with these changes, and then merge when 
> it has stabilized (in 1-3 months)?

I have two proposals:

(i) Tell Junio you would like the changes to stay in pu or next for now.
But he will probably do that by default anyway. :-) Thus, you do not
need to worry about them getting into a release any soon, but you will
still see some real-life testing (in theory).

(ii) When introducing new interface, introduce a user to it right away.
So, if I were you, my roadmap would be something like:

	(a) Make Git.pm use gitweb's config parser
	(b) Add 'use Git' to gitweb and convert all Git calls possible
	(c) For the rest, introduce the necessary methods to Git.pm,
	    one patch per method (I would even bundle the Git.pm
	    addition with the gitweb changes)

I'm not saying you _have_ to do it this way, but I believe it's one of
the smoothest paths. Me and I think many others of the Git project are
huge believers in "small steps" instead of "grand designs"; you will be
getting immediate feedback about your changes as you go and your work
will be useful at any point of time.

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

(I would love to provide feedback and review your patches, but please
note that at the same time I cannot promise I will be able to do it all
the time; I have failed these hopes in the past already, and again
likely will in the future.  But hopefully there's plenty of other Perl
hackers on the list.)

-- 
				Petr "Pasky" Baudis
Whatever you can do, or dream you can, begin it.
Boldness has genius, power, and magic in it.	-- J. W. von Goethe

  reply	other threads:[~2008-05-30 10:00 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-30  4:43 [PATCH] perl/Git.pm: add rev_parse method Lea Wiemann
2008-05-30  7:03 ` Lea Wiemann
2008-05-30  9:59   ` Petr Baudis [this message]
2008-05-30 15:15     ` Merging strategy for extending Git.pm (was: [PATCH] perl/Git.pm: add rev_parse method) Lea Wiemann
2008-05-30 23:20       ` Merging strategy for extending Git.pm Junio C Hamano
2008-05-31 11:38       ` Merging strategy for extending Git.pm (was: [PATCH] perl/Git.pm: add rev_parse method) Johannes Schindelin
2008-05-31 12:42         ` Merging strategy for extending Git.pm Lea Wiemann
2008-05-31 12:52           ` Johannes Schindelin
2008-05-30 20:28   ` [PATCH] perl/Git.pm: add rev_parse method Junio C Hamano
2008-05-30  9:50 ` Petr Baudis
2008-05-30 20:27   ` [PATCH] perl/Git.pm: add parse_rev method Lea Wiemann
2008-05-30 21:05     ` Petr Baudis
2008-05-30 21:25       ` Junio C Hamano
2008-05-30 21:44         ` Randal L. Schwartz
2008-05-30 21:59           ` Lea Wiemann
2008-05-30 22:03             ` Randal L. Schwartz
2008-05-30 22:05               ` Lea Wiemann
2008-05-30 22:19             ` Junio C Hamano
2008-05-31 11:50             ` Johannes Schindelin
2008-05-31 12:17               ` Support for old Perl versions Petr Baudis
2008-05-31 12:32                 ` Johannes Schindelin
2008-05-30 21:49         ` [PATCH] perl/Git.pm: add parse_rev method Petr Baudis
2008-05-31 13:52 ` [PATCH v2] " Lea Wiemann
2008-06-01  3:17   ` [PATCH v3] " Lea Wiemann
2008-06-01  3:17     ` Lea Wiemann
2008-06-01 17:38       ` Lea Wiemann
2008-06-01 21:54         ` Miklos Vajna
2008-06-01 22:51           ` Lea Wiemann
2008-06-02  4:59             ` Junio C Hamano
2008-06-02 13:51               ` Lea Wiemann
2008-06-01 23:09       ` [PATCH v4] perl/Git.pm: add get_hash method Lea Wiemann
2008-06-01 23:24         ` Lea Wiemann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080530095938.GE18781@machine.or.cz \
    --to=pasky@suse.cz \
    --cc=git@vger.kernel.org \
    --cc=lewiemann@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).