Re: [Qemu-devel] Re: updating git tree

[Kevin Wolf]

Jan Kiszka schrieb:
> Kevin Wolf wrote:
>> Jan Kiszka schrieb:
>>> Kevin Wolf wrote:
>>>> Jan Kiszka schrieb:
>>>>> If you have non-trivial changes pending, probably in multiple commits, I
>>>>> can only recommend using stgit (or guilt) to compensate the missing
>>>>> patch queue feature of git. It allows you to easily navigate back and
>>>>> forth in your patch queues before finally posting them.
>>>> I haven't used these yet. Is there a real benefit compared to using a
>>>> normal git branch and rebase -i? Maybe I should try them if so.
>>> I'm not only talking about rebasing, also about working within your
>>> patch queue, editing patches in their middle, splitting it up,
>>> reordering it etc. There are surely ways to do this with native git
>>> (stgit is just a front-end and uses normal git), but that's not done
>>> with two or three git commands.
>> This is why I said rebase -i and not only rebase. In case you don't know
>> this yet: It presents you a list of all commits you did since the point
>> you're rebasing on. You can then drop, merge, edit (which includes
>> splitting, see the man page of git-rebase) and change the order of them.
> 
> It still lacks the flexibility and consistency of stgit-managed series
> as it is designed around the original "rebase" step. With stgit, you are
> permanently in "rebase -i" mode, you can go back and forth _while_
> editing. You can switch branches without leaving the rebase mode. You
> can also hide patches temporarily (how do you do this with rebase -i?).

Thanks, this is more or less what I wanted to know.

(And I don't think I had to hide a patch yet, but I would either create
another branch with the patch dropped or revert the patch and drop the
revert commit later.)

> However, in the end it is a question how you set up your personal
> workflow. There are n ways to skin a cat.

Sure. But as long as I only know m < n ways, there is always a chance to
miss the better workflow. ;-)

Kevin