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