RE: git pull on Linux/ACPI release tree

From: Linus Torvalds <torvalds@osdl.org>
Date: Jan 9, 2006, 16:57 UTC
Message-ID: <Pine.LNX.4.64.0601090850350.3169@g5.osdl.org>
In-Reply-To: <Pine.LNX.4.64.0601090835580.3169@g5.osdl.org>

On Mon, 9 Jan 2006, Linus Torvalds wrote:

Show 8 quoted lines

>
> One thing we could do is to make it easier to apply a patch to a 
> _non_current_ branch.
>   [ ... ]
> Do you think that kind of workflow would be more palatable to you? It 
> shouldn't be /that/ hard to make git-apply branch-aware... (It was part of 
> my original plan, but it is more work than just using the working 
> directory, so I never finished the thought).

Btw, this is true in a bigger sense: the things "git" does have largely been driven by user needs. Initially mainly mine, but things like "git-rebase" were from people who wanted to work as "sub-maintainers" (eg Junio before he became the head honcho for git itself).

But if there are workflow problems, let's try to fix them. The "apply patches directly to another branch" suggestion may not be sane (maybe it's too confusing to apply a patch and not actually see it in the working tree), but workflow suggestions in general are appreciated.

We've made switching branches about as efficient as it can be (but if the differences are huge, the cost of re-writing the working directory is never going to be low). But switching branches has the "confusion factor" (ie you forget which branch you're on, and apply a patch to your working branch instead of your development branch), so maybe there are other ways of doing the same thing that might be sensible..

So send suggestions to the git lists. Maybe they're insane and can't be done, but while I designed git to work with _my_ case (ie mostly merging tons of different trees and then having occasional big batches of patches), it's certainly _supposed_ to support other maintainers too..

		Linus