threads / discuss / 1765

git-rev-list and git-format-patch script oddness

Subject: git-rev-list and git-format-patch script oddness

## tl;dr

9 messages between Sep 11, 2005 and Sep 12, 2005.

replies: 8people: 3as markdown or json

Martin Langhoff· Sep 11, 2005, 08:52 UTC · lore

When I run git-format-patch, it insists on outputting merges that have already been merged upstream, regardless of the fact that git-merge-base knows better.

Is there a way to get it to skip merged-in patches that git already has detected as merged upstream?

cheers,
martin
Johannes Schindelin· Sep 11, 2005, 09:20 UTC · re: Martin Langhoff · lore

Re: git-rev-list and git-format-patch script oddness

Hi,
On Sun, 11 Sep 2005, Martin Langhoff wrote:
Show 6 quoted lines
> When I run git-format-patch, it insists on outputting merges that have
> already been merged upstream, regardless of the fact that
> git-merge-base knows better.
> 
> Is there a way to get it to skip merged-in patches that git already
> has detected as merged upstream?
I always use something like
	git-format-patch HEAD ^origin

Hth, Dscho

Junio C Hamano· Sep 11, 2005, 20:32 UTC · re: Martin Langhoff · lore

[PATCH] Omit patches that have already been merged from format-patch output.

This switches the logic to pick which commits to include in the output from git-rev-list to git-cherry; as a side effect, 'format-patch ^up mine' would stop working, although up..mine would continue to work.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 Martin Langhoff <martin.langhoff@gmail.com> writes:
 > When I run git-format-patch, it insists on outputting merges that have
 > already been merged upstream, regardless of the fact that
 > git-merge-base knows better.
 >
 > Is there a way to get it to skip merged-in patches that git already
 > has detected as merged upstream?
 >
 > cheers,
 >
 > martin
 This is what the format-patch should have been from the beginning,
 although for hysterical raisins it was not the case (it predates
 git-cherry).  One thing I am reluctant about this is it breaks the
 exact example Johannes just posted.
 git-format-patch.sh |   38 +++++++++++++++++++++++++++-----------
 1 files changed, 27 insertions(+), 11 deletions(-)
9798f6dad84c9c3e39ed05c91d8e97fe4abc9222
diff --git a/git-format-patch.sh b/git-format-patch.sh
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -27,8 +27,6 @@ with applymbox.
 }
 
 diff_opts=
-IFS='
-'
 LF='
 '
 
@@ -61,7 +59,10 @@ do
     --output-directo|--output-director|--output-directory)
     case "$#" in 1) usage ;; esac; shift
     outdir="$1" ;;
-    -*)	diff_opts="$diff_opts$LF$1" ;;
+    -*' '* | -*"$LF"* | -*'	'*)
+	# Ignore diff option that has whitespace for now.
+	;;
+    -*)	diff_opts="$diff_opts$1 " ;;
     *) break ;;
     esac
     shift
@@ -72,16 +73,20 @@ tt)
 	die '--keep-subject and --numbered are incompatible.' ;;
 esac
 
-revpair=
+rev1= rev2=
 case "$#" in
 2)
-    revpair="$1..$2" ;;
+    rev1="$1" rev2="$2" ;;
 1)
     case "$1" in
     *..*)
-    	revpair="$1";;
+	rev1=`expr "$1" : '\(.*\)\.\.'`
+	rev2=`expr "$1" : '.*\.\.\(.*\)'`
+	;;
     *)
-	revpair="$1..HEAD";;
+        rev1="$1"
+	rev2="HEAD"
+	;;
     esac ;;
 *)
     usage ;;
@@ -127,10 +132,21 @@ _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 --no-merges --merge-order \
-	$(git-rev-parse --revs-only "$revpair") >$series
+git-cherry -v "$rev1" "$rev2" |
+while read sign rev comment
+do
+	case "$sign" in
+	'-')
+		echo >&2 "Merged already: $comment"
+		;;
+	*)
+		echo $rev
+		;;
+	esac
+done >$series
+
 total=`wc -l <$series | tr -dc "[0-9]"`
-i=$total
+i=1
 while read commit
 do
     git-cat-file commit "$commit" | git-stripspace >$commsg
@@ -145,7 +161,7 @@ do
     esac
 
     file=`printf '%04d-%stxt' $i "$title"`
-    i=`expr "$i" - 1`
+    i=`expr "$i" + 1`
     echo "* $file"
     {
 	mailScript='
Martin Langhoff· Sep 11, 2005, 21:08 UTC · re: Junio C Hamano · lore

Re: [PATCH] Omit patches that have already been merged from format-patch output.

>  git-cherry).  One thing I am reluctant about this is it breaks the
>  exact example Johannes just posted.

Well, Johannes example didn't work at all for me. Output was empty, when I was expecting 4~6 entries.

cheers,
martin
Martin Langhoff· Sep 11, 2005, 21:10 UTC · re: Junio C Hamano · lore

Re: [PATCH] Omit patches that have already been merged from format-patch output.

On 9/12/05, Junio C Hamano <junkio@cox.net> wrote:
> This switches the logic to pick which commits to include in the output
> from git-rev-list to git-cherry; as a side effect, 'format-patch ^up mine'
> would stop working, although up..mine would continue to work.

Also -- forgot to say thanks for this. I'm interested in porting this to cg-log as an option.

BTW, anyone heard of Baudis lately?
cheers,
martin
Martin Langhoff· Sep 12, 2005, 07:24 UTC · re: Junio C Hamano · lore

Re: [PATCH] Omit patches that have already been merged from format-patch output.

On 9/12/05, Junio C Hamano <junkio@cox.net> wrote:
> This switches the logic to pick which commits to include in the output
> from git-rev-list to git-cherry; as a side effect, 'format-patch ^up mine'
> would stop working, although up..mine would continue to work.
>

Hmmm - git-format-patch is now broken. Not sure if it's been this particular commit or a change in git-rev-list. The bottom line is that it will only create patches for my commits since the last merge.

This is broken when I work for a few days, merging often from my upstream. At the end of the dev cycle, I want to generate the patchbomb for upstream, and it only gives me the commits since the last merge-in of upstream.

OTOH, git-log-script is doing the same since I've updated today. Yesterday, both commands were behaving themselves...

cheers,
martin
Junio C Hamano· Sep 12, 2005, 11:48 UTC · re: Martin Langhoff · lore

Re: [PATCH] Omit patches that have already been merged from format-patch output.

Martin Langhoff <martin.langhoff@gmail.com> writes:
> Strike that. PEBCAK: my branch entry was pointing to the wrong place. Sorry.

Thanks for quick correction. Just from a curiosity, do you run GIT from the proposed updates branch? I am asking because that suspect git-format-patch change is supposed to be only in there.

I am somewhat seriously curious. How many of you on the list regularly look at what is in the proposed updates, and how many of you actually run it?

Martin Langhoff· Sep 12, 2005, 12:03 UTC · re: Junio C Hamano · lore

Re: [PATCH] Omit patches that have already been merged from format-patch output.

On 9/12/05, Junio C Hamano <junkio@cox.net> wrote:
Show 7 quoted lines
> Martin Langhoff <martin.langhoff@gmail.com> writes:
> 
> > Strike that. PEBCAK: my branch entry was pointing to the wrong place. Sorry.
> 
> Thanks for quick correction.  Just from a curiosity, do you run
> GIT from the proposed updates branch?  I am asking because that
> suspect git-format-patch change is supposed to be only in there.
 
I'm running git on ~5 different machines. On the box where I do my
development, I have both 'master' and 'pu' checkouts, but mostly
master. Elsewhere, I track master, with updates every few days, when
my gut feeling is that things aren't too risky. On the servers (add ~4
servers to the list), I deploy only tagged versions, usually from the
Debian package.

And it was a total PEBCAK. I had just pulled in your latest merges to master and built/installed on a dev box, things were looking odd and I jumped the gun badly. As you point out, I didn't even have the patch in.

cheers,
martin

← back to recent threads