Re: qgit idea: interface for cherry-picking

"Marco Costalba" [off-list ref] writes:

I cannot test your patch now, so I'm just guessing, what if we have a
series of patches?

The patch stops at each patch.  I am primarily interested in
keeping "git-am" usable from command line while making it easy
to use from other tools.

The expected use for the patch you are responding to is that
after the first application with --fail the user has an
opportunity to fix the result up but needs to create a commit by
rerunning "git-am" (or just drop that by resetting the index and
saying "git-am --skip").

Is it possible that for two patches A and B happens that

git-am A
git-am B
git-reset --soft HEAD^^

gives a different result then

git-am --fail A
git-am --fail B

If you had a series of patches chosen inside your GUI and
squash-apply them all, two full am with soft reset to the
original state would be the easiest, if and only if both patch
applications do not fail.  If patch A does not apply for
whatever reason, you have to guide your user through the patch
adjustment process before applying B, regardless of the reason
why the patch application failed (either A did not apply
cleanly, or you gave --fail to the command).

The main question is what you would let your users do and how
you would guide them through the process, when the application
of an earlier patch in the series fails.  I think it is a
secondary implementation detail which of "git-am", "git-am
--fail" or "git-apply" to implement that process.

On 7/3/06, Junio C Hamano [off-list ref] wrote:

If you had a series of patches chosen inside your GUI and
squash-apply them all, two full am with soft reset to the
original state would be the easiest, if and only if both patch
applications do not fail.  If patch A does not apply for
whatever reason, you have to guide your user through the patch
adjustment process before applying B, regardless of the reason
why the patch application failed (either A did not apply
cleanly, or you gave --fail to the command).

The main question is what you would let your users do and how
you would guide them through the process, when the application
of an earlier patch in the series fails.  I think it is a
secondary implementation detail which of "git-am", "git-am
--fail" or "git-apply" to implement that process.

QGit is not supposed to be a GUI replacement of git UI. QGit only let
users quickly call some commonly used commands. The process of error
recovering, conflicts resolve and any other complication that could
involve more the one main flow of processing are outside the scope.
QGit simply leaves the job to native git tools any time there
something 'outside tha main flow'.

So in case a patch does not apply a message feedback is returned and
the process is terminated. All the not qgit generated intermediate
files are left at their places and is up to the user fix the things
up, possibly using native git commands.

QGit does not play magic. If something goes wrong it simply stops.

     Marco

Marco Costalba wrote:

QGit is not supposed to be a GUI replacement of git UI. QGit only let
users quickly call some commonly used commands. [...]

It's a pity. Doing some of commands from visual history viewer, with view of
branches etc. would be so much easier: like bisect, rebasing, cherry
picking, reverting a commit...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

On 7/4/06, Jakub Narebski [off-list ref] wrote:

Marco Costalba wrote:

quoted

QGit is not supposed to be a GUI replacement of git UI. QGit only let
users quickly call some commonly used commands. [...]

It's a pity. Doing some of commands from visual history viewer, with view of
branches etc. would be so much easier: like bisect, rebasing, cherry
picking, reverting a commit...

In the past weeks I (with Pavel support) have implemented and pushed
the concept of "custom actions".

Is it possible to associate commands sequences, scripts and anything
else executable to a custom action. Actions can be called and run from
menu entry and corresponding output is grabbed by a terminal window.

Instead of hard code each git-native command, this way you have a
flexible framework to add shortcuts and menu entry for anything you
would like to be a click away. BTW I use this for stuff like git pull,
but also for 'make' and 'make install' because you have a window
terminal for feedback.

There is also the possibility to input command line parameters before
to run, useful, as example for a git pull action that asks for source
repository to pull from.

Is this something that can fulfill you request? do you need something
different?  perhaps something as a "default to current selected SHA as
input argument" flag.

  Marco

Marco Costalba wrote:

In the past weeks I (with Pavel support) have implemented and pushed
the concept of "custom actions".

Is it possible to associate commands sequences, scripts and anything
else executable to a custom action. Actions can be called and run from
menu entry and corresponding output is grabbed by a terminal window.

Instead of hard code each git-native command, this way you have a
flexible framework to add shortcuts and menu entry for anything you
would like to be a click away. BTW I use this for stuff like git pull,
but also for 'make' and 'make install' because you have a window
terminal for feedback.

There is also the possibility to input command line parameters before
to run, useful, as example for a git pull action that asks for source
repository to pull from.

Is this something that can fulfill you request? do you need something
different?  perhaps something as a "default to current selected SHA as
input argument" flag.

It would be nice (I don't know if feasible) that either to provide some kind
of parameters substitution in the likes of "%head" in the invocation line
for a script to be expanded to the sha1 or name of head of currently
selected commit.

Other solution would be to provide GUI for input of command line parameters,
e.g. combo-box (i.e. editable text field, with provided list of default
values) for repository (populated from .git/branches and .git/remotes),
option to select commit or use selected commit for head ref or just commit
ref, etc...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

On 7/4/06, Jakub Narebski [off-list ref] wrote:

Marco Costalba wrote:

quoted

Is this something that can fulfill you request? do you need something
different?  perhaps something as a "default to current selected SHA as
input argument" flag.

It would be nice (I don't know if feasible) that either to provide some kind
of parameters substitution in the likes of "%head" in the invocation line
for a script to be expanded to the sha1 or name of head of currently
selected commit.

Well, I think that the indiscussed champion in this field is git-rev-parse

Please note that an action have not to be _one_  git command, but you
can assign a command sequence to an action, if the first command is
git-rev-parse probably you have what you need.

I have to better explain some implemantation details. In case a multi
line text is set as an action content,  qgit wraps up the content in a
temporary script and run the script as a whole.
So you can use anything inside your action definition.

NOTE: this is possible because the input parameters are _always_
appended to the first line command only.

As example if the action 'test' is defined as:

echo
echo 2
echo 3

When you run 'test' and insert  '1'  when prompted for input
parameters the output will be:
1
2
3

Hope this helps.

    Marco