Re: git fetch origin $SHA1 doesn't work as often as it could

From: JP Sugarbroad <jpsugar@google.com>
Date: May 18, 2016, 22:40 UTC
Message-ID: <CAD0oC4wezb8svOW5KHONLi5wQN+H_3xqPLoU_EZbtL5zAkdv_Q@mail.gmail.com>
In-Reply-To: <xmqq8tz7qb7d.fsf@gitster.mtv.corp.google.com>

On Wed, May 18, 2016 at 5:59 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 5 quoted lines

> The commit from the submodule that is bound to the superproject may
> no longer be sitting at the tip of any branch in the submodule.  The
> hack you are outlining here would not help, and invites "the feature
> works some of the time (i.e. the commit happens to be at the tip of
> one of the refs) but fails most of the time" bug reports.

Sure, that's a reasonable fear. In this case the branches don't move, but if one were concerned about that one could use tags instead. It is quite reasonable to point a submodule to a tag and not expect that to go away.

> So I am not enthused, even though at the technical level, I agree
> that it is a good "solution" to pretend as if one of the refs were
> requested after the fetch-pack discovers the refs advertised by the
> upload-pack.

It could also lead to allowing "git clone -b $SHA".

It's possible to implement this today by manually doing the conversion via git ls-remote. This is a significant streamlining that would interact well with the recent change to submodules to attempt "git fetch origin $SHA1".

> I just fear that it is a wrong approach to solve the real issue and
> instead make it worse by relieving the pressure from the project and
> hosting site to configure their repository to support their users
> properly.

Unfortunately I don't see the likes of github or bitbucket adding allow-reachable-sha1-in-want any time soon, as it is an expensive operation server-side.

This is a significant boost to utility of shallow submodules (a flag for which was just recently added to clone), without requiring any significant changes to repository configuration.

- JP