ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > 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. > > - 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? - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html