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

[Jan Kiszka <jan.kiszka@siemens.com>]

Kevin Wolf wrote:
> 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. ;-)
> 

Yeah, true.

For that and some other reasons it would be great if git itself could
gain fully flexible queue management. stgit is only a workaround that
has some downsides, too (same for guilt). Once I'll find its core
features natively, I'm going to switch over to have only a single UI.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux