top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Should "git help" respect the 'pager' setting?

0 votes
370 views

I have my global git config pager set to 'cat', but when I do a "git help ", it still uses a pager. This is especially irksome in emacs shell buffers, where I am most of the time. I know I can do a M-x man -> git-, but wondered if this was a bug or user error. ("git --no-pager help " does the same.)

% git --no-pager help log
WARNING: terminal is not fully functional
(press RETURN)
posted May 30, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote
 
Best answer

"git help foo" just calls "man git-foo" by default, so what happens is the same as if you called "man git-foo" by hand. Git does not have much control over what man will do, it could probably call "man -P $pager" when the Git pager is set, but I'd find it a bit weird.

If you're an Emacs user, you can read about man.viewer and set it to woman, or set PAGER=cat when inside Emacs.

I personally run M-x git-foo RET, and never run "git help".

answer May 30, 2013 by anonymous
Similar Questions
+1 vote
Git uses less by default if there is no explicit pager specification

After using "git diff", I believe that Git (1.7.7.6) uses "less" by default if there is no explicit pager specification (via $PAGER or Git's core.pager).

1) Am I correct?
2) I dislike defaulting to using a pager (partly because I dislike "less" in particular).
3) In any case, using a pager by default doesn't seem to be documented, either on the main "git" manual page or in "git-config".

+1 vote
I wanted to avoid push if any of the files is deleted from local git clone area. Can anyone please help me with that?

I wanted to avoid push if any of the files is deleted from the local git clone area. Can anyone please help me with that?

I am using Stash for repository management.

0 votes
Help on move the git repo directory from /opt/git to /passdev/git on unix server

I'm about to move the git repository directory from current one: /opt/git to new one: /passdev/git. And I got some question regards how to perform this?

First I will Shut down git and I tried to search online but I can't find any links on how to shutdown git? could you let me know what is the commands on how to shutdown the git?

Next is Copy /opt/git to /passdev/git? Is this the correct way to move the whole installation directory? Next Bring up git, what is the commands to bring up? and also I had find out this link: http://gbayer.com/development/moving-files-from-one-git-repository-to-another-preserving-history/ is for move the folders on one repository to another repository, so I was wondering since I'm going to move the whole repository folder into different location, so should I using git filter-branch --subdirectory-filter -- --all to move each dirctory in one repo, or I can just using unix commands cp to move the whole repository folder?

0 votes
device files should be handled by git

I have a disk image of a small embedded device whose root file system I'd like to check-in to git as a means of distributing its GPL'd software. In that disk image are device files, which GIT studiously ignores. If symlinks are handled (contents being the path that the symlink points at), I don't see why device files can't be handled (contents being the type (char or block) and the major and minor device number). TAR, for example, handles this fine, except that using tar in git sort-of goes against the granularity of the objects being modified (like adding a bunch of extra "sd??" devices), such that you are modifying a whole tar ball instead of the individual (device) files.

Is there a reason not to handle device files other than "its not traditional"? That's the only reason given in google or the IRC channel.

+1 vote
Git reset should be able to ignore file permissions

Recently I had to write some automation scripts and I found that git reset --hard actually restores each file's permissions.

That is causing both the created and the last-modified dates of the file to get changed to the time of the git reset.

This behavior is easy to demonstrate:

echo "test" > myfile
chmod 777 myfile

git add myfile && git commit -m "Test" & the only solution I'm able to think about is actually restoring the permissions of each file to the ones git thinks they should have before doing the git reset.

Maybe I'm wrong and there is a way for doing what I want, if so, please correct me. But if there isn't, should this be implemented? Are there any reasons for not doing it?

...