Re: A series file for git?

From: Junio C Hamano <junkio@cox.net>
Date: Jun 24, 2006, 09:01 UTC
Message-ID: <7vac83ylk6.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <m1odwkyuf5.fsf_-_@ebiederm.dsl.xmission.com>

ebiederm@xmission.com (Eric W. Biederman) writes:

Show 8 quoted lines

> I was using:
> 	git-rev-list $revargs | tac > list
> 	for sha1 in $(cat list); do git-cherry-pick -r $sha1 ; done
>...
> - Keeping patches in git and just remembering their sha1 is nice
>   but it has the downside that it can be really easy to loose
>   the sha1, and thus the patch.  So some sort of history mechanism
>   so you can get back to where you were would be nice.

Actually, the $revargs above is composed of your branch names (e.g. "^master this-topic that-topic"), so as long as you do not lose these branches they are protected.

Show 5 quoted lines

>
> - This is a similar technique to topic branches.  However in some
>   of the more interesting cases a topic branch can't be used because
>   you have a whole series of little changes, that allow depend on
>   each other.  So topic branches need not apply.

Sorry I fail to see why. A series of little changes that depend on each other would be a string of pearls on a topic branch in the simplest case, or a handful of topic branches that occasionally merge with each other if you want to get fancier. Cherry-picking from a DAG of the latter kind with your rev-list piped to tac is no different than cherry-picking from a simple straight line of the former kind, isn't it?

> - One of the places where we currently uses series files
>   (patch-scripts && quilt), and heavy cherry picking is for patch
>   aging.  That is letting patches sit in a testing branch for 
>   a while so people have a chance to test and look at them.

I agree that patch aging and updating does not mesh well with how git inherently works, as git regards commits immutable objects. Even then, I use my "pu" branch (and topics that hasn't merged to "next" but in "pu") pretty much as patch aging area and I regularly do "git commit --amend" to update them. This however is cumbersome with core git tools alone, and I suspect is better done with StGIT.

> If we create a meta data branch with just the series file
> we can remove the risk of loosing things, as we always
> have a path back to the old history if we want it.

I am not sure about that. What does the series file contain, and what other things the meta data branch contain? If you are listing commit SHA1 in the series file, you _do_ have the risk of losing things -- git-fsck-objects needs to look at such blob object and consider that as the root of reachability chain; to me that seems too specialized hack.

I have a feeling that I really should study how well StGIT does things before talking about this further. It may suit your needs perfectly. What do you feel is lacking in StGIT that you need?