* 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: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 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
* 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 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
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).