On 3/16/07, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> Porting things like qgit to it or writting proper perl/python bindings > is wasted time since you'd have to rewrite all of it once you decided > which functions to expose and which structures to use (calling the > main() routines of builtin's doesn't count as real libifaction, it would > rather be a performance improvement only). Nope. It is _not_ a complete rewrite. More likely, it is minimal adjustments. It's not like we will replace apples with cars...
IMHO probably the truth is in the middle. I wouldn't call it a trivial porting, at least for me, but anyway it would be interesting to have fun with linking libgit. *The most important thing for a libgit to be used by qgit is reentrancy* Currently an unlimited number of tabs could be open in qgit, I'm not talking about tabs open on different repos, but different views on the same repo: main view, file history of file A, file history of file B, tree view, i.e. select some files/directory from directory tree and view the revisions that modified that repo subset, and so on. Other different views could be added in the future. Because each view has a dedicated tab and each tab calls _his_ 'git rev-list' instance (could be called also at the same time) this libgit thing should be able to support many instance of the libified git-rev-list function running at the same time. Perhaps currently this need is only for qgit among the GUI browsers, but it would be not too difficult to foreseen a multi view GUI interface as a relative common feature in the future also for the remaining crop of git tools. Marco - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html