A series file for git?

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

Agreed that seem to make a lot of sense.

At least for now the using tac is fine. Longer term I think having some reverse arguments to rev-list or even better git-log so we can review patches in order instead backwards would be very interesting.

So I have played with this some and a bit of feedback.

I was using:
	git-rev-list $revargs | tac > list

	for sha1 in $(cat list); do git-cherry-pick -r $sha1 ; done

Is there any real difference between using git-format-patch | git-am and using git-am to apply patches. I was using git-cherry-pick simply because it was easier to sha1 too.

- When you reorder patches minor merge conflicts are common
  so a big pipe won't work very often in practice.  So you
  need a way to handle failures in the middle.

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

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

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

  The important pieces there are the ability to reorder the changes
  to put the patches with the highest confidence first.

  The ability to comment on the patches so that it is possible
  to record groups of patches and information about their relative
  stability.  As once a patch series gets large without at least
  a few comments it is too much for a person to remember what
  is happening with each patch without a few clues.

- The other place where we use series files is in pure development
  where we are breaking up or otherwise creating the needed changes
  in a set of simple obviously correct changes.

....

So I think it could be very interesting to have a series file as something the base git porcelain helps to deal with.

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.

We can keep track of the series file with a SERIES_HEAD similar to FETCH_HEAD. This fairly easily allows editing in different places in the patch stack that normally happens with quilt or patch-scripts.

We can put comments in a series file to keep track of probationary patches.

The two tricky pieces I see with this idea are:
- teaching git-fsck-objects that we have a sha1 in a blob objects.

- Where to put the active checkout series file when we are working,
  so we don't stumble on it.

...

I'm trying to sort out a sane work flow for developing with a large number of highly related patches on the development side. I care because the way I think I usually fix the root cause of problems.

It took me nearly 25 patches to decouple the brain damage the msi code imposed on x86 irq handling. In the development of that I had to reorder and edit things extensively as I broke the work up, and created a sane patch flow.

The trick with rev-list | tac to create a series file for reordering changes was very useful but it wasn't enough to say it solve the problem.

One trivial issue was that git-cherry-pick -r always does the full git-commit so it is much more I/O bound than necessary, because git-commit does git-status. Which is just silly if you are applying a bunch of changes that apply without errors.

Eric