[PATCH] git-merge --squash

[PATCH] git-merge --squash

[Junio C Hamano]

Some people tend to do many little commits on a topic branch,
recording all the trials and errors, and when the topic is
reasonably cooked well, would want to record the net effect of
the series as one commit on top of the mainline, removing the
cruft from the history.  The topic is then abandoned or forked
off again from that point at the mainline.

The barebone porcelainish that comes with core git tools does
not officially support such operation, but you can fake it by
using "git pull --no-merge" when such a topic branch is not a
strict superset of the mainline, like this:

	git checkout mainline
	git pull --no-commit . that-topic-branch
	: fix conflicts if any
	rm -f .git/MERGE_HEAD
        git commit -a -m 'consolidated commit log message'
	git branch -f that-topic-branch ;# now fully merged

This however does not work when the topic branch is a fast
forward of the mainline, because normal "git pull" will never
create a merge commit in such a case, and there is nothing
special --no-commit could do to begin with.

This patch introduces a new option, --squash, to support such a
workflow officially in both fast-forward case and true merge
case.  The user-level operation would be the same in both cases:

	git checkout mainline
        git pull --squash . that-topic-branch
        : fix conflicts if any -- naturally, there would be
        : no conflict if fast forward.
	git commit -a -m  'consolidated commit log message'
	git branch -f that-topic-branch ;# now fully merged

When the current branch is already up-to-date with respect to
the other branch, there truly is nothing to do, so the new
option does not have any effect.

This was brought up in #git IRC channel recently.

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

 * This is something I am unlikely to use myself, since
   "squashing into one" is too coarse grained for the commits I
   usually make myself.

   If one's habit is to use a sequence of many commits to keep
   too-finer-grained snapshots, and the result of a squash
   commit out of such a sequence of commits is a coherent,
   self-contained unit, then I do not see any reason to
   discourage that workflow.  I however suspect that people who
   make such a sequence of "many too-finer-grained commits"
   would inevitably include changes that do not belong together
   in in one sequence on a topic branch and end up squashing
   them together into one resulting commit.  If that is the
   case, this facility is actively encouraging a bad workflow
   and we should instead teach them to use StGIT or something
   saner.

   But somebody asked on #git channel, so here is the rope.

 Documentation/merge-options.txt |    8 ++++
 git-commit.sh                   |    7 +++-
 git-merge.sh                    |   72 +++++++++++++++++++++++++++++----------
 git-pull.sh                     |    7 +++-
 git-reset.sh                    |    2 +
 5 files changed, 72 insertions(+), 24 deletions(-)

diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 53cc355..182cef5 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -6,6 +6,14 @@
 	not autocommit, to give the user a chance to inspect and
 	further tweak the merge result before committing.
 
+--squash::
+	Produce the working tree and index state as if a real
+	merge happened, but do not actually make a commit or
+	move the `HEAD`, nor record `$GIT_DIR/MERGE_HEAD` to
+	cause the next `git commit` command to create a merge
+	commit.  This allows you to create a single commit on
+	top of the current branch whose effect is the same as
+	merging another branch (or more in case of an octopus).
 
 -s <strategy>, \--strategy=<strategy>::
 	Use the given merge strategy; can be supplied more than
diff --git a/git-commit.sh b/git-commit.sh
index 6dd04fd..cd7358e 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -564,6 +564,9 @@ then
 elif test -f "$GIT_DIR/MERGE_HEAD" && test -f "$GIT_DIR/MERGE_MSG"
 then
 	cat "$GIT_DIR/MERGE_MSG"
+elif test -f "$GIT_DIR/SQUASH_MSG"
+then
+	cat "$GIT_DIR/SQUASH_MSG"
 fi | git-stripspace >"$GIT_DIR"/COMMIT_EDITMSG
 
 case "$signoff" in
@@ -661,7 +664,7 @@ else
 fi
 if [ "$?" != "0" -a ! -f "$GIT_DIR/MERGE_HEAD" -a -z "$amend" ]
 then
-	rm -f "$GIT_DIR/COMMIT_EDITMSG"
+	rm -f "$GIT_DIR/COMMIT_EDITMSG" "$GIT_DIR/SQUASH_MSG"
 	run_status
 	exit 1
 fi
@@ -727,7 +730,7 @@ else
 	false
 fi
 ret="$?"
-rm -f "$GIT_DIR/COMMIT_MSG" "$GIT_DIR/COMMIT_EDITMSG"
+rm -f "$GIT_DIR/COMMIT_MSG" "$GIT_DIR/COMMIT_EDITMSG" "$GIT_DIR/SQUASH_MSG"
 if test -d "$GIT_DIR/rr-cache"
 then
 	git-rerere
diff --git a/git-merge.sh b/git-merge.sh
index af1f25b..e6db610 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -3,8 +3,7 @@ #
 # Copyright (c) 2005 Junio C Hamano
 #
 
-
-USAGE='[-n] [--no-commit] [-s <strategy>]... <merge-message> <head> <remote>+'
+USAGE='[-n] [--no-commit] [--squash] [-s <strategy>]... <merge-message> <head> <remote>+'
 . git-sh-setup
 
 LF='
@@ -42,20 +41,49 @@ restorestate() {
 	fi
 }
 
+finish_up_to_date () {
+	case "$squash" in
+	t)
+		echo "$1 (nothing to squash)" ;;
+	'')
+		echo "$1" ;;
+	esac
+	dropsave
+}
+
+squash_message () {
+	echo Squashed commit of the following:
+	echo
+	git-log --no-merges ^"$head" $remote
+}
+
 finish () {
 	test '' = "$2" || echo "$2"
-	case "$merge_msg" in
-	'')
-		echo "No merge message -- not updating HEAD"
+	case "$squash" in
+	t)
+		echo "Squash commit -- not updating HEAD"
+		squash_message >"$GIT_DIR/SQUASH_MSG"
 		;;
-	*)
-		git-update-ref HEAD "$1" "$head" || exit 1
+	'')
+		case "$merge_msg" in
+		'')
+			echo "No merge message -- not updating HEAD"
+			;;
+		*)
+			git-update-ref HEAD "$1" "$head" || exit 1
+			;;
+		esac
 		;;
 	esac
-
-	case "$no_summary" in
+	case "$1" in
 	'')
-		git-diff-tree -p --stat --summary -M "$head" "$1"
+		;;
+	?*)
+		case "$no_summary" in
+		'')
+			git-diff-tree -p --stat --summary -M "$head" "$1"
+			;;
+		esac
 		;;
 	esac
 }
@@ -66,6 +94,8 @@ do
 	-n|--n|--no|--no-|--no-s|--no-su|--no-sum|--no-summ|\
 		--no-summa|--no-summar|--no-summary)
 		no_summary=t ;;
+	--sq|--squ|--squa|--squas|--squash)
+		squash=t no_commit=t ;;
 	--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
 		no_commit=t ;;
 	-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
@@ -152,8 +182,7 @@ f,*)
 ?,1,"$1",*)
 	# If head can reach all the merge then we are up to date.
 	# but first the most common case of merging one remote.
-	echo "Already up-to-date."
-	dropsave
+	finish_up_to_date "Already up-to-date."
 	exit 0
 	;;
 ?,1,"$head",*)
@@ -205,8 +234,7 @@ f,*)
 	done
 	if test "$up_to_date" = t
 	then
-		echo "Already up-to-date. Yeeah!"
-		dropsave
+		finish_up_to_date "Already up-to-date. Yeeah!"
 		exit 0
 	fi
 	;;
@@ -310,11 +338,17 @@ case "$best_strategy" in
 	git-merge-$best_strategy $common -- "$head_arg" "$@"
 	;;
 esac
-for remote
-do
-	echo $remote
-done >"$GIT_DIR/MERGE_HEAD"
-echo "$merge_msg" >"$GIT_DIR/MERGE_MSG"
+
+if test "$squash" = t
+then
+	finish
+else
+	for remote
+	do
+		echo $remote
+	done >"$GIT_DIR/MERGE_HEAD"
+	echo "$merge_msg" >"$GIT_DIR/MERGE_MSG"
+fi
 
 if test "$merge_was_ok" = t
 then
diff --git a/git-pull.sh b/git-pull.sh
index 4611ae6..1670da1 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -8,7 +8,7 @@ USAGE='[-n | --no-summary] [--no-commit]
 LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEAD.'
 . git-sh-setup
 
-strategy_args= no_summary= no_commit=
+strategy_args= no_summary= no_commit= squash=
 while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
 do
 	case "$1" in
@@ -17,6 +17,8 @@ do
 		no_summary=-n ;;
 	--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
 		no_commit=--no-commit ;;
+	--sq|--squ|--squa|--squas|--squash)
+		squash=--squash ;;
 	-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
 		--strateg=*|--strategy=*|\
 	-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -100,4 +102,5 @@ case "$strategy_args" in
 esac
 
 merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD")
-git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head
+git-merge $no_summary $no_commit $squash $strategy_args \
+	"$merge_name" HEAD $merge_head
diff --git a/git-reset.sh b/git-reset.sh
index 296f3b7..46451d0 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -61,4 +61,4 @@ case "$reset_type" in
 	;;
 esac
 
-rm -f "$GIT_DIR/MERGE_HEAD" "$GIT_DIR/rr-cache/MERGE_RR"
+rm -f "$GIT_DIR/MERGE_HEAD" "$GIT_DIR/rr-cache/MERGE_RR" "$GIT_DIR/SQUASH_MSG"
-- 
1.4.1.rc1.g1f33

Re: [PATCH] git-merge --squash

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

>    If one's habit is to use a sequence of many commits to keep
>    too-finer-grained snapshots, and the result of a squash
>    commit out of such a sequence of commits is a coherent,
>    self-contained unit, then I do not see any reason to
>    discourage that workflow.  I however suspect that people who
>    make such a sequence of "many too-finer-grained commits"
>    would inevitably include changes that do not belong together
>    in in one sequence on a topic branch and end up squashing
>    them together into one resulting commit.  If that is the
>    case, this facility is actively encouraging a bad workflow
>    and we should instead teach them to use StGIT or something
>    saner.

This part of the commentary needs a bit of clarification, as I
realize that I was a bit too negative about this --squash
option.

Suppose you have this bright idea for the new filesystem feature
that involves some VFS layer changes.  Let's call that "frob"
feature, and create a topic branch to develop it in.

	git checkout -b frob linus

Now, when you are done, you would want the result to be
a nice, neat, logical steps.  Perhaps that would introduce
features in a sequence like this:

	[PATCH 1/n] vfs: support f_op.frob_read
	[PATCH 2/n] vfs: support f_op.frob_write
        [PATCH 3/n] ext3: add f_op.frob_read and frob_write
        [PATCH 4/n] ramfs: add f_op.frob_read and frob_write
        [PATCH 5/n] vfat: add f_op.frob_read and frob_write
	...

But would you be able to develop things in a neat sequence like
this?  Probably not.  In practice (I do not do kernel myself, so
I am just speculating), I would imagine you would pick one
filesystem (say ext3) as your initial target, and do the
codepath for frob_read operation from bottom to top (vfs to
ext3), and then do the same exercise for frob_write codepath, to
have something working first. After that, you would start
migrating another fs to your updated vfs layer, and during that
process you would find your earlier changes to the vfs are
insufficient and need further tweaks to support that other fs.
So your topic branch with many little snapshot commits might
end up looking this way (fictional show-branch output):

  ! [linus] linux-2.6.17
   * [frob] vfs: finishing touches to frob_write
  --
   * [frob] vfs: finishing touches to frob_write
   * [frob~1] vfat: final fix to frob_read to make it work
   * [frob~2] vfs: Oops, vfat is special and frob_write needs this hack
   * [frob~3] vfat: fix support frob_write for disk full condition
   * [frob~4] vfat: support f_op.frob_write
   * [frob~5] ext3, ramfs: give frob_read the extra parameter like vfat does.
   * [frob~6] vfat: give frob_read the extra parameter
   * [frob~7] vfs: frob_read needs an extra parameter for vfat.
   * [frob~8] ramfs: add frob_write, that was easy.
   * [frob~9] ramfs: add frob_read, that was easy.
   * [frob~10] ext3: more frob_write, now ext3 works!
   * [frob~11] ext3: starting to add frob_write
   * [frob~12] vfs: support frob_write
   * [frob~13] vfs: enhance frob_read for special case, now ext3 works!
   * [frob~14] ext3: yet more frob_read
   * [frob~15] ext3: more frob_read
   * [frob~16] ext3: starting to add frob_read
   * [frob~17] vfs: support frob_read
  +* [linus] linux-2.6.17

The --squash merge alone would not help sorting out something
like this.  However, you could do something like this to
separate them out and squash:

	git checkout -b temp master
        for c in 17 13 7 1; do git cherry-pick frob~$c; done
        git checkout master
        git pull --sq . temp
        git commit -a -m 'vfs: support f_op.frob_read'
        git checkout temp
        git reset --hard master
        for c in 12 2 0; do git cherry-pick frob~$c; done
        git checkout master
        git pull --sq . temp
        git commit -a -m 'vfs: support f_op.frob_write'
        git checkout temp
        git reset --hard master
        for c in 16 15 14 11 10 5; do git cherry-pick frob~$c; done
        git checkout master
        git pull --sq . temp
        edit to remove changes to ramfs portion
        git commit -a -m 'ext3: add f_op.frob_read and frob_write'
        ...

So in that sense I would imagine --squash is not really useless
in such a situation as I made it sound like, but at the same
time I suspect people might be better off to use tools like
StGIT which are specially designed to support such a workflow if
they were to do this.

Re: [PATCH] git-merge --squash

[Thomas Glanzmann]

Hello Junio,

> So in that sense I would imagine --squash is not really useless
> in such a situation as I made it sound like, but at the same
> time I suspect people might be better off to use tools like
> StGIT which are specially designed to support such a workflow if
> they were to do this.

thanks for --squash. So --squash is basically a 'suck multiple deltas
from another branch into ., but don't commit it'. I very often use that
way of work flow. I do small and many commits, and when I am done I
merge them to one a bit bigger one and submit it upstream. I useally use
'one branch per feature'.

        Thomas

Re: [PATCH] git-merge --squash

[Johannes Schindelin]

Hi,

On Fri, 23 Jun 2006, Thomas Glanzmann wrote:

> Hello Junio,
> 
> > So in that sense I would imagine --squash is not really useless
> > in such a situation as I made it sound like, but at the same
> > time I suspect people might be better off to use tools like
> > StGIT which are specially designed to support such a workflow if
> > they were to do this.
> 
> thanks for --squash. So --squash is basically a 'suck multiple deltas
> from another branch into ., but don't commit it'. I very often use that
> way of work flow. I do small and many commits, and when I am done I
> merge them to one a bit bigger one and submit it upstream. I useally use
> 'one branch per feature'.

Isn't this the same as 'git-cherry-pick -n'? I often do a poor man's StGIT 
by cherry picking my way through a messy branch, often combining patches 
by '-n'.

Ciao,
Dscho

Re: [PATCH] git-merge --squash

[Thomas Glanzmann]

Hello,

> Isn't this the same as 'git-cherry-pick -n'? I often do a poor man's StGIT 
> by cherry picking my way through a messy branch, often combining patches 
> by '-n'.

yes it is. I didn't know about the cherry-pick -n option. Thanks.

        Thomas

Re: [PATCH] git-merge --squash

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Isn't this the same as 'git-cherry-pick -n'? I often do a poor man's StGIT 
> by cherry picking my way through a messy branch, often combining patches 
> by '-n'.

Operationally, it probably is equivalent to the repeated use of
'cherry-pick -n' for all commits on a topic, but that would risk
you having to resolve conflicts unnecessarily when you are
shooting for as the result is a single commit, because you would
have to do N merges with that workflow.  Squashing is about
merging the tip of the topic into mainline, so the conflict
resolution needs to be done only once.