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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html