{"thread":{"id":"9440","subject":"[PATCH] Mod. gitk to support REBASE (with stash support).","startedAt":"2007-08-08T18:33:48Z","lastAt":"2007-08-09T07:55:00Z","messageCount":10,"participants":["Alexandre Bourget","Peter Baumann","Johannes Schindelin","Junio C Hamano","David Kastrup","Shawn O. Pearce"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"50207","messageId":"1186598028457-git-send-email-alexandre.bourget@savoirfairelinux.com","threadId":"9440","inReplyTo":null,"subject":"[PATCH] Mod. gitk to support REBASE (with stash support).","fromName":"Alexandre Bourget","fromEmail":"alexandre.bourget@savoirfairelinux.com","sentAt":"2007-08-08T18:33:48Z","receivedAt":"2007-08-08T18:33:48Z","isPatch":true,"sender":{"key":"alexandre.bourget@savoirfairelinux.com","avatar":null},"body":"---\nAdds a context menu for commits, so that a 'rebase' can be done.\n\nOptionally, it will ask if you want to 'stash' current work before doing so.\n\nTODO: better error handling.\n\n gitk | 38 ++++++++++++++++++++++++++++++++++++++\n 1 files changed, 38 insertions(+), 0 deletions(-)\n\ndiff --git a/gitk b/gitk\nindex f74ce51..558b7bb 100755\n--- a/gitk\n+++ b/gitk\n@@ -898,6 +898,8 @@ proc makewindow {} {\n \t-command cherrypick\n $rowctxmenu add command -label \"Reset HEAD branch to here\" \\\n \t-command resethead\n+ $rowctxmenu add command -label \"Rebase HEAD branch on this commit\" \\\n+\t-command rebasehead\n \n set fakerowmenu .fakerowmenu\n menu $fakerowmenu -tearoff 0\n@@ -5593,6 +5595,7 @@ proc rowmenu {x y id} {\n if {$id ne $nullid && $id ne $nullid2} {\n \tset menu $rowctxmenu\n \t$menu entryconfigure 7 -label \"Reset $mainhead branch to here\"\n+\t$menu entryconfigure 8 -label \"Rebase $mainhead branch on this commit\"\n } else {\n \tset menu $fakerowmenu\n }\n@@ -5972,6 +5975,41 @@ proc cherrypick {} {\n notbusy cherrypick\n }\n \n+proc rebasehead {} {\n+ global mainheadid mainhead rowmenuid confirm_ok\n+ global localfrow localirow\n+\n+\n+ set head $mainhead\n+ set id $rowmenuid\n+\n+ set confirm_ok 0\n+\n+ if {$localfrow != -1 || $localirow != -1} {\n+\t# There's something to stash.\n+\tset confirm_ok [confirm_popup \"There are some local modifications.\\n\\nDo you want to git-stash any changes before doing a rebase?\\n\\n(They will be reapplied right after, and stash will be *cleared*)\"]\n+ }\n+\n+ nowbusy rebasehead\n+ update\n+\n+ if {$confirm_ok} {\n+\texec git stash save\n+ }\n+\n+ # TODO: error handling.\n+ exec git rebase $id\n+\n+ if {$confirm_ok} {\n+\texec git stash apply stash@{0}\n+\texec git stash clear\n+ }\n+\n+ notbusy rebasehead\n+ updatecommits\n+}\n+\n+\n proc resethead {} {\n global mainheadid mainhead rowmenuid confirm_ok resettype\n global showlocalchanges\n-- \n1.5.3.rc4.24.g5b56a\n"},{"id":"50212","messageId":"20070808193130.GC27470@xp.machine.xx","threadId":"9440","inReplyTo":"1186598028457-git-send-email-alexandre.bourget@savoirfairelinux.com","subject":"Re: [PATCH] Mod. gitk to support REBASE (with stash support).","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-08-08T19:31:30Z","receivedAt":"2007-08-08T19:31:30Z","isPatch":true,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Wed, Aug 08, 2007 at 02:33:48PM -0400, Alexandre Bourget wrote:\n> ---\n> Adds a context menu for commits, so that a 'rebase' can be done.\n> \n> Optionally, it will ask if you want to 'stash' current work before doing so.\n> \n> TODO: better error handling.\n> \n[...long patch ...]\n> + # TODO: error handling.\n> + exec git rebase $id\n> +\n> + if {$confirm_ok} {\n> +\texec git stash apply stash@{0}\n\n'git stash apply' could fail with merge conflicts ...\n\n> +\texec git stash clear\n\nand here you are throwing the stash away!\n\n> + }\n> +\n> + notbusy rebasehead\n> + updatecommits\n> +}\n\n-Peter\n"},{"id":"50219","messageId":"Pine.LNX.4.64.0708082141170.21916@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"9440","inReplyTo":"1186598028457-git-send-email-alexandre.bourget@savoirfairelinux.com","subject":"Re: [PATCH] Mod. gitk to support REBASE (with stash support).","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-08T19:42:19Z","receivedAt":"2007-08-08T19:42:19Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 8 Aug 2007, Alexandre Bourget wrote:\n\n> ---\n> Adds a context menu for commits, so that a 'rebase' can be done.\n> \n> Optionally, it will ask if you want to 'stash' current work before doing so.\n> \n\nYou want something like this as a commit message, _not_ between \"---\" and \ndiffstat.\n\nGeneral question: should this not be in git-gui rather than gitk? Gitk as \nof now is really more a viewing tool.\n\nCiao,\nDscho\n"},{"id":"50221","messageId":"7vvebp3irz.fsf@assigned-by-dhcp.cox.net","threadId":"9440","inReplyTo":"1186598028457-git-send-email-alexandre.bourget@savoirfairelinux.com","subject":"Re: [PATCH] Mod. gitk to support REBASE (with stash support).","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-08T19:53:20Z","receivedAt":"2007-08-08T19:53:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alexandre Bourget \nwrites:\n\n> ---\n> Adds a context menu for commits, so that a 'rebase' can be done.\n>\n> Optionally, it will ask if you want to 'stash' current work before doing so.\n>\n> TODO: better error handling.\n\nPlease do not discard a commit log message by placing them after\nthe three-dashes. A good commit message would be of this form:\n\n - A single line to summarize what it does (goes to Subject);\n\n - A blank line (paragraph break);\n\n - A paragraph or more that elaborate on the above summary, if\n needed, and defend why the change is a good idea; especially\n if you considered other alternatives, a comparison to justify\n your choice.\n\nThis is largely up to Paulus, but I think anything that\nupdates the repository should go to git-gui, not gitk. The\nlatter is primarily a viewer.\n"},{"id":"50225","messageId":"85lkclrdpr.fsf@lola.goethe.zz","threadId":"9440","inReplyTo":"Pine.LNX.4.64.0708082141170.21916@wbgn129.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Mod. gitk to support REBASE (with stash support).","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-08T20:08:48Z","receivedAt":"2007-08-08T20:08:48Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n> On Wed, 8 Aug 2007, Alexandre Bourget wrote:\n>\n>> ---\n>> Adds a context menu for commits, so that a 'rebase' can be done.\n>> \n>> Optionally, it will ask if you want to 'stash' current work before doing so.\n>> \n>\n> You want something like this as a commit message, _not_ between \"---\" and \n> diffstat.\n>\n> General question: should this not be in git-gui rather than gitk? Gitk as \n> of now is really more a viewing tool.\n\nWell, yes. But git-gui only works on a single branch head at a time,\nand that is not enough for rebasing. It would be really nice if\ngit-gui did not outsource its branch handling and viewing to gitk.\n\nCould git-gui perhaps be merged with giggle at some point of time?\nAnother option might be to let it talk with uDraw(Graph) over a\nsocket: uDraw(Graph) keeps track of the graph layout and tells its\nclient what has been dragged where.\n\nRebasing would also be a fine operation for drag and drop on a\ngraphical revision history/branch system: pull one head onto another,\nor mark one segment and pull it onto another head. And use the reflog\nto recover from catastrophes...\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"50275","messageId":"20070809032610.GA24573@spearce.org","threadId":"9440","inReplyTo":"85lkclrdpr.fsf@lola.goethe.zz","subject":"Re: [PATCH] Mod. gitk to support REBASE (with stash support).","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-08-09T03:26:10Z","receivedAt":"2007-08-09T03:26:10Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"David Kastrup wrote:\n> Johannes Schindelin writes:\n> > General question: should this not be in git-gui rather than gitk? Gitk as \n> > of now is really more a viewing tool.\n> \n> Well, yes. But git-gui only works on a single branch head at a time,\n> and that is not enough for rebasing.\n\nSure. But so does git's command line tools. They tend to only\nwork on a single branch at time, the one called `HEAD`. HEAD is\nusually a symref/symlink, in which case such work is actually done\non a different branch, but doesn't have to be. Oh, and in case\nyou did not know this, such single head operation *does* support\nrebasing. Bought to you by no less than *three* different flavors\nof git-rebase.\n\nSo \"single branch head at a time\" is *not* why git-gui doesn't\nsupport rebase. Its because nobody has gotten around to writing it.\n\n> It would be really nice if\n> git-gui did not outsource its branch handling and viewing to gitk.\n\nI agree, for the very reason that you mention about being able to\ndrag and drop commit nodes to setup a rebase. This gets a little\nhairy when you want to also drag and drop to create merges, or to\nrecreate merges, but its still implementable.\n\nI have been considering loading a 'safe' interpreter and throwing\ngitk into there, rather than reimplementing its rendering engine\nin git-gui. But I haven't had the time to look into how that would\nwork, and if there is any benefit to it.\n \n> Could git-gui perhaps be merged with giggle at some point of time?\n\nUnlikely. A while ago I considered \"Stay in Tcl/Tk or move to\nsomething more 'powerful/better/faster/Linus friendly'\" and stayed\nin Tcl/Tk. I doubt git-gui will leave Tcl/Tk. giggle is Gtk based.\n\n> Another option might be to let it talk with uDraw(Graph) over a\n> socket: uDraw(Graph) keeps track of the graph layout and tells its\n> client what has been dragged where.\n\nInteresting. I had not heard of this tool before.\n \n> Rebasing would also be a fine operation for drag and drop on a\n> graphical revision history/branch system: pull one head onto another,\n> or mark one segment and pull it onto another head. And use the reflog\n> to recover from catastrophes...\n\nYes, I agree. I decided that any sort of rebase operation in git-gui\nmust be *at least* as easy to use/user friendly as `rebase -i` is.\nAnything less is just mocking the end-user. Or something like that.\nAnyway, since git-gui is restricted to a graphical interface and\nmost such interfaces have these pointy rodents available we can do\nfancy things like dragging to express what we want to have happen,\ninstead of moving lines of text around.\n\nWant to write a patch (or series of patches) for git-gui? ;-)\n\n-- \nShawn.\n"},{"id":"50281","messageId":"85odhhntmb.fsf@lola.goethe.zz","threadId":"9440","inReplyTo":"20070809032610.GA24573@spearce.org","subject":"Re: [PATCH] Mod. gitk to support REBASE (with stash support).","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-09T05:51:08Z","receivedAt":"2007-08-09T05:51:08Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> David Kastrup wrote:\n>> Johannes Schindelin writes:\n>> > General question: should this not be in git-gui rather than gitk? Gitk as \n>> > of now is really more a viewing tool.\n>> \n>> Well, yes. But git-gui only works on a single branch head at a time,\n>> and that is not enough for rebasing.\n>\n> Sure. But so does git's command line tools. They tend to only\n> work on a single branch at time, the one called `HEAD`.\n\n\"tend\", and many accept an explicit override: rebase accepts three\ncommit names, for example. Those that _write_ into the repository\nusually _end_ up at HEAD, but most need not start there.\n\nAnd git-gui does not have any operation either looking at or working\nother than on the current HEAD. No diff, no file view, no rebase,\nnothing.\n\n> So \"single branch head at a time\" is *not* why git-gui doesn't\n> support rebase. Its because nobody has gotten around to writing it.\n\nI never claimed that it is not possible to put a rebase in there (the\npatch does this, after all). I just said that it does not _fit_ in\nthere since you can't actually look at what you are rebasing on.\n\n>> Could git-gui perhaps be merged with giggle at some point of time?\n>\n> Unlikely. A while ago I considered \"Stay in Tcl/Tk or move to\n> something more 'powerful/better/faster/Linus friendly'\" and stayed\n> in Tcl/Tk. I doubt git-gui will leave Tcl/Tk. giggle is Gtk based.\n\nMy bad: git-gui has a nice polished look on my systems (Ubuntu Feisty)\nwhile gitk has an ugly retro-blockish old-font Tk look; so not looking\nat the innards, I had assumed they were implemented using different\nsystems.\n\n> I decided that any sort of rebase operation in git-gui must be *at\n> least* as easy to use/user friendly as `rebase -i` is. Anything\n> less is just mocking the end-user. Or something like that. Anyway,\n> since git-gui is restricted to a graphical interface and most such\n> interfaces have these pointy rodents available we can do fancy\n> things like dragging to express what we want to have happen, instead\n> of moving lines of text around.\n>\n> Want to write a patch (or series of patches) for git-gui?\n\nUser interfaces are really not what I am good at, and I don't even\nhave enough time to deal with the things I am good at.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"50289","messageId":"20070809065810.GC24573@spearce.org","threadId":"9440","inReplyTo":"85odhhntmb.fsf@lola.goethe.zz","subject":"Re: [PATCH] Mod. gitk to support REBASE (with stash support).","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-08-09T06:58:10Z","receivedAt":"2007-08-09T06:58:10Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"David Kastrup wrote:\n> \"Shawn O. Pearce\" writes:\n> >> Well, yes. But git-gui only works on a single branch head at a time,\n> >> and that is not enough for rebasing.\n> >\n> > Sure. But so does git's command line tools. They tend to only\n> > work on a single branch at time, the one called `HEAD`.\n> \n> \"tend\", and many accept an explicit override: rebase accepts three\n> commit names, for example. Those that _write_ into the repository\n> usually _end_ up at HEAD, but most need not start there.\n> \n> And git-gui does not have any operation either looking at or working\n> other than on the current HEAD. No diff, no file view, no rebase,\n> nothing.\n\nUh, \"Repository->Browse Browse Branch Files...\" will let you look\nat files from any commit-ish, not just HEAD or an existing branch.\nYou can open many file browsers at once against the same commit or\ndifferent commits. Double clicking a file opens it in the blame\nviewer, which itself can move around history a little bit.\n\n\"Merge->Local Merge...\" will let you select any another commit to\nmerge with this current branch. That's two commits.\n\nSo your assertion that git-gui only works with one commit, HEAD,\nis wrong.\n\nAnd git-rebase taking three arguments? Its actually two; if it\nis given the optional final argument of the branch to rebase it\nfirst switches to that branch, then does the rebase. In other\nwords these are identical:\n\n # this...\n git checkout to-rebase &&\n git rebase --onto upstreamA upstreamB\n\n # is the same as this...\n git rebase --onto upstreamA upstreamB to-rebase\n \n> >> Could git-gui perhaps be merged with giggle at some point of time?\n> >\n> > Unlikely. A while ago I considered \"Stay in Tcl/Tk or move to\n> > something more 'powerful/better/faster/Linus friendly'\" and stayed\n> > in Tcl/Tk. I doubt git-gui will leave Tcl/Tk. giggle is Gtk based.\n> \n> My bad: git-gui has a nice polished look on my systems (Ubuntu Feisty)\n> while gitk has an ugly retro-blockish old-font Tk look; so not looking\n> at the innards, I had assumed they were implemented using different\n> systems.\n\nNope. Myself and a few others have just spent some time making\ngit-gui look somewhat sane by default. It doesn't always; there are\nat least a few places where it still has too much of a Tk-ish look\nto it. This is especially true in a few of the dialog boxes that\ngit-gui might open when you are about to do something potentially\nbad.\n\n> User interfaces are really not what I am good at, and I don't even\n> have enough time to deal with the things I am good at.\n\nHah. Me neither. Yet git-gui exists.\n\n-- \nShawn.\n"},{"id":"50290","messageId":"20070809072147.GD24573@spearce.org","threadId":"9440","inReplyTo":"20070809065810.GC24573@spearce.org","subject":"Re: [PATCH] Mod. gitk to support REBASE (with stash support).","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-08-09T07:21:47Z","receivedAt":"2007-08-09T07:21:47Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Shawn O. Pearce\" wrote:\n> David Kastrup wrote:\n> > other than on the current HEAD. No diff, no file view, no rebase,\n> > nothing.\n> \n> So your assertion that git-gui only works with one commit, HEAD,\n> is wrong.\n\nOh, and git-gui has some features that don't even really exist in the\nshell porcelain. E.g. you can do this all from the Branch->Create\ndialog in git-gui:\n\n b=refs/heads/branch-to-create\n git fetch origin foof:refs/remotes/origin/foof &&\n if test git show-ref $b\n then\n git push . refs/remotes/origin/foof:$b\n else\n git branch $b refs/remotes/origin/foof\n fi &&\n git checkout foof\n\nThat's actually somewhat hard to do on the command line, but as\nit turns out is just insanely handy to have for some workflows.\nIt amounts to \"Always fetch the remote tracking branch, make sure\nmy local branch will fast-forward to it, do so, then checkout my\nlocal branch; but if the local branch doesn't exist create it,\nthen do the checkout anyway\".\n\nI used git-push above just because its handy to do the fast-forward\ncheck and update if successful; that's not what git-gui uses\ninternally because its actually a really stupid abuse of the\npush command. But it was shorter to write out the shell code for\nthis email. Wow, OK, I just spent more time explaining why I used\ngit-push than to just write the damn fast-forward test. Whatever.\n\nI count 1-2 commits in that operation, depending on if your local\nbranch exists or not. Oh, and this nifty thing called a remote.\n\n\nBut you are correct to some extent, there's no diff of a prior commit\navailable from within git-gui. Or rebase. I'd like to fix both.\nBut its time for sleep instead. Oh, and I'm supposed to be fixing\nsome \"features\" of fast-import this week too...\n\n-- \nShawn.\n"},{"id":"50295","messageId":"86r6mdqh0r.fsf@lola.quinscape.zz","threadId":"9440","inReplyTo":"20070809065810.GC24573@spearce.org","subject":"Re: [PATCH] Mod. gitk to support REBASE (with stash support).","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-09T07:55:00Z","receivedAt":"2007-08-09T07:55:00Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> David Kastrup wrote:\n>> \"Shawn O. Pearce\" writes:\n>> >> Well, yes. But git-gui only works on a single branch head at a time,\n>> >> and that is not enough for rebasing.\n>> >\n>> > Sure. But so does git's command line tools. They tend to only\n>> > work on a single branch at time, the one called `HEAD`.\n>> \n>> \"tend\", and many accept an explicit override: rebase accepts three\n>> commit names, for example. Those that _write_ into the repository\n>> usually _end_ up at HEAD, but most need not start there.\n>> \n>> And git-gui does not have any operation either looking at or working\n>> other than on the current HEAD. No diff, no file view, no rebase,\n>> nothing.\n>\n> Uh, \"Repository->Browse Browse Branch Files...\" will let you look at\n> files from any commit-ish, not just HEAD or an existing branch.\n\nDuh. But why are the menus called \"Browse master's Files\" and \"Browse\nBranch Files\" rather than \"Browse heads/master\" or \"Browse master's\nhead\" versus \"Browse any commit\" or maybe just \"Browse current\" and\n\"Browse at ...\"? \"Browse Branch Files\" is _really_ misleading.\n\n> You can open many file browsers at once against the same commit or\n> different commits. Double clicking a file opens it in the blame\n> viewer, which itself can move around history a little bit.\n\nI though about the blame window after my first posting (actually, I\ndid not yet notice one can move around in the revisions in the blame.\nNice. Now if it supported utf-8 files...). Well, yes.\n\n> \"Merge->Local Merge...\" will let you select any another commit to\n> merge with this current branch. That's two commits.\n\nOk, ok. Still, commits and history are much more visible as whole in\ngitk: git-gui mostly lets one pick out single views (the blame window\nis probably the closest one gets to moving about, but then it _is_ a\nmoving view which always shows a single point of time ultimately).\n\n> So your assertion that git-gui only works with one commit, HEAD,\n> is wrong.\n\nYes.\n\n-- \nDavid Kastrup\n"}]}