Re: [PATCH 0/4] ack recoding in commit log

On Wed, Jun 11, 2014 at 10:05:46AM +0200, Fabian Ruch wrote:

I think the two additions should be judged separately, they aren't related.

So I am not sure we need to spend time discussing what is an ack commit.

What I mean is that I prefer using git history for recording activity, and git rebase for modifying history. I think I am not alone in this.

To record acks, I wrote this tool to create empty commits, that only record log changes. They are named specially such that rebase knows not to discard them, and to automate the editing stage.

I added some features to the tool since. Did not yet address all comments I got here, but just in case you are curious it's attached at the end.

Other possible cases I handle:
    people reply with:

    For the series:
        Reviewed-by: Somebody <somebody@example.com>

This uses the save/restore flags.

or an informal
    Ack the series
(this one I handle by creating ACKS file manually,
 then applying it with git ack restore)

Someone sends a fixup! patch, and someone else replies to the fixup with Reviewed-by: tag. (this was not handled correctly in the version you reviewed, I attach latest one below where it is handled correctly).

git ack creates commits like this:

---- ack! Some changes

Reviewed-by: Somebody <somebody@example.com>
---

Other work-flows

At the moment git ack does not create non empty commits.

At the moment git ack does not create such commits.

I use them together but ack command is more powerful than git ack. Same as commit --fixup, that is not the only way to use fixup!.

Hmm, I don't see why is flag any easier to remember than a separate command frankly, and there's help text at the end to remind you.

That's too much typing I think, I just want to use a single letter. You could argue the same thing for fixup right? It's really squash but discards the log, and there is no requirement that it fixes anything, it can add functionality or whatever. So why not squash --discardlog b The next commit

I think that would be bad usability, and so would --no-edit.

--no-edit also does not convey the fact that it allows empty commits.

I don't mind renaming the command to something else but I could not come up with a better name so far.

## latest git-ack ## changes: handle fixup!/squash!/ack! messages in mail

msg=`mktemp`
patch=`mktemp`
info=`git mailinfo $msg $patch`
subj=`echo "$info"|sed -n 's/^Subject: //p'`
#strip ack!/fixup!/squash! prefix
subj=`echo "$subj"|sed "s/^fixup![ 	]*//"`
subj=`echo "$subj"|sed "s/^squash![ 	]*//"`
subj=`echo "$subj"|sed "s/^ack![ 	]*//"`
author=`echo "$info"|sed -n 's/^Author: //p'`
email=`echo "$info"|sed -n 's/^Email: //p'`
auth="$author <$email>"
date=`echo "$info"|sed -n 's/^Date: //p'`
sign=`mktemp`
echo "ack! $subj" > $sign
echo "" >> $sign
if
    git diff --cached HEAD
then
    nop < /dev/null
else
    echo "DIFF in cache. Not acked, reset or commit!"
    exit 1
fi
GIT_DIR=`pwd`/.git

usage () {
	echo "Usage: git ack " \
            "[-s|--save|-a|--append|-r|--restore |-c|--clear]\n" >& 2;
        exit 1;
}

append= save= clear=

while test $# != 0
do
	case "$1" in
	-a|--append)
		append="y"
		;;
	-s|--s)
		save="y"
		;;
	-r|--restore)
		restore="y"
		;;
	-c|--clear)
		clear="y"
                ;;
	*)
		usage ;;
	esac
	shift
done

if
    test "$clear"
then
    rm -f "${GIT_DIR}/ACKS"
fi

if
    test "$save"
then
    if
        test "$append"
    then
        cat $msg >> "${GIT_DIR}/ACKS"
    else
        cat $msg > "${GIT_DIR}/ACKS"
    fi
fi

if
    test "$restore"
then
    msg=${GIT_DIR}/ACKS
fi

echo $msg > /dev/tty
if
    grep '^[A-Z][A-Za-z-]*-by:' $msg >> $sign
then
    git commit --allow-empty -F $sign --author="$auth" --date="$date"
else
    echo "No signature found!"
    exit 2
fi