Re: merge time

[david@lang.hm]

On Mon, 30 Jul 2007, Matthew L Foster wrote:

> --- Rogan Dawes <lists@dawes.za.net> 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