Re: [PATCH 1/3] t9350: point out that refs are not updated correctly

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Oct 25, 2012, 06:19 UTC
Message-ID: <CAMP44s1cRg_we5nXeRG1WcWz7YUOBrauJigeNna1YETcno9p=A@mail.gmail.com>
In-Reply-To: <CAGdFq_jfiX9apPyq6pba4S4iCQLGLmDvSrLaujSB5rO0i+fzfg@mail.gmail.com>

On Thu, Oct 25, 2012 at 8:07 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:

Show 17 quoted lines

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

Oh really? This is with your patches:

% git fast-export --{im,ex}port-marks=/tmp/marks foo1 ^foo2 foo3..foo3 reset refs/heads/foo1 from :21

reset refs/heads/foo3 from :21

reset refs/heads/foo2 from :21

This is with mine:

% ./git fast-export --{im,ex}port-marks=/tmp/marks foo1 ^foo2 foo3..foo3 reset refs/heads/foo3 from :21

reset refs/heads/foo2 from :21

reset refs/heads/foo1 from :21

Now tell me again. What is the benefit of your approach?

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

If 'git fast-export ^master foo' is catastrophic, so is 'git fast-export foo ^master', and that already exports master *today*.

Show 5 quoted lines

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

Which is something few users will notice. What they surely notice is that there's no remote-hg they can readily use. Nobody expects all software to be perfect or have all the features from day 1. Something that just fetches a hg repo is already better than the current situation: *nothing*.

And BTW, in mercurial a commit can be only on one branch anyway, so you can't have 'foo' and 'master' both pointing to the same commit/revision. Sure bookmarks is another story, but again, I don't think people would prefer remote-hg to stay out because bookmarks don't work _perfectly_.

Cheers.

-- 
Felipe Contreras