threads / discuss / 860

git/cogito usage scenarios for CVS refugee

Subject: git/cogito usage scenarios for CVS refugee

## tl;dr

3 messages between Jun 8, 2005 and Jun 8, 2005.

replies: 2people: 2as markdown or json

Martin Langhoff· Jun 8, 2005, 09:51 UTC · lore

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

Petr Baudis· Jun 8, 2005, 18:34 UTC · re: Martin Langhoff · lore

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...

Show 19 quoted lines

> 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

Martin Langhoff· Jun 8, 2005, 20:26 UTC · re: Petr Baudis · lore

Re: git/cogito usage scenarios for CVS refugee

On 6/9/05, Petr Baudis <pasky@ucw.cz> wrote:

> 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.

Agreed -- there's no support for cherry picking. Is there some git-specific strategy perhaps?

For example, when using cvs, which doesn't support cherry picking either, people running "stable" branches use a "merged" tag that they move around to indicate how far the bugfixes on the stable branch have been merged into head. It doesn't allow cherry picking, but it works and it is a valuable (if hackish) practice.

Show 5 quoted lines

> > 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?

Something along the lines of what I've mention above. I mean, not literally moving a tag around, but to have some basic suport to identify what the merge status is. As soon as we are one commit out of sync, git stops being useful.

It doesn't need to happen inside git actually -- perhaps there is just enough support to add an identifier in each commit msg, so we could have ancillary scripts that perform some simple patch tracking for simple scenarios.

When an automatic merge succeeds, does git bring in the commitmsg and a unique identifier of the commit?

cheers,

martin