On Wed, Jul 17, 2019 at 12:07 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Sure. I started skimming and then gave up after seeing that quite a > lot of code has been shuffled around without much explanation (e.g. > printing of "Squash commit -- not updating HEAD" is gone from the > callee and now it is a responsibility of the caller), making it > harder than necessary to see if there is any unintended behaviour > change when the new feature is not in use. Whatever you are trying, > it does look like the change deserves to be split into a smaller > pieces to become more manageable. > > Thanks. > yw! I'm focusing on the squash --commit part only. I think I'm close to getting the desired result and now I'm taking a close look at the unit tests and a question came up on two tests of t7600-merge.sh: merge c0 with c1 (squash) merge c0 with c1 (squash, ff-only) In both cases it's a FF (right?) so no new revision is created. The unit tests are requiring that $GIT_DIR/squash_msg have some content: not ok 20 - merge c0 with c1 (squash, ff-only) # # git reset --hard c0 && # git merge --squash --ff-only c1 && # verify_merge file result.1 && # verify_head $c0 && # verify_no_mergehead && # test_cmp squash.1 .git/SQUASH_MSG not ok 18 - merge c0 with c1 (squash) # # git reset --hard c0 && # git merge --squash c1 && # verify_merge file result.1 && # verify_head $c0 && # verify_no_mergehead && # test_cmp squash.1 .git/SQUASH_MSG Does it make sense to keep this file in those two situations?