On Sun, Jun 30, 2019 at 4:39 PM Jeff King <[email protected]> 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
