<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
* martin f krafft wrote, On 22/11/08 13:56:
<blockquote cite="mid:20081122135626.GB24132@lapse.rw.madduck.net"
type="cite">
<pre wrap="">also sprach Sam Liddicott <a class="moz-txt-link-rfc2396E" href="mailto:sam@liddicott.com"><sam@liddicott.com></a> [2008.11.19.1533 +0100]:
</pre>
<blockquote type="cite">
<pre wrap="">A set of patches between the source tar and the target released is
automatically generated, coping with merging and branching by
selecting the paths that have the most number of commits - as was
done for the bitkeeper exports.
</pre>
</blockquote>
<pre wrap=""><!---->
Would you elaborate on this a bit? </pre>
</blockquote>
sure<br>
<blockquote cite="mid:20081122135626.GB24132@lapse.rw.madduck.net"
type="cite">
<pre wrap="">How do you lay out your branches,
</pre>
</blockquote>
it doesn't matter<br>
<blockquote cite="mid:20081122135626.GB24132@lapse.rw.madduck.net"
type="cite">
<pre wrap="">how do you or does it select the commits/branches to turn into
patches, </pre>
</blockquote>
it has a concept of "origin" and "release". <br>
It does a git-export on "origin" and then patches from origin..release<br>
<blockquote cite="mid:20081122135626.GB24132@lapse.rw.madduck.net"
type="cite">
<pre wrap="">how does it flatten them into a linear series of files, and
</pre>
</blockquote>
using an awk function I wrote, git_linearize, which parses git-rev-list
output to build a DAG and then finds the longest path from release back
to origin.<br>
<br>
Unlike git-log which is a commit history, git-rev-list is the revision
history. It includes merges and conflict resolution etc, it is a
history of tree revisions, so I can do git-diff between revisions and
get the actual conflict-resolved merged diff's between revisions, which
often is not quite the same as the output of git-log.<br>
<br>
I produce the DAG by git-rev-list --top-order --reverse --parents
^origin release so I skip out a V shaped chunk of ancestors that are
parents to origin. When parsing the git-rev-list output I cut out all
revisions that aren't descended from origin. This gives me a nice ^
(inverted v) shape. I then navigate that from the bottom up (which
explores a V shape) but it intersects with the ^ shape and hopefully I
don't have a lot to explore.<br>
<br>
So once I have the path with the most number of commits, I have the
best granularity on patches.<br>
<br>
At merges sometimes there will be multiple patches on each branch, but
the branch with the least number of patches will get merged as one
patch. (It's not trivial to keep both sets of patches except in cases
when they don't touch the same files).<br>
<blockquote cite="mid:20081122135626.GB24132@lapse.rw.madduck.net"
type="cite">
<pre wrap="">how does it integrate them with the SRPM?
</pre>
</blockquote>
It has origin exported as the Source0, which hopefully is a tagged
upstream release and then a bunch of patches from the packager.<br>
<br>
If the packager has a branch with the upstream + a load of patches then
it will spit out a nice srpm.<br>
<blockquote cite="mid:20081122135626.GB24132@lapse.rw.madduck.net"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">All in all it produces srpms's and spec files full of patches just like
the old redhat kernel rpm's.
</pre>
</blockquote>
<pre wrap=""><!---->
So you have dozens of patches? Is each patch useful by itself? </pre>
</blockquote>
Depends on the person that managed the patches since the upstream
release.<br>
Shortly after release time it will make sense. Many months after
release time there could be a lot of patches.<br>
I've got 1,600 patches until the next samba4 release!<br>
<blockquote cite="mid:20081122135626.GB24132@lapse.rw.madduck.net"
type="cite">
<pre wrap="">Let's
say you have a couple of fixes against upstream, and two new
features you developed on top of upstream, how does someone else
extract e.g. the first of the two features for their own use?
</pre>
</blockquote>
The packager does "make srpm" and produces his release which contains
all 4 patches.<br>
Someone else can:<br>
rpm -Uvh blah.srpm<br>
<br>
and then grab the patches from .../redhat/SOURCES/patch*<br>
<br>
Sam<br>
</body>
</html>