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

[François Revol]

> >>>> 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?).
>
> However, in the end it is a question how you set up your personal
> workflow. There are n ways to skin a cat.

In the end it's a question of whether you have the time to read the doc
and learn a new SCM or not.

ATM... I do not.

François.