Re: FFmpeg considering GIT

Re: FFmpeg considering GIT

[Brett Schwarz]

Sorry for the posting, my email reader sucks.

What is the real issue? Is it that there isn't enough people to maintain gitk? I've been hiding in the bushes, mostly because of time issues, but if there's a real need, I'd be willing to help. I'm a seasoned Tcl/Tk coder, and wouldn't have any problems helping out.

Also, I've been waiting for the git lib to get done. When this gets done, a lot of the procs in gitk can be re-written in 'C' as Tcl commands. This obviously gives the advantage of speed, but since it is written in 'C', the potential maintainership would be larger. The 'C' code would just be dyn loaded into the Tcl interpreter.

As Shawn mentions below, he started using namespaces for git-gui. I think gitk could benefit from that as well, along with a few other changes.


----- Original Message ----
From: Shawn O. Pearce <spearce@spearce.org>
To: Paul Mackerras <paulus@samba.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>; Karl Hasselstr?m <kha@treskal.com>; Junio C Hamano <junkio@cox.net>; Carl Worth <cworth@cworth.org>; Michael Niedermayer <michaelni@gmx.at>; Git Mailing List <git@vger.kernel.org>
Sent: Monday, May 7, 2007 7:03:38 PM
Subject: Re: FFmpeg considering GIT

Paul Mackerras <paulus@samba.org> wrote:
> I have thought about rewriting it in a different language, but I
> haven't found anything that really appeals.  I don't want to go to
> C/GTK or C/Qt since that would make it hard to port to Windows and
> MacOS AFAIK.  Python/Tk would be a possibility, but I have never
> learnt python and I'm actually not all that comfortable with having to
> do things the object-oriented way.
> 
> Any suggestions?

Funny that you mention this.  Lately I have been hacking on git-gui,
trying to improve it and clean up some of the code.

I've thought about wxWindows but didn't really dig into it to see
how usuable it would be - primary reason is not everyone has it
installed on their system.  The same for GTK and Qt.  Actually I
don't even have GTK installed on my Mac but I did install Qt3
(took half a day!)  so I could build qgit at one point in time.

But almost everyone already has a wish installed.

I've thought about writing git-gui in C, but linking to the Tk
library for the "portable UI".  But not everyone has the Tcl/Tk
development headers and libraries installed, but they probably do
have the wish executable installed.

I want to limit the barrier to entry for git, and that means limiting
the barrier of entry for git-gui.  Keeping our requirements to a
minimum helps.

So I think I've settled on sticking to Tcl and its Tk extensions,
but making more use of newer Tcl constructs like namespaces.  If you
look at my `pu` branch of git-gui I have actually split the program
down into many files, and have started to organize the code in each
into different namespaces, depending on function.

-- 
Shawn.
-
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




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: FFmpeg considering GIT

[Paul Mackerras]

Brett Schwarz writes:

> What is the real issue? Is it that there isn't enough people to

The real issue is that I would like, if possible, to make it easier
for people like Linus to hack on gitk and add cool features that I
wouldn't necessarily think of.

> maintain gitk? I've been hiding in the bushes, mostly because of
> time issues, but if there's a real need, I'd be willing to help. I'm
> a seasoned Tcl/Tk coder, and wouldn't have any problems helping
> out.

That could be very useful, thanks.

> As Shawn mentions below, he started using namespaces for git-gui. I
> think gitk could benefit from that as well, along with a few other
> changes.

Gitk ends up handling pretty significant amounts of data.  In
particular the per-commit data can get to gigabytes, and processing it
is pretty cpu-intensive.  I did try using namespaces for the
per-commit data but I found that the performance hit to be more than I
was willing to tolerate.

Paul.

Re: FFmpeg considering GIT

[Shawn O. Pearce]

Paul Mackerras <paulus@samba.org> wrote:
> Brett Schwarz writes:
> > As Shawn mentions below, he started using namespaces for git-gui. I
> > think gitk could benefit from that as well, along with a few other
> > changes.
> 
> Gitk ends up handling pretty significant amounts of data.  In
> particular the per-commit data can get to gigabytes, and processing it
> is pretty cpu-intensive.  I did try using namespaces for the
> per-commit data but I found that the performance hit to be more than I
> was willing to tolerate.

If that is the case then an obvious direction is to start using C
for the actual Git operations/datastore and Tcl/Tk for the basic
UI layout and event handlers.

If we go down that path for gitk then I may wind up doing the
same for git-gui.  Because gitk would require the tcl/tk heders
and libraries at that point, so also requiring them for git-gui
wouldn't be too unreasonable.

But fortunately git-gui doesn't have to deal with gigabytes
of data; I'm only really looking at the "dirty" stuff, or
at worst, the blame for an entire file.

-- 
Shawn.

gitk and git-gui, was Re: FFmpeg considering GIT

[Johannes Schindelin]

Hi,

On Tue, 8 May 2007, Shawn O. Pearce wrote:

> Paul Mackerras <paulus@samba.org> wrote:
>
> > Gitk ends up handling pretty significant amounts of data.  In 
> > particular the per-commit data can get to gigabytes, and processing it 
> > is pretty cpu-intensive.  I did try using namespaces for the 
> > per-commit data but I found that the performance hit to be more than I 
> > was willing to tolerate.
> 
> If that is the case then an obvious direction is to start using C for 
> the actual Git operations/datastore and Tcl/Tk for the basic UI layout 
> and event handlers.

It might be a much better idea to write something a la git-fetch--tool, 
which is a helper in C (thus very fast and memory efficient), outputting 
easily parseable data. 

For example, when constructing the commit graph, the calculations could be 
done in C, and Tcl/Tk could do _just_ the display. AFAIK tig already has 
the algorithm implemented in C...

The big benefits would not only be that you can compile this without the 
headers/libs of Tcl/Tk (possibly avoiding the problem we experienced when 
trying to compile Git with gcc, and linking to Perl, which was compiled 
with a different compiler), but other Git viewers could take this output 
as well, avoiding reimplementing the algorithm in Ruby or Haskell.

Ciao,
Dscho

Re: gitk and git-gui, was Re: FFmpeg considering GIT

[Linus Torvalds]

On Tue, 8 May 2007, Johannes Schindelin wrote:
> 
> It might be a much better idea to write something a la git-fetch--tool, 
> which is a helper in C (thus very fast and memory efficient), outputting 
> easily parseable data. 

Well, we actually do have that. "git log" (or "git-rev-list") really does 
all the heavy lifting. The reason you can do things like "gitk --merge" is 
not because gitk itself has _any_ idea about anything, but because it just 
passes the arguments down to git-rev-list (and hopefully soon git log), 
which really does all the complex stuff.

But gitk still ends up having a big memory footpring, simply because if 
you get the data for a few hundred thousand commits (with commit messages 
etc), and have to keep track of the relationships between them, you are 
going to easily use hundreds of megs of memory.

		Linus