Any plans to make export work?

Any plans to make export work?

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

Hi Y'all,

I've been playing with export a bit, and it doesn't seem to work. Or at least 
it doesn't do what I think of as "work"-ing.

I'm basically doing a git-export and trying to create a quilt series out of 
it.

When you do a "quilt push -a" I get as far as:
06f81ea8ca09b880cadf101d7e23b500e9c164bc
[PATCH] scsi: remove volatile from scsi data

which doesn't apply as it (seems to) conflict with: 
152587deb8903c0edf483a5b889f975bc6bea7e0
[PATCH] fix NMI lockup with CFQ scheduler

Those two commits (and others) were merged by hand in:
c46f2ffb9e7fce7208c2639790e1ade42e00b146
merge by hand (scsi_device.h)

Export gives me a patch for the merge, but it a) appears to contain everything 
that was merged, not just the fixup-by-hand, and b) export spits it out after 
both of the commits which the merge merged - which is no good as quilt 
doesn't even get that far.

I realise I'm trying to represent a DAG as a linear series of patches. But the 
merge order is a linear sequence of commits, and so it *should* be 
representable as a linear series of patches. I think.

Any thoughts?

cheers

-- 
Michael Ellerman
IBM OzLabs

email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Any plans to make export work?

[Junio C Hamano]

Michael Ellerman <michael@ellerman.id.au> writes:

> I realise I'm trying to represent a DAG as a linear series of patches. But the 
> merge order is a linear sequence of commits, and so it *should* be 
> representable as a linear series of patches. I think.
>
> Any thoughts?

All true, and more.  It does not show the initial import so you
cannot bootstrap from an emptiness.

git-export is among one of the things that were there before all
the modern core features were invented (especially git-rev-list,
let alone --merge-order flag to it) and could use an overhaul.
I would script around rev-list --merge-order and diff-tree
instead of hacking on that C code if I were doing it myself.

But we need to define what we _want_ to see first.

Here is a simple example:

         ---> B --> C --> D
       /          /
     O ---> A ---

The original O forked into branch A and B, merged at C and then
continued on to D.

What the current (admittedly ancient) 'git export' gives is:

    commit object O
    diff between void and O should be given but it doesn't.
    commit object A
    diff O A
    commit object B
    diff O B
    commit object C
    diff A C
    commit object D
    diff C D

I just noticed that diff between B and C is not shown.  Come to
think of it, this is _not_ a bug (unlike the initial import not
showing which I think is just a bug).  The purpose of export is
to give you everything that lets you recreate each tree
associated with all commits and their ancestry information, so
as long as you know C is a child of A and B, enough information
to get trees A and B, and diff between A and C, diff between B
and C is simply redundant.  So, in short, export is perfect if
we fix it to show the initial import.  It just is not designed
for doing whatever you are trying to do with its output.

To be usable in your quilt workflow, what output would we want?

Off the top of my head, I can think of this:

    commit object O
    diff between void and O
    commit object A
    diff between O and A
    commit object B
    diff between O and B
    commit object C
    diff between A and C
    diff between B and C
    commit object D
    diff between C and D

Is this what you can use?  If you can live with something like
the above, 'git whatchanged -p -m --merge-order --root' would
give you exactly that in a reverse order.  It would give you:

    commit object D
    diff between C and D
    commit object C
    diff between A and C
    diff between B and C
    commit object B
    diff between O and B
    commit object A
    diff between O and A
    commit object O
    diff between void and O

You earlier said "diff between (automerged A+B) and C", but the
former is not something git even records, so you have to compute
it yourself from the given information, if you really want it.