* qgit idea: interface for cherry-picking
@ 2006-07-02 19:01 Jakub Narebski
2006-07-02 21:33 ` Marco Costalba
0 siblings, 1 reply; 18+ messages in thread
From: Jakub Narebski @ 2006-07-02 19:01 UTC (permalink / raw)
To: git
Currently in qgit one can git-format-patch a commit. It woul be nice if one
would be able to git-cherry-pick and git-cherry-pick -n a commit (denoting
the head, i.e. where cherry pick would be applied to). It would be very
usefull in reordering patches (cleaning up history).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: qgit idea: interface for cherry-picking
2006-07-02 19:01 qgit idea: interface for cherry-picking Jakub Narebski
@ 2006-07-02 21:33 ` Marco Costalba
2006-07-02 21:46 ` Jakub Narebski
0 siblings, 1 reply; 18+ messages in thread
From: Marco Costalba @ 2006-07-02 21:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
On 7/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Currently in qgit one can git-format-patch a commit. It woul be nice if one
> would be able to git-cherry-pick and git-cherry-pick -n a commit (denoting
> the head, i.e. where cherry pick would be applied to). It would be very
> usefull in reordering patches (cleaning up history).
>
> --
Currently in qgit you can git-format-patch a commit series and git-am
a given patch file series.
This can be done transparently with a drag & drop mechanic:
1) Open the source repository
2) Then open a new qgit instance (File->Open in a new window...)
3) Open the destination repository in the new qgit window
4) Drag & drop selected commits (multi selection in supported) from
source to destination.
I normally use this instead of git-cherry-pick that, I admit, I don't
know very well, so please I need some more hints on how to upgrade
this behaviour introducing git.cherry-pick support.
Marco
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: qgit idea: interface for cherry-picking
2006-07-02 21:33 ` Marco Costalba
@ 2006-07-02 21:46 ` Jakub Narebski
2006-07-02 22:04 ` Marco Costalba
0 siblings, 1 reply; 18+ messages in thread
From: Jakub Narebski @ 2006-07-02 21:46 UTC (permalink / raw)
To: git
Marco Costalba wrote:
> On 7/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Currently in qgit one can git-format-patch a commit. It woul be nice
>> if one would be able to git-cherry-pick and git-cherry-pick -n a commit
>> (denoting the head, i.e. where cherry pick would be applied to). It would
>> be very usefull in reordering patches (cleaning up history).
>
> Currently in qgit you can git-format-patch a commit series and git-am
> a given patch file series.
> This can be done transparently with a drag & drop mechanic:
>
> 1) Open the source repository
> 2) Then open a new qgit instance (File->Open in a new window...)
> 3) Open the destination repository in the new qgit window
> 4) Drag & drop selected commits (multi selection in supported) from
> source to destination.
Does multi selection commits all selected commits as one merged commit?
> I normally use this instead of git-cherry-pick that, I admit, I don't
> know very well, so please I need some more hints on how to upgrade
> this behaviour introducing git.cherry-pick support.
I use git-cherry-pick -n to join few patches into one, or with editing the
result to split one patch/commit into few smaller.
git-cherry-pick [-n] <commit> picks up a commit and drops it on top of
current branch. I'd like to see it in context menu for current commit,
i.e. "cherry-pick to <head>", where <head> will be replaced by current
branch name, or/and "cherry-pick -n to <head>".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: qgit idea: interface for cherry-picking
2006-07-02 21:46 ` Jakub Narebski
@ 2006-07-02 22:04 ` Marco Costalba
2006-07-02 22:54 ` Jakub Narebski
0 siblings, 1 reply; 18+ messages in thread
From: Marco Costalba @ 2006-07-02 22:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
On 7/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Marco Costalba wrote:
>
> > On 7/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
> >> Currently in qgit one can git-format-patch a commit. It woul be nice
> >> if one would be able to git-cherry-pick and git-cherry-pick -n a commit
> >> (denoting the head, i.e. where cherry pick would be applied to). It would
> >> be very usefull in reordering patches (cleaning up history).
> >
> > Currently in qgit you can git-format-patch a commit series and git-am
> > a given patch file series.
> > This can be done transparently with a drag & drop mechanic:
> >
> > 1) Open the source repository
> > 2) Then open a new qgit instance (File->Open in a new window...)
> > 3) Open the destination repository in the new qgit window
> > 4) Drag & drop selected commits (multi selection in supported) from
> > source to destination.
>
> Does multi selection commits all selected commits as one merged commit?
>
No. Currently it's just a shortcut for git-format-patch --> git-am
> > I normally use this instead of git-cherry-pick that, I admit, I don't
> > know very well, so please I need some more hints on how to upgrade
> > this behaviour introducing git.cherry-pick support.
>
> I use git-cherry-pick -n to join few patches into one, or with editing the
> result to split one patch/commit into few smaller.
>
> git-cherry-pick [-n] <commit> picks up a commit and drops it on top of
> current branch. I'd like to see it in context menu for current commit,
> i.e. "cherry-pick to <head>", where <head> will be replaced by current
> branch name, or/and "cherry-pick -n to <head>".
>
>
>From the git-cherry-pick documentation I see -n option "applies the
change necessary to cherry-pick the named commit to your working tree,
but does not make the commit"
What do you think about this:
When dropping the selected commits, instead of creating new commits,
appears a message box with something like "Do you want to apply the
commits on top of your current branch or on your working directory?"
Sounds good for you? Or you still prefer the context menu?
In the latter case, if I have understood correctly, you are limited to
cherry-pick among branches and/or working directory of the _same_
repository.
Marco
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: qgit idea: interface for cherry-picking
2006-07-02 22:04 ` Marco Costalba
@ 2006-07-02 22:54 ` Jakub Narebski
2006-07-03 5:45 ` Marco Costalba
0 siblings, 1 reply; 18+ messages in thread
From: Jakub Narebski @ 2006-07-02 22:54 UTC (permalink / raw)
To: git
Marco Costalba wrote:
> What do you think about this:
>
> When dropping the selected commits, instead of creating new commits,
> appears a message box with something like "Do you want to apply the
> commits on top of your current branch or on your working directory?"
>
> Sounds good for you? Or you still prefer the context menu?
> In the latter case, if I have understood correctly, you are limited to
> cherry-pick among branches and/or working directory of the _same_
> repository.
Yes, git-cherry-pick works only between commits in the same repository,
as it use merge (first "simple", i.e. git-read-tree -m -u --aggresive, if
fails tries "automatic" i.e. git-merge-index -o git-merge-one-file -a, then
git-write-tree), as opposed to git-format-patch and git-am or git-apply,
which can work across repositories.
What I really want is "no-commit" of drag'n'dropped, or exported and applied
commits/patches (although interface to cherry-pick would be nice, even if
cherry-pick is limited), so I'd like message box with "Do you want to
commit selected patches?" when dropping commits, or something like that.
Unfortunately git-am doesn't have --no-commit flag, but one could emulate it
with git-reset after git-am a patch, I think.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: qgit idea: interface for cherry-picking
2006-07-02 22:54 ` Jakub Narebski
@ 2006-07-03 5:45 ` Marco Costalba
2006-07-03 6:42 ` Junio C Hamano
0 siblings, 1 reply; 18+ messages in thread
From: Marco Costalba @ 2006-07-03 5:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, junkio
On 7/3/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Marco Costalba wrote:
>
> > What do you think about this:
> >
> > When dropping the selected commits, instead of creating new commits,
> > appears a message box with something like "Do you want to apply the
> > commits on top of your current branch or on your working directory?"
> >
> > Sounds good for you? Or you still prefer the context menu?
> > In the latter case, if I have understood correctly, you are limited to
> > cherry-pick among branches and/or working directory of the _same_
> > repository.
>
> Yes, git-cherry-pick works only between commits in the same repository,
> as it use merge (first "simple", i.e. git-read-tree -m -u --aggresive, if
> fails tries "automatic" i.e. git-merge-index -o git-merge-one-file -a, then
> git-write-tree), as opposed to git-format-patch and git-am or git-apply,
> which can work across repositories.
>
> What I really want is "no-commit" of drag'n'dropped, or exported and applied
> commits/patches (although interface to cherry-pick would be nice, even if
> cherry-pick is limited), so I'd like message box with "Do you want to
> commit selected patches?" when dropping commits, or something like that.
> Unfortunately git-am doesn't have --no-commit flag, but one could emulate it
> with git-reset after git-am a patch, I think.
>
When I need to modify the patch/revision before to import I usaually
drag&drop and then I call git-reset --soft, then I edit working
directory and commit again.
Perhaps I can automate this in case the user answers "No, apply to
working dir only" to the message box.
Is it the correct way to go or is better to wait for a --no-commit
flag in git-am?
Junio?
Thanks
Marco
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: qgit idea: interface for cherry-picking
2006-07-03 5:45 ` Marco Costalba
@ 2006-07-03 6:42 ` Junio C Hamano
2006-07-03 11:18 ` Marco Costalba
0 siblings, 1 reply; 18+ messages in thread
From: Junio C Hamano @ 2006-07-03 6:42 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
"Marco Costalba" <mcostalba@gmail.com> writes:
> When I need to modify the patch/revision before to import I usaually
> drag&drop and then I call git-reset --soft, then I edit working
> directory and commit again.
These days, I tend to just let "am" or "pull" do its thing, edit
working tree and retest, and run "commit --amend". Before we
added "commit --amend", I used to do soft reset and recommit
like you described above. One advantage of "commit --amend" is
that it can even amend a merge, but I do not think it applies to
what Jakub wants in this thread.
> Perhaps I can automate this in case the user answers "No, apply to
> working dir only" to the message box.
>
> Is it the correct way to go or is better to wait for a --no-commit
> flag in git-am?
Probably your "git-am --no-commit" would stop after applying one
patch (the first one in the sequence) but before writing a
commit. We already sometimes do that when the patch does not
apply cleanly, so I do not offhand have much objection against
adding such a flag.
I think the workflow to continue after "git-am --no-commit" will
be quite similar to what you would do when "git-am --3way" stops
with conflicts. In order to continue from there, you would do
whatever is needed to bring the index into the shape you wanted
to have if the patch applied cleanly. Then "git am --resolved".
Perhaps something like the attached. If somebody finds it
useful, after testing it out, please kick it back to me, perhaps
with a paragraph or two to properly document it.
-- >8 --
git-am --fail
The new flag prevents a new commit from being made even when the
patch applies cleanly. This gives you an opportunity to further
fix up the change in your working tree before making the final
commit.
In order to continue, do whatever is needed to bring the index
into the shape you wanted to have if the patch applied cleanly,
and run "git am --resolved".
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-am.sh b/git-am.sh
index 679045a..77d8cd9 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -3,7 +3,7 @@ #
# Copyright (c) 2005, 2006 Junio C Hamano
USAGE='[--signoff] [--dotest=<dir>] [--utf8] [--binary] [--3way]
- [--interactive] [--whitespace=<option>] <mbox>...
+ [--fail] [--interactive] [--whitespace=<option>] <mbox>...
or, when resuming [--skip | --resolved]'
. git-sh-setup
@@ -91,7 +91,7 @@ fall_back_3way () {
}
prec=4
-dotest=.dotest sign= utf8= keep= skip= interactive= resolved= binary= ws= resolvemsg=
+dotest=.dotest sign= utf8= keep= skip= interactive= resolved= binary= ws= resolvemsg= fail=
while case "$#" in 0) break;; esac
do
@@ -109,6 +109,9 @@ do
-b|--b|--bi|--bin|--bina|--binar|--binary)
binary=t; shift ;;
+ -f|--f|--fa|--fai|--fail)
+ fail=t; shift ;;
+
-3|--3|--3w|--3wa|--3way)
threeway=t; shift ;;
-s|--s|--si|--sig|--sign|--signo|--signof|--signoff)
@@ -401,6 +404,10 @@ do
then
echo Patch failed at $msgnum.
stop_here_user_resolve $this
+ elif test -n "$fail"
+ then
+ echo Stopped at $msg per user request
+ stop_here_user_resolve $this
fi
if test -x "$GIT_DIR"/hooks/pre-applypatch
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: qgit idea: interface for cherry-picking
2006-07-03 6:42 ` Junio C Hamano
@ 2006-07-03 11:18 ` Marco Costalba
2006-07-03 20:03 ` Junio C Hamano
0 siblings, 1 reply; 18+ messages in thread
From: Marco Costalba @ 2006-07-03 11:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
On 7/3/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > When I need to modify the patch/revision before to import I usaually
> > drag&drop and then I call git-reset --soft, then I edit working
> > directory and commit again.
>
> These days, I tend to just let "am" or "pull" do its thing, edit
> working tree and retest, and run "commit --amend". Before we
> added "commit --amend", I used to do soft reset and recommit
> like you described above. One advantage of "commit --amend" is
> that it can even amend a merge, but I do not think it applies to
> what Jakub wants in this thread.
>
I cannot test your patch now, so I'm just guessing, what if we have a
series of patches?
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
As example, if B modify the same file of A then could happen that in
the latter case git-am --fail B stops with conflicts because the
working dir is not synced with the index (this happens only in the
latter case) ?
Put in other words, I don't know if the two procedures are
_equivalent_ because in the first case you operate under the
assumption that working dir and index are always synced before and
after to apply, in the second case this assumption is broken so I
don't know if this could have side effects.
Marco
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: qgit idea: interface for cherry-picking
2006-07-03 11:18 ` Marco Costalba
@ 2006-07-03 20:03 ` Junio C Hamano
2006-07-04 6:22 ` Marco Costalba
0 siblings, 1 reply; 18+ messages in thread
From: Junio C Hamano @ 2006-07-03 20:03 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
"Marco Costalba" <mcostalba@gmail.com> 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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: qgit idea: interface for cherry-picking
2006-07-03 20:03 ` Junio C Hamano
@ 2006-07-04 6:22 ` Marco Costalba
2006-07-04 6:39 ` Jakub Narebski
2006-07-04 6:41 ` Junio C Hamano
0 siblings, 2 replies; 18+ messages in thread
From: Marco Costalba @ 2006-07-04 6:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On 7/3/06, Junio C Hamano <junkio@cox.net> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: qgit idea: interface for cherry-picking
2006-07-04 6:22 ` Marco Costalba
@ 2006-07-04 6:39 ` Jakub Narebski
2006-07-04 11:58 ` Marco Costalba
2006-07-04 6:41 ` Junio C Hamano
1 sibling, 1 reply; 18+ messages in thread
From: Jakub Narebski @ 2006-07-04 6:39 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: qgit idea: interface for cherry-picking
2006-07-04 6:22 ` Marco Costalba
2006-07-04 6:39 ` Jakub Narebski
@ 2006-07-04 6:41 ` Junio C Hamano
2006-07-04 7:02 ` Jakub Narebski
2006-07-04 11:21 ` Marco Costalba
1 sibling, 2 replies; 18+ messages in thread
From: Junio C Hamano @ 2006-07-04 6:41 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
"Marco Costalba" <mcostalba@gmail.com> writes:
>> 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'.
Yes, either you (1) need to make sure the user is aware what
underlying git commands QGit runs for them, so that the user
knows what workflow to follow when the procedure needs to go
manual, or (2) hide the underlying git commands QGit runs for
users, but then you need to make QGit aware of what workflow to
follow when the procedure needs to go manual, and guide the user
through that workflow. I think either is fine approach;
personally I prefer transparent tools that does (1), which is
the impression I am getting from your description of QGit.
If you take route (1), using "am --fail" number of times
involves QGit runs "am --fail" once, guide user to fix things up
_and_ give control back to QGit, then you run the next "am
--fail", etc, which would be quite cumbersome to implement. But
running multiple am and do reset soft to roll back needed number
of parents might be easier option to implement in QGit, but you
still have the same "you give the control to the user but then
you have to take the control away to proceed" problem when the
patch does not apply cleanly somewhere (you let the user to hand
resolve and say "am --resolved", but then when the series is
depleted, somebody has to run "reset --soft" to roll N commits
back to realize what you wanted to do, so at that point QGit
somehow needs to take control back).
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: qgit idea: interface for cherry-picking
2006-07-04 6:41 ` Junio C Hamano
@ 2006-07-04 7:02 ` Jakub Narebski
2006-07-04 11:21 ` Marco Costalba
1 sibling, 0 replies; 18+ messages in thread
From: Jakub Narebski @ 2006-07-04 7:02 UTC (permalink / raw)
To: git
Junio C Hamano wrote:
> [...] (you let the user to hand
> resolve and say "am --resolved", but then when the series is
> depleted, somebody has to run "reset --soft" to roll N commits
> back to realize what you wanted to do, so at that point QGit
> somehow needs to take control back).
Would it be easier if QGit for "am --squash" generated lightweight temporary
tag before first git-am, so one would need not to remember N for "reset
--soft"?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: qgit idea: interface for cherry-picking
2006-07-04 6:41 ` Junio C Hamano
2006-07-04 7:02 ` Jakub Narebski
@ 2006-07-04 11:21 ` Marco Costalba
2006-07-04 18:23 ` Marco Costalba
1 sibling, 1 reply; 18+ messages in thread
From: Marco Costalba @ 2006-07-04 11:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
On 7/4/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
>
> Yes, either you (1) need to make sure the user is aware what
> underlying git commands QGit runs for them, so that the user
> knows what workflow to follow when the procedure needs to go
> manual, or (2) hide the underlying git commands QGit runs for
> users, but then you need to make QGit aware of what workflow to
> follow when the procedure needs to go manual, and guide the user
> through that workflow. I think either is fine approach;
> personally I prefer transparent tools that does (1), which is
> the impression I am getting from your description of QGit.
>
Yes, I prefer way (1) too. QGit as an error reporting infrastructure
to always report by a message box arguments (starting from 0) of
offending command, be it native git or not.
> If you take route (1), using "am --fail" number of times
> involves QGit runs "am --fail" once, guide user to fix things up
> _and_ give control back to QGit, then you run the next "am
> --fail", etc, which would be quite cumbersome to implement. But
> running multiple am and do reset soft to roll back needed number
> of parents might be easier option to implement in QGit, but you
> still have the same "you give the control to the user but then
> you have to take the control away to proceed" problem when the
> patch does not apply cleanly somewhere (you let the user to hand
> resolve and say "am --resolved", but then when the series is
> depleted, somebody has to run "reset --soft" to roll N commits
> back to realize what you wanted to do, so at that point QGit
> somehow needs to take control back).
>
>
I have started to implement the feature suggested by Jakub (patch in
working dir only, not committed). The core is a loop of git-am, one
for each patch to import, followed by a:
git-reset --mixed HEAD~<Num of succesfully applied patches>
To note that the above git-reset command is _always_ run be the patch
series apply successfully be it fails at some point, so that in any
case the tree is not dirty up, and you have the working tree with the
information you need in case of manual fixup.
I will plan to push as soon I'm able to reach a "pushable site" ;-)
Comments? could work? not consistent?
Marco
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: qgit idea: interface for cherry-picking
2006-07-04 6:39 ` Jakub Narebski
@ 2006-07-04 11:58 ` Marco Costalba
2006-07-04 13:29 ` Jakub Narebski
0 siblings, 1 reply; 18+ messages in thread
From: Marco Costalba @ 2006-07-04 11:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
On 7/4/06, Jakub Narebski <jnareb@gmail.com> wrote:
> 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...
>
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: qgit idea: interface for cherry-picking
2006-07-04 11:58 ` Marco Costalba
@ 2006-07-04 13:29 ` Jakub Narebski
2006-07-04 18:38 ` Marco Costalba
0 siblings, 1 reply; 18+ messages in thread
From: Jakub Narebski @ 2006-07-04 13:29 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: qgit idea: interface for cherry-picking
2006-07-04 11:21 ` Marco Costalba
@ 2006-07-04 18:23 ` Marco Costalba
0 siblings, 0 replies; 18+ messages in thread
From: Marco Costalba @ 2006-07-04 18:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
On 7/4/06, Marco Costalba <mcostalba@gmail.com> wrote:
> On 7/4/06, Junio C Hamano <junkio@cox.net> wrote:
> > "Marco Costalba" <mcostalba@gmail.com> writes:
> >
>
> I have started to implement the feature suggested by Jakub (patch in
> working dir only, not committed).
Ok. I have pushed two patches, the first with support for applying a
patch series in working dir only, i.e. without to create new commits,
the second to add "branch that a rev belongs to" info as in gitk, near
tags information was already there.
The difference with gitk is that only loaded branch/tags are
considered, this is to better scale.
Anyhow, due to little tricks ;-) , indexing is very fast, about 250ms
to index the whole Linux tree on my box.
Marco
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: qgit idea: interface for cherry-picking
2006-07-04 13:29 ` Jakub Narebski
@ 2006-07-04 18:38 ` Marco Costalba
0 siblings, 0 replies; 18+ messages in thread
From: Marco Costalba @ 2006-07-04 18:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
On 7/4/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Marco Costalba wrote:
>
> >
> > 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
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2006-07-04 18:38 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-02 19:01 qgit idea: interface for cherry-picking Jakub Narebski
2006-07-02 21:33 ` Marco Costalba
2006-07-02 21:46 ` Jakub Narebski
2006-07-02 22:04 ` Marco Costalba
2006-07-02 22:54 ` Jakub Narebski
2006-07-03 5:45 ` Marco Costalba
2006-07-03 6:42 ` Junio C Hamano
2006-07-03 11:18 ` Marco Costalba
2006-07-03 20:03 ` Junio C Hamano
2006-07-04 6:22 ` Marco Costalba
2006-07-04 6:39 ` Jakub Narebski
2006-07-04 11:58 ` Marco Costalba
2006-07-04 13:29 ` Jakub Narebski
2006-07-04 18:38 ` Marco Costalba
2006-07-04 6:41 ` Junio C Hamano
2006-07-04 7:02 ` Jakub Narebski
2006-07-04 11:21 ` Marco Costalba
2006-07-04 18:23 ` Marco Costalba
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).