On Thu, Feb 2, 2017 at 12:03 PM, Junio C Hamano <gits...@pobox.com> wrote:
>
> 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
