Linus Torvalds <torvalds@osdl.org> writes: > For example, I use git-applypatch _only_ through git-applymbox. Ie > non-interactively. I definitely do _not_ want it to try random other trees > unless I tell it to, especially when applying a series of 175 patches in > one go. My understanding of your workflow, from reading your earlier posts to the git list, is: * Read bunch of mails -- mostly concentrating on the description in the log message and skimming the code -- while saving the worthy patches into a 'to-apply' mbox. * Review 'to-aplly' mbox again, perhaps excluding not-so-good ones. When you need to fix log messages, that is done in this step. * Run git-applymbox on the surviving messages in a batch mode, processing 175 patches in one go. What is your workflow after seeing that the 47th patch among 175 patches fails to apply? I understand you run git-applymbox without -q, so it immediately fails and exits there. You would have split mails, numbered from 0001 to 0175 in the .dotest directory, with msg, patch and info files from the mail 0047 left behind. I presume that, if the conflict/fuzz is manageably small, you would hand edit the file 0047 to make the diff part to apply cleanly, and then run 'git-applymbox -c .dotest/0047'. I would understand you would be able to resume and process the rest 128 patches this way. Once you mentioned that if the conflict is too great you would apply the patch to an old version that the patch sender based her work on, and merge using git (this was the direct inspiration of the change to git-applypatch). What I am wondering is how that step fits in your workflow. Do you do this by the following sequence? * Temporarily switch to a new throwaway branch for merge from the known old version with 'git checkout -b test v2.6.12'; * 'git apply --index <.dotest/patch' to apply the patch, and perhaps 'git commit -F .dotest/msg'; * Switch back to the master branch with 'git checkout master'; * Merge them with 'git resolve master test <some message>', which may leave conflicts, in which case you would hand resolve, and say 'git commit -F .dotest/msg'. Then 'git branch -d test' to get rid of the throwaway branch. * Resume the patch application with 'git-applymbox -c .dotest/0048'. Well, I just noticed that it is not even immediately obvious that the 47th of the 175 patches failed to apply from the git-applymbox batch output (it shows how I do not process really many patches myself X-<). Is there anything I can do to improve this? For example, after git-applypatch exits with 0 exit status we could remove the split mail file, like this: ------------ diff --git a/git-applymbox.sh b/git-applymbox.sh --- a/git-applymbox.sh +++ b/git-applymbox.sh @@ -82,7 +82,11 @@ do do git-applypatch .dotest/msg-clean .dotest/patch .dotest/info "$signoff" case "$?" in - 0 | 2 ) + 0) + # Remove the cleanly applied one to reduce clutter. + rm -f .dotest/$i + ;; + 2) # 2 is a special exit code from applypatch to indicate that # the patch wasn't applied, but continue anyway ;; ------------ Or it may not matter at all if your "after failure" workflow is very different from what I've been imagining. This is the primarily reason why I would like to understand your workflow better. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Wed Oct 05 16:59:15 2005
This archive was generated by hypermail 2.1.8 : 2005-10-05 16:59:18 EST