Re: [RFC/PATCH 1/2] rebuash - squash/rebase in a single step

From: Edmundo Carmona Antoranz <eantoranz@gmail.com>
Date: Jul 1, 2019, 01:37 UTC
Message-ID: <CAOc6etZxHWQ24TNsYDf74zgn-VJzbwDsxWxO4-tMkvv92KRKkw@mail.gmail.com>
In-Reply-To: <20190630223951.GB21696@sigill.intra.peff.net>

On Sun, Jun 30, 2019 at 4:39 PM Jeff King <peff@peff.net> wrote:

Show 8 quoted lines

>
>
> 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.

> 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.

Hmm... I as a gatekeeper would rather get either a straight line of revisions for a feature with no merges (even if a final merge takes care of solving conflicts with the upstream branch) or a single revision (if I thought that the change is not worth having more than a single revision). I'd ask the developer to rebase the whole thing and give a straight line (with rebase -i or cherry-picks) or to give me a single revision (where rebuash would come into the picture).

Also, I wonder how it would make life easier for people that are learning to use git and the command that they see thrown around very often is to use `git pull` in order to get updates from the other developers.

But that might be me being opinionated.

PS About rebuash ordering not to use commit: Sure, at the moment, rebuash is not commit-safe.... or merge-continue-safe.... but I can add checks for that in case the user runs them before using rebuash --continue