Re: A series file for git?

From: Eric W. Biederman <ebiederm@xmission.com>
Date: Jun 24, 2006, 17:54 UTC
Message-ID: <m1r71exww5.fsf@ebiederm.dsl.xmission.com>
In-Reply-To: <7vac83ylk6.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

Show 14 quoted lines

> ebiederm@xmission.com (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.

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.

Show 12 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?

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.

Show 12 quoted lines

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

Show 10 quoted lines

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