{"thread":{"id":"6954","subject":"RFC: Patch editing","startedAt":"2007-02-25T21:59:22Z","lastAt":"2007-03-01T23:59:21Z","messageCount":15,"participants":["Johannes Schindelin","Peter Baumann","Shawn O. Pearce","Junio C Hamano","Daniel Barkalow","Karl Hasselström"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"35459","messageId":"Pine.LNX.4.63.0702252156190.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6954","inReplyTo":null,"subject":"RFC: Patch editing","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-25T21:59:22Z","receivedAt":"2007-02-25T21:59:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi list,\n\nwhile I was hacking on another issue, I realized just how often I would \nlike to stash away a fix which is unrelated (but often triggered) by the \ntheme of the current topic branch. Or I fix an earlier commit, which is \nnot the tip of the branch, so I cannot --amend it.\n\nMy common practice is to commit it nevertheless, and sort the topic \nbranches out later, by cherry-picking my way through the commits.\n\nThis is a tedious and error-prone procedure, and I often wished I knew how \nto use StGIT. But then, StGIT is overkill for me: on some machines I work \non, there is no Python installed, I do not really need to have a history \non the order and version of patches, and I do not need to preserve author \nand committer information *1*.\n\nTherefore, I wrote this extremely simple script to sort out the order of \ncommits, and possibly merging some. The script lets you edit the commit \nlist upon start (reordering it, or removing commits), and then works on \nthat list. It has three subcommands:\n\n\tstart <base>\n\tcontinue\n\treset [-f]\n\nThe subcommand \"start\" takes a base commit (actually, it will take the \nmerge base of HEAD and that base commit) from which to start. It builds a \ncommit list and opens it in an editor. The rows of the list have the form \n\"<action> <sha1> <oneline>\". The oneline description is purely for ease of \nuse.\n\nThe three possible actions are \"pick\" (the default), \"edit\" and \"merge\". \n\"pick\" will just cherry-pick that commit, \"edit\" will stop after \ncherry-picking so that you can make a small fixup (in the code or in the \ncommit message), and \"merge\" will try to apply the corresponding patch, \namend the previous commit with the result, and let you edit the combined \ncommit message.\n\nIf a patch fails, or \"edit\" was specified, the loop is interrupted for \nfixups. Use the subcommand \"continue\" to restart the loop (the working \ntree has to be clean, though).\n\nOnce there are no more commits to be picked, the original branch is \nupdated to that new tip.\n\nIf you decide at some point that you do not want to rewrite the patches \nafter all, you can use the subcommand \"reset\".\n\nTo see which commits were already applied, you can inspect .series/done, \nand likewise .series/todo for what is to be applied yet. You can even edit \n.series/todo if you decide on another course of action.\n\nAnyway, it is a relatively short and stupid script.\n\nCiao,\nDscho\n\n*1* My slight aversion against Python and Perl might be involved, too.\n\n-- snipsnap --\n#!/bin/sh\n#\n# Copyright (c) 2006 Johannes E. Schindelin\n\n# SHORT DESCRIPTION\n#\n# This is a really stupid script to arrange a patch series for submission.\n# It does not care for authorship or dates, all it does is make it easy\n# to fix up commits in the middle of a series, and rearrange commits.\n#\n# MOTIVATION\n#\n# It is extremely useful for this type of workflow:\n#\n#\t1. have a wonderful idea\n#\t2. hack on the code\n#\t3. prepare a series for submission\n#\t4. submit\n#\n# where the point (2) consists of several instances of\n#\n#\tA.1. finish something worthy of a commit\n#\tA.2. commit\n#\n# and/or\n#\n#\tB.1. realize that something does not work\n#\tB.2. fix that\n#\tB.3. commit it\n#\n# Sometimes the thing fixed in B.2. cannot be amended to the not-quite\n# perfect commit it fixes, because that commit is buried deeply in a\n# patch series.\n#\n# Use this script after plenty of \"A\"s and \"B\"s, by rearranging, and\n# possibly editing and merging commits.\n#\n# USAGE:\n#\n# The subcommand \"start\" will make a list of the commits in the patch\n# series <base>..HEAD, where <base> is the commit identiefied by the\n# parameter.\n#\n# It will automatically start an editor, where you can rearrange the\n# commits. The list looks more or less like this:\n#\n#\tpick deadbee The oneline of this commit\n#\tpick fa1afe1 The oneline of the next commit\n#\t...\n#\n# By replacing the command \"pick\" with \"edit\" you can tell\n# this script to stop the loop so you can fix up the commit by editing\n# files and/or the commit message.\n#\n# When replacing the command \"pick\" with \"merge, the script will merge\n# this commit's changes into the previous commit, munge the commit\n# messages of both, and open the commit message editor.\n#\n# In both cases, or when a \"pick\" does not succeed (because of merge\n# errors), the loop will stop to let you fix things, and you can continue\n# the loop with `git edit-patch-series continue`.\n\nUSAGE='(start <basecommit>| continue | reset [--force])'\n\n. git-sh-setup\nrequire_work_tree\n\nSERIESDIR=\"$(pwd)/.series\"\nTODO=\"$SERIESDIR\"/todo\nDONE=\"$SERIESDIR\"/done\n\nwarn () {\n\techo \"$@\" >&2\n}\n\nrequire_clean_work_tree () {\n\t# test if working tree is dirty\n\tgit rev-parse --verify HEAD > /dev/null &&\n\tgit update-index --refresh &&\n\ttest -z \"`git diff-files --name-only`\" &&\n\ttest -z \"`git diff-index --cached --name-only HEAD`\" ||\n\tdie \"Working tree is dirty\"\n}\n\nORIG_REFLOG_ACTION=\"$GIT_REFLOG_ACTION\"\n\ncomment_for_reflog () {\n\tif test -z \"$ORIG_REFLOG_ACTION\"; then\n\t\tGIT_REFLOG_ACTION=\"edit-patch-series($1)\"\n\t\texport GIT_REFLOG_ACTION\n\tfi\n}\n\nmark_action_done () {\n\tsed -n 1p < \"$TODO\" >> \"$DONE\"\n\tsed -n '2,$p' < \"$TODO\" >> \"$TODO\".new\n\tmv -f \"$TODO\".new \"$TODO\"\n}\n\ndo_next () {\n\tread command sha1 rest < \"$TODO\"\n\tcase \"$command\" in\n\t\\#)\n\t\tmark_action_done\n\t\tcontinue\n\t;;\n\tpick)\n\t\tcomment_for_reflog pick\n\n\t\tmark_action_done\n\t\tgit cherry-pick \"$sha1\" || \\\n\t\t\tdie \"Could not apply $sha1... $rest\"\n\t;;\n\tedit)\n\t\tcomment_for_reflog edit\n\n\t\tmark_action_done\n\t\tgit cherry-pick \"$sha1\" || \\\n\t\t\tdie \"Could not apply $sha1... $rest\"\n\t\texit 0\n\t;;\n\tmerge)\n\t\tcomment_for_reflog merge\n\n\t\ttest -s \"$DONE\" &&\n\t\t\tdie \"Cannot 'merge' without a previous commit\"\n\n\t\tmark_action_done\n\t\tfailed=f\n\t\tgit cherry-pick -n \"$sha1\" || failed=t\n\t\tMSG=\"$SERIESDIR\"/message\n\t\techo \"# This is a combination of two commits.\" > \"$MSG\"\n\t\techo \"# The first commit's message is:\" >> \"$MSG\"\n\t\tgit cat-file commit HEAD | sed -n '/^$/,$p' >> \"$MSG\"\n\t\techo >> \"$MSG\"\n\t\techo \"# And this is the 2nd commit message:\" >> \"$MSG\"\n\t\techo >> \"$MSG\"\n\t\tcat .msg >> \"$MSG\"\n\t\tcase $failed in\n\t\tf)\n\t\t\t# Usually, I would use --amend here, but -F forbids it\n\t\t\tgit reset --soft HEAD^\n\t\t\tgit commit -F \"$MSG\" -e\n\t\t;;\n\t\tt)\n\t\t\tcp \"$MSG\" .msg\n\t\t\twarn \"Could not apply $sha1... $rest\"\n\t\t\twarn \"After you fixed that, commit the result with\"\n\t\t\twarn\n\t\t\twarn \"\tgit commit --reedit-message .msg\"\n\t\t\texit 1\n\t\tesac\n\t;;\n\t*)\n\t\twarn \"Unknown command: $command $sha1 $rest\"\n\t\twarn \"Please fix this in the file $TODO.\"\n\t\texit 1\n\tesac\n\ttest -s \"$TODO\" && continue\n\n\tHEAD=$(git rev-parse HEAD)\n\tHEADNAME=$(cat \"$SERIESDIR\"/head-name)\n\tgit update-ref $HEADNAME $HEAD &&\n\tgit symbolic-ref HEAD $HEADNAME &&\n\trm -rf \"$SERIESDIR\" &&\n\twarn \"Successfully edited patch series and updated $HEADNAME.\"\n\n\texit $?\n}\n\ncase \"$1\" in\nstart)\n\tcomment_for_reflog start\n\n\tHEAD=$(git rev-parse --verify HEAD) || die \"No HEAD?\"\n\tBASE=$(git rev-parse --verify \"$2\") || die \"Invalid base\"\n\n\t# DWIM: use the merge base\n\tMERGEBASE=$(git merge-base $HEAD $BASE)\n\tif test \"$BASE\" != \"$MERGEBASE\"\n\tthen\n\t\tCANDIDATES=\"$(git merge-base --all $HEAD $BASE)\"\n\t\tif test \"$MERGEBASE\" != \"$CANDIDATES\"\n\t\tthen\n\t\t\twarn \"Error: Multiple merge bases found:\"\n\t\t\twarn \"$CANDIDATES\"\n\t\t\trm -rf \"$SERIESDIR\"\n\t\t\texit 1\n\t\tfi\n\t\tBASE=$MERGEBASE\n\tfi\n\n\trequire_clean_work_tree\n\n\tgit var GIT_COMMITTER_IDENT >/dev/null || exit\n\n\ttest -d \"$SERIESDIR\" &&\n\t\tdie \"Edit-patch-series already started\"\n\n\ttest \"z$(git rev-list --parents $BASE..$HEAD | grep \" .* \")\" != z &&\n\t\tdie \"Cannot edit a series including merges\"\n\n\tmkdir \"$SERIESDIR\" || die \"Could not create temporary $SERIESDIR\"\n\tgit symbolic-ref HEAD > \"$SERIESDIR\"/head-name || die \"Could not get HEAD\"\n\n\techo $HEAD > \"$SERIESDIR\"/head\n\techo $BASE > \"$SERIESDIR\"/base\n\n\tcat > \"$TODO\" << EOF\n# Edit the patch series by exchanging lines.  The commits will be\n# arranged in the given order.  If you want to edit a commit, replace\n# the \"pick\" command with \"edit\".  If you want to merge the changes of\n# a commit A into a commit B, place A directly after B, and replace the\n# \"pick\" command with \"merge\".\nEOF\n\tgit rev-list --reverse --pretty=oneline --abbrev-commit --abbrev=7 \\\n\t\t$BASE..$HEAD | sed \"s/^/pick /\" >> \"$TODO\"\n\n\tcp \"$TODO\" \"$TODO\".backup\n\t${VISUAL:-${EDITOR:-vi}} \"$TODO\" || warn \"Could not execute editor\"\n\tif git diff --no-index \"$TODO\" \"$TODO\".backup > /dev/null\n\tthen\n\t\trm -rf \"$SERIESDIR\"\n\t\twarn \"No changes\"\n\t\texit 0\n\tfi\n\n\tgit checkout $BASE || die \"Could not checkout $BASE\"\n\n\twhile :\n\tdo\n\t\tdo_next\n\tdone\n;;\ncontinue)\n\tcomment_for_reflog continue\n\n\ttest -d \"$SERIESDIR\" || die \"No edit-patch-series running\"\n\n\trequire_clean_work_tree\n\n\twhile :\n\tdo\n\t\tdo_next\n\tdone\n;;\nreset)\n\tcomment_for_reflog reset\n\n\ttest -d \"$SERIESDIR\" || die \"No edit-patch-series running\"\n\n\tHEADNAME=$(cat \"$SERIESDIR\"/head-name)\n\tforce=\n\tcase \"$2\" in\n\t-f|--force)\n\t\tgit symbolic-ref HEAD $HEADNAME &&\n\t\tgit reset --hard\n\t;;\n\t*)\n\t\tgit checkout $HEADNAME\n\tesac &&\n\trm -rf \"$SERIESDIR\"\n;;\n*)\n\tusage\nesac\n"},{"id":"35501","messageId":"slrneu5ngm.s8g.siprbaum@xp.machine.xx","threadId":"6954","inReplyTo":"Pine.LNX.4.63.0702252156190.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: RFC: Patch editing","fromName":"Peter Baumann","fromEmail":"siprbaum@stud.informatik.uni-erlangen.de","sentAt":"2007-02-26T13:18:14Z","receivedAt":"2007-02-26T13:18:14Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> schrieb:\n> Hi list,\n>\n> while I was hacking on another issue, I realized just how often I would \n> like to stash away a fix which is unrelated (but often triggered) by the \n> theme of the current topic branch. Or I fix an earlier commit, which is \n> not the tip of the branch, so I cannot --amend it.\n>\n> My common practice is to commit it nevertheless, and sort the topic \n> branches out later, by cherry-picking my way through the commits.\n>\n> This is a tedious and error-prone procedure, and I often wished I knew how \n> to use StGIT. But then, StGIT is overkill for me: on some machines I work \n> on, there is no Python installed, I do not really need to have a history \n> on the order and version of patches, and I do not need to preserve author \n> and committer information *1*.\n>\n> Therefore, I wrote this extremely simple script to sort out the order of \n> commits, and possibly merging some. The script lets you edit the commit \n> list upon start (reordering it, or removing commits), and then works on \n> that list. It has three subcommands:\n>\n> \tstart <base>\n> \tcontinue\n> \treset [-f]\n>\n> The subcommand \"start\" takes a base commit (actually, it will take the \n> merge base of HEAD and that base commit) from which to start. It builds a \n> commit list and opens it in an editor. The rows of the list have the form \n> \"<action> <sha1> <oneline>\". The oneline description is purely for ease of \n> use.\n>\n> The three possible actions are \"pick\" (the default), \"edit\" and \"merge\". \n> \"pick\" will just cherry-pick that commit, \"edit\" will stop after \n> cherry-picking so that you can make a small fixup (in the code or in the \n> commit message), and \"merge\" will try to apply the corresponding patch, \n> amend the previous commit with the result, and let you edit the combined \n> commit message.\n>\n> If a patch fails, or \"edit\" was specified, the loop is interrupted for \n> fixups. Use the subcommand \"continue\" to restart the loop (the working \n> tree has to be clean, though).\n>\n> Once there are no more commits to be picked, the original branch is \n> updated to that new tip.\n>\n> If you decide at some point that you do not want to rewrite the patches \n> after all, you can use the subcommand \"reset\".\n>\n> To see which commits were already applied, you can inspect .series/done, \n> and likewise .series/todo for what is to be applied yet. You can even edit \n> .series/todo if you decide on another course of action.\n>\n> Anyway, it is a relatively short and stupid script.\n>\n\nNice.  I tried it on a simple testcase to just rearrange some commits\nand it worked as expected. That was exactly what I was looking for!\n\nI tried for a while stgit, but it seemed like overkill to me and I messed\nup my test repo several times, propably because I have done something wrong\nso I gave up.\n\n-Peter\n"},{"id":"35517","messageId":"20070226180314.GA2108@spearce.org","threadId":"6954","inReplyTo":"Pine.LNX.4.63.0702252156190.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: RFC: Patch editing","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-26T18:03:14Z","receivedAt":"2007-02-26T18:03:14Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> Therefore, I wrote this extremely simple script to sort out the order of \n> commits, and possibly merging some. The script lets you edit the commit \n> list upon start (reordering it, or removing commits), and then works on \n> that list. It has three subcommands:\n\nThis simple tool rocks.  Thank you!  ;-)\n\n-- \nShawn.\n"},{"id":"35521","messageId":"Pine.LNX.4.63.0702261949560.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6954","inReplyTo":"20070226180314.GA2108@spearce.org","subject":"Re: RFC: Patch editing","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-26T18:52:35Z","receivedAt":"2007-02-26T18:52:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 26 Feb 2007, Shawn O. Pearce wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > Therefore, I wrote this extremely simple script to sort out the order of \n> > commits, and possibly merging some. The script lets you edit the commit \n> > list upon start (reordering it, or removing commits), and then works on \n> > that list. It has three subcommands:\n> \n> This simple tool rocks.  Thank you!  ;-)\n\nI am undecided how to continue. Originally, I wanted to add an \"--onto \n<commit>\" option, and maybe an \"edit\" subcommand, but since Junio made me \nrealize that it is more similar to git-rebase than I previously thought, \nand that they should merge, possibly in the form of a builtin...\n\nBut in order to merge the two, I have to learn about rebase's syntax first \n;-)\n\nCiao,\nDscho\n"},{"id":"35523","messageId":"20070226185655.GB2108@spearce.org","threadId":"6954","inReplyTo":"Pine.LNX.4.63.0702261949560.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: RFC: Patch editing","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-26T18:56:55Z","receivedAt":"2007-02-26T18:56:55Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> On Mon, 26 Feb 2007, Shawn O. Pearce wrote:\n> \n> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > > Therefore, I wrote this extremely simple script to sort out the order of \n> > > commits, and possibly merging some. The script lets you edit the commit \n> > > list upon start (reordering it, or removing commits), and then works on \n> > > that list. It has three subcommands:\n> > \n> > This simple tool rocks.  Thank you!  ;-)\n> \n> I am undecided how to continue. Originally, I wanted to add an \"--onto \n> <commit>\" option, and maybe an \"edit\" subcommand, but since Junio made me \n> realize that it is more similar to git-rebase than I previously thought, \n> and that they should merge, possibly in the form of a builtin...\n\nYea - this is a lot like rebase.  I was also thinking that the -m\n(merge mode) in rebase probably should be the only option offered.\nI don't see why rebase should format-patch|am when we have the\nwhole commit available and merge-recursive does an excellent job\non tree level merges.\n\n> But in order to merge the two, I have to learn about rebase's syntax first \n> ;-)\n\nIts easier than it looks.  ;-)\n\n-- \nShawn.\n"},{"id":"35531","messageId":"7vveholmu2.fsf@assigned-by-dhcp.cox.net","threadId":"6954","inReplyTo":"20070226185655.GB2108@spearce.org","subject":"Re: RFC: Patch editing","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-26T19:51:01Z","receivedAt":"2007-02-26T19:51:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" <spearce@spearce.org> writes:\n\n> Yea - this is a lot like rebase.  I was also thinking that the -m\n> (merge mode) in rebase probably should be the only option offered.\n> I don't see why rebase should format-patch|am when we have the\n> whole commit available and merge-recursive does an excellent job\n> on tree level merges.\n\nOne reason is that it just matches the practice to the mental\nmodel.  Rebasing is like sending yourself a patch series and\napplying with 'am' on top of a known commit afresh, which is\nexactly what the command without -m does.\n\nThe other historical reason is that reconstructing (with -3) the\nonly part of the tree that matters in the 3-way merge and\nrunning the merge was a lot faster with the merge tool we had,\nthan a full 3-way merge.\n"},{"id":"35578","messageId":"Pine.LNX.4.64.0702270205540.6485@iabervon.org","threadId":"6954","inReplyTo":"Pine.LNX.4.63.0702252156190.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: RFC: Patch editing","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-02-27T07:14:55Z","receivedAt":"2007-02-27T07:14:55Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 25 Feb 2007, Johannes Schindelin wrote:\n\n> Hi list,\n> \n> while I was hacking on another issue, I realized just how often I would \n> like to stash away a fix which is unrelated (but often triggered) by the \n> theme of the current topic branch. Or I fix an earlier commit, which is \n> not the tip of the branch, so I cannot --amend it.\n> \n> My common practice is to commit it nevertheless, and sort the topic \n> branches out later, by cherry-picking my way through the commits.\n> \n> This is a tedious and error-prone procedure, and I often wished I knew how \n> to use StGIT. But then, StGIT is overkill for me: on some machines I work \n> on, there is no Python installed, I do not really need to have a history \n> on the order and version of patches, and I do not need to preserve author \n> and committer information *1*.\n> \n> Therefore, I wrote this extremely simple script to sort out the order of \n> commits, and possibly merging some. The script lets you edit the commit \n> list upon start (reordering it, or removing commits), and then works on \n> that list.\n\nFor much the same reason, I wrote a script that entirely ignores the \nintermediate commits in a throw-away head, and lets you trim down the diff \nbetween the mainline and your head, and arrange it into a new patch \nseries. Never got around to making it particularly nice, but it might be a \ngood starting point for someone who wants to make something useable. (In \nits current state, you need some external tool that you're comfortable \nediting diffs with, and it doesn't do anything with any commit messages \nyou may have written)\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n#!/bin/sh\n\nif [ \"$1\" != \"\" ]\nthen\n  git-symbolic-ref REFINE_HEAD refs/heads/$1\nfi\n\nif [ -f .git/refine-patch ]\nthen\n  if ! git-apply --index .git/refine-patch\n  then\n    exit 1\n  fi\n  rm .git/refine-patch\n  echo \"Applied selected changes; verify and commit\"\n  exit 0\nfi\n\nif git-status > /dev/null\nthen\n  echo \"Uncommitted changes; verify and commit\"\n  exit 0\nfi\n\ngit-diff -M HEAD REFINE_HEAD > .git/refine-patch\nif [ -s .git/refine-patch ]\nthen\n  $EDITOR .git/refine-patch\nelse\n  echo \"All done\"\n  rm .git/refine-patch\nfi\n"},{"id":"35594","messageId":"Pine.LNX.4.63.0702271247000.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6954","inReplyTo":"Pine.LNX.4.64.0702270205540.6485@iabervon.org","subject":"Re: RFC: Patch editing","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-27T11:54:56Z","receivedAt":"2007-02-27T11:54:56Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Feb 2007, Daniel Barkalow wrote:\n\n> For much the same reason, I wrote a script that entirely ignores the \n> intermediate commits in a throw-away head, and lets you trim down the \n> diff between the mainline and your head, and arrange it into a new patch \n> series.\n\nIt looks to me like you just start a new branch, get the state of an \nexisting commit *1*, and then \"git add -i\" your way through that diff.\n\nThis is slightly different from my work flow:\n\n- I can have overlapping changes (i.e. one commit fixes something which \n  gets refactored in the next), and\n\n- I try not to touch the code when editing the patch series. Only in the \n  conflicting case, I _have_ to edit it.\n\nThe latter means, of course, that the commits in the throwaway branch \n_must_ be a superset of the commits I want to have in the cleaned up \nbranch. (Meaning that I never commit two unrelated things with the same \ncommit.)\n\nTo achieve that, I use my own version of \"git add -i\" quite often while \ncomposing the throwaway branch. For example, when I found a bug with an \neasy fix, in the middle of something different, and the fix touches a file \nthat is already changed, I only commit the appropriate hunks of that file.\n\nCiao,\nDscho\n\n*1* It is not really as easy as \"git diff ..other-branch | git apply\", \nsince you would lose valuable information about added files, so you have \nto be very careful there.\n"},{"id":"35644","messageId":"Pine.LNX.4.64.0702271201400.6485@iabervon.org","threadId":"6954","inReplyTo":"Pine.LNX.4.63.0702271247000.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: RFC: Patch editing","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-02-27T17:35:28Z","receivedAt":"2007-02-27T17:35:28Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 27 Feb 2007, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Tue, 27 Feb 2007, Daniel Barkalow wrote:\n> \n> > For much the same reason, I wrote a script that entirely ignores the \n> > intermediate commits in a throw-away head, and lets you trim down the \n> > diff between the mainline and your head, and arrange it into a new patch \n> > series.\n> \n> It looks to me like you just start a new branch, get the state of an \n> existing commit *1*, and then \"git add -i\" your way through that diff.\n\nEssentially, yes.\n\n> This is slightly different from my work flow:\n> \n> - I can have overlapping changes (i.e. one commit fixes something which \n>   gets refactored in the next), and\n\nThat's true; I occasionally add some change that will go away in the next \npatch (or a later patch). This goes in between applying the cut-down \npatch and committing it (I also often build and test at this point, to \nmake sure that my intermediate states work; so I can leave thing not \nworking in the patch, and fix the build errors to generate the temporary \nintermediate state).\n\n> - I try not to touch the code when editing the patch series. Only in the \n>   conflicting case, I _have_ to edit it.\n> \n> The latter means, of course, that the commits in the throwaway branch \n> _must_ be a superset of the commits I want to have in the cleaned up \n> branch. (Meaning that I never commit two unrelated things with the same \n> commit.)\n> \n> To achieve that, I use my own version of \"git add -i\" quite often while \n> composing the throwaway branch. For example, when I found a bug with an \n> easy fix, in the middle of something different, and the fix touches a file \n> that is already changed, I only commit the appropriate hunks of that file.\n\nOne nice thing about my method is that, if you've had to make a dozen \nunrelated changes to get something to compile and run far enough to test \nwhether any of the changes are actually correct, you can be sure to get \nthat work preserved. I'd be a lot less comfortable preparing intermediate \nstates if I didn't have the final state securely tucked away.\n\nI don't really trust myself to not lose some partially-working state \nbefore I reach a state that's worthy of a commit, so I generate a lot of \nunworthy commits as part of the process of generating a state worth \ncommitting. I also sometimes want to use multiple computers in the course \nof reaching a state worthy of a commit; using git's state-distribution \nmechanism for that is really nice.\n\n> *1* It is not really as easy as \"git diff ..other-branch | git apply\", \n> since you would lose valuable information about added files, so you have \n> to be very careful there.\n\n\"git apply --index\" actually recovers the information about added files.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"35660","messageId":"Pine.LNX.4.63.0702272106150.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6954","inReplyTo":"Pine.LNX.4.64.0702271201400.6485@iabervon.org","subject":"Re: RFC: Patch editing","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-27T20:07:35Z","receivedAt":"2007-02-27T20:07:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Feb 2007, Daniel Barkalow wrote:\n\n> One nice thing about my method is that, if you've had to make a dozen \n> unrelated changes to get something to compile and run far enough to test \n> whether any of the changes are actually correct, you can be sure to get \n> that work preserved. I'd be a lot less comfortable preparing \n> intermediate states if I didn't have the final state securely tucked \n> away.\n\nYou _could_ still ensure that by looking in the reflog which was your old \ntip-of-branch, and git-diff with that.\n\nBut I agree. That is why I commit _everything_ before rearranging.\n\nCiao,\nDscho\n"},{"id":"35700","messageId":"Pine.LNX.4.64.0702271651500.6485@iabervon.org","threadId":"6954","inReplyTo":"Pine.LNX.4.63.0702272106150.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: RFC: Patch editing","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-02-27T22:07:11Z","receivedAt":"2007-02-27T22:07:11Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 27 Feb 2007, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Tue, 27 Feb 2007, Daniel Barkalow wrote:\n> \n> > One nice thing about my method is that, if you've had to make a dozen \n> > unrelated changes to get something to compile and run far enough to test \n> > whether any of the changes are actually correct, you can be sure to get \n> > that work preserved. I'd be a lot less comfortable preparing \n> > intermediate states if I didn't have the final state securely tucked \n> > away.\n> \n> You _could_ still ensure that by looking in the reflog which was your old \n> tip-of-branch, and git-diff with that.\n> \n> But I agree. That is why I commit _everything_ before rearranging.\n\nI think you're misunderstanding me; I want to use git's \narchival/distribution functionality before I have a commit that I can put \na useful message on. This means that, at some point, I'm making real \ncommits, and I know what final state I want, but that final state involves \nunrelated changes.\n\nI think I usually come up with something like: 7 patches related to the \nfunctionality I'm working on, 1 patch that fixes an old bug that became \nimportant due to the change, and 2 patches which improve the debugging \ninfrastructure. And the actual sequence of intermediate states that my \ncode was in is something like: API written, stub implementations, some \ncode that suggests what should happen; program calling the API and \ncrashing; version that is written but buggy; version that's buggy but \nverbose; version that's working but verbose. In refining the work, I drop \nor \"if (DEFINED_TO_0_DEBUG)\" the messages, split out the patches that \nsupport the new kinds of messages, and include only working versions of \nfunctions. And then I write commit messages that talk about the code and \nsign them.\n\nAm I unusual in being afraid of losing work in a state that contains 3 \ndifferent half-features?\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"35710","messageId":"Pine.LNX.4.63.0702272332440.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6954","inReplyTo":"Pine.LNX.4.64.0702271651500.6485@iabervon.org","subject":"Re: RFC: Patch editing","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-27T22:37:15Z","receivedAt":"2007-02-27T22:37:15Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Feb 2007, Daniel Barkalow wrote:\n\n> On Tue, 27 Feb 2007, Johannes Schindelin wrote:\n> \n> > On Tue, 27 Feb 2007, Daniel Barkalow wrote:\n> > \n> > > One nice thing about my method is that, if you've had to make a dozen \n> > > unrelated changes to get something to compile and run far enough to test \n> > > whether any of the changes are actually correct, you can be sure to get \n> > > that work preserved. I'd be a lot less comfortable preparing \n> > > intermediate states if I didn't have the final state securely tucked \n> > > away.\n> > \n> > You _could_ still ensure that by looking in the reflog which was your old \n> > tip-of-branch, and git-diff with that.\n> > \n> > But I agree. That is why I commit _everything_ before rearranging.\n> \n> I think you're misunderstanding me; I want to use git's \n> archival/distribution functionality before I have a commit that I can put \n> a useful message on. This means that, at some point, I'm making real \n> commits, and I know what final state I want, but that final state involves \n> unrelated changes.\n> \n> I think I usually come up with something like: 7 patches related to the \n> functionality I'm working on, 1 patch that fixes an old bug that became \n> important due to the change, and 2 patches which improve the debugging \n> infrastructure.\n\nSame for me.\n\n> And the actual sequence of intermediate states that my \n> code was in is something like: API written, stub implementations, some \n> code that suggests what should happen; program calling the API and \n> crashing; version that is written but buggy;\n\nStill same for me.\n\n> version that's buggy but verbose;\n\nI don't commit that.\n\nHowever, if I _do_, it _only_ contains the messages. And in that case \nrebase--interactive (this is the new working title for edit-patch-series) \nallows you to just kill these commits...\n\n> version that's working but verbose.\n\nWould be handled by (3way) cherry-pick.\n\n> Am I unusual in being afraid of losing work in a state that contains 3 \n> different half-features?\n\nNot at all. I often do \"git checkout -b temp && git commit -a -m temp && \ngit checkout <oldname>\".\n\nCiao,\nDscho\n"},{"id":"35793","messageId":"20070228101315.GA18444@diana.vm.bytemark.co.uk","threadId":"6954","inReplyTo":"Pine.LNX.4.64.0702271651500.6485@iabervon.org","subject":"Re: RFC: Patch editing","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-02-28T10:13:15Z","receivedAt":"2007-02-28T10:13:15Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-02-27 17:07:11 -0500, Daniel Barkalow wrote:\n\n> I think I usually come up with something like: 7 patches related to\n> the functionality I'm working on, 1 patch that fixes an old bug that\n> became important due to the change, and 2 patches which improve the\n> debugging infrastructure. And the actual sequence of intermediate\n> states that my code was in is something like: API written, stub\n> implementations, some code that suggests what should happen; program\n> calling the API and crashing; version that is written but buggy;\n> version that's buggy but verbose; version that's working but\n> verbose. In refining the work, I drop or \"if (DEFINED_TO_0_DEBUG)\"\n> the messages, split out the patches that support the new kinds of\n> messages, and include only working versions of functions. And then I\n> write commit messages that talk about the code and sign them.\n>\n> Am I unusual in being afraid of losing work in a state that contains\n> 3 different half-features?\n\nMy usual workflow looks like this too. I start out with a rough plan\nof how to accomplish my goal with a number of smaller changes, but it\nalways turns out that I need more debug code, need to fix old bugs in\nthe middle of the process, need to fix silly bugs in earlier commits\nin the series I'm building, and so on. I record this work with lots of\nsmall commits. When I'm done, and usually at some intermediate stages\nas well, I coalesce and reorder these commits to get a history\nresembling my initial plan.\n\nStGit is really helpful here. It doesn't actually do anything I\ncouldn't do manually with just git, but it makes it _simple_, and\ntracks all the metadata for me so that I don't get a chance to make a\nmess of things.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"36031","messageId":"Pine.LNX.4.63.0703020020470.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6954","inReplyTo":"Pine.LNX.4.63.0702252156190.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Updated version, was Re: RFC: Patch editing","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-01T23:30:03Z","receivedAt":"2007-03-01T23:30:03Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nthis is an updated version, which got even less testing than the first \nversion :-( However, the changes were small:\n\n- added an attribution to Eric Biederman for the idea,\n- if you mark a commit as \"edit\", it will _not_ be committed, so that\n  you do not need --amend _both_ in case of conflicts and no conflicts \n  (noticed by Shawn Pearce),\n- a \"merge\" is refused when it is the _first_ in the list (the first \n  version erroneously checked the opposite...)\n- for a failed \"merge\", like for an \"edit\", you do not need --amend both \n  in case of conflicts and no conflicts, and\n- the wrong usage of the \"--reedit-message\" flag was replaced by the \n  appropriate \"-F .msg -e\".\n\nMy plans are _not_ to turn this into git-rebase--interactive.sh, as I \noriginally planned. Instead, I will try to make git-rebase a builtin, and \nadd a \"-i\" flag which does the equivalent of this script.\n\nBTW would people be mad at me if I did _not_ imitate git-rebase.sh (call \nformat-patch and feed that into apply), but rather used cherry-pick \nthroughout?\n\nCiao,\nDscho\n\n-- snipsnap --\n#!/bin/sh\n#\n# Copyright (c) 2006 Johannes E. Schindelin\n\n# SHORT DESCRIPTION\n#\n# This is a really stupid script to arrange a patch series for submission.\n# It does not care for authorship or dates, all it does is make it easy\n# to fix up commits in the middle of a series, and rearrange commits.\n#\n# The original idea comes from Eric W. Biederman, in\n# http://article.gmane.org/gmane.comp.version-control.git/22407\n#\n# MOTIVATION\n#\n# It is extremely useful for this type of workflow:\n#\n#\t1. have a wonderful idea\n#\t2. hack on the code\n#\t3. prepare a series for submission\n#\t4. submit\n#\n# where the point (2) consists of several instances of\n#\n#\tA.1. finish something worthy of a commit\n#\tA.2. commit\n#\n# and/or\n#\n#\tB.1. realize that something does not work\n#\tB.2. fix that\n#\tB.3. commit it\n#\n# Sometimes the thing fixed in B.2. cannot be amended to the not-quite\n# perfect commit it fixes, because that commit is buried deeply in a\n# patch series.\n#\n# Use this script after plenty of \"A\"s and \"B\"s, by rearranging, and\n# possibly editing and merging commits.\n#\n# USAGE:\n#\n# The subcommand \"start\" will make a list of the commits in the patch\n# series <base>..HEAD, where <base> is the commit identiefied by the\n# parameter.\n#\n# It will automatically start an editor, where you can rearrange the\n# commits. The list looks more or less like this:\n#\n#\tpick deadbee The oneline of this commit\n#\tpick fa1afe1 The oneline of the next commit\n#\t...\n#\n# By replacing the command \"pick\" with \"edit\" you can tell\n# this script to stop the loop so you can fix up the commit by editing\n# files and/or the commit message.\n#\n# When replacing the command \"pick\" with \"merge, the script will merge\n# this commit's changes into the previous commit, munge the commit\n# messages of both, and open the commit message editor.\n#\n# In both cases, or when a \"pick\" does not succeed (because of merge\n# errors), the loop will stop to let you fix things, and you can continue\n# the loop with `git edit-patch-series continue`.\n\nUSAGE='(start <basecommit>| continue | reset [--force])'\n\n. git-sh-setup\nrequire_work_tree\n\nSERIESDIR=\"$(pwd)/.series\"\nTODO=\"$SERIESDIR\"/todo\nDONE=\"$SERIESDIR\"/done\n\nwarn () {\n\techo \"$@\" >&2\n}\n\nrequire_clean_work_tree () {\n\t# test if working tree is dirty\n\tgit rev-parse --verify HEAD > /dev/null &&\n\tgit update-index --refresh &&\n\ttest -z \"`git diff-files --name-only`\" &&\n\ttest -z \"`git diff-index --cached --name-only HEAD`\" ||\n\tdie \"Working tree is dirty\"\n}\n\nORIG_REFLOG_ACTION=\"$GIT_REFLOG_ACTION\"\n\ncomment_for_reflog () {\n\tif test -z \"$ORIG_REFLOG_ACTION\"; then\n\t\tGIT_REFLOG_ACTION=\"edit-patch-series($1)\"\n\t\texport GIT_REFLOG_ACTION\n\tfi\n}\n\nmark_action_done () {\n\tsed -n 1p < \"$TODO\" >> \"$DONE\"\n\tsed -n '2,$p' < \"$TODO\" >> \"$TODO\".new\n\tmv -f \"$TODO\".new \"$TODO\"\n}\n\ndo_next () {\n\tread command sha1 rest < \"$TODO\"\n\tcase \"$command\" in\n\t\\#)\n\t\tmark_action_done\n\t\tcontinue\n\t;;\n\tpick)\n\t\tcomment_for_reflog pick\n\n\t\tmark_action_done\n\t\tgit cherry-pick \"$sha1\" || \\\n\t\t\tdie \"Could not apply $sha1... $rest\"\n\t;;\n\tedit)\n\t\tcomment_for_reflog edit\n\n\t\tmark_action_done\n\t\tgit cherry-pick -n \"$sha1\" || \\\n\t\t\tdie \"Could not apply $sha1... $rest\"\n\t\twarn\n\t\twarn \"After you edited the files, commit the result with\"\n\t\twarn\n\t\twarn \"\tgit commit -F .msg -e\"\n\t\twarn\n\t\texit 0\n\t;;\n\tmerge)\n\t\tcomment_for_reflog merge\n\n\t\ttest -s \"$DONE\" ||\n\t\t\tdie \"Cannot 'merge' without a previous commit\"\n\n\t\tmark_action_done\n\t\tfailed=f\n\t\tgit cherry-pick -n \"$sha1\" || failed=t\n\t\tMSG=\"$SERIESDIR\"/message\n\t\techo \"# This is a combination of two commits.\" > \"$MSG\"\n\t\techo \"# The first commit's message is:\" >> \"$MSG\"\n\t\tgit cat-file commit HEAD | sed -n '/^$/,$p' >> \"$MSG\"\n\t\techo >> \"$MSG\"\n\t\techo \"# And this is the 2nd commit message:\" >> \"$MSG\"\n\t\techo >> \"$MSG\"\n\t\tcat .msg >> \"$MSG\"\n\t\tgit reset --soft HEAD^\n\t\tcase $failed in\n\t\tf)\n\t\t\t# Usually, I would use --amend here, but -F forbids it\n\t\t\tgit commit -F \"$MSG\" -e\n\t\t;;\n\t\tt)\n\t\t\tcp \"$MSG\" .msg\n\t\t\twarn\n\t\t\twarn \"Could not apply $sha1... $rest\"\n\t\t\twarn \"After you fixed that, commit the result with\"\n\t\t\twarn\n\t\t\twarn \"\tgit commit -F .msg -e\"\n\t\t\twarn\n\t\t\texit 1\n\t\tesac\n\t;;\n\t*)\n\t\twarn \"Unknown command: $command $sha1 $rest\"\n\t\twarn \"Please fix this in the file $TODO.\"\n\t\texit 1\n\tesac\n\ttest -s \"$TODO\" && continue\n\n\tHEAD=$(git rev-parse HEAD)\n\tHEADNAME=$(cat \"$SERIESDIR\"/head-name)\n\tgit update-ref $HEADNAME $HEAD &&\n\tgit symbolic-ref HEAD $HEADNAME &&\n\trm -rf \"$SERIESDIR\" &&\n\twarn \"Successfully edited patch series and updated $HEADNAME.\"\n\n\texit $?\n}\n\ncase \"$1\" in\nstart)\n\tcomment_for_reflog start\n\n\tHEAD=$(git rev-parse --verify HEAD) || die \"No HEAD?\"\n\tBASE=$(git rev-parse --verify \"$2\") || die \"Invalid base\"\n\n\t# DWIM: use the merge base\n\tMERGEBASE=$(git merge-base $HEAD $BASE)\n\tif test \"$BASE\" != \"$MERGEBASE\"\n\tthen\n\t\tCANDIDATES=\"$(git merge-base --all $HEAD $BASE)\"\n\t\tif test \"$MERGEBASE\" != \"$CANDIDATES\"\n\t\tthen\n\t\t\twarn \"Error: Multiple merge bases found:\"\n\t\t\twarn \"$CANDIDATES\"\n\t\t\trm -rf \"$SERIESDIR\"\n\t\t\texit 1\n\t\tfi\n\t\tBASE=$MERGEBASE\n\tfi\n\n\trequire_clean_work_tree\n\n\tgit var GIT_COMMITTER_IDENT >/dev/null || exit\n\n\ttest -d \"$SERIESDIR\" &&\n\t\tdie \"Edit-patch-series already started\"\n\n\ttest \"z$(git rev-list --parents $BASE..$HEAD | grep \" .* \")\" != z &&\n\t\tdie \"Cannot edit a series including merges\"\n\n\tmkdir \"$SERIESDIR\" || die \"Could not create temporary $SERIESDIR\"\n\tgit symbolic-ref HEAD > \"$SERIESDIR\"/head-name || die \"Could not get HEAD\"\n\n\techo $HEAD > \"$SERIESDIR\"/head\n\techo $BASE > \"$SERIESDIR\"/base\n\n\tcat > \"$TODO\" << EOF\n# Edit the patch series by exchanging lines.  The commits will be\n# arranged in the given order.  If you want to edit a commit, replace\n# the \"pick\" command with \"edit\".  If you want to merge the changes of\n# a commit A into a commit B, place A directly after B, and replace the\n# \"pick\" command with \"merge\".\nEOF\n\tgit rev-list --reverse --pretty=oneline --abbrev-commit --abbrev=7 \\\n\t\t$BASE..$HEAD | sed \"s/^/pick /\" >> \"$TODO\"\n\n\tcp \"$TODO\" \"$TODO\".backup\n\t${VISUAL:-${EDITOR:-vi}} \"$TODO\" || warn \"Could not execute editor\"\n\tif git diff --no-index \"$TODO\" \"$TODO\".backup > /dev/null\n\tthen\n\t\trm -rf \"$SERIESDIR\"\n\t\twarn \"No changes\"\n\t\texit 0\n\tfi\n\n\tgit checkout $BASE || die \"Could not checkout $BASE\"\n\n\twhile :\n\tdo\n\t\tdo_next\n\tdone\n;;\ncontinue)\n\tcomment_for_reflog continue\n\n\ttest -d \"$SERIESDIR\" || die \"No edit-patch-series running\"\n\n\trequire_clean_work_tree\n\n\twhile :\n\tdo\n\t\tdo_next\n\tdone\n;;\nreset)\n\tcomment_for_reflog reset\n\n\ttest -d \"$SERIESDIR\" || die \"No edit-patch-series running\"\n\n\tHEADNAME=$(cat \"$SERIESDIR\"/head-name)\n\tforce=\n\tcase \"$2\" in\n\t-f|--force)\n\t\tgit symbolic-ref HEAD $HEADNAME &&\n\t\tgit reset --hard\n\t;;\n\t*)\n\t\tgit checkout $HEADNAME\n\tesac &&\n\trm -rf \"$SERIESDIR\"\n;;\n*)\n\tusage\nesac\n"},{"id":"36033","messageId":"7vwt20o6qu.fsf@assigned-by-dhcp.cox.net","threadId":"6954","inReplyTo":"Pine.LNX.4.63.0703020020470.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Updated version, was Re: RFC: Patch editing","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-01T23:59:21Z","receivedAt":"2007-03-01T23:59:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> My plans are _not_ to turn this into git-rebase--interactive.sh, as I \n> originally planned. Instead, I will try to make git-rebase a builtin, and \n> add a \"-i\" flag which does the equivalent of this script.\n>\n> BTW would people be mad at me if I did _not_ imitate git-rebase.sh (call \n> format-patch and feed that into apply), but rather used cherry-pick \n> throughout?\n\nThen that C built-in would not replace git-rebase but only\n\"git-rebase -m\".\n\nI very often find it easier to deal with a conflicting rebase by\nediting the patch text, so yes I would imagine I would be rather\nupset, but I do not know about others.\n"}]}