Hi, Git Developers,

Thanks for your help regarding my earlier email (trying to break git
pull --rebase).

I just wanted to warn you all that my first attempt at a patch is
imminent.  I'm working on a "git squash" command.  Here's a quick

git squash [<commit>]

Squashes <commit>..HEAD into a single commit. Replaces HEAD with the
result.  If not specified, <commit> defaults to the current branch's
upstream (a.k.a. @{upstream}).


This command provides an intuitive mechanism for in-place squash that
doesn't drop dirty merge results.

We call this an in-place squash because the state of all files and
directories at HEAD does not change. Only the ancestory of HEAD
changes: its (only) parent becomes the merge-base of <commit> and
HEAD, removing all intermediate commits.


- "git merge --squash master" correctly preserves dirty merge results,
but it's tricky to achieve an in-place squash with this command, since
it requires the following sequence of commands (these assume the
current branch is "feature" and we want to squash it relative to

    git checkout $(git merge-base HEAD master)
    git merge --squash feature
    git commit
    git branch -f feature
    git checkout feature

- "git rebase --interactive HEAD~N" with commits set to "squash" (or
"fixup") is very popular in industry.  But it has some tricky edge
cases: drops dirty merge results, can run into conflicts, and can be
confusing if HEAD~N spans any merges (including clean merges).

I expect I'll have the patch finished this weekend, and ready for
everyone to look at by Monday (Feb 26th).

Note:  I'm not 100% sure "git rebase --interactive" would drop dirty
merge results (e.g., the dirty parts from conflict-resolving merges).
That's speculation on my part.  I'll confirm this before I finish and
submit the patch.

yours sincerely,

Julius Musseau

Reply via email to