On Mon, 9 Jan 2006, Linus Torvalds wrote:
>
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
