On Wed, 16 July 2008 at 22:32 (13:32:25 -0700 (PDT)), Lea Wiemann wrote:
I was wondering (but forgot to ask) why for some files you had
continuous block of documentation, and in others documentation
interspersed with documented code.
I think that providing documentation for all methods for "front-end"
class, even for those that are implemented in [abstract] base class,
is a very good idea. Better to have everything in one place, or at
least in "porcelain" documentation.
True. Or to be more exact in a Git::Revlist (or somesuch) container
class.
We would probably want _in the future_ to return some object wrapper,
which stringifies to value of author and committer headers (to author
and committer string), but allows to extract (and format) parts of it,
for example
$commit->author->name
$commit->author->email
$commit->author->date(format => RFC2822)
or perhaps
$commit->author{'email'}
I'd rather then have _git_ convert it to UTF=8 for us (using
--encoding=<encoding> option to git-log/git-rev-list), see below
on using git-log.
I'm not worried about; I think using git-log would be better (see also
below)
It don't know if it is good or bad idea, but you should have mentioned
it in the documentation.
[HERE IS MAIN PART OF THIS RESPONSE]
It is (much) better than forking git-cat-file for each commit shown
on the list; nevertheless I think that it would be better to use git-log
to generate list (or Git::Revlist) of Git::Commit objects. It is one
fork less, but what more important you don't have to access repository
twice for the very same objects.
Let me elaborate: if I understand correctly for log-like views you
propose to first run simple git-rev-list with appropriate starting
point and limiters (--skip, --max-count, -- <pathname>), perhaps using
'--parents' option to get parents in simplified/rewritten history,
which would traverse history getting commit objects, but outputting
only fragments of info, then feed list of revisions (perhaps via cache,
i.e. excluding objects which are in cache) to 'git cat-file --batch'
open two-directional pipeline.
What I propose instead is to provide alternate method to fully
instantiate Git::Commit object (in addition to ->_load), which would
fill fields by parsing git-log / git-rev-list --headers output
(what gitweb currently does in parse_commits).
On the other hand... "git cat-file --batch" should have commits to be
accessed in filesystem cache, which means in memory; but it is possible
that they wouldn't be in cache because of I/O pressure (git-rev-list and
git-cat-file are separate processes). And checking if object is in
cache can be simpler... if less effective. If you generate Git::Commit
objects via parsing git-log / git-rev-list output, then you can limit
history further by excluding starting points from cache.
[END OF MAIN PART]
I was not asking what this mean, but why do you need to set up lower
bound on Perl version. What feature pre 5.6.2 Perl lacks...
Requiring 5.8 is bad. What feature pre 5.8 Perl lacks, that you
absolutely cannot go without it? There will be complaints.
I think that _not using_ Git::Cmd (or somesuch) API results in botched,
horrible API like (in the 3/3 patch in this series):
our $git_version = $repo_root->repo(directory => 'dummy')->version;
Aaaaaargh! My eyes!
out $git_version = Git->version;
(Unless it is not needed any longer, or not used any longer; if it is
so, then perhaps implementing Git::Cmd as generic wrapper around git
commands, hiding for example ActivePerl hack, could be left for later).
Just a question: was this reply only to him, or to all?
I think that $repo->cmd_output(%opts) is a great shortcut for invoking
Git->cmd_output with '--git-dir=<repo>' added automatically. So it
should be left, but perhaps under different implementation.
Actually magic open, '-|' _does_ forks, only implicitely. So Git.pm
does generate the same or almost the same code, but it work (around)
with ActiveState Perl.
O.K.
I can understand this simpler, although less than optimal, and geared
mainly towards gitweb needs.
Errr... "yes" to first question means that 'reuse' option makes sense
_only_ for get_bidi_pipe? If so, why it is present in other commands?
See above.
Why do you _need_ name_rev, if you are not to include git-describe
equivalent.
See above, in comment about Git::Commit.
I meant here equivalent of "git tag -v <tag>"
--
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
