{"thread":{"id":"4633","subject":"[PATCH] git-merge --squash","startedAt":"2006-06-23T08:50:17Z","lastAt":"2006-06-23T23:11:26Z","messageCount":6,"participants":["Junio C Hamano","Thomas Glanzmann","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"22336","messageId":"7virmscl2u.fsf@assigned-by-dhcp.cox.net","threadId":"4633","inReplyTo":null,"subject":"[PATCH] git-merge --squash","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-23T08:50:17Z","receivedAt":"2006-06-23T08:50:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Some people tend to do many little commits on a topic branch,\nrecording all the trials and errors, and when the topic is\nreasonably cooked well, would want to record the net effect of\nthe series as one commit on top of the mainline, removing the\ncruft from the history.  The topic is then abandoned or forked\noff again from that point at the mainline.\n\nThe barebone porcelainish that comes with core git tools does\nnot officially support such operation, but you can fake it by\nusing \"git pull --no-merge\" when such a topic branch is not a\nstrict superset of the mainline, like this:\n\n\tgit checkout mainline\n\tgit pull --no-commit . that-topic-branch\n\t: fix conflicts if any\n\trm -f .git/MERGE_HEAD\n        git commit -a -m 'consolidated commit log message'\n\tgit branch -f that-topic-branch ;# now fully merged\n\nThis however does not work when the topic branch is a fast\nforward of the mainline, because normal \"git pull\" will never\ncreate a merge commit in such a case, and there is nothing\nspecial --no-commit could do to begin with.\n\nThis patch introduces a new option, --squash, to support such a\nworkflow officially in both fast-forward case and true merge\ncase.  The user-level operation would be the same in both cases:\n\n\tgit checkout mainline\n        git pull --squash . that-topic-branch\n        : fix conflicts if any -- naturally, there would be\n        : no conflict if fast forward.\n\tgit commit -a -m  'consolidated commit log message'\n\tgit branch -f that-topic-branch ;# now fully merged\n\nWhen the current branch is already up-to-date with respect to\nthe other branch, there truly is nothing to do, so the new\noption does not have any effect.\n\nThis was brought up in #git IRC channel recently.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n * This is something I am unlikely to use myself, since\n   \"squashing into one\" is too coarse grained for the commits I\n   usually make myself.\n\n   If one's habit is to use a sequence of many commits to keep\n   too-finer-grained snapshots, and the result of a squash\n   commit out of such a sequence of commits is a coherent,\n   self-contained unit, then I do not see any reason to\n   discourage that workflow.  I however suspect that people who\n   make such a sequence of \"many too-finer-grained commits\"\n   would inevitably include changes that do not belong together\n   in in one sequence on a topic branch and end up squashing\n   them together into one resulting commit.  If that is the\n   case, this facility is actively encouraging a bad workflow\n   and we should instead teach them to use StGIT or something\n   saner.\n\n   But somebody asked on #git channel, so here is the rope.\n\n Documentation/merge-options.txt |    8 ++++\n git-commit.sh                   |    7 +++-\n git-merge.sh                    |   72 +++++++++++++++++++++++++++++----------\n git-pull.sh                     |    7 +++-\n git-reset.sh                    |    2 +\n 5 files changed, 72 insertions(+), 24 deletions(-)\n\ndiff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt\nindex 53cc355..182cef5 100644\n--- a/Documentation/merge-options.txt\n+++ b/Documentation/merge-options.txt\n@@ -6,6 +6,14 @@\n \tnot autocommit, to give the user a chance to inspect and\n \tfurther tweak the merge result before committing.\n \n+--squash::\n+\tProduce the working tree and index state as if a real\n+\tmerge happened, but do not actually make a commit or\n+\tmove the `HEAD`, nor record `$GIT_DIR/MERGE_HEAD` to\n+\tcause the next `git commit` command to create a merge\n+\tcommit.  This allows you to create a single commit on\n+\ttop of the current branch whose effect is the same as\n+\tmerging another branch (or more in case of an octopus).\n \n -s <strategy>, \\--strategy=<strategy>::\n \tUse the given merge strategy; can be supplied more than\ndiff --git a/git-commit.sh b/git-commit.sh\nindex 6dd04fd..cd7358e 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -564,6 +564,9 @@ then\n elif test -f \"$GIT_DIR/MERGE_HEAD\" && test -f \"$GIT_DIR/MERGE_MSG\"\n then\n \tcat \"$GIT_DIR/MERGE_MSG\"\n+elif test -f \"$GIT_DIR/SQUASH_MSG\"\n+then\n+\tcat \"$GIT_DIR/SQUASH_MSG\"\n fi | git-stripspace >\"$GIT_DIR\"/COMMIT_EDITMSG\n \n case \"$signoff\" in\n@@ -661,7 +664,7 @@ else\n fi\n if [ \"$?\" != \"0\" -a ! -f \"$GIT_DIR/MERGE_HEAD\" -a -z \"$amend\" ]\n then\n-\trm -f \"$GIT_DIR/COMMIT_EDITMSG\"\n+\trm -f \"$GIT_DIR/COMMIT_EDITMSG\" \"$GIT_DIR/SQUASH_MSG\"\n \trun_status\n \texit 1\n fi\n@@ -727,7 +730,7 @@ else\n \tfalse\n fi\n ret=\"$?\"\n-rm -f \"$GIT_DIR/COMMIT_MSG\" \"$GIT_DIR/COMMIT_EDITMSG\"\n+rm -f \"$GIT_DIR/COMMIT_MSG\" \"$GIT_DIR/COMMIT_EDITMSG\" \"$GIT_DIR/SQUASH_MSG\"\n if test -d \"$GIT_DIR/rr-cache\"\n then\n \tgit-rerere\ndiff --git a/git-merge.sh b/git-merge.sh\nindex af1f25b..e6db610 100755\n--- a/git-merge.sh\n+++ b/git-merge.sh\n@@ -3,8 +3,7 @@ #\n # Copyright (c) 2005 Junio C Hamano\n #\n \n-\n-USAGE='[-n] [--no-commit] [-s <strategy>]... <merge-message> <head> <remote>+'\n+USAGE='[-n] [--no-commit] [--squash] [-s <strategy>]... <merge-message> <head> <remote>+'\n . git-sh-setup\n \n LF='\n@@ -42,20 +41,49 @@ restorestate() {\n \tfi\n }\n \n+finish_up_to_date () {\n+\tcase \"$squash\" in\n+\tt)\n+\t\techo \"$1 (nothing to squash)\" ;;\n+\t'')\n+\t\techo \"$1\" ;;\n+\tesac\n+\tdropsave\n+}\n+\n+squash_message () {\n+\techo Squashed commit of the following:\n+\techo\n+\tgit-log --no-merges ^\"$head\" $remote\n+}\n+\n finish () {\n \ttest '' = \"$2\" || echo \"$2\"\n-\tcase \"$merge_msg\" in\n-\t'')\n-\t\techo \"No merge message -- not updating HEAD\"\n+\tcase \"$squash\" in\n+\tt)\n+\t\techo \"Squash commit -- not updating HEAD\"\n+\t\tsquash_message >\"$GIT_DIR/SQUASH_MSG\"\n \t\t;;\n-\t*)\n-\t\tgit-update-ref HEAD \"$1\" \"$head\" || exit 1\n+\t'')\n+\t\tcase \"$merge_msg\" in\n+\t\t'')\n+\t\t\techo \"No merge message -- not updating HEAD\"\n+\t\t\t;;\n+\t\t*)\n+\t\t\tgit-update-ref HEAD \"$1\" \"$head\" || exit 1\n+\t\t\t;;\n+\t\tesac\n \t\t;;\n \tesac\n-\n-\tcase \"$no_summary\" in\n+\tcase \"$1\" in\n \t'')\n-\t\tgit-diff-tree -p --stat --summary -M \"$head\" \"$1\"\n+\t\t;;\n+\t?*)\n+\t\tcase \"$no_summary\" in\n+\t\t'')\n+\t\t\tgit-diff-tree -p --stat --summary -M \"$head\" \"$1\"\n+\t\t\t;;\n+\t\tesac\n \t\t;;\n \tesac\n }\n@@ -66,6 +94,8 @@ do\n \t-n|--n|--no|--no-|--no-s|--no-su|--no-sum|--no-summ|\\\n \t\t--no-summa|--no-summar|--no-summary)\n \t\tno_summary=t ;;\n+\t--sq|--squ|--squa|--squas|--squash)\n+\t\tsquash=t no_commit=t ;;\n \t--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)\n \t\tno_commit=t ;;\n \t-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\\\n@@ -152,8 +182,7 @@ f,*)\n ?,1,\"$1\",*)\n \t# If head can reach all the merge then we are up to date.\n \t# but first the most common case of merging one remote.\n-\techo \"Already up-to-date.\"\n-\tdropsave\n+\tfinish_up_to_date \"Already up-to-date.\"\n \texit 0\n \t;;\n ?,1,\"$head\",*)\n@@ -205,8 +234,7 @@ f,*)\n \tdone\n \tif test \"$up_to_date\" = t\n \tthen\n-\t\techo \"Already up-to-date. Yeeah!\"\n-\t\tdropsave\n+\t\tfinish_up_to_date \"Already up-to-date. Yeeah!\"\n \t\texit 0\n \tfi\n \t;;\n@@ -310,11 +338,17 @@ case \"$best_strategy\" in\n \tgit-merge-$best_strategy $common -- \"$head_arg\" \"$@\"\n \t;;\n esac\n-for remote\n-do\n-\techo $remote\n-done >\"$GIT_DIR/MERGE_HEAD\"\n-echo \"$merge_msg\" >\"$GIT_DIR/MERGE_MSG\"\n+\n+if test \"$squash\" = t\n+then\n+\tfinish\n+else\n+\tfor remote\n+\tdo\n+\t\techo $remote\n+\tdone >\"$GIT_DIR/MERGE_HEAD\"\n+\techo \"$merge_msg\" >\"$GIT_DIR/MERGE_MSG\"\n+fi\n \n if test \"$merge_was_ok\" = t\n then\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 4611ae6..1670da1 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -8,7 +8,7 @@ USAGE='[-n | --no-summary] [--no-commit]\n LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEAD.'\n . git-sh-setup\n \n-strategy_args= no_summary= no_commit=\n+strategy_args= no_summary= no_commit= squash=\n while case \"$#,$1\" in 0) break ;; *,-*) ;; *) break ;; esac\n do\n \tcase \"$1\" in\n@@ -17,6 +17,8 @@ do\n \t\tno_summary=-n ;;\n \t--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)\n \t\tno_commit=--no-commit ;;\n+\t--sq|--squ|--squa|--squas|--squash)\n+\t\tsquash=--squash ;;\n \t-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\\\n \t\t--strateg=*|--strategy=*|\\\n \t-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)\n@@ -100,4 +102,5 @@ case \"$strategy_args\" in\n esac\n \n merge_name=$(git-fmt-merge-msg <\"$GIT_DIR/FETCH_HEAD\")\n-git-merge $no_summary $no_commit $strategy_args \"$merge_name\" HEAD $merge_head\n+git-merge $no_summary $no_commit $squash $strategy_args \\\n+\t\"$merge_name\" HEAD $merge_head\ndiff --git a/git-reset.sh b/git-reset.sh\nindex 296f3b7..46451d0 100755\n--- a/git-reset.sh\n+++ b/git-reset.sh\n@@ -61,4 +61,4 @@ case \"$reset_type\" in\n \t;;\n esac\n \n-rm -f \"$GIT_DIR/MERGE_HEAD\" \"$GIT_DIR/rr-cache/MERGE_RR\"\n+rm -f \"$GIT_DIR/MERGE_HEAD\" \"$GIT_DIR/rr-cache/MERGE_RR\" \"$GIT_DIR/SQUASH_MSG\"\n-- \n1.4.1.rc1.g1f33\n"},{"id":"22338","messageId":"7vd5d09pe2.fsf@assigned-by-dhcp.cox.net","threadId":"4633","inReplyTo":"7virmscl2u.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-merge --squash","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-23T09:45:25Z","receivedAt":"2006-06-23T09:45:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n>    If one's habit is to use a sequence of many commits to keep\n>    too-finer-grained snapshots, and the result of a squash\n>    commit out of such a sequence of commits is a coherent,\n>    self-contained unit, then I do not see any reason to\n>    discourage that workflow.  I however suspect that people who\n>    make such a sequence of \"many too-finer-grained commits\"\n>    would inevitably include changes that do not belong together\n>    in in one sequence on a topic branch and end up squashing\n>    them together into one resulting commit.  If that is the\n>    case, this facility is actively encouraging a bad workflow\n>    and we should instead teach them to use StGIT or something\n>    saner.\n\nThis part of the commentary needs a bit of clarification, as I\nrealize that I was a bit too negative about this --squash\noption.\n\nSuppose you have this bright idea for the new filesystem feature\nthat involves some VFS layer changes.  Let's call that \"frob\"\nfeature, and create a topic branch to develop it in.\n\n\tgit checkout -b frob linus\n\nNow, when you are done, you would want the result to be\na nice, neat, logical steps.  Perhaps that would introduce\nfeatures in a sequence like this:\n\n\t[PATCH 1/n] vfs: support f_op.frob_read\n\t[PATCH 2/n] vfs: support f_op.frob_write\n        [PATCH 3/n] ext3: add f_op.frob_read and frob_write\n        [PATCH 4/n] ramfs: add f_op.frob_read and frob_write\n        [PATCH 5/n] vfat: add f_op.frob_read and frob_write\n\t...\n\nBut would you be able to develop things in a neat sequence like\nthis?  Probably not.  In practice (I do not do kernel myself, so\nI am just speculating), I would imagine you would pick one\nfilesystem (say ext3) as your initial target, and do the\ncodepath for frob_read operation from bottom to top (vfs to\next3), and then do the same exercise for frob_write codepath, to\nhave something working first. After that, you would start\nmigrating another fs to your updated vfs layer, and during that\nprocess you would find your earlier changes to the vfs are\ninsufficient and need further tweaks to support that other fs.\nSo your topic branch with many little snapshot commits might\nend up looking this way (fictional show-branch output):\n\n  ! [linus] linux-2.6.17\n   * [frob] vfs: finishing touches to frob_write\n  --\n   * [frob] vfs: finishing touches to frob_write\n   * [frob~1] vfat: final fix to frob_read to make it work\n   * [frob~2] vfs: Oops, vfat is special and frob_write needs this hack\n   * [frob~3] vfat: fix support frob_write for disk full condition\n   * [frob~4] vfat: support f_op.frob_write\n   * [frob~5] ext3, ramfs: give frob_read the extra parameter like vfat does.\n   * [frob~6] vfat: give frob_read the extra parameter\n   * [frob~7] vfs: frob_read needs an extra parameter for vfat.\n   * [frob~8] ramfs: add frob_write, that was easy.\n   * [frob~9] ramfs: add frob_read, that was easy.\n   * [frob~10] ext3: more frob_write, now ext3 works!\n   * [frob~11] ext3: starting to add frob_write\n   * [frob~12] vfs: support frob_write\n   * [frob~13] vfs: enhance frob_read for special case, now ext3 works!\n   * [frob~14] ext3: yet more frob_read\n   * [frob~15] ext3: more frob_read\n   * [frob~16] ext3: starting to add frob_read\n   * [frob~17] vfs: support frob_read\n  +* [linus] linux-2.6.17\n\nThe --squash merge alone would not help sorting out something\nlike this.  However, you could do something like this to\nseparate them out and squash:\n\n\tgit checkout -b temp master\n        for c in 17 13 7 1; do git cherry-pick frob~$c; done\n        git checkout master\n        git pull --sq . temp\n        git commit -a -m 'vfs: support f_op.frob_read'\n        git checkout temp\n        git reset --hard master\n        for c in 12 2 0; do git cherry-pick frob~$c; done\n        git checkout master\n        git pull --sq . temp\n        git commit -a -m 'vfs: support f_op.frob_write'\n        git checkout temp\n        git reset --hard master\n        for c in 16 15 14 11 10 5; do git cherry-pick frob~$c; done\n        git checkout master\n        git pull --sq . temp\n        edit to remove changes to ramfs portion\n        git commit -a -m 'ext3: add f_op.frob_read and frob_write'\n        ...\n\nSo in that sense I would imagine --squash is not really useless\nin such a situation as I made it sound like, but at the same\ntime I suspect people might be better off to use tools like\nStGIT which are specially designed to support such a workflow if\nthey were to do this.\n"},{"id":"22348","messageId":"20060623122501.GD15631@cip.informatik.uni-erlangen.de","threadId":"4633","inReplyTo":"7vd5d09pe2.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-merge --squash","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2006-06-23T12:25:01Z","receivedAt":"2006-06-23T12:25:01Z","isPatch":true,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello Junio,\n\n> So in that sense I would imagine --squash is not really useless\n> in such a situation as I made it sound like, but at the same\n> time I suspect people might be better off to use tools like\n> StGIT which are specially designed to support such a workflow if\n> they were to do this.\n\nthanks for --squash. So --squash is basically a 'suck multiple deltas\nfrom another branch into ., but don't commit it'. I very often use that\nway of work flow. I do small and many commits, and when I am done I\nmerge them to one a bit bigger one and submit it upstream. I useally use\n'one branch per feature'.\n\n        Thomas\n"},{"id":"22350","messageId":"Pine.LNX.4.63.0606231433370.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4633","inReplyTo":"20060623122501.GD15631@cip.informatik.uni-erlangen.de","subject":"Re: [PATCH] git-merge --squash","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-06-23T12:36:11Z","receivedAt":"2006-06-23T12:36:11Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 23 Jun 2006, Thomas Glanzmann wrote:\n\n> Hello Junio,\n> \n> > So in that sense I would imagine --squash is not really useless\n> > in such a situation as I made it sound like, but at the same\n> > time I suspect people might be better off to use tools like\n> > StGIT which are specially designed to support such a workflow if\n> > they were to do this.\n> \n> thanks for --squash. So --squash is basically a 'suck multiple deltas\n> from another branch into ., but don't commit it'. I very often use that\n> way of work flow. I do small and many commits, and when I am done I\n> merge them to one a bit bigger one and submit it upstream. I useally use\n> 'one branch per feature'.\n\nIsn't this the same as 'git-cherry-pick -n'? I often do a poor man's StGIT \nby cherry picking my way through a messy branch, often combining patches \nby '-n'.\n\nCiao,\nDscho\n"},{"id":"22352","messageId":"20060623124259.GF15631@cip.informatik.uni-erlangen.de","threadId":"4633","inReplyTo":"Pine.LNX.4.63.0606231433370.29667@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] git-merge --squash","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2006-06-23T12:42:59Z","receivedAt":"2006-06-23T12:42:59Z","isPatch":true,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello,\n\n> Isn't this the same as 'git-cherry-pick -n'? I often do a poor man's StGIT \n> by cherry picking my way through a messy branch, often combining patches \n> by '-n'.\n\nyes it is. I didn't know about the cherry-pick -n option. Thanks.\n\n        Thomas\n"},{"id":"22385","messageId":"7vwtb78o2p.fsf@assigned-by-dhcp.cox.net","threadId":"4633","inReplyTo":"Pine.LNX.4.63.0606231433370.29667@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] git-merge --squash","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-23T23:11:26Z","receivedAt":"2006-06-23T23:11:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> Isn't this the same as 'git-cherry-pick -n'? I often do a poor man's StGIT \n> by cherry picking my way through a messy branch, often combining patches \n> by '-n'.\n\nOperationally, it probably is equivalent to the repeated use of\n'cherry-pick -n' for all commits on a topic, but that would risk\nyou having to resolve conflicts unnecessarily when you are\nshooting for as the result is a single commit, because you would\nhave to do N merges with that workflow.  Squashing is about\nmerging the tip of the topic into mainline, so the conflict\nresolution needs to be done only once.\n"}]}