Re: git/cogito usage scenarios for CVS refugee

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Jun 8, 2005, 20:26 UTC
Message-ID: <46a038f9050608132625803d@mail.gmail.com>
In-Reply-To: <20050608183414.GD982@pasky.ji.cz>

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