Re: git-format-patch-script bug?

git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed

* Re: git-format-patch-script bug?
@ 2005-08-07 20:53 Marco Costalba
  2005-08-07 21:54 ` backward compatible changes to format-patch, rebase, cherry and fetch Junio C Hamano
  2005-08-08  6:09 ` [PATCH] Teach format-patch, rebase and cherry a..b format Junio C Hamano
  0 siblings, 2 replies; 3+ messages in thread
From: Marco Costalba @ 2005-08-07 20:53 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Eric W. Biederman, git

Junio C Hamano wrote:

>
>I am reluctant to actually do this right away, because this is
>an incompatible change from the current format:
>
>    $ git format-patch his mine
>

Of course this breaks qgit interface to git-format-patch-script
but if you think it's better this way....

>The same goes for rebase (and therefore cherry).  I could use an
>ugly heuristics for backward compatibility like "if invoked with
>exactly two parameters, and there is no prefix ^ nor .. in these
>two, then use the old interpretation, otherwise give them to
>rev-parse", but I think this is ugly.
>
>So my question to the list is: do people mind this change?
>

I think it's ugly too, in this early phase of git development 
better go with proper solution then compatibility compromises.

A suggestion I would like to present is if can be useful a
kind of scheduling/list of planned compatibility break features so
 that developers can know in advance when and what will break
 their stuff and users can know when they will need to upgrade.

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* backward compatible changes to format-patch, rebase, cherry and fetch
  2005-08-07 20:53 git-format-patch-script bug? Marco Costalba
@ 2005-08-07 21:54 ` Junio C Hamano
  2005-08-08  6:09 ` [PATCH] Teach format-patch, rebase and cherry a..b format Junio C Hamano
  1 sibling, 0 replies; 3+ messages in thread
From: Junio C Hamano @ 2005-08-07 21:54 UTC (permalink / raw)
  To: Marco Costalba; +Cc: git

Marco Costalba <mcostalba@yahoo.it> writes:

> A suggestion I would like to present is if can be useful a
> kind of scheduling/list of planned compatibility break features so
>  that developers can know in advance when and what will break
>  their stuff and users can know when they will need to upgrade.

Yes, that is a valid concern.  Fortunately this is the only
backward incompatible thing I currently see on the horizon.

Here are the list of things I am currently thinking about
updating.

 - The format-patch, rebase and cherry parameters you already
   know about.  I do not think the "ugly" two parameter
   compromise is too much baggage to keep around, so my original
   plan was not to break the backward compatibility.

 - Fetch and pull.  Currently git fetch (and git pull) takes the
   following forms:

    $ git fetch <remote>
    $ git fetch <remote> <head>
    $ git fetch <remote> tag <tag>

   I am planning to update it to take:

    $ git fetch <remote> <refspec>...

   but in a backward compatible way.

   <refspec> can take the following forms:

    - A <refspec> of form "<src>:<dst>" is to fetch the objects
      needed for the remote ref that matches <src>, and if <dst>
      is not empty, store it to the local that matches <dst>.
      The same rule as "git push" applies for <dst>.  <src> can
      be either a ref pattern or the SHA1 object name.  If <src>
      is not an SHA1 object name, and it does not match exactly
      one remote ref, it is an error.

    - "tag" followed by <next> is just an old way of saying
      "refs/tags/<next>:refs/tags/<next>"; this mimics the
      current behaviour of the third form above and means "fetch
      that tag and store it under the same name".

    - A single token <refspec> without colon is a shorthand for
      "<refspec>:"  That is, "fetch that ref but do not store
      anywhere".

    - when there is no <refspec> specified

      - if <remote> is the name of a file under
        $GIT_DIR/branches/ (i.e. a shorthand without trailing
        path), then it is the same as giving a single <refspec>
        "<remote-name>:refs/heads/<remote>" on the command line,
        where <remote-name> is the remote branch name (defaults
        to HEAD, but can be overridden by .git/branches/<remote>
        file having the URL fragment notation).  That is, "fetch
        that branch head and store it in refs/heads/<remote>".

      - otherwise, it is the same as giving a single <refspec>
        that is "HEAD:".

    The SHA1 object names of fetched refs are stored in FETCH_HEAD
    [*1*], one name per line.  There will be an empty line for the
    ref that was not available on the remote end.

  I have pull enhancements that takes more than one remote refs
  in mind, but that will not be in the immediate future.  What
  will happen when the above fetch enhancement happens is that
  pull will accept the same set of parameters as the updated
  fetch does, runs the fetch, but refuses to run resolve when
  more than one remote ref is involved.  When resolve is updated
  to do an octopus (or a king ghidorah), this restriction can be
  lifted without breaking backward compatibility.

[Footnote]
*1* git-fetch-pack most likely will just output SHA1 to its
standard output like Linus suggested earlier.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [PATCH] Teach format-patch, rebase and cherry a..b format
  2005-08-07 20:53 git-format-patch-script bug? Marco Costalba
  2005-08-07 21:54 ` backward compatible changes to format-patch, rebase, cherry and fetch Junio C Hamano
@ 2005-08-08  6:09 ` Junio C Hamano
  1 sibling, 0 replies; 3+ messages in thread
From: Junio C Hamano @ 2005-08-08  6:09 UTC (permalink / raw)
  To: git; +Cc: Marco Costalba

Although these commands take only begin and end, not necessarily
generic SHA1 expressions rev-parse supports, supporting a..b
notation is good for consistency.  This commit adds such without
breaking backward compatibility.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

Unlike the outline I suggested in an earlier message, this adds
support for only a single parameter "a..b" format, while
retaining the original code which takes two parameters.  Meant
to be fully backward compatible not to break qgit and friends.

 git-cherry              |   25 +++++++++++++++++--------
 git-format-patch-script |   21 +++++++++++++++------
 git-rebase-script       |   23 +++++++++++++++--------
 3 files changed, 47 insertions(+), 22 deletions(-)

c67e91fad243565423b08a55f63947bd3e36c5a3
diff --git a/git-cherry b/git-cherry
--- a/git-cherry
+++ b/git-cherry
@@ -3,6 +3,8 @@
 # Copyright (c) 2005 Junio C Hamano.
 #
 
+. git-sh-setup-script || die "Not a git archive."
+
 usage="usage: $0 "'<upstream> [<head>]
 
              __*__*__*__*__> <upstream>
@@ -18,8 +20,8 @@ upstream, it is shown on the standard ou
 The output is intended to be used as:
 
     OLD_HEAD=$(git-rev-parse HEAD)
-    git-rev-parse linus >${GIT_DIR-.}/HEAD
-    git-cherry linus OLD_HEAD |
+    git-rev-parse upstream >${GIT_DIR-.}/HEAD
+    git-cherry upstream $OLD_HEAD |
     while read commit
     do
         GIT_EXTERNAL_DIFF=git-apply-patch-script git-diff-tree -p "$commit" &&
@@ -27,20 +29,27 @@ The output is intended to be used as:
     done
 '
 
+case "$#,$1" in
+1,*..*)
+    upstream=$(expr "$1" : '\(.*\)\.\.') ours=$(expr "$1" : '.*\.\.\(.*\)$')
+    set x "$upstream" "$ours"
+    shift ;;
+esac
+
 case "$#" in
-1) linus=`git-rev-parse --verify "$1"` &&
-   junio=`git-rev-parse --verify HEAD` || exit
+1) upstream=`git-rev-parse --verify "$1"` &&
+   ours=`git-rev-parse --verify HEAD` || exit
    ;;
-2) linus=`git-rev-parse --verify "$1"` &&
-   junio=`git-rev-parse --verify "$2"` || exit
+2) upstream=`git-rev-parse --verify "$1"` &&
+   ours=`git-rev-parse --verify "$2"` || exit
    ;;
 *) echo >&2 "$usage"; exit 1 ;;
 esac
 
 # Note that these list commits in reverse order;
 # not that the order in inup matters...
-inup=`git-rev-list ^$junio $linus` &&
-ours=`git-rev-list $junio ^$linus` || exit
+inup=`git-rev-list ^$ours $upstream` &&
+ours=`git-rev-list $ours ^$upstream` || exit
 
 tmp=.cherry-tmp$$
 patch=$tmp-patch
diff --git a/git-format-patch-script b/git-format-patch-script
--- a/git-format-patch-script
+++ b/git-format-patch-script
@@ -3,6 +3,8 @@
 # Copyright (c) 2005 Junio C Hamano
 #
 
+. git-sh-setup-script || die "Not a git archive."
+
 usage () {
     echo >&2 "usage: $0"' [-n] [-o dir] [--mbox] [--check] [-<diff options>...] upstream [ our-head ]
 
@@ -60,13 +62,20 @@ do
     shift
 done
 
+revpair=
 case "$#" in
-2)    linus="$1" junio="$2" ;;
-1)    linus="$1" junio=HEAD ;;
-*)    usage ;;
+2)
+    revpair="$1..$2" ;;
+1)
+    case "$1" in
+    *..*)
+    	revpair="$1";;
+    *)
+	revpair="$1..HEAD";;
+    esac ;;
+*)
+    usage ;;
 esac
-junio=`git-rev-parse --verify "$junio"`
-linus=`git-rev-parse --verify "$linus"`
 
 me=`git-var GIT_AUTHOR_IDENT | sed -e 's/>.*/>/'`
 
@@ -108,7 +117,7 @@ _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0
 _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
 stripCommitHead='/^'"$_x40"' (from '"$_x40"')$/d'
 
-git-rev-list --merge-order "$junio" "^$linus" >$series
+git-rev-list --merge-order $(git-rev-parse --revs-only "$revpair") >$series
 total=`wc -l <$series | tr -dc "[0-9]"`
 i=$total
 while read commit
diff --git a/git-rebase-script b/git-rebase-script
--- a/git-rebase-script
+++ b/git-rebase-script
@@ -3,25 +3,32 @@
 # Copyright (c) 2005 Junio C Hamano.
 #
 
+. git-sh-setup-script || die "Not a git archive."
+
 usage="usage: $0 "'<upstream> [<head>]
 
 Uses output from git-cherry to rebase local commits to the new head of
 upstream tree.'
 
-: ${GIT_DIR=.git}
+case "$#,$1" in
+1,*..*)
+    upstream=$(expr "$1" : '\(.*\)\.\.') ours=$(expr "$1" : '.*\.\.\(.*\)$')
+    set x "$upstream" "$ours"
+    shift ;;
+esac
 
 case "$#" in
-1) linus=`git-rev-parse --verify "$1"` &&
-   junio=`git-rev-parse --verify HEAD` || exit
+1) upstream=`git-rev-parse --verify "$1"` &&
+   ours=`git-rev-parse --verify HEAD` || exit
    ;;
-2) linus=`git-rev-parse --verify "$1"` &&
-   junio=`git-rev-parse --verify "$2"` || exit
+2) upstream=`git-rev-parse --verify "$1"` &&
+   ours=`git-rev-parse --verify "$2"` || exit
    ;;
 *) echo >&2 "$usage"; exit 1 ;;
 esac
 
-git-read-tree -m -u $junio $linus &&
-echo "$linus" >"$GIT_DIR/HEAD" || exit
+git-read-tree -m -u $ours $upstream &&
+echo "$upstream" >"$GIT_DIR/HEAD" || exit
 
 tmp=.rebase-tmp$$
 fail=$tmp-fail
@@ -29,7 +36,7 @@ trap "rm -rf $tmp-*" 0 1 2 3 15
 
 >$fail
 
-git-cherry $linus $junio |
+git-cherry $upstream $ours |
 while read sign commit
 do
 	case "$sign" in

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-08-08  6:11 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-07 20:53 git-format-patch-script bug? Marco Costalba
2005-08-07 21:54 ` backward compatible changes to format-patch, rebase, cherry and fetch Junio C Hamano
2005-08-08  6:09 ` [PATCH] Teach format-patch, rebase and cherry a..b format Junio C Hamano

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