announce: git browser

announce: git browser

[Artem Khodush]

Hello,

I'd like to announce experimental web interface for git,
complementary to gitweb. It visualizes commit history graph
and shows commit diffs.

See http://straytree.com/git-browser/GitBrowser.html?r=git

Artem.

Re: announce: git browser

[Petr Baudis]

  Hello,

Dear diary, on Mon, Dec 05, 2005 at 01:23:24AM CET, I got a letter
where Artem Khodush <greenkaa@gmail.com> said that...
> I'd like to announce experimental web interface for git,
> complementary to gitweb. It visualizes commit history graph
> and shows commit diffs.
> 
> See http://straytree.com/git-browser/GitBrowser.html?r=git

  quite interesting! I always dreamt (not intensively enough to go
myself and do it) about gitweb having gitk-like visualization, possibly
this might help. ;-)

  Couple of initial notes:

  * I would find it much nicer if you wouldn't "squeeze" all the day's
(except merge) commits together, but left them separate. Possibly a
switch to squeeze them, but I'm really not sure if it's even useful to
have.

  * The line graphics etc. might be more colourful and prettier. ;-)

  * Then it could have a "gitk mode" where the time flows vertically and
author+title+time is shown in each line. It turns out that this might
not be the prettiest, but it's really the most informative and useful
view, IMHO.

  * When I click on the little black box, the commit window disappears
before I manage to click on anything inside; I would intuitively expect
the reverse behaviour - that this happens when I don't click on the box.
Or that clicking on the box does not matter. *shrug* The web interface
with those windows popping up admitelly makes my mind somewhat
uncomfortable, but it's hard to pin-point down why.

  * Possibly, the commit information could be shown in a dedicated
screen area altogether. It also wouldn't obscure the view of the actual
diagram, and it would be more visible that it cutely highlights the
appropriate box based on the current commit you have your cursor on.

  * It looks too much like Feynman diagrams when the merge arrow
points slightly backwards; perhaps you could try to avoid that.

  * It doesn't seem to handle the UTF8 characters properly.

  Quite nice for starters, though! The diff viewer looks pretty slick,
too.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: announce: git browser

[Artem Khodush]

On 12/5/05, Petr Baudis <pasky@suse.cz> wrote:

> > See http://straytree.com/git-browser/GitBrowser.html?r=git
>
>   quite interesting! I always dreamt (not intensively enough to go
> myself and do it) about gitweb having gitk-like visualization, possibly
> this might help. ;-)
>
>   Couple of initial notes:
>
>   * I would find it much nicer if you wouldn't "squeeze" all the day's
> (except merge) commits together, but left them separate. Possibly a
> switch to squeeze them, but I'm really not sure if it's even useful to
> have.

Well it's easy to do, but then, in Linus tree, a single day would not fit
on my screen :-) So 'squeezed' mode is helpful for me, at least,
 to get big picture at a glance - in git tree, for example, I can see
the 0.99.5 release branch to  begin and end on a single screen.


>   * The line graphics etc. might be more colourful and prettier. ;-)

And the question is: the colours are assigned to what:
branches ? authors ? committers ? repositories ?


>   * Then it could have a "gitk mode" where the time flows vertically and
> author+title+time is shown in each line. It turns out that this might
> not be the prettiest, but it's really the most informative and useful
> view, IMHO.

But in this view, you can have only the number-of-lines-on-the-screen
commits visible. And with graphics done in javascript, scrolling is
painfully slow, at least in mozilla. And I think that implementing
quick search in a diagram will provide much more information
than one can get by 'visual grep' :-). So I don't know, need to think
a bit more .

>   * When I click on the little black box, the commit window disappears
> before I manage to click on anything inside; I would intuitively expect
> the reverse behaviour - that this happens when I don't click on the box.
> Or that clicking on the box does not matter. *shrug* The web interface
> with those windows popping up admitelly makes my mind somewhat
> uncomfortable, but it's hard to pin-point down why.

Yep, the boxes intentionally are not clickable, I think it makes navigation
easier, perhaps it could be made as a preference..


>   * Possibly, the commit information could be shown in a dedicated
> screen area altogether. It also wouldn't obscure the view of the actual
> diagram, and it would be more visible that it cutely highlights the
> appropriate box based on the current commit you have your cursor on.

Yes I also think about it. Initially the boxes were semi-transparent so
you could track the highlihgt under the box, it looked very nice,
but that was too slow to be usable on my computer, and opera
does not have that 'opacity' thing..

>   * It looks too much like Feynman diagrams when the merge arrow
> points slightly backwards; perhaps you could try to avoid that.

If I find a way to do it without further complicating placement algorightm,
maybe..

>   * It doesn't seem to handle the UTF8 characters properly


>   Quite nice for starters, though! The diff viewer looks pretty slick,
> too.

Thanks! Btw, I took the diff viewer pretty much unmodified from gitweb.

Artem.

Re: announce: git browser

[Petr Baudis]

Dear diary, on Mon, Dec 05, 2005 at 02:20:39AM CET, I got a letter
where Artem Khodush <greenkaa@gmail.com> said that...
> On 12/5/05, Petr Baudis <pasky@suse.cz> wrote:
> >   * I would find it much nicer if you wouldn't "squeeze" all the day's
> > (except merge) commits together, but left them separate. Possibly a
> > switch to squeeze them, but I'm really not sure if it's even useful to
> > have.
> 
> Well it's easy to do, but then, in Linus tree, a single day would not fit
> on my screen :-) So 'squeezed' mode is helpful for me, at least,
>  to get big picture at a glance - in git tree, for example, I can see
> the 0.99.5 release branch to  begin and end on a single screen.

I see. Well, how useful the big picture is? (Or rather the part of it
you don't get by just looking at the current state.)

> >   * The line graphics etc. might be more colourful and prettier. ;-)
> 
> And the question is: the colours are assigned to what:
> branches ? authors ? committers ? repositories ?

Branches for easy visual distinguishing of what line is what, I guess.
Coloring based on repositories in particular would be very hard.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: announce: git browser

[Artem Khodush]

>
> I see. Well, how useful the big picture is? (Or rather the part of it
> you don't get by just looking at the current state.)

Yes, I see that for day-to-day development the gitk view is optimal.
I'll see if I can do something similar, but web-based.

Artem.

Re: announce: git browser

[Junio C Hamano]

Artem Khodush <greenkaa@gmail.com> writes:

>> I see. Well, how useful the big picture is? (Or rather the part of it
>> you don't get by just looking at the current state.)
>
> Yes, I see that for day-to-day development the gitk view is optimal.
> I'll see if I can do something similar, but web-based.

I think there are at least two web interfaces already and this
is the third one with an interesting "twist".  Javascript
drawing is cute.

This is not to discourage yet another web based one, but I wish
there were an NNTP interface, that feeds each repository/branch
as a newsgroup and each commit as if it is "git-format-patch"
output, with References: pointing at its parent commit "articles".

A merge commit would probably become a multipart with usually 2
attachments (but N attachments for a N-way octopus), showing
diff from each branch.

Re: announce: git browser

[Artem Khodush]

> I think there are at least two web interfaces already

The web does not care how many web pages it has :-)

> This is not to discourage yet another web based one, but I wish
> there were an NNTP interface, that feeds each repository/branch
> as a newsgroup and each commit as if it is "git-format-patch"
> output, with References: pointing at its parent commit "articles".
>
> A merge commit would probably become a multipart with usually 2
> attachments (but N attachments for a N-way octopus), showing
> diff from each branch.

I'll see if I can do something with Perl and Net::NNTP..

Re: announce: git browser

[Junio C Hamano]

Artem Khodush <greenkaa@gmail.com> writes:

>> This is not to discourage yet another web based one, but I wish
>> there were an NNTP interface, that feeds each repository/branch
>> as a newsgroup and each commit as if it is "git-format-patch"
>> output, with References: pointing at its parent commit "articles".
>>
>> A merge commit would probably become a multipart with usually 2
>> attachments (but N attachments for a N-way octopus), showing
>> diff from each branch.
>
> I'll see if I can do something with Perl and Net::NNTP..

"Ask and it shall be given you" ;-)

In case it was not obvious, I was talking about an NNTP server,
not a client.

You would probably have to keep a mapping between sequence
number and commit object name in each "newsgroup", which is the
only nontrivial part.

Re: announce: git browser

[Artem Khodush]

>
> In case it was not obvious, I was talking about an NNTP server,
> not a client.
>
> You would probably have to keep a mapping between sequence
> number and commit object name in each "newsgroup", which is the
> only nontrivial part.

And the reason why special NNTP server is needed is, I guess,
that plain NNTP server will not be able to cope with all the diffs
stored in message database? Well, but then, the newsgroups
will not be distributable..

Or is there any other reason?

Re: announce: git browser

[Junio C Hamano]

Artem Khodush <greenkaa@gmail.com> writes:

> Or is there any other reason?

Just for fun ;-).

Re: announce: git browser

[Artem Khodush]

>
> > Or is there any other reason?
>
> Just for fun ;-).

And then, it could be taught to apply posted patches, which could be
even more fun.. :-)

Re: announce: git browser

[Junio C Hamano]

Artem Khodush <greenkaa@gmail.com> writes:

>> > Or is there any other reason?
>>
>> Just for fun ;-).
>
> And then, it could be taught to apply posted patches, which could be
> even more fun.. :-)

By the way, by "fun" I do not mean "joke" at all.

You earlier said such newsgroups cannot be distributed, but I
would say why not.  They will be moderated groups and patches
will go to the "moderator" who applies the patches to the
branches.

Reading such a newsgroup would be like going through
"commitdiff" link on gitweb one commit after another, but is
more efficient and would match the workflow of people who review
lots of patches on mailing lists.

Re: announce: git browser

[Junio C Hamano]

Artem Khodush <greenkaa@gmail.com> writes:

> And the reason why special NNTP server is needed is, I guess,
> that plain NNTP server will not be able to cope with all the diffs
> stored in message database? Well, but then, the newsgroups
> will not be distributable..
>
> Or is there any other reason?

Actually, the real reason was I was stupid (I am always stupid
but I was more stupid than I usually am in this case).  We could
just inject new patches into appropriate newsgroups as they come
along, either from a cron job or from the post-update hook.