{"thread":{"id":"1447","subject":"Re: git-format-patch-script bug?","startedAt":"2005-08-07T20:53:42Z","lastAt":"2005-08-08T06:09:52Z","messageCount":3,"participants":["Marco Costalba","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"6913","messageId":"20050807205342.8497.qmail@web26304.mail.ukl.yahoo.com","threadId":"1447","inReplyTo":null,"subject":"Re: git-format-patch-script bug?","fromName":"Marco Costalba","fromEmail":"mcostalba@yahoo.it","sentAt":"2005-08-07T20:53:42Z","receivedAt":"2005-08-07T20:53:42Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n\n>\n>I am reluctant to actually do this right away, because this is\n>an incompatible change from the current format:\n>\n>    $ git format-patch his mine\n>\n\n\nOf course this breaks qgit interface to git-format-patch-script\nbut if you think it's better this way....\n\n\n>The same goes for rebase (and therefore cherry).  I could use an\n>ugly heuristics for backward compatibility like \"if invoked with\n>exactly two parameters, and there is no prefix ^ nor .. in these\n>two, then use the old interpretation, otherwise give them to\n>rev-parse\", but I think this is ugly.\n>\n>So my question to the list is: do people mind this change?\n>\n\nI think it's ugly too, in this early phase of git development \nbetter go with proper solution then compatibility compromises.\n\nA suggestion I would like to present is if can be useful a\nkind of scheduling/list of planned compatibility break features so\n that developers can know in advance when and what will break\n their stuff and users can know when they will need to upgrade.\n\n\n\n\n\n\n\n\t\t\n____________________________________________________\nStart your day with Yahoo! - make it your home page \nhttp://www.yahoo.com/r/hs \n \n"},{"id":"6916","messageId":"7vhde1pg5b.fsf@assigned-by-dhcp.cox.net","threadId":"1447","inReplyTo":"20050807205342.8497.qmail@web26304.mail.ukl.yahoo.com","subject":"backward compatible changes to format-patch, rebase, cherry and fetch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-07T21:54:08Z","receivedAt":"2005-08-07T21:54:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marco Costalba <mcostalba@yahoo.it> writes:\n\n> A suggestion I would like to present is if can be useful a\n> kind of scheduling/list of planned compatibility break features so\n>  that developers can know in advance when and what will break\n>  their stuff and users can know when they will need to upgrade.\n\nYes, that is a valid concern.  Fortunately this is the only\nbackward incompatible thing I currently see on the horizon.\n\nHere are the list of things I am currently thinking about\nupdating.\n\n - The format-patch, rebase and cherry parameters you already\n   know about.  I do not think the \"ugly\" two parameter\n   compromise is too much baggage to keep around, so my original\n   plan was not to break the backward compatibility.\n\n - Fetch and pull.  Currently git fetch (and git pull) takes the\n   following forms:\n\n    $ git fetch <remote>\n    $ git fetch <remote> <head>\n    $ git fetch <remote> tag <tag>\n\n   I am planning to update it to take:\n\n    $ git fetch <remote> <refspec>...\n\n   but in a backward compatible way.\n\n   <refspec> can take the following forms:\n\n    - A <refspec> of form \"<src>:<dst>\" is to fetch the objects\n      needed for the remote ref that matches <src>, and if <dst>\n      is not empty, store it to the local that matches <dst>.\n      The same rule as \"git push\" applies for <dst>.  <src> can\n      be either a ref pattern or the SHA1 object name.  If <src>\n      is not an SHA1 object name, and it does not match exactly\n      one remote ref, it is an error.\n\n    - \"tag\" followed by <next> is just an old way of saying\n      \"refs/tags/<next>:refs/tags/<next>\"; this mimics the\n      current behaviour of the third form above and means \"fetch\n      that tag and store it under the same name\".\n\n    - A single token <refspec> without colon is a shorthand for\n      \"<refspec>:\"  That is, \"fetch that ref but do not store\n      anywhere\".\n\n    - when there is no <refspec> specified\n\n      - if <remote> is the name of a file under\n        $GIT_DIR/branches/ (i.e. a shorthand without trailing\n        path), then it is the same as giving a single <refspec>\n        \"<remote-name>:refs/heads/<remote>\" on the command line,\n        where <remote-name> is the remote branch name (defaults\n        to HEAD, but can be overridden by .git/branches/<remote>\n        file having the URL fragment notation).  That is, \"fetch\n        that branch head and store it in refs/heads/<remote>\".\n\n      - otherwise, it is the same as giving a single <refspec>\n        that is \"HEAD:\".\n\n    The SHA1 object names of fetched refs are stored in FETCH_HEAD\n    [*1*], one name per line.  There will be an empty line for the\n    ref that was not available on the remote end.\n\n  I have pull enhancements that takes more than one remote refs\n  in mind, but that will not be in the immediate future.  What\n  will happen when the above fetch enhancement happens is that\n  pull will accept the same set of parameters as the updated\n  fetch does, runs the fetch, but refuses to run resolve when\n  more than one remote ref is involved.  When resolve is updated\n  to do an octopus (or a king ghidorah), this restriction can be\n  lifted without breaking backward compatibility.\n\n[Footnote]\n*1* git-fetch-pack most likely will just output SHA1 to its\nstandard output like Linus suggested earlier.\n"},{"id":"6923","messageId":"7vpsspgdsf.fsf@assigned-by-dhcp.cox.net","threadId":"1447","inReplyTo":"20050807205342.8497.qmail@web26304.mail.ukl.yahoo.com","subject":"[PATCH] Teach format-patch, rebase and cherry a..b format","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-08T06:09:52Z","receivedAt":"2005-08-08T06:09:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Although these commands take only begin and end, not necessarily\ngeneric SHA1 expressions rev-parse supports, supporting a..b\nnotation is good for consistency.  This commit adds such without\nbreaking backward compatibility.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\nUnlike the outline I suggested in an earlier message, this adds\nsupport for only a single parameter \"a..b\" format, while\nretaining the original code which takes two parameters.  Meant\nto be fully backward compatible not to break qgit and friends.\n\n git-cherry              |   25 +++++++++++++++++--------\n git-format-patch-script |   21 +++++++++++++++------\n git-rebase-script       |   23 +++++++++++++++--------\n 3 files changed, 47 insertions(+), 22 deletions(-)\n\nc67e91fad243565423b08a55f63947bd3e36c5a3\ndiff --git a/git-cherry b/git-cherry\n--- a/git-cherry\n+++ b/git-cherry\n@@ -3,6 +3,8 @@\n # Copyright (c) 2005 Junio C Hamano.\n #\n \n+. git-sh-setup-script || die \"Not a git archive.\"\n+\n usage=\"usage: $0 \"'<upstream> [<head>]\n \n              __*__*__*__*__> <upstream>\n@@ -18,8 +20,8 @@ upstream, it is shown on the standard ou\n The output is intended to be used as:\n \n     OLD_HEAD=$(git-rev-parse HEAD)\n-    git-rev-parse linus >${GIT_DIR-.}/HEAD\n-    git-cherry linus OLD_HEAD |\n+    git-rev-parse upstream >${GIT_DIR-.}/HEAD\n+    git-cherry upstream $OLD_HEAD |\n     while read commit\n     do\n         GIT_EXTERNAL_DIFF=git-apply-patch-script git-diff-tree -p \"$commit\" &&\n@@ -27,20 +29,27 @@ The output is intended to be used as:\n     done\n '\n \n+case \"$#,$1\" in\n+1,*..*)\n+    upstream=$(expr \"$1\" : '\\(.*\\)\\.\\.') ours=$(expr \"$1\" : '.*\\.\\.\\(.*\\)$')\n+    set x \"$upstream\" \"$ours\"\n+    shift ;;\n+esac\n+\n case \"$#\" in\n-1) linus=`git-rev-parse --verify \"$1\"` &&\n-   junio=`git-rev-parse --verify HEAD` || exit\n+1) upstream=`git-rev-parse --verify \"$1\"` &&\n+   ours=`git-rev-parse --verify HEAD` || exit\n    ;;\n-2) linus=`git-rev-parse --verify \"$1\"` &&\n-   junio=`git-rev-parse --verify \"$2\"` || exit\n+2) upstream=`git-rev-parse --verify \"$1\"` &&\n+   ours=`git-rev-parse --verify \"$2\"` || exit\n    ;;\n *) echo >&2 \"$usage\"; exit 1 ;;\n esac\n \n # Note that these list commits in reverse order;\n # not that the order in inup matters...\n-inup=`git-rev-list ^$junio $linus` &&\n-ours=`git-rev-list $junio ^$linus` || exit\n+inup=`git-rev-list ^$ours $upstream` &&\n+ours=`git-rev-list $ours ^$upstream` || exit\n \n tmp=.cherry-tmp$$\n patch=$tmp-patch\ndiff --git a/git-format-patch-script b/git-format-patch-script\n--- a/git-format-patch-script\n+++ b/git-format-patch-script\n@@ -3,6 +3,8 @@\n # Copyright (c) 2005 Junio C Hamano\n #\n \n+. git-sh-setup-script || die \"Not a git archive.\"\n+\n usage () {\n     echo >&2 \"usage: $0\"' [-n] [-o dir] [--mbox] [--check] [-<diff options>...] upstream [ our-head ]\n \n@@ -60,13 +62,20 @@ do\n     shift\n done\n \n+revpair=\n case \"$#\" in\n-2)    linus=\"$1\" junio=\"$2\" ;;\n-1)    linus=\"$1\" junio=HEAD ;;\n-*)    usage ;;\n+2)\n+    revpair=\"$1..$2\" ;;\n+1)\n+    case \"$1\" in\n+    *..*)\n+    \trevpair=\"$1\";;\n+    *)\n+\trevpair=\"$1..HEAD\";;\n+    esac ;;\n+*)\n+    usage ;;\n esac\n-junio=`git-rev-parse --verify \"$junio\"`\n-linus=`git-rev-parse --verify \"$linus\"`\n \n me=`git-var GIT_AUTHOR_IDENT | sed -e 's/>.*/>/'`\n \n@@ -108,7 +117,7 @@ _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0\n _x40=\"$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40\"\n stripCommitHead='/^'\"$_x40\"' (from '\"$_x40\"')$/d'\n \n-git-rev-list --merge-order \"$junio\" \"^$linus\" >$series\n+git-rev-list --merge-order $(git-rev-parse --revs-only \"$revpair\") >$series\n total=`wc -l <$series | tr -dc \"[0-9]\"`\n i=$total\n while read commit\ndiff --git a/git-rebase-script b/git-rebase-script\n--- a/git-rebase-script\n+++ b/git-rebase-script\n@@ -3,25 +3,32 @@\n # Copyright (c) 2005 Junio C Hamano.\n #\n \n+. git-sh-setup-script || die \"Not a git archive.\"\n+\n usage=\"usage: $0 \"'<upstream> [<head>]\n \n Uses output from git-cherry to rebase local commits to the new head of\n upstream tree.'\n \n-: ${GIT_DIR=.git}\n+case \"$#,$1\" in\n+1,*..*)\n+    upstream=$(expr \"$1\" : '\\(.*\\)\\.\\.') ours=$(expr \"$1\" : '.*\\.\\.\\(.*\\)$')\n+    set x \"$upstream\" \"$ours\"\n+    shift ;;\n+esac\n \n case \"$#\" in\n-1) linus=`git-rev-parse --verify \"$1\"` &&\n-   junio=`git-rev-parse --verify HEAD` || exit\n+1) upstream=`git-rev-parse --verify \"$1\"` &&\n+   ours=`git-rev-parse --verify HEAD` || exit\n    ;;\n-2) linus=`git-rev-parse --verify \"$1\"` &&\n-   junio=`git-rev-parse --verify \"$2\"` || exit\n+2) upstream=`git-rev-parse --verify \"$1\"` &&\n+   ours=`git-rev-parse --verify \"$2\"` || exit\n    ;;\n *) echo >&2 \"$usage\"; exit 1 ;;\n esac\n \n-git-read-tree -m -u $junio $linus &&\n-echo \"$linus\" >\"$GIT_DIR/HEAD\" || exit\n+git-read-tree -m -u $ours $upstream &&\n+echo \"$upstream\" >\"$GIT_DIR/HEAD\" || exit\n \n tmp=.rebase-tmp$$\n fail=$tmp-fail\n@@ -29,7 +36,7 @@ trap \"rm -rf $tmp-*\" 0 1 2 3 15\n \n >$fail\n \n-git-cherry $linus $junio |\n+git-cherry $upstream $ours |\n while read sign commit\n do\n \tcase \"$sign\" in\n"}]}