Re: [PATCH] ls-remote: add "--diff" option to show only refs that differ

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Feb 2, 2017, 20:32 UTC
Message-ID: <CA+55aFw14UXMa6OJ6YLHjy3tzOD+VSNytw6kMpaxFEfyuO2hAw@mail.gmail.com>
In-Reply-To: <xmqqshnws6ma.fsf@gitster.mtv.corp.google.com>

On Thu, Feb 2, 2017 at 12:03 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 5 quoted lines

>
> Most downstream folks seem to care about refs/remotes/origin/$branch
> and I think in that context "git ls-remote --diff [origin]" that
> compares their refs/heads/* and refs/remotes/origin/* would make
> sense.

Hmm. Maybe. The main target for noise reduction for me was actually all the shared tags.

Which doesn't have that issue.

Also, I've never ever used "git ls-remote" on origin. Do people actually do that? Why would a regular user ever use ls-remote in the first place?

The only reason I've ever had for using ls-remote is exactly because the remote is somehow "odd", and the _normal_ flow didn't work, so you want to start investigating. So by definition (at least for me), ls-remote is not part of a good normal flow.

So I kind of see where you are coming from, but I don't really see that as being a normal workflow for me - or really anybody.

What I think *your* use case is would be more for a workflow along the lines of

   # update the remote data
   git fetch [origin]

   # have some way to just see what branches are not the same
   git status --all

or something ("git status" already talks about the status of the current branch vs the origin branch).

> Your has_ref_locally() seems to return true by comparing
> their value with the value of the local ref without any the fetch
> refspec mapping.

Right. Because I see the use of "ls-remote" being mostly for maintainer pulls, and the "origin" in many ways would be the other way around (and you wouldn't even know what the name of said origin would be locally).

I basically don't see downstream contributor doing ls-remote, it's a upstream maintainer command.

But that may be a lack of imagination on my part.

> When one contributor asks you to pull refs/heads/master you want to
> go and see if it is different from refs/heads/master you have?

No. What happens is that people ask me to do something like

    git pull ..some-target.. tags/for-linus-3

and the pull fails because there is no such tag. That's when I go "ok, they screwed up, let's see what they *meant* for me to pull", and I go "git ls-remote".

In other words, I don't see anybody ever using git ls-remote if they already know what the remote is. That's why I don't see "origin" to be an issue - origin is by definition somethinig you trust, and you just fetch and pull from.

So the only reason I've ever had for using ls-remote is literally "ok, what the hell is going on at that remote repo".

And then it is generally a bare repository, and it generally does *not* have remote branches in it at all. But it *does* generally end up having all the basic branches and tags (not always, but it's very common).

Which is why I as a maintainer then want to just weed out anything that is already my usual branches that everybody downstream already has.

I agree that it's a specialized case, but I also think it's the _main_ case for ls-remote in the first place (apart from some scripting to check for updates or whatever).

But maybe more people use ls-remote than I think they do (and in different ways than what I envision).

                 Linus