Re: RFC: git squash
On Thu, Feb 22, 2018 at 10:04 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Julius Musseau <jul...@mergebase.com> writes:
>
>> git squash []
>>
>> Squashes ..HEAD into a single commit. Replaces HEAD with the
>> result. If not specified, defaults to the current branch's
>> upstream (a.k.a. @{upstream}).
>>
>> Rationale:
>>
>> 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 and
>> HEAD, removing all intermediate commits.
>
> So is it essentially the same as
>
> git reset --soft $(git merge-base $commit HEAD)
> git commit
>
> with some icing for coming up with a default log message? The above
> won't touch the working tree at all.
>
>
Yes! I had no idea about this approach. Thanks! My implementation
uses "git commit-tree".
Yes, some icing to build the squashed log message, as well as some
protection to ensure the working tree is clean before doing the squash
(just like "git rebase" does).
I'm also working on two more pieces of icing:
- Adding an "--oldest-author" flag to help adjust the author for the
squashed commit (using the author value from the oldest commit in the
squash). By "oldest" I mean whatever "git log --reverse --no-merges
-1 ..HEAD" spits out. (I don't consider timestamps.)
- Ability to arbitrarily squash any branch by taking a 2nd "branch"
argument. (And making the command work with bare repos.)
I'm embarrassed to realise your approach matches the top-voted
stack-overflow answer on the subject:
https://stackoverflow.com/a/5201642
Nonetheless, the top-voted stack-overflow comment to that answer says:
> Ha! I like this method. It is the one closes to the spirit of the problem.
> It's a pity that it requires so much voodoo. Something like this should be
> added to one of the basic commands.
Should I proceed?
RFC: git squash
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
summary:
--
git squash []
Squashes ..HEAD into a single commit. Replaces HEAD with the
result. If not specified, defaults to the current branch's
upstream (a.k.a. @{upstream}).
Rationale:
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 and
HEAD, removing all intermediate commits.
Alternatives:
- "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
"master"):
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
I'm trying to break "git pull --rebase"
Hi, Git Developers, I'm currently writing a blog post about "git pull --rebase". The point of the blog post is to examine scenarios where two people are working together on a short-lived feature branch, where history rewrites are allowed, and where both are using "git pull --rebase" to stay in sync with each other. I was hoping to concoct a situation where "git pull --rebase" makes a mess of things. So far I have been unable to do this. I tried version v1.7.2 of Git as well as version v2.14.1, and as far as I can tell, "git pull --rebase" is bulletproof. Does anyone here happen to know a situation where "git pull --rebase" makes a mess? Here's a draft of the blog post: Title: "(Too much) fun with git pull --rebase" https://mergebase.com/doing-git-wrong/2018/02/17/fun-with-git-pull-rebase/ Here are the "git pull --rebase" scenarios I've tested so far: 1. origin/feature rebased against origin/master 2. origin/feature squash-merged against origin/master 3. origin/feature squashed in-place` 4. origin/feature dropped a commit 5. origin/feature insanity (adjusted merge-base, reversed commits, squashed some commits) 6. undo of 5 So far "git pull --rebase" does the exact right thing in every case! If anyone knows a scenario where "git pull --rebase" fails to do the right thing, I would be very grateful to hear of it. Thanks! yours sincerely, Julius Musseau
