Dear diary, on Fri, Apr 22, 2005 at 12:41:56PM CEST, I got a letter
where Christian Meder <[EMAIL PROTECTED]> told me that...
> Ok. The URI should start by stating the project name
> e.g. /linux-2.6. This does bloat the URI slightly but I don't think
> that we want to have one root namespace per git archive in the long
> run. Additionally you can always put rewriting or redirecting rules at
> the root level for additional convenience when there's an obvious
> default project.
> Should provide some meta data, stats, etc. if available.
I don't think this makes much sense. I think you should just apply -p1
to all the directories, and define that there should be some / page
which should contain some metadata regarding the repository you are
accessing (probably branches, tags, and such).
> These are the easy ones: the web interface should be able to spit out
> the plain text data of a blob and a commit at these URIs. Users would
> be probably scripts and other downloads.
> Open questions:
> * Blob data should be probably binary ?
What do you mean by binary?
> * Should it be commit or changeset ? Linus seems to have changed
> nomenclature in the REAME
We call it commit everywhere but in the README. :-)
The "changeset" name is bad anyway. It is a commit of a complete tree
state, diff against one of its parent commits is the set of changes.
> Tree objects are served in binary form. Primary audience are scripts,
> etc. Human beings will probably get a heart attack when they
> accidentally visit this URI.
Binary form is unusable for scripts.
Anything wrong with putting ls-tree output there?
We should also have /gitobj/<sha1> for fetching the raw git objects.
> A HTML version of blob, commit and tree fully linked aimed at human
How can I imagine an "HTML version of blob"?
> Non recursive HTML view of the objects which are contained in the diff
> fully linked with the individual HTML views.
Why not .html?
I'd personally prefer /log/, but whatever.
For consistency, I'd stay with the plaintext output by default, .html if
And I think abusing directories for this is bad. Query string seems much
more appropriate, since this is something that changes dynamically a
lot, not a permanent resource identifier.
OTOH, I'd use
to specify what commit to start at. It just does not make sense
otherwise, you would not know where to start.
I think the <commit> should follow the same or similar rules as Cogito
id decoding. E.g. to get latest Linus' changelog, you'd do
> HTML changelog for the given <time-spec> filtered by the <regexp>.
> * again plain version needed ?
> convenience wrappers for generic search restricted to these fields.
Same here. just ?author=...&committer=...&signedoffby=... etc. You can
even combine several criteria.
> open questions:
> * how to generate and publish additional merge information ?
I don't understand....
> * how to generate and publish tree and blob history information ? This
> is probably expensive with git.
> * how to represent branches ? should we code up the branches in the
> project id like linux-2.6-mm or whatever ?
Petr "Pasky" Baudis
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html