exporting patches like bitkeeper

[martin f krafft]

also sprach Sam Liddicott <sam at liddicott.com> [2008.11.24.1549 +0100]:
> > how do you or does it select the commits/branches to turn into
> > patches,
>
> it has a concept of "origin" and "release".
> It does a git-export on "origin" and then patches from
> origin..release

I assume you mean git-archive to create the tarball, and then
patches.

> > how does it flatten them into a linear series of files, and
>
> 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.

Why does it build a DAG? Git already maintains a DAG. Arguably,
though, you cannot really access it directly, so you are using
git-rev-list to obtain paths between multi-parent/multi-children
nodes and put them back together?

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

If I point git-log -p at a merge commit, I see the merge and
resolved patch.

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

I cannot really follow this and don't have the time right now to
test an example. But I'll just take your word that it works.

> So once I have the path with the most number of commits, I have
> the best granularity on patches.

Is granularity on patches what you seek? Why? Assuming you have
a feature branch F with commits C1 through C4 implementing the
feature, and C5 correcting a typo, and C5 is merged into master
recursively and separately from C4, wouldn't your patch series thus
contain a patch for C5 and, say C3, which introduced the typo?
Ideally, you wouldn't submit C1..C5 upstream, but a consolidated,
single patch, and I'd think that this is what you want in your
source package as well, no?

> If the packager has a branch with the upstream + a load of patches
> then it will spit out a nice srpm.

Let's call this the master branch. Let's assume it contains M1..M9.
B1 branches off M3, followed by B2..B4, and the branch is merged
back at M6. In other words, M4..M5 is only reachable from M6 through
its first parent, and B1..B4 are only reachable via the second
parent.

If I understand you algorithm, then the longest path from M9 to M1
includes the segment M6..B4..B1..M3, but not M5..M4. I assume those
two are simply squashed and presented as the patch for M6, since all
the other changes merged at M6 are part of the linear series. If
B were shorter than the M segment, it would be the other way around.

In either case, the content at M9 is identical, but there is no
control over which commits get into the patch series.

... unless of course your branch off upstream is merely a collector
branch where you stuff squashed commits and into which you
cherry-pick that which you want. In that case, I'd think that
a branch dependency hierarchy managed by TopGit would be more
manageable.

I'd love to clone a repo where you make use of this to understand
your steps better.

Cheers,

-- 
 .''`.   martin f. krafft <madduck at debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"whale feces or working at microsoft? i would probably be the whale
 feces researcher. salt air and whale flatulence; what
 could go wrong?"
             -- michael moyer, executive editor of _popular science_
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
Url : http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20081125/f756ed13/attachment.pgp