Re: [PATCH v2] ls-remote: print URL when no repo is specified

Tay Ray Chuan [off-list ref] writes:

After 9c00de5 (ls-remote: fall-back to default remotes when no remote
specified), when no repository is specified, ls-remote may use
the URL/remote in the config "branch.<name>.remote" or the remote
"origin"; it may not be immediately obvious to the user which was used.

I cannot convince myself that this is a good change, as I've always
thought "ls-remote" output as something people want to let their scripts
read and parse.  9c00de5 may have given an enhancement to these scripts in
the sense that they can now respond to an empty input from the end user,
but this patch forces them to change the way they parse the output from
the command.

I also think this patch is solving a wrong problem.

When an end user does not know which remote ls-remote would be talking to
by default, what else does he *not* know?  Probably which remote "pull"
would be fetching from and what branch it would be merging with?  Doesn't
he have a better command to use to learn that information to reorient
himself when he is lost that way?

Hi,

On Wed, May 12, 2010 at 1:50 PM, Junio C Hamano [off-list ref] wrote:

Tay Ray Chuan [off-list ref] writes:

quoted

After 9c00de5 (ls-remote: fall-back to default remotes when no remote
specified), when no repository is specified, ls-remote may use
the URL/remote in the config "branch.<name>.remote" or the remote
"origin"; it may not be immediately obvious to the user which was used.

I cannot convince myself that this is a good change, as I've always
thought "ls-remote" output as something people want to let their scripts
read and parse.  9c00de5 may have given an enhancement to these scripts in
the sense that they can now respond to an empty input from the end user,
but this patch forces them to change the way they parse the output from
the command.

in this patch, the remote url is printed to stderr, instead of stdout,
so existing scripts should be safe.

I also think this patch is solving a wrong problem.

When an end user does not know which remote ls-remote would be talking to
by default, what else does he *not* know?  Probably which remote "pull"
would be fetching from and what branch it would be merging with?  Doesn't
he have a better command to use to learn that information to reorient
himself when he is lost that way?

I'm not sure if there's a command to determine the remote - I'd be
interested to know it, if there's one.

That aside, I believe this patch as an attempt at improving usability.

Compare (pre-patch):

  $ git ls-remote
  (scratch head)
  $ git-x # to determine which remote we listed refs from

with (post-patch):

  $ git ls-remote

The advantage is minor, but I feel there's some added convenience.

-- 
Cheers,
Ray Chuan

Tay Ray Chuan wrote:

On Wed, May 12, 2010 at 1:50 PM, Junio C Hamano [off-list ref] wrote:

quoted

I cannot convince myself that this is a good change, as I've always
thought "ls-remote" output as something people want to let their scripts
read and parse.  9c00de5 may have given an enhancement to these scripts in
the sense that they can now respond to an empty input from the end user,
but this patch forces them to change the way they parse the output from
the command.

Would 9c00de5 be so useful for scripts?  I suspect the typical script
does

  git ls-remote "$remote"

so to use the new default it would need adjusting.

Run by hand, 'ls-remote | grep heads' can be quite useful.

in this patch, the remote url is printed to stderr, instead of stdout,
so existing scripts should be safe.

quoted

I also think this patch is solving a wrong problem.

When an end user does not know which remote ls-remote would be talking to
by default, what else does he *not* know?  Probably which remote "pull"
would be fetching from

[...]

I think I see what you are saying, and for scripts, that really would
be the most useful thing.  Then the script could use something like

  if test -z "$remote"
  then
	remote=$(git branch --get-remote --current)
  fi
  git ls-remote "$remote"

which would be much better than

  git ls-remote ${remote:+"$remote"} 2>/dev/null

because it does not suppress error messages.

For manual use of ls-remote, on the other hand, I can see the use of
the reminder.

Jonathan

On Sat, May 15, 2010 at 12:17 AM, Jonathan Nieder [off-list ref] wrote:

Tay Ray Chuan wrote:

quoted

On Wed, May 12, 2010 at 1:50 PM, Junio C Hamano [off-list ref] wrote:

quoted

quoted

I cannot convince myself that this is a good change, as I've always
thought "ls-remote" output as something people want to let their scripts
read and parse.  9c00de5 may have given an enhancement to these scripts in
the sense that they can now respond to an empty input from the end user,
but this patch forces them to change the way they parse the output from
the command.

Would 9c00de5 be so useful for scripts?  I suspect the typical script
does

 git ls-remote "$remote"

so to use the new default it would need adjusting.

Right, existing scripts that use git-ls-remote are unlikely to be
affected by 9c00de5, or this patch, for that matter.

quoted

in this patch, the remote url is printed to stderr, instead of stdout,
so existing scripts should be safe.

quoted

I also think this patch is solving a wrong problem.

When an end user does not know which remote ls-remote would be talking to
by default, what else does he *not* know?  Probably which remote "pull"
would be fetching from

[...]

I think I see what you are saying, and for scripts, that really would
be the most useful thing.  Then the script could use something like

 if test -z "$remote"
 then
       remote=$(git branch --get-remote --current)
 fi
 git ls-remote "$remote"

Just curious - when did git-branch learn "--get-remote"? Or "--current"?

-- 
Cheers,
Ray Chuan

Tay Ray Chuan wrote:

On Sat, May 15, 2010 at 12:17 AM, Jonathan Nieder [off-list ref] wrote:

quoted

I think I see what you are saying, and for scripts, that really would
be the most useful thing.  Then the script could use something like

 if test -z "$remote"
 then
       remote=$(git branch --get-remote --current)
 fi
 git ls-remote "$remote"

Just curious - when did git-branch learn "--get-remote"? Or "--current"?

It didn’t.  I was just saying that it should (or we should provide some
commands to that effect).  What do you think?

Maybe later today...
Jonathan

On May 13, 2010, at 23:07, Tay Ray Chuan wrote:

quoted

When an end user does not know which remote ls-remote would be talking to
by default, what else does he *not* know?  Probably which remote "pull"
would be fetching from and what branch it would be merging with?  Doesn't
he have a better command to use to learn that information to reorient
himself when he is lost that way?

I'm not sure if there's a command to determine the remote - I'd be
interested to know it, if there's one.

What git seems to be missing is a "git info" command, which
would print out essentially something like what "svn info" does:
name of remote repo that we're tracking, name of current branch,
date/author/subject of last commit.

Regards,
  -Geert

Heya,

On Sun, May 16, 2010 at 04:14, Geert Bosch [off-list ref] wrote:

What git seems to be missing is a "git info" command, which
would print out essentially something like what "svn info" does:
name of remote repo that we're tracking, name of current branch,
date/author/subject of last commit.

You can get information about the remote with:

$ git remote -v

And then for the branch etc you can do (although it doesn't list the author):

$ git branch -v

-- 
Cheers,

Sverre Rabbelier

On May 16, 2010, at 06:36, Sverre Rabbelier wrote:

On Sun, May 16, 2010 at 04:14, Geert Bosch [off-list ref] wrote:

quoted

What git seems to be missing is a "git info" command, which
would print out essentially something like what "svn info" does:
name of remote repo that we're tracking, name of current branch,
date/author/subject of last commit.

You can get information about the remote with:

$ git remote -v

geert-boschs-computer:/tmp%ssh kwai git init --bare /work/bosch/temp.git
Initialized empty Git repository in /export/work/bosch/temp.git/
geert-boschs-computer:/tmp%git init temp
Initialized empty Git repository in /private/tmp/temp/.git/
geert-boschs-computer:/tmp%cd temp
geert-boschs-computer:/tmp/temp%echo hello>world
geert-boschs-computer:/tmp/temp%git add world
geert-boschs-computer:/tmp/temp%git commit -m "Add hello" world
[master (root-commit) 10837b9] Add hello
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 world
geert-boschs-computer:/tmp/temp%git push --all kwai:/work/bosch/temp.git
Counting objects: 3, done.
Writing objects: 100% (3/3), 211 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To kwai:/work/bosch/temp.git
 * [new branch]      master -> master
geert-boschs-computer:/tmp/temp%git push -u --all kwai:/work/bosch/temp.git
Branch master set up to track remote branch master from kwai:/work/bosch/temp.git.
Everything up-to-date
geert-boschs-computer:/tmp/temp%git remote -v
geert-boschs-computer:/tmp/temp%git push
Everything up-to-date

So, there is a remote that gets used automatically by git push and git pull,
but it's not obvious which one. Basically, a "git info" command should give
a dozen lines or so that allows one quickly to identify a repository, including
current branch, any remote it tracks, last commit, wether the working directory
is clean, wether anything is staged for commit, wether the repository tracks
a non-git (svn, bzr, hg) repository.

And then for the branch etc you can do (although it doesn't list the author):

$ git branch -v

While both commands are very useful, I think a case can be made for a single
command that pulls together enough information in a few lines that it is clear.

I'll see if I can cobble something up.

Jonathan Nieder [off-list ref] writes:

Tay Ray Chuan wrote:

quoted

On Sat, May 15, 2010 at 12:17 AM, Jonathan Nieder [off-list ref] wrote:

quoted

quoted

I think I see what you are saying, and for scripts, that really would
be the most useful thing.  Then the script could use something like

 if test -z "$remote"
 then
       remote=$(git branch --get-remote --current)
 fi
 git ls-remote "$remote"

Just curious - when did git-branch learn "--get-remote"? Or "--current"?

It didn’t.  I was just saying that it should (or we should provide some
commands to that effect).  What do you think?

I think you said what I meant to say much more clearly.  Thanks.