[Fwd: git/cogito usage scenarios for CVS refugee]

[Kevin Smith]

This recent post to the git list asks some great questions. Nobody on 
the git side has responded yet, but I would love to hear the answers 
from a mercurial standpoint. I suspect the answers this week will be 
different from what they would have been prior to the multi-head stuff 
going in.

Kevin


-------- Original Message --------
Subject: git/cogito usage scenarios for CVS refugee
Date: Wed, 8 Jun 2005 21:51:17 +1200
From: Martin Langhoff <martin.langhoff at gmail.com>
Reply-To: Martin Langhoff <martin.langhoff at gmail.com>
To: Git Mailing List <git at vger.kernel.org>

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?

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?

So far I think the answer is "no -- you'll need to keep track of your
damn patches somewhere else" ;-) but there's a lot about the git
mindset I don't quite understand yet. And I'm sure that the workflow
of the Linux team must have some ancillary tools & strategies to keep
track of this.

cheers,


martin
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html