Edmundo Carmona Antoranz <[email protected]> writes:
> 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).
That part is understandable, but is "rebase-and-squash" a tool
intended to be used by the contributor to respond to that request?
Wouldn't the developer just do
git checkout topic
git fetch
git rebase [-i] [@{upstream}]
git push [publish +topic]
to update the topic and ask to be pulled again? The two steps in
the middle may be "pull --rebase", but my point is I do not quite
see where the new squash/rebase-in-a-single-step thing comes into
this picture. There may be a different picture that it fits, but
I do not think it is this one.
