[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [RFC/PATCH 1/2] rebuash - squash/rebase in a single step
From:       Jeff King <peff () peff ! net>
Date:       2019-06-30 22:39:51
Message-ID: 20190630223951.GB21696 () sigill ! intra ! peff ! net
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]