# Re: FFmpeg considering GIT 5 messages from 2007-05-08 to 2007-05-08. Participants: Brett Schwarz, Paul Mackerras, Shawn O. Pearce, Johannes Schindelin, Linus Torvalds. Thread: https://gitlist.dev/t/8027 ## Brett Schwarz, 2007-05-08 03:39 Subject: Re: FFmpeg considering GIT Message-ID: <57600.59393.qm@web38909.mail.mud.yahoo.com> URL: https://gitlist.dev/e/57600.59393.qm%40web38909.mail.mud.yahoo.com ``` 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 To: Paul Mackerras Cc: Linus Torvalds ; Karl Hasselstr?m ; Junio C Hamano ; Carl Worth ; Michael Niedermayer ; Git Mailing List Sent: Monday, May 7, 2007 7:03:38 PM Subject: Re: FFmpeg considering GIT Paul Mackerras 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 ``` ## Paul Mackerras, 2007-05-08 04:06 Subject: Re: FFmpeg considering GIT Message-ID: <17983.63329.314321.305860@cargo.ozlabs.ibm.com> URL: https://gitlist.dev/e/17983.63329.314321.305860%40cargo.ozlabs.ibm.com In-Reply-To: <57600.59393.qm@web38909.mail.mud.yahoo.com> ``` 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. ``` ## Shawn O. Pearce, 2007-05-08 04:19 Subject: Re: FFmpeg considering GIT Message-ID: <20070508041939.GK11311@spearce.org> URL: https://gitlist.dev/e/20070508041939.GK11311%40spearce.org In-Reply-To: <17983.63329.314321.305860@cargo.ozlabs.ibm.com> ``` Paul Mackerras 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. ``` ## Johannes Schindelin, 2007-05-08 11:16 Subject: gitk and git-gui, was Re: FFmpeg considering GIT Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0705081311550.4167%40racer.site In-Reply-To: <20070508041939.GK11311@spearce.org> ``` Hi, On Tue, 8 May 2007, Shawn O. Pearce wrote: > Paul Mackerras 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 ``` ## Linus Torvalds, 2007-05-08 15:33 Subject: Re: gitk and git-gui, was Re: FFmpeg considering GIT Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.98.0705080830380.3974%40woody.linux-foundation.org In-Reply-To: ``` 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 ```