From: firstname.lastname@example.org (Eric W. Biederman)
To: Junio C Hamano <email@example.com>
Cc: Linus Torvalds <firstname.lastname@example.org>,
Git Mailing List <email@example.com>
Subject: A series file for git?
Date: Fri, 23 Jun 2006 05:37:34 -0600 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <email@example.com> (Junio C. Hamano's message of "Wed, 31 May 2006 15:53:19 -0700")
Junio C Hamano <firstname.lastname@example.org> writes:
> Linus Torvalds <email@example.com> 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 |
> 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.
next prev 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
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: http://vger.kernel.org/majordomo-info.html
* 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).