Linus Torvalds [off-list ref] writes:
My main use of "git ls-remote" tends to be to check what the other end
has when some pull request goes wrong (they forgot to push, or they used
the wrong ref name or whatever), and it ends up being hard to see all
the relevant data from the noise of people just having the same basic
tags etc from upstream.
So this adds a "--diff" option that shows only the refs that are
different from the local repository. So when somebody asks me to pull,
I can now just trivially look at what they have that isn't already my
basic branches and tags.
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. 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.
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?
quoted hunk
Comments?
+static int has_ref_locally(const struct ref *ref)
+{
+ unsigned char sha1[20];
+
+ if (!resolve_ref_unsafe(ref->name, RESOLVE_REF_READING, sha1, NULL))
+ return 0;
+
+ return !hashcmp(ref->old_oid.hash, sha1);
+}
+@@ -105,6 +121,8 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
continue;
if (!tail_match(pattern, ref->name))
continue;
+ if (diff && has_ref_locally(ref))
+ continue;
if (show_symref_target && ref->symref)
printf("ref: %s\t%s\n", ref->symref, ref->name);
printf("%s\t%s\n", oid_to_hex(&ref->old_oid), ref->name);
On Thu, Feb 2, 2017 at 12:03 PM, Junio C Hamano [off-list ref] 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