Git workflow: how to achieve?

["George Spelvin" <linux@horizon.com>]

Here's something I and my co-workers would like to achieve, but are not
too sure how to arrange.

I want to be committing to a feature branch, but always be compiling
and testing a merge of that branch and several others.  (Kind of like
linux-next.)  I want to be able to switch feature branches easily.

For example, I may have a background project that I'm working on slowly in
between short-term fixes.  Or I want to be running the latest kernel.org
kernel while my patches await approval.

If it's just my own projects, I can just commit in random order and
straighten things out later.  Although even that is problematic,
as I may not remember what line of development a cleanup patch is a
prerequisite for.  (This is something that darcs is apparently good at.)

But when I want to be testing something highly volatile like linux-next,
and ensuring that my work continues to merge with it cleanly, as well
as helping others with their branches, it becomes a daily pain.

The best attempt I have so far is to rebase a lot.  But that means that
I can't do any merging in my development branch lest the rebasing turn
into a mess.  And forcing everything to be linear makes changing branches
a pain.  And I can't share half-finished versions with co-workers.

This is all vaguely quilt-like, although I'd rather not worry about the
order of patches.  I suppose I'd like git to let me "commit under" the
final merge.  When I switch branches, git should reorganize the tree of
merges so that the current branch is only one merge from the HEAD.

(Another thing I've wished for that might be related is for a branch
to have a notion of its origin.  So I can rebase it onto an arbitrary
place in the commit tree without having to explicitly specify an origin.)

((Another really simple feature I keep wanting is "git commit -b
<newbranch>".  I should probably try to write a patch...))


Anyway, my feature ideas might be unworkable, and in any case, they'll
take a long time to implement.  Is there some easier way to achieve more
or less this effect?

Maybe the planned git-rebase improvements to handle merges better will
fix this, so I can just commit on top and periodically rebase the changes
under the head manually without too much pain?  (git rebase -i -p does
appear to be working better than I remember.)

H'm... in fact, it might be as easy as replacing "git pull" with
git rebase -p -i <last merge>^
(Delete the merge in the editor)
git pull <remote>

Annoying to remember, but not TOO bad.