On Sun, Jun 30, 2019 at 09:09:31AM -0600, Edmundo Carmona Antoranz wrote: > > git merge --squash feature > > > > I get the same merge that rebuash is doing (with R6 as the merge base, > > so we see F5 and R7 conflicting with each other). And then when I finish > > it with "git commit", the result is a linear strand with M3 at the tip > > (and its commit message is even auto-populated with information from the > > squashed commits). > > From the point of view of the revisions that you produce in the end, > it's the same thing, but you are not rebasing/squashing your feature > branch, you are moving your upstream branch to where you want the > squashed/rebased branch to be. So, in fact you would need more steps, > something like (starting from your feature branch being checked out): Ah, OK, that's what I was missing. I agree that "merge --squash" isn't quite what you want, then. It's sort of a "reverse squash": do the merge, but use the _other_ side as the parent of the new squash commit. I wonder if it might be easier to implement as an option to git-merge. I noticed when I hit a conflict with rebuash that it emphatically told me not to use "git commit" once I had resolved everything. If this were just a special case of a merge, that might be a bit more seamless (though I imagine it might still require teaching git-commit about the feature, since it generally wants to mark HEAD as the parent). > I think it makes more sense in terms of development flow of feature > branches, if you know in the end you will give up a squashed branch: Yeah, I agree it is a separate operation that by itself makes sense. I do wonder a little why you'd care about squashing on the branch. If you're eventually going to squash the whole thing anyway, you don't care about a messy history. So you can just continue to back-merge from master into the feature branch and build on top. But perhaps the squashed version is easier to work with for further modifications? I'm not sure how, though. Certainly in your example rewriting changes in F1 with "rebase --interactive" would be a pain. But I think the end-state of the tree after your rebuash is identical to what you'd get by just merging from master. So in either case, just building new work on top should be the same. > But, as you said, it's not like it's not possible to do it (with a > little more effort) with available tools like merge --squash Yeah, but I agree with you that just because it is possible to do something does not mean that it is not a good idea to make the workflow easier or safer. I'm still not quite sure of the greater workflow where having the rebuash-ed commit on the feature branch is more useful than just having a merge from master. -Peff
