mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: (Eric W. Biederman)
To: Junio C Hamano <>
Cc: Linus Torvalds <>,
	Git Mailing List <>
Subject: A series file for git?
Date: Fri, 23 Jun 2006 05:37:34 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Junio C. Hamano's message of "Wed, 31 May 2006 15:53:19 -0700")

Junio C Hamano <> writes:

> Linus Torvalds <> writes:
>>  (a) git-rev-list --pretty=oneline "$upstream"..ORIG_HEAD > rev-list
>>  (b) edit the rev-list, moving the single lines around, deleting them, etc
>>  (c) cat rev-list |
>>      git-format-patch -k --stdout --stdin --full_index |
>>      git-am

> Tentatively my feeling is that we should make it known that the
> list format-patch takes from --stdin is supposed to be _not_
> reversed, and do nothing in format-patch.  In other words, the
> list fed is a moral equivalent to quilt "series" file.

Agreed that seem to make a lot of sense.

> What this means is:
> 	git-format-patch $revargs
> is not equivalent to
> 	git-rev-list $revargs | git-format-patch --stdin
> but is equivalent to
> 	git-rev-list $revargs | tac | git-format-patch --stdin

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.

> Thoughts from the list?

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

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

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.


  parent reply	other threads:[~2006-06-23 11:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-29 19:15 [PATCH 0/10] re-based and expanded tree-walker cleanup patches Linus Torvalds
2006-05-29 19:16 ` [PATCH 1/10] Make "struct tree" contain the pointer to the tree buffer Linus Torvalds
2006-05-29 19:16 ` [PATCH 2/10] Make "tree_entry" have a SHA1 instead of a union of object pointers Linus Torvalds
2006-05-29 19:17 ` [PATCH 3/10] Switch "read_tree_recursive()" over to tree-walk functionality Linus Torvalds
2006-05-29 19:18 ` [PATCH 4/10] builtin-read-tree.c: avoid tree_entry_list in prime_cache_tree_rec() Linus Torvalds
2006-05-29 19:18 ` [PATCH 5/10] Remove "tree->entries" tree-entry list from tree parser Linus Torvalds
2006-05-29 19:19 ` [PATCH 6/10] fsck-objects: avoid unnecessary tree_entry_list usage Linus Torvalds
2006-05-29 19:29   ` Linus Torvalds
2006-05-29 19:19 ` [PATCH 7/10] Remove unused "zeropad" entry from tree_list_entry Linus Torvalds
2006-05-29 19:20 ` [PATCH 8/10] Convert "mark_tree_uninteresting()" to raw tree walker Linus Torvalds
2006-05-29 19:20 ` [PATCH 9/10] Convert fetch.c: process_tree() " Linus Torvalds
2006-05-29 19:21 ` [PATCH 10/10] Remove last vestiges of generic tree_entry_list Linus Torvalds
2006-05-29 22:31 ` [PATCH 0/10] re-based and expanded tree-walker cleanup patches Junio C Hamano
2006-05-30  0:42   ` Linus Torvalds
2006-05-30  3:04     ` Junio C Hamano
2006-05-30  4:17       ` Linus Torvalds
2006-05-30  4:26         ` Junio C Hamano
2006-05-31 22:53         ` Junio C Hamano
2006-06-01  3:11           ` Shawn Pearce
2006-06-23 11:37           ` Eric W. Biederman [this message]
2006-06-23 21:52             ` A series file for git? Junio C Hamano
2006-06-24  9:01             ` Junio C Hamano
2006-06-24 17:54               ` Eric W. Biederman
2006-06-26  0:44                 ` Shawn Pearce

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).