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

From: Edmundo Carmona Antoranz <eantoranz@gmail.com>
Date: Jul 1, 2019, 20:48 UTC
Message-ID: <CAOc6etZWKOGDX749i=8R2V44HGtemL3-n0=01WH6amcRro-uPw@mail.gmail.com>
In-Reply-To: <xmqqy31h612o.fsf@gitster-ct.c.googlers.com>

On Mon, Jul 1, 2019 at 12:51 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 19 quoted lines

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