Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
- From
Sverre Rabbelier <srabbelier@gmail.com>
- Date
- Oct 25, 2012, 06:07 UTC
- Message-ID
- <CAGdFq_jfiX9apPyq6pba4S4iCQLGLmDvSrLaujSB5rO0i+fzfg@mail.gmail.com>
- In-Reply-To
- <CAMP44s3kBxzJbyoxPqWbRMWmpX9sNPGjdRy_KrTeRoVmGC-+Hg@mail.gmail.com>
On Wed, Oct 24, 2012 at 10:50 PM, Felipe Contreras <felipe.contreras@gmail.com> 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