On Mon, 30 Jul 2007, Matthew L Foster wrote:
--- Rogan Dawes <lists@xxxxxxxxxxxx> wrote:
And also keep in mind that on the command line you can invoke a lot of
"plumbing commands" that you certainly wouldn't expect to be exposed in
a web interface.
If the web interface requires logins over https why can't plumbing commands be exposed to the web?
Though I agree not everything needs to be webified. What I envision is a wikipedia style interface
front end with git remaining the backend so you can more easily browse the file system and see
history and diff the way you can on Wikipedia. But that idea is very separate from my concern that
right now gitweb.cgi effectively has a bug in it because it sorts using external/superset commit
order/time rather than local commit order which causes changes to appear as if they were made
before they were really merged locally.
what you are asking for would be a very useful piece of software, but
that's very different from the current gitweb. you are fileing a bug about
the software doing what it was designed to do. yes, it could be done
differently. yes, that would be useful. but the software to do so is
mostly a new product, not a simple tweak to the existing gitweb software.
right now gitweb isn't designed for figuring out what was merged when,
it's just for retreiving specific versions.
if someone really wanted to do this, the right answer may be to take the
concept of gitk and webify it (think SVG for the graphics and AJAX
interfaces to retreive the info as needed). I think this would be a very
useful tool, but it would be a lot of work to implement.
but without the graph showing the commits and how they are related to each
other, you really are crippled in your ability to figure out how things
are related to each other. Date order just doesn't cut it.
David Lang
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
