git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Petr Baudis <pasky@suse.cz>
Date
May 30, 2008, 09:59 UTC
Message-ID
<20080530095938.GE18781@machine.or.cz>
In-Reply-To
<483FA6B3.4070607@gmail.com>
On Fri, May 30, 2008 at 09:03:15AM +0200, Lea Wiemann wrote:
Show 12 quoted lines
> 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.

Show 5 quoted lines
> 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
Previous: Lea WiemannNext: Lea Wiemann
Message 3 of 32 in “perl/Git.pm: add rev_parse method”
  1. perl/Git.pm: add rev_parse methodLea Wiemann, May 30, 2008
  2. Lea WiemannMay 30, 2008
  3. Petr BaudisMay 30, 2008
  4. Merging strategy for extending Git.pm (was: [PATCH] perl/Git.pm: add rev_parse method)Lea Wiemann, May 30, 2008
  5. Junio C HamanoMay 30, 2008
  6. Johannes SchindelinMay 31, 2008
  7. Lea WiemannMay 31, 2008
  8. Johannes SchindelinMay 31, 2008
  9. Junio C HamanoMay 30, 2008
  10. Petr BaudisMay 30, 2008
  11. perl/Git.pm: add parse_rev methodLea Wiemann, May 30, 2008
  12. Petr BaudisMay 30, 2008
  13. Junio C HamanoMay 30, 2008
  14. Randal L. SchwartzMay 30, 2008
  15. Lea WiemannMay 30, 2008
  16. Randal L. SchwartzMay 30, 2008
  17. Lea WiemannMay 30, 2008
  18. Junio C HamanoMay 30, 2008
  19. Johannes SchindelinMay 31, 2008
  20. Support for old Perl versionsPetr Baudis, May 31, 2008
  21. Johannes SchindelinMay 31, 2008
  22. Petr BaudisMay 30, 2008
  23. perl/Git.pm: add parse_rev methodLea Wiemann, May 31, 2008
  24. perl/Git.pm: add parse_rev methodLea Wiemann, Jun 1, 2008
  25. perl/Git.pm: add parse_rev methodLea Wiemann, Jun 1, 2008
  26. Lea WiemannJun 1, 2008
  27. Miklos VajnaJun 1, 2008
  28. Lea WiemannJun 1, 2008
  29. Junio C HamanoJun 2, 2008
  30. Lea WiemannJun 2, 2008
  31. perl/Git.pm: add get_hash methodLea Wiemann, Jun 1, 2008
  32. perl/Git.pm: add get_hash methodLea Wiemann, Jun 1, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.