Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#10 thank you



Just wanted to let you know that I really like qgit a lot and that I appreciate the time you spent on developing it.

It could become the de-facto frontend for git if it could feature full support for the git toolchain in a graphical fashion, this could for example be achieved by using the existing notion of tool actions, which could then be based on shell commands (git scripts/custom scripts) with certain arguments, thus the GUI integration would mainly boil down to allowing users to provide tooltips for custom actions and place these actions along with a description on some sort of toolbar or in a context menu.

maybe saving actions/commands separately would be the best option because that would mean that users could easily share their "action files" for new/custom commands.

So, "Action" might benefit from a "scope" attribute, so that qgit may smartly detect the context in which they are valid or not, to adjust the toolbar or context menu accordingly.

Thus future extension of qgit would mainly come down to providing a growing library of "action snippets" for qgit use, so that it may eventually become a fully fledged frontend to git

thank you very much for qgit!


  • Marco Costalba
    Marco Costalba

    Logged In: YES
    Originator: NO

    Thanks for your nice words.

    If I have understood correctly you propose to add the custom actions (i.e. what you see under 'Action' menu) to the tool bar?

    Is it correct?


  • Logged In: YES
    Originator: NO

    I also like QGit a lot, but I think it should mature as a pure commit message viewer (i.e. gitk replacement) for now.

    A Qt-based GUI for actually performing actions on the repository (i.e. a git-gui replacement) is currently underway here: http://repo.or.cz/w/ugit.git/

    Maybe at a later point in time ugit could be rewritten in C++ as a new application or merged with QGit.

  • Logged In: YES
    Originator: NO

    I'm sorry, I wasn't really aware that QGit already can perform some "write actions" like "commit" from the Edit menu. That's great! However, I guess ugit can currently perform some more actions, making it the better replacement for git-gui for now. It would be fantastic to see QGit emerging to the one-and-only GUI for Git which encapsulates both gitk and git-gui functionality.

  • Marco Costalba
    Marco Costalba

    Logged In: YES
    Originator: NO

    As you said correctly QGit is on the same playfield as gitk.

    It is not a specialized GUI git interface tool as git-gui, and is not meant to be.

    Yes, you can customize actions, give them a name and call from Action menu.
    Any command/script/etc can be an action and you can also pass parameters to them when launching.

    But this is not a GUI interface, just a way to avoid the user to go on the ALT+TAB switch.

    Just as a note, I have created the following custom actions that are useful for me:

    git pull
    make install

    As you can see you can write anything you want, so it's really more then a set of
    customizables shortcuts then a git interface.

    BTW I have quickly checked ugit and I like it, developer has been very quick to play
    catch up with the much more long lived git-gui.

    Also ugit, altough in Python, uses Qt libraries as graphical framework, so it's the
    most similar to qgit among the git tools that I know.


    P.S: I have pushed some patches for Inno Setup that address your concerns, but if you cannot
    compile under Windows I can push a new version qgit2.1.1_win.exe installer if this is easier
    for you to use.

  • Marco Costalba
    Marco Costalba

    Logged In: YES
    Originator: NO

    Reading agin your post I think I have misunderstood you.

    Commit action is not a custom action, but is one thing that qgit knows how to do as builtin.

    Custom actions are under Action menu and are a totally different thing.

    May I suggest you to give a look to QGit handbook (perss F1)..you could find some surprise ;-)


  • Logged In: YES
    Originator: NO

    Yeah, I really need to read more docs ;-) I think some of the confusion was due to how I used the word "actions" in my previous posts. I wasn't necessarily meaning to refer to what is listed in the "Actions" menu with that.

    Anyway, the difference between "built-in commands" in the "Edit" menu and "custom commands" (which could call Git from the command line) in the "Actions" menu is clear.

    I was just having a hard time trying to get ugit to run natively under Windows, which is why I thought it might be a nice thing if QGit included ugit's functionality in the future.

    Regarding the updated installer: If you already managed to default to what is set via "GIT_EXTERNAL_DIFF" / "diff.external" for the "External patch viewer" (see bug #1862033) I would highly appreciate an updated installer.

    Thank you very much!

  • Logged In: NO

    Hi, me again - the OP.

    Yes, I was mainly thinking of a way to extend and generalize the current concept of "actions", so that actions can be easily integrated into the GUI in various places (i.e. toolbars, context menus), preferably such configured actions would then be saved as individual files, i.e. in XML format, so that user-defined actions can be easily exported/imported for use by other users, basically facilitating "qgit actions sharing", where you as the qgit author would primarily make sure that you provide the low level building blocks so that qgit users can easily conceive, create and provide new actions for all sorts of interesting GUI/git integration which they would then only have to upload to the qgit webpage, so that others can download their actions.

    Actions would then at least consist of the following "meta" information:
    - version of action file format/XML?
    - name of action
    - description of action
    - pre-requisites of action (i.e. certain tools)
    - type/context of embedding/GUI integration (i.e. toolbar/context menus)
    - context in which the action is valid and applicable (i.e. only for branches or tags)
    - optional symbol/icon to be used within the GUI

    So, the original idea was mainly to provide means for "static plugins" to be integrated into the GUI, so that "smart actions" can be implemented which are "context-aware", so that these actions only show up in the right context (think of context menu).

    Hope, this clariefies the idea


  • Logged In: NO

    I've read the other postings, and personally I have to admit that I am not sure whether I agree about the future scope of qgit possibly becoming restricted to be mainly a repository tracker/viewer:
    I just don't see the benefits in such a decision. However, on the other hand I really don't suggest qgit to become a fully-fledged git/GUI frontend anytime soon, rather I would hope qgit to become a generic "framework" for git-related GUI operations, regardless of whether they are passive or active. Hopefully, providing the core infrastructure required to enable its user base and community to provide individual functionality, for example in the form of custom actions that can be easily exported/imported by users and thus be shared within the community. And I am saying this for a reason: you might happen to know diff/patch frontends like Kompare or KDiff3, if you check out the history of these projects, as well as the overall nature of feature requests and suggestions made, you'll notice one trend: genericity.

    A high degree of interoperability is becoming more and more important, users want to be able to use these GUI frontends to diff/patch with all sorts of SCM/RCS frontends (cvs,svn,hq,git etc), but they also want to be able to highly customize the GUI for certain specific purposes, i.e. so that they can provide specifically adapted frontends. However, these projects are now facing a challenge because of their rather static and inflexible design, which can no longer accomodate many of the recently requested features, as these would basically require a framework-centric thinking, where the hardcoded core is mainly providing an infrastructure to high level logics that may implement various types of abstract case-specific "applications".

    And this is a pity, as it is simply in the nature of these projects to be primarily used by fellow developers, who usually happen to be quite familiar with coding and would more often than not like to be able to provide additional functionality.
    Thus, I think that it is important to keep this in mind, so that this manpower may be leveraged for the sake of project's progress.

    In this sense, I actually do like the approach of implementing higher level logics in a scripted fashion, i.e. by using Python. preferably using a dynamic architecture that can be easily extended using Plugins at runtime, where the community is encouraged and enabled to provide arbitrary high level wrappers on top of the actual core application, which would boil down to becoming a framework for patch management related tasks.

    Assuming a certain degree of "evolution" taking place, it would only be natural that such a framework-centric development philosophy would eventually result in generic scripted libraries being derived from otherwise standalone scripts.

  • Marco Costalba
    Marco Costalba

    Logged In: YES
    Originator: NO

    I agree with you that flexibility and possibility to integrate external plugins is for sure a big plus.

    Currently custom actions are saved as plain text, but the idea to use xml format instead is appealing.

    Regarding interoperability with all sorts of SCM/RCS frontends (cvs,svn,hq,git etc) I would think that is very difficult that a single tool can achieve this, or, also if it is possible, I would expect results in terms of performance/code manteinability and so on would be sub-optimal.

    From the experience I have with QGit I would say that the biggest part of the code and also the most "difficult" is the one that interface git, IOW is the one SCM dependant. In case you want to connect to different SCM you need to duplicate that part. Unfortunatly the code that can be reused 'as is' for different backends, i.e. the graphical part of qgit, is not the 90%, I would say we are more or less at 40-50%.

    Anyhow is impossible for me to state how qgit will evolve in the future, what I'm sure is that I really don't want to block the updates/patches/ideas that come from the users. qgit will go where it's user/hacker base will choose, I will stay open to any contribute from anybody.

  • Logged In: NO

    Just to clarify: I really wasn't trying to suggest that Qgit itself should feature support for
    multiple RCS/SCM backends, after all it's Q*GIT* - so it's purpose is pretty specific, and I don't mind
    this at all. However, the original example was only meant to point out the requirement for
    flexibility and extendsibility for most generic patch managers.

    And in the context of qgit, I would personally also like to see an architecture that
    encourages and enables community involvement. For example, I would like to have the
    possibility to show a preview of patches directly in the main window or to add a
    combo box (dropdown menu) showing all branches and tags in the main window, likewise
    it would be interesting to eventually have the possibility to open multiple git repositories
    and execute actions between them.

    There are more examples for the power behind the aforementioned philosophy of framework-centric software development:

    - you delegate the development of high level frontends to the user community
    - core stability is not affectd
    - new code can be added without recompiling qgit
    - development of new features can be facilitated by providing the low level infrastructure

    In this sense, it would actually be desirable to see a hybrid approach of qgit/git-gui, simply because
    it would allow the flexibility of a dynamic, scripted approach, with the benefit of a native excutable,
    which would mean that a qgit/git-gui hybrid would be based on an embedded python interpreter to
    facilitate plugin integration.

    This could be facilitated by removing the different between native and custom actions: if
    native actions are implemented using the same means as custom actions are using, then the
    playground is levelled off.

    So, whether actions are passive or active doesn't matter anymore, users decide.

  • Logged In: NO

    Here are some thoughts concerning the use of XML to save/share custom actions:

    - it would make sense to introduce the concept of "classes" or "types" of custom actions, depending on what sort of data they're dealing with, so that qgit can embed them appropriately and disable/hide actions if their functionality is not applicable to the currently active GUI element

    - embedding should also take place accordingly, i.e. in a toolbar or context menu

  • Logged In: NO

    WRT interoperability: git supports already a multitude of wrappers for things like cvs and svn, so you can form example work with CVS and SVN repositories easily using git.

    Apart from that I would also appreciate a way to expose more of these command line wrappers to the QGIT UI, so that custom actions can be defined. If these could be shared and exchanged with fellow users, all the better! That way, QGIT could easily become an interactive repository viewer/frontend.

  • Marco Costalba
    Marco Costalba

    • status: open --> closed