Re: A series file for git?
From: Eric W. Biederman <hidden>
Date: 2016-06-15 22:42:31
Junio C Hamano [off-list ref] writes:
ebiederm@xmission.com (Eric W. Biederman) writes:quoted
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.
Right but typically I have something that looks like. "git-rev-list --pretty=oneline 2.6.17-rc6-mm2..HEAD | tac > list" and HEAD changes. I could be careful and before I do each operation save a branch name.
quoted
- 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?
It is exactly a string of perls on a topic branch. My point is that when things are sufficiently interrelated that you can't use more than one topic branch. With topic branches when you find a small fix to an existing perl you just commit it to that branch, and it works because each branch really is composed of a single pearl. (At least that is my intuition). When you have multiple highly interrelated pearls and you are testing you can easily put the fix for a pearl at the end of the branch. But before you push your changes upstream that fix needs to be merged with the original pearl that it fixes. Which is fundamentally a history editing kind of action.
quoted
- 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.
I have a similar suspicion. I am glad we pretty much see the same problem.
quoted
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.
When described that way I agree. The best I can imagine is to list those commits as ancestors of the current commit. Hmm. Or possibly I could collect up tag objects and work with them. In any case representing this in a non-hackish way is my goal.
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?
What I want and what I see lacking in the git and StGit is the ability to record the history of editing the history of a branch. A mundane example. It would be nice if I rebased a branch if I could record in some fashion what that branch was before I rebased it. So I am trying to figure out how to construct a meta branch that records that kind of information about a branch. Intuitively this feels like the history of a series file to me. Did I add commits? Did I remove commits? Did I reorder commits? Did I merge commits? Andrew in his patch-scripts documentation recommends using CVS to record this information (The documentation predates git). I think this is something that got lost with quilt when Andrews patch-scripts were cleaned up and made more general. I need to look some more but I don't think recording the history of editing a branch is problem that has been solved in any of the git flavors. I will certainly look at StGit more and at the core git data structures some more and see if I can come up with a creative way of representing the history of branch edit operations that will not break existing tools. Eric