Re: git/cogito usage scenarios for CVS refugee

Dear diary, on Wed, Jun 08, 2005 at 11:51:17AM CEST, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> told me that...
> Trying to get my head around what usage patterns the git
> infrastructure supports. I'm interested in exploring more git-centric
> approaches...
> 
> For a project that uses CVS with a classic HEAD and FOO_15_STABLE
> approach, where FOO_15_STABLE gets only fixes -- how do I manage HEAD
> and XX_STABLE where some patches that work well in HEAD I may decide
> to merge into XX_STABLE, and some security patch may be applied first
> to XX_STABLE and then to HEAD? I can apply the patch on both branches
> -- yep. But does git help me in keeping track of what's been merged?
> 
> Does git help in any way to keep track of patches across 2.6.11.12 and
> 2.6.12rc5 ?
> 
> In a git-based project, one developer is about to merge from someone
> else's tree, are there any tools to review the patchlog that is about
> to be applied (or replayed?) against his tree? Is there any way to say
> "of the 20 commits that I'm about to merge, hold off 2" other than
> letting git apply them ... and backing them out right next?

The answer for all those questions is that git has no support for
cherrypicking (that sucks, but is hard to fix right now). git does ok
as long as one branch is superset of the other, but it does not help you
otherwise.

> And generally, is there any long-lived branch support? If I am to run
> a "local branch" of the Linux kernel, does git help me at all?

I don't understand what do you mean. How does a long-lived branch differ
from a short-lived one and what support would you expect/like?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html