Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#6 Export selected patches to actions

closed
nobody
None
5
2007-11-01
2007-10-04
Florian Festi
No

While it is currently possible to define customized actions they have only limited use as they cannot access any of the GUI elements. To pass information about the GUI to the actions environment variables can be used.

The attached patch add support for adding environment variables to the whole stack of classes that are involved in executing the actions. Additionally it sets two environment variables CURRENT_PATCH and PATCHES which refer to the patch SHAs selected in the GUI.
The patch is against the QT3 qgit repository.

As further improvements more vars could be added - especially filtered list of patches - as only already/not yet applied patches and so on.

Discussion

1 2 > >> (Page 1 of 2)
  • Florian Festi
    Florian Festi
    2007-10-15

    Logged In: YES
    user_id=1736372
    Originator: YES

    The new patch reverses the order of PATCHES and and introduces PATCHES_LASTFIRST which contains the old order.

    I now have two actions that already work and are useful:

    Cherry Pick:
    #!/bin/bash
    for PATCH in $PATCHES ; do
    git cherry-pick $PATCH;
    done

    Cherry pick -n:
    #!/bin/bash
    for PATCH in $PATCHES ; do
    git cherry-pick -n $PATCH;
    done
    File Added: qgit-env_for_actions-2.diff

     
  • Marco Costalba
    Marco Costalba
    2007-10-27

    lightly massaged patch

     
  • Marco Costalba
    Marco Costalba
    2007-10-27

    Logged In: YES
    user_id=1286020
    Originator: NO

    From Qt3 documentation:

    QProcess::launch ( const QByteArray & buf, QStringList * env = 0 )

    "If env is null, then the process is started with the same environment as the starting process. If env is non-null, then the values in the string list are interpreted as environment setttings of the form key=value and the process is started with these environment settings."

    This means that your proposed patch would be broken for people that uses some environment variable hinerithed from starting process, i.e. qgit. Problem is that if env != NULL then current environment setttings are overwritten NOT added as you probably may want.

    Anyhow I like your patch in principle, I have also fixed a leak and done sone coding style triviality, in case you are interested in fixing the "env overwrite" issue the attached file could be a good base from where to start.

    Thanks
    Marco

    P.S: Please e-mail me at mcostalba@gmail.com instead of this seldom checked sourceforge account

    File Added: qgit-env_for_actions-3.diff

     
  • Marco Costalba
    Marco Costalba
    2007-11-01

    • status: open --> closed
     
  • Marco Costalba
    Marco Costalba
    2007-11-01

    Logged In: YES
    user_id=1286020
    Originator: NO

    Patch pushed upstream. Will be included in next release.

     
  • I guess however that the fact that I obviously posted a duplicate request, seems to indicate that this feature of qgit isn't yet sufficiently documented, or at least the corresponding variables should probably be available/exposed in the actions dialog, so that users can simply "pick" them from a list to customize their actions?

    Also, some of my suggestions in the other item still seem relevant.

     
  • Thinking some more about this, there are now apparently two ways to customize actions: using these environment variables provided by qgit, and by having qqit ask for parameters that are added to an action, right?

    Another thing that would be very useful and powerful to have would be a way to define variables in actions that are to be filled in by the user before running an action (customization of actions), so a combination of the current approach that would allow users to set the value of custom variables that are NOT automatically preset by the UI, but that can be dynamically customized by the user whenever an action is run.

    So, such variables could for example have a different syntax so that qgit can easily recognize them and tell that they are different from standard variables, so that it can provide a dialog to allow the user to customize the action by filling in these variables with custom values before running a script.

    This could for example look like this in scripts:

    $AUTHOR:STRING("Author:")

    So that qgit finds a variable token with an appended colon, indicating that it is a runtime-configurable variable of type "string" that is to be asked for, with the label "Author". This could then be used in a simple dialog where a label and textbox are shown asking for an author to be provided.

    So, once this is filled in by the user, the script and all such variables could be simplified by truncating the string beginning with the ':' before running the script.

    While providing a "type" may seem unnecessary and redundant for the moment, it's probably a good idea to take this approach into consideration because it would allow qgit -at some point- to optionally also validate the data that is provided by author before running a script.

    Similarly, there could be 3-5 additional types like NUMBER, DATE, EMAIL, URL etc.

    Initially, one simple string type would probably be sufficient - but later on, having better control over the type of data that is provided (validated) could surely be helpful.

    In addition, more complex actions may not only require static and such dynamically defined variables, but also a way to get a listing (dropdown box) of repository-specific data (think: TAGS, BRANCHES, HEADS) to allow users to pick one item from such a list - this, could also work using the proposed syntax of doing something like:

    $MYBRANCH:BRANCHES("Pick a branch")
    $MYTAG:TAGS("Pick a tag")
    $MYHEAD:HEADS("Pick a head")

    So that qgit would display a dropdown box that is populated with all available branches and allow the user to pick a branch from it, so that the corresponding branch is then automatically filled in into the "MYBRANCH" variable.

    Of course, introducing such variables and such a scheme would mean that scripts would need to be slightly "pre-processed" by qgit before running them, but this would enable very powerful additions and usage.

    Maybe, users could optionally set an attribute/checkbox to indicate if a script is a "raw" shell script or a qgit-specific script that needs to be parsed for such scripting enhancements?

    What do you guys think?

    - Boris

     
  • I have now looked into the both qgit repositories (SF.net & kernel.org) and it seems this feature never made it into the latest version of qgit, is that right?

    If that's the case, I think this is very unfortunate - this would indeed be a very useful addition, certainly not only from my point of view?

    What was the reason for not porting this to the qgit4 tree?
    Also, is there any interest to re-implement the support for this again?

    Thanks,

    Boris

     
1 2 > >> (Page 1 of 2)