On Wed, Oct 24, 2012 at 10:50 PM, Felipe Contreras
<[email protected]> wrote:
> This works just fine. Go ahead, apply my patch, and run it, the second
> branch gets updated.
Yes, but as you said:
> That is already the case, my patch will cause this to generate the same
> output:
> % git fast-export --{im,ex}port-marks=/tmp/marks ^foo foo.foo
> Which is still not got, but not catastrophic by any means.
Which is exactly the reason we (Dscho and I during our little
hackathon) went with the approach we did. We considered the approach
you took (if I still had the repository I might even find something
very like your patch in my reflog), but dismissed it for that reason.
By teaching fast-export to properly re-export interesting refs, this
exporting of negated refs does not happen. Additionally, you say it is
not catastrophic, but it _is_, if you run: 'git fast-export ^master
foo', you do not expect master to suddenly show up on the remote side.
I agree that your test more accurately describes what we're testing
(and in fact, it should probably go in the tests for remote helpers).
However, this test points out a shortcoming of fast-export that
prevents us from implementing a cleaner solution to the 'fast-export
push an existing ref' problem.
--
Cheers,
Sverre Rabbelier
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
