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

[Edmundo Carmona Antoranz <eantoranz@gmail.com>]

On Sun, Jun 30, 2019 at 4:39 PM Jeff King <peff@peff.net> wrote:
>
>
> 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