[PATCH] rebase -m: Fix incorrect short-logs of already applied commits.

[PATCH] rebase -m: Fix incorrect short-logs of already applied commits.

[Johannes Sixt]

When a topic branch is rebased, some of whose commits are already
cherry-picked upstream:

    o--X--A--B--Y    <- master
     \
      A--B--Z        <- topic

then 'git rebase -m master' would report:

    Already applied: 0001 Y
    Already applied: 0002 Y

With this fix it reports the expected:

    Already applied: 0001 A
    Already applied: 0002 B

As an added bonus, this change also avoids 'echo' of a commit message,
which might contain escapements.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 git-rebase.sh |   13 ++++++++-----
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index cbafa14..9cf0056 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -59,20 +59,23 @@ continue_merge () {
 		die "$RESOLVEMSG"
 	fi
 
+	cmt=`cat $dotest/current`
 	if ! git diff-index --quiet HEAD
 	then
-		if ! git-commit -C "`cat $dotest/current`"
+		if ! git-commit -C "$cmt"
 		then
 			echo "Commit failed, please do not call \"git commit\""
 			echo "directly, but instead do one of the following: "
 			die "$RESOLVEMSG"
 		fi
-		printf "Committed: %0${prec}d" $msgnum
+		printf "Committed: %0${prec}d " $msgnum
+		git rev-list --pretty=oneline -1 HEAD | \
+			sed 's/^[a-f0-9]\+ //'
 	else
-		printf "Already applied: %0${prec}d" $msgnum
+		printf "Already applied: %0${prec}d " $msgnum
+		git rev-list --pretty=oneline -1 "$cmt" | \
+			sed 's/^[a-f0-9]\+ //'
 	fi
-	echo ' '`git rev-list --pretty=oneline -1 HEAD | \
-				sed 's/^[a-f0-9]\+ //'`
 
 	prev_head=`git rev-parse HEAD^0`
 	# save the resulting commit so we can read-tree on it later
-- 
1.5.3.rc6.55.ga005

Re: [PATCH] rebase -m: Fix incorrect short-logs of already applied commits.

[Junio C Hamano]

Johannes Sixt <johannes.sixt@telecom.at> writes:

> When a topic branch is rebased, some of whose commits are already
> cherry-picked upstream:
>
>     o--X--A--B--Y    <- master
>      \
>       A--B--Z        <- topic
>
> then 'git rebase -m master' would report:
>
>     Already applied: 0001 Y
>     Already applied: 0002 Y
>
> With this fix it reports the expected:
>
>     Already applied: 0001 A
>     Already applied: 0002 B

Well, good eyes.  A new test script would have been nice.

> +		printf "Already applied: %0${prec}d " $msgnum
> +		git rev-list --pretty=oneline -1 "$cmt" | \
> +			sed 's/^[a-f0-9]\+ //'

This is not your fault but I just noticed this sed script that
steps outside BRE [*1*, *2*].  In this case we do not even need
to use '\+', as we know what we are reading.

A few "sed" disciplines to keep things portable I tried to
follow so far are:

 - Always use '-e' to introduce expression;
 - Don't use two expressions concatenated with ';' in a single
   string; multi-line scripts tend to be more portable;
 - Do not use one-or-more "\+", that's not BRE.

I would propose doing the attached patch on top of yours.
Opinion?

[Footnotes] 

*1* http://www.opengroup.org/onlinepubs/000095399/utilities/sed.html
*2* http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap09.html#tag_09_03

---

 git-rebase.sh             |    5 +----
 t/t3406-rebase-message.sh |   44 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 45 insertions(+), 4 deletions(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index 9cf0056..3bd66b0 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -69,13 +69,10 @@ continue_merge () {
 			die "$RESOLVEMSG"
 		fi
 		printf "Committed: %0${prec}d " $msgnum
-		git rev-list --pretty=oneline -1 HEAD | \
-			sed 's/^[a-f0-9]\+ //'
 	else
 		printf "Already applied: %0${prec}d " $msgnum
-		git rev-list --pretty=oneline -1 "$cmt" | \
-			sed 's/^[a-f0-9]\+ //'
 	fi
+	git rev-list --pretty=oneline -1 "$cmt" | sed -e 's/^[^ ]* //'
 
 	prev_head=`git rev-parse HEAD^0`
 	# save the resulting commit so we can read-tree on it later
diff --git a/t/t3406-rebase-message.sh b/t/t3406-rebase-message.sh
new file mode 100755
index 0000000..332b2b2
--- /dev/null
+++ b/t/t3406-rebase-message.sh
@@ -0,0 +1,44 @@
+#!/bin/sh
+
+test_description='messages from rebase operation'
+
+. ./test-lib.sh
+
+quick_one () {
+	echo "$1" >"file$1" &&
+	git add "file$1" &&
+	test_tick &&
+	git commit -m "$1"
+}
+
+test_expect_success setup '
+	quick_one O &&
+	git branch topic &&
+	quick_one X &&
+	quick_one A &&
+	quick_one B &&
+	quick_one Y &&
+
+	git checkout topic &&
+	quick_one A &&
+	quick_one B &&
+	quick_one Z
+
+'
+
+cat >expect <<\EOF
+Already applied: 0001 A
+Already applied: 0002 B
+Committed: 0003 Z
+EOF
+
+test_expect_success 'rebase -m' '
+
+	git rebase -m master >report &&
+	sed -n -e "/^Already applied: /p" \
+		-e "/^Committed: /p" report >actual &&
+	diff -u expect actual
+
+'
+
+test_done

[PATCH] rebase--interactive: do not use one-or-more (\+) in sed.

[Junio C Hamano]

This is a continuation of the other one to avoid one-or-more operator
in sed.  At the same time, it actually tightens error checking,
because the numbers in the squash messages are not padded with
leading zero and cannot begin with 0.

With this, I think we do not have any more use of one-or-more
(\+) in sed scripts.

---

 git-rebase--interactive.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index ec798a1..abc2b1c 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -190,7 +190,7 @@ nth_string () {
 
 make_squash_message () {
 	if test -f "$SQUASH_MSG"; then
-		COUNT=$(($(sed -n "s/^# This is [^0-9]*\([0-9]\+\).*/\1/p" \
+		COUNT=$(($(sed -n "s/^# This is [^0-9]*\([1-9][0-9]*\).*/\1/p" \
 			< "$SQUASH_MSG" | tail -n 1)+1))
 		echo "# This is a combination of $COUNT commits."
 		sed -n "2,\$p" < "$SQUASH_MSG"

Re: [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.

[Johannes Schindelin]

Hi,

On Sat, 1 Sep 2007, Junio C Hamano wrote:

> This is a continuation of the other one to avoid one-or-more operator
> in sed.  At the same time, it actually tightens error checking,
> because the numbers in the squash messages are not padded with
> leading zero and cannot begin with 0.
> 
> With this, I think we do not have any more use of one-or-more
> (\+) in sed scripts.
> 
> ---
> 
>  git-rebase--interactive.sh |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index ec798a1..abc2b1c 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -190,7 +190,7 @@ nth_string () {
>  
>  make_squash_message () {
>  	if test -f "$SQUASH_MSG"; then
> -		COUNT=$(($(sed -n "s/^# This is [^0-9]*\([0-9]\+\).*/\1/p" \
> +		COUNT=$(($(sed -n "s/^# This is [^0-9]*\([1-9][0-9]*\).*/\1/p" \

Looks obviously correct to me... Ack.

Ciao,
Dscho

Re: [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.

[David Kastrup]

Junio C Hamano <gitster@pobox.com> writes:

> This is a continuation of the other one to avoid one-or-more operator
> in sed.  At the same time, it actually tightens error checking,
> because the numbers in the squash messages are not padded with
> leading zero and cannot begin with 0.
>
> With this, I think we do not have any more use of one-or-more
> (\+) in sed scripts.

Just for the record: I believe that \{1,\} might be portable.

As usual, <URL:info:autoconf#Limitations%20of%20Usual%20Tools> (aka as
(info "(autoconf) Limitations of Usual Tools")
) provides a real horror show of sed variants.

Actually, one can get the cursor right on the spot by typing
info autoconf      (or the respective Emacs command C-h i g (autoconf))
i sed RET

There is something to be said for well-indexed documentation...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.

[Junio C Hamano]

David Kastrup <dak@gnu.org> writes:

> Just for the record: I believe that \{1,\} might be portable.

Yeah, I obviously looked at the page I quoted that describes
what's in and what's not in BRE definition ;-)

But in practice, I do not recall ever seeing an older sed that
did not understand one-or-more \+ *and* understood \{1,\}.  Do
you?

I had to deal with autoconf (hence various flavours of UNIX
implementations) in my previous life, but that was an ancient
history (back then the effect of SysV vs BSD war was still
felt).  As a maintainer of a public project I understand you
have to deal with the current set of variations, and you might
know better than me about the current portability situation.

Re: [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.

[David Kastrup]

Junio C Hamano <gitster@pobox.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Just for the record: I believe that \{1,\} might be portable.
>
> Yeah, I obviously looked at the page I quoted that describes
> what's in and what's not in BRE definition ;-)

> As a maintainer of a public project I understand you have to deal
> with the current set of variations, and you might know better than
> me about the current portability situation.

Don't ask.  That was what "just for the record" was about.  In
practice, one uses the most simplistic expressions (and then some) and
prays, and your patches are quite in line with that.

Basically, one has to bear up under attack from two sides: the Windows
side with its idiosyncratic file names (and habitual spaces) under the
Cygwin and MSYS environments (which are quite Posix and GNU), and the
non-Posix madness from all sorts of Unices all across the utilities.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.

[Simon 'corecode' Schubert]

Junio C Hamano wrote:
>> Just for the record: I believe that \{1,\} might be portable.
> 
> Yeah, I obviously looked at the page I quoted that describes
> what's in and what's not in BRE definition ;-)
> 
> But in practice, I do not recall ever seeing an older sed that
> did not understand one-or-more \+ *and* understood \{1,\}.  Do
> you?

Yes, BSD sed (at least DragonFly's, so probably as well FreeBSD-4 (dunno 
about later)):

chlamydia % echo 5ab123x | sed -e 's/[a-z]\+/AAA/' 

5ab123x
chlamydia % echo 5ab123x | sed -e 's/[a-z]\{1,\}/AAA/' 

5AAA123x
chlamydia % echo 5ab123x | sed -E -e 's/[a-z]+/AAA/' 

5AAA123x

cheers
   simon

Re: [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.

[Johannes Schindelin]

Hi,

On Sun, 2 Sep 2007, Simon 'corecode' Schubert wrote:

> Junio C Hamano wrote:
> > > Just for the record: I believe that \{1,\} might be portable.
> > 
> > Yeah, I obviously looked at the page I quoted that describes
> > what's in and what's not in BRE definition ;-)
> > 
> > But in practice, I do not recall ever seeing an older sed that
> > did not understand one-or-more \+ *and* understood \{1,\}.  Do
> > you?
> 
> Yes, BSD sed (at least DragonFly's, so probably as well FreeBSD-4 (dunno
> about later)):
> 
> chlamydia % echo 5ab123x | sed -e 's/[a-z]\+/AAA/' 
> 5ab123x
> chlamydia % echo 5ab123x | sed -e 's/[a-z]\{1,\}/AAA/' 
> 5AAA123x
> chlamydia % echo 5ab123x | sed -E -e 's/[a-z]+/AAA/' 
> 5AAA123x

Thank you for a proper argument.  I usually ignore hand-waving POSIX 
arguments, but a real-world case changes the situation.

Ciao,
Dscho

Re: [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.

[Nix]

On 2 Sep 2007, David Kastrup uttered the following:
> As usual, <URL:info:autoconf#Limitations%20of%20Usual%20Tools> (aka as
> (info "(autoconf) Limitations of Usual Tools")
> ) provides a real horror show of sed variants.

A goodly number of things in that section of the Autoconf manual are
passing on hints and ancient legends that may or may not be accurate:
I've found a number of its descriptions of shell limitations to be
downright wrong (applying to one build of one shell back in 1981 that
was never shipped to anyone, that sort of thing).

(Of course it's valuable, even if it *is* a compendium of legends. But
confirming any of it is quite hard.)

Re: [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.

[Benoit SIGOURE]

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

On Sep 2, 2007, at 7:07 PM, Nix wrote:

> On 2 Sep 2007, David Kastrup uttered the following:
>> As usual, <URL:info:autoconf#Limitations%20of%20Usual%20Tools>  
>> (aka as
>> (info "(autoconf) Limitations of Usual Tools")
>> ) provides a real horror show of sed variants.
>
> A goodly number of things in that section of the Autoconf manual are
> passing on hints and ancient legends that may or may not be accurate:
> I've found a number of its descriptions of shell limitations to be
> downright wrong (applying to one build of one shell back in 1981 that
> was never shipped to anyone, that sort of thing).
>
> (Of course it's valuable, even if it *is* a compendium of legends. But
> confirming any of it is quite hard.)

The autoconf maintainers will be glade to hear about such legends or  
inaccurate things.

Cheers,

-- 
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.

[Nix]

On 5 Sep 2007, Benoit SIGOURE told this:
> The autoconf maintainers will be glade to hear about such legends or  inaccurate things.

I know, and when I finally dig up my list (it's on an old CD somewhere)
I'll send it their way. (Disk crash -> lots of stuff still stuck on CDs
years after the fact... obviously I should have kept everything
significant in git instead so I just had to restore one packfile ;) )

Re: [PATCH] rebase -m: Fix incorrect short-logs of already applied commits.

[David Kastrup]

Junio C Hamano <gitster@pobox.com> writes:

> I would propose doing the attached patch on top of yours.
> Opinion?
>
> +	git rev-list --pretty=oneline -1 "$cmt" | sed -e 's/^[^ ]* //'

What about

    git-rev-list --pretty=format:%s -1 "$cmt"

It seems pretty pointless to first print with a wrong format, then fix
it up afterwards.

Incidentally, the above spews out a full commit line before the entry
(meaning this does not work with current git-rev-list).  This is
arguably wrong: when format: is employed, the user presumably knows
perfectly well what he wants printed.

So I guess I vouch for both not using sed as well as what I consider
fixing git-rev-list --pretty=format:

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [PATCH] rebase -m: Fix incorrect short-logs of already applied commits.

[Johannes Sixt]

On Saturday 01 September 2007 11:01, Junio C Hamano wrote:
>  		printf "Committed: %0${prec}d " $msgnum
> -		git rev-list --pretty=oneline -1 HEAD | \
> -			sed 's/^[a-f0-9]\+ //'
>  	else
>  		printf "Already applied: %0${prec}d " $msgnum
> -		git rev-list --pretty=oneline -1 "$cmt" | \
> -			sed 's/^[a-f0-9]\+ //'
>  	fi
> +	git rev-list --pretty=oneline -1 "$cmt" | sed -e 's/^[^ ]* //'

I prefer this over my version as well.

-- Hannes

Re: [PATCH] rebase -m: Fix incorrect short-logs of already applied commits.

[Robin Rosenberg]

Just so we know what the '-m' is from the documentation.

-- robin

>From b4fd5fca1aa45183c04327a29ee98d01a4e76e59 Mon Sep 17 00:00:00 2001
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Date: Sat, 1 Sep 2007 13:52:26 +0200
Subject: [PATCH] Mention -m as an abbreviation for --merge

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
 Documentation/git-rebase.txt |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index a1b6dce..cb87b03 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -8,7 +8,7 @@ git-rebase - Forward-port local commits to the updated upstream head
 SYNOPSIS
 --------
 [verse]
-'git-rebase' [-i | --interactive] [-v | --verbose] [--merge] [-C<n>]
+'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge] [-C<n>]
 	[-p | --preserve-merges] [--onto <newbase>] <upstream> [<branch>]
 'git-rebase' --continue | --skip | --abort
 
@@ -188,7 +188,7 @@ OPTIONS
 --skip::
 	Restart the rebasing process by skipping the current patch.
 
---merge::
+-m, \--merge::
 	Use merging strategies to rebase.  When the recursive (default) merge
 	strategy is used, this allows rebase to be aware of renames on the
 	upstream side.
-- 
1.5.3.rc7.844.gfd3c5