From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Wed, 08 Jun 2005 20:26:03 GMT
Subject: Re: git/cogito usage scenarios for CVS refugee
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.

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