wishlist: git info

Hi,

while git is pleasant to use in everyday work, there is one svn feature which is miss dearly, namely "svn info". svn info can give information about specific file objects, but I think its main feature is to use it without any path and thus just describe the current project. I use this a lot to quickly find out to which remote repository the current directory belongs (yes, some work projects tend to look very similar...) and what is the current state of the directory.

As a crude approximation, "git info" should print something like: cat .git/config | grep url git show | head -3

Probably not the most intelligent way to compute it, but you get the idea. git info should give a brief overview over the current working directory. If there is consensus that this is a useful feature I can try to suggest a patch (although honestly I would prefer that someone else does it, I am not familiar with the git internals).

Thomas

Thomas Neumann, Mon, Nov 12, 2007 21:30:56 +0100:

you're better of just running "gitk --all" at this point. It'll show remote branches (with the names of remote repos prepended) and their relations to the local repo.

Like what? None of the commands you suggested even touch it. Would

    git remote -r -v && git log --max-count=1 --pretty=format:'%h %s'

do what you think is what you need?

May I suggest you to consider just running "git fetch -v"?

hm, this is not what I am after. I do not want to inspect the history, I want to see where this repository "belongs" to. Gitk shows me the name (which is reasonable, of course), but not the URL. And it is a GUI application, which is not so perfect.

probably "current working directory" was not the best way to phrase it. I mean state of the repository, which in my case is a clone of a central repository. My commands show (ignoring formatting): 1. the remote repositories with URL 2. the current head commit hash 3. the date of the head commit. Which gives a pretty decent idea about the state of the repository.

perhaps, the first command gives me an error (git 1.5.2.5). This here is nearly ok

git remote && git log --max-count=1 --pretty=format:'%H %cD'

except the missing URL from git remote (but perhaps your options include it with a newer git version, will test).

this is has side effects, and is quite slow. Your command sequence above
  is more handy (and faster).

So I can emulate git info with an alias, and this is good enough for mew now, thanks for the hints. Perhaps a somewhat more elaborate version of git info might be useful for others, too, but this is not urgent.

Thomas

Thomas Neumann, Mon, Nov 12, 2007 23:50:18 +0100:

Don't you want to know where the remote repo is at?

...which in Git-lingo would be misunderstood as the output of git-status :)

Ach, make it "git remote -v". It does exactly showing of the url.

Dunno what I wanted the "-r" for. Probably left from thinking of "git branch -r" (which shows remote branches).

It is there since 1.5.3-rc1

Thomas Neumann wrote:

Perhaps also project description (if it exists?)

one can specify a project description? I did not even know this. But yes, this would be useful, too. In general I think git info should show everything to quickly understand what is currently checked out. The name of the current branch should probably be included, too. I use an alias with the commands proposed by Alex Riessen for now, but a more general command would be nice.

Thomas

Thomas Neumann wrote:

It is project description for gitweb (git web interface), and I think also for other web interfaces (cgit, wit, git-php). Or rather *repository* description. It is in .git/description (in 'description' file in git repository).

Unfortunately by default it contains (see: ${tempate_dir}/description)

  Unnamed repository; edit this file to name it for gitweb.

Name of current branch, current directory, name of topdir (with '.git' stripped if it is bare repository), perhaps oneline description of top commit. And if branch is under StGit or Guilt (patch management interfaces) control.

See also helper functions to set shell prompt in contrib/completion/git-completion.bash.

I for example have "1760:[gitweb/web!git]$ " as bash prompt:
 - 1760 is number of command in history, 
 - 'gitweb/web' is name of branch I am on,
 - 'git' is the name of repository
This migitates need got 'git-info' command.

You can always write[*1*] git-info.sh or git-info.perl[*2*], and install it as git-info in your git installation. And send patches here, to git mailing list, for comments.

Footnotes:
----------
[*1*] Even if one of the most common complaints is "too many user-visible
      commands".
[*2*] Scripts are better for ptototyping. Choose your own poison: POSIX
      shell or Perl...

Jakub Narebski wrote:

On the other hand one of the proposed and long requested features is git-explain, which is meant to show status of git command progress. If you could incorporate proposed features in git-info (perhaps only with some option: --state, --explain, -v / --verbose,...) there would be no complaints about yet another git command.

What git-info / git-explain should show:
 * interrupted fetch / fetch in progress
 * interrupted pull  / pull  in progress
 * interrupted merge / merge in progress
 * interrupted commit, commit --amend, or tag editing
 * rebase in progress (including interactive rebase and rebasing
   using merge engine)
 * git-am (apply mbox) in progress

Perhaps we should also include git-count-objects in git-info, like git-verify-tag functionality was included in 'git tag --verify'...

Hi,

On Tue, 13 Nov 2007, Thomas Neumann wrote:

Is slightly troubles me that you put so much emphasis on what I would call "remote information". I understand that in svn, your working directory without the server is not very useful. But we do not have that problem.

FWIW I think a much better idea is to have that bash prompt that was posted some months ago; there's not even a need to run a program manually then!

His name is "Riesen", just like in the German translation of the famous Newton statement.

Ciao, Dscho

that is true. My usage pattern probably stems from the fact that I am a long term svn user :) And I use git for work now, where there is indeed some kind of central repository just as in a Subversion setting. In a fully decentralized setting the remote information is probably not as important, although you might still want to know what happens if you issue "git pull".

a bash prompt is nice too, of course. But there is only so much information you can reasonably encode in the prompt. When you know the remote url (ok, this assumes a "centralized" model), branch, head commit and date of the head commit (this is just for humans), you know very precisely what you are looking at. For the more decentralized users some other information might be relevant, I don't know.

While the head commit hash is enough to identify a point in the revision history, the other information allows a human to identify the point in the revision history easily. So I can see what is checked out, how old the checkout is etc.

sorry for the typo, I noticed it just the moment I had pressed send... Sometimes I really wish I could edit mails after sending them.

Thomas

On Tue, Nov 13, 2007 at 12:32:19 +0100, Thomas Neumann wrote:

The remote URL isn't /the/ useful bit, most of the time. Either you have just one remote, which is the project central repository and you probably know which it is just by knowing which project it is, or you have many of them and their names tell you enough.

Note, that unlike in Subversion, the branch name is /not/ part of the URL.
And that is the useful bit of the information. So what 'git info' probably
should show is:
 - Which branch is currently checked out
 - Which branch it is tracking (inspect the config)
 - List of n (where n is small integer) "closest" branches, where the
   distance to a branch is number of commits in HEAD since common ancestor
   with that branch.
 - Latest included tag. Basically something like git describe.
 - Short log of last few commits.

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I mildly disagree.

Exactly because you can do so much more in isolation than with other systems like SVN, I tend to think that you would want to know what "git remote show" gives you, and a lot more (e.g. what "git shortlog origin@{1}..origin" would give you if you were to fetch now). You can deviate from the others quite a lot without synchronizing, because git allows you to do so very easily, and I can understand that some people will find it scary when it comes to the point to synchronize with the others.

A stronger support to learn "what happened there while I was looking the other way" would be a definite plus.

But "project description"? Give me a break. If you have cloned the repository (or learned the existence of repository), you already learned from elsewhere what the project is about.

I haven't spoken in this thread because honestly I found most of the things mentioned here were totally uninteresting.

well, not that I asked for the project description, but I see a small benefit there. The point is not to know what the project is about. You know, after all you checked it out in the first place. My goal is to quickly/easily see "what is in this directory".

Perhaps my usage pattern is obscure, but I have something like 40 repositories checked out in different directories, and I sometimes loose track of what actually is in a certain directory (and in what state). A simple "ls" is not enough, as some of them look very similar on the top level. Hence my interest for "git info".

sorry for this. While I find it useful, this is certainly not an important feature, and I can mimic it now myself.

Thomas

Thomas Neumann wrote:

I had that problem too, until I realized that what I really needed was to clone repos out with the same careful structure we're using on the server, and then just use \w instead of \W in my $PS1.

Thomas Neumann <tneumann@users.sourceforge.net> writes:

Don't get me wrong. My not finding it useful does not mean it won't be useful in the git user comminity in general. It just means I do not have a useful input to the discussion.

Johannes Schindelin, Tue, Nov 13, 2007 12:13:59 +0100:

now I am misspelled. How should I feel?...

Alex Riesen wrote:

Better than if you'd done it yourself in a patch that was allowed to endure for more than 10000 commits ;-)