On Mon, Jul 1, 2019 at 12:51 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
>
> 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.
>
>
I think rebasing -i makes sense* _if_ there are no conflicts on the
way to reach the current state of the branch if the developer was
pulling while developing the feature branch. If there are conflicts
that I took care of when i was pulling, i don't want to run rebase -i
to have to deal with them yet again. So rebuash would help developers
with or without merges with upstream on their feature branch, with or
without conflicts on those merges (if there are merges), get their
development into a single revision without having to write 4 or 5 git
commands, as Jeff was saying, if it makes workflows simpler....
* rebase -i is the way I see people solve their "squash and rebase"
needs (pick the first revision, then squash all the others... but what
happens if the very first revision is conflicting with the current
state of upstream?), but I (for one) do it the way rebuash is doing:
merge with upstream, reset --soft to upstream, commit, voila! That's
why i wrote rebuash in the first place, just so you can see where I'm
coming from.
