{"thread":{"id":"8027","subject":"Re: FFmpeg considering GIT","startedAt":"2007-05-08T03:39:53Z","lastAt":"2007-05-08T15:33:09Z","messageCount":5,"participants":["Brett Schwarz","Paul Mackerras","Shawn O. Pearce","Johannes Schindelin","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"41404","messageId":"57600.59393.qm@web38909.mail.mud.yahoo.com","threadId":"8027","inReplyTo":null,"subject":"Re: FFmpeg considering GIT","fromName":"Brett Schwarz","fromEmail":"brett_schwarz@yahoo.com","sentAt":"2007-05-08T03:39:53Z","receivedAt":"2007-05-08T03:39:53Z","isPatch":false,"sender":{"key":"brett_schwarz@yahoo.com","avatar":null},"body":"Sorry for the posting, my email reader sucks.\n\nWhat 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.\n\nAlso, 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.\n\nAs 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.\n\n\n----- Original Message ----\nFrom: Shawn O. Pearce \nTo: Paul Mackerras \nCc: Linus Torvalds ; Karl Hasselstr?m ; Junio C Hamano ; Carl Worth ; Michael Niedermayer ; Git Mailing List \nSent: Monday, May 7, 2007 7:03:38 PM\nSubject: Re: FFmpeg considering GIT\n\nPaul Mackerras wrote:\n> I have thought about rewriting it in a different language, but I\n> haven't found anything that really appeals. I don't want to go to\n> C/GTK or C/Qt since that would make it hard to port to Windows and\n> MacOS AFAIK. Python/Tk would be a possibility, but I have never\n> learnt python and I'm actually not all that comfortable with having to\n> do things the object-oriented way.\n> \n> Any suggestions?\n\nFunny that you mention this. Lately I have been hacking on git-gui,\ntrying to improve it and clean up some of the code.\n\nI've thought about wxWindows but didn't really dig into it to see\nhow usuable it would be - primary reason is not everyone has it\ninstalled on their system. The same for GTK and Qt. Actually I\ndon't even have GTK installed on my Mac but I did install Qt3\n(took half a day!) so I could build qgit at one point in time.\n\nBut almost everyone already has a wish installed.\n\nI've thought about writing git-gui in C, but linking to the Tk\nlibrary for the \"portable UI\". But not everyone has the Tcl/Tk\ndevelopment headers and libraries installed, but they probably do\nhave the wish executable installed.\n\nI want to limit the barrier to entry for git, and that means limiting\nthe barrier of entry for git-gui. Keeping our requirements to a\nminimum helps.\n\nSo I think I've settled on sticking to Tcl and its Tk extensions,\nbut making more use of newer Tcl constructs like namespaces. If you\nlook at my `pu` branch of git-gui I have actually split the program\ndown into many files, and have started to organize the code in each\ninto different namespaces, depending on function.\n\n-- \nShawn.\n-\nTo unsubscribe from this list: send the line \"unsubscribe git\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html\n\n\n\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"41408","messageId":"17983.63329.314321.305860@cargo.ozlabs.ibm.com","threadId":"8027","inReplyTo":"57600.59393.qm@web38909.mail.mud.yahoo.com","subject":"Re: FFmpeg considering GIT","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2007-05-08T04:06:57Z","receivedAt":"2007-05-08T04:06:57Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Brett Schwarz writes:\n\n> What is the real issue? Is it that there isn't enough people to\n\nThe real issue is that I would like, if possible, to make it easier\nfor people like Linus to hack on gitk and add cool features that I\nwouldn't necessarily think of.\n\n> maintain gitk? I've been hiding in the bushes, mostly because of\n> time issues, but if there's a real need, I'd be willing to help. I'm\n> a seasoned Tcl/Tk coder, and wouldn't have any problems helping\n> out.\n\nThat could be very useful, thanks.\n\n> As Shawn mentions below, he started using namespaces for git-gui. I\n> think gitk could benefit from that as well, along with a few other\n> changes.\n\nGitk ends up handling pretty significant amounts of data. In\nparticular the per-commit data can get to gigabytes, and processing it\nis pretty cpu-intensive. I did try using namespaces for the\nper-commit data but I found that the performance hit to be more than I\nwas willing to tolerate.\n\nPaul.\n"},{"id":"41409","messageId":"20070508041939.GK11311@spearce.org","threadId":"8027","inReplyTo":"17983.63329.314321.305860@cargo.ozlabs.ibm.com","subject":"Re: FFmpeg considering GIT","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-08T04:19:39Z","receivedAt":"2007-05-08T04:19:39Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Paul Mackerras wrote:\n> Brett Schwarz writes:\n> > As Shawn mentions below, he started using namespaces for git-gui. I\n> > think gitk could benefit from that as well, along with a few other\n> > changes.\n> \n> Gitk ends up handling pretty significant amounts of data. In\n> particular the per-commit data can get to gigabytes, and processing it\n> is pretty cpu-intensive. I did try using namespaces for the\n> per-commit data but I found that the performance hit to be more than I\n> was willing to tolerate.\n\nIf that is the case then an obvious direction is to start using C\nfor the actual Git operations/datastore and Tcl/Tk for the basic\nUI layout and event handlers.\n\nIf we go down that path for gitk then I may wind up doing the\nsame for git-gui. Because gitk would require the tcl/tk heders\nand libraries at that point, so also requiring them for git-gui\nwouldn't be too unreasonable.\n\nBut fortunately git-gui doesn't have to deal with gigabytes\nof data; I'm only really looking at the \"dirty\" stuff, or\nat worst, the blame for an entire file.\n\n-- \nShawn.\n"},{"id":"41441","messageId":"Pine.LNX.4.64.0705081311550.4167@racer.site","threadId":"8027","inReplyTo":"20070508041939.GK11311@spearce.org","subject":"gitk and git-gui, was Re: FFmpeg considering GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-08T11:16:37Z","receivedAt":"2007-05-08T11:16:37Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 8 May 2007, Shawn O. Pearce wrote:\n\n> Paul Mackerras wrote:\n>\n> > Gitk ends up handling pretty significant amounts of data. In \n> > particular the per-commit data can get to gigabytes, and processing it \n> > is pretty cpu-intensive. I did try using namespaces for the \n> > per-commit data but I found that the performance hit to be more than I \n> > was willing to tolerate.\n> \n> If that is the case then an obvious direction is to start using C for \n> the actual Git operations/datastore and Tcl/Tk for the basic UI layout \n> and event handlers.\n\nIt might be a much better idea to write something a la git-fetch--tool, \nwhich is a helper in C (thus very fast and memory efficient), outputting \neasily parseable data. \n\nFor example, when constructing the commit graph, the calculations could be \ndone in C, and Tcl/Tk could do _just_ the display. AFAIK tig already has \nthe algorithm implemented in C...\n\nThe big benefits would not only be that you can compile this without the \nheaders/libs of Tcl/Tk (possibly avoiding the problem we experienced when \ntrying to compile Git with gcc, and linking to Perl, which was compiled \nwith a different compiler), but other Git viewers could take this output \nas well, avoiding reimplementing the algorithm in Ruby or Haskell.\n\nCiao,\nDscho\n"},{"id":"41467","messageId":"alpine.LFD.0.98.0705080830380.3974@woody.linux-foundation.org","threadId":"8027","inReplyTo":"Pine.LNX.4.64.0705081311550.4167@racer.site","subject":"Re: gitk and git-gui, was Re: FFmpeg considering GIT","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-08T15:33:09Z","receivedAt":"2007-05-08T15:33:09Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 8 May 2007, Johannes Schindelin wrote:\n> \n> It might be a much better idea to write something a la git-fetch--tool, \n> which is a helper in C (thus very fast and memory efficient), outputting \n> easily parseable data. \n\nWell, we actually do have that. \"git log\" (or \"git-rev-list\") really does \nall the heavy lifting. The reason you can do things like \"gitk --merge\" is \nnot because gitk itself has _any_ idea about anything, but because it just \npasses the arguments down to git-rev-list (and hopefully soon git log), \nwhich really does all the complex stuff.\n\nBut gitk still ends up having a big memory footpring, simply because if \nyou get the data for a few hundred thousand commits (with commit messages \netc), and have to keep track of the relationships between them, you are \ngoing to easily use hundreds of megs of memory.\n\n\t\tLinus\n"}]}