threads / discuss / 19552

Strangely hosed git install

Subject: Strangely hosed git install

## tl;dr

8 messages between May 28, 2009 and May 28, 2009.

replies: 7people: 3as markdown or json

Martin Langhoff· May 28, 2009, 07:08 UTC · lore

My main laptop (and part-time dev box) has a partially hosed git installation. This is an ubuntu intrepid machine where I have been building git from src for a while. Perhaps there's a way to diagnose this before I take more drastic measures :-)

So far gc, repack and stash show errors. No dataloss AFAICS (though the git stash errors scared me initially).

gc and repack error out thus:
$ git gc
usage: git-pack-objects [{ -q | --progress | --all-progress }]
        [--max-pack-size=N] [--local] [--incremental]
        [--window=N] [--window-memory=N] [--depth=N]
        [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset]
        [--threads=N] [--non-empty] [--revs [--unpacked | --all]*] [--reflog]
        [--stdout | base-name] [--keep-unreachable] [<ref-list | <object-list]
error: failed to run repack
$ echo $?
255
And stash...

$ git stash usage: git-diff-index [-m] [--cached] [<common diff options>] <tree-ish> [<path>...] common diff options: (...)

usage: git-diff-index [-m] [--cached] [<common diff options>]
<tree-ish> [<path>...]
common diff options:
(...)
Saved working directory and index state "WIP on master: 1eac877... WIP
olpc-update-query: if the lease is due soon avoid
randomly_do_nothing()"
HEAD is now at 1eac877... WIP olpc-update-query: if the lease is due
soon avoid randomly_do_nothing()
(To restore them type "git stash apply")
$ echo $?
0
$ git stash show
 olpc-update-query |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)
$ git stash apply # does the right thing
Some background diagnostics info
 - $ git --version
   git version 1.6.3.1.26.gf5b223
 - $ which git
   /home/martin/bin/git
  # there is no other git install anywhere on the box
 - the git-core package was once installed temporarily (to try out a
package that depends on git-core)
 - some oldstyle "dashed" commands trigger a helper bash extension, thus
   $ git-diff
   The program 'git-diff' is currently not installed.  You can install
it by typing:
   sudo apt-get install git-core
   bash: git-diff: command not found

I can't figure out what is wrong with the install. I have bisected a few bugs in the past, but that had never left any traces behind.

It's not a serious problem -- I just wonder whether it'd affect other people developing / tracking git.

cheers,
m
--
 martin.langhoff@gmail.com
 martin@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
Junio C Hamano· May 28, 2009, 07:18 UTC · re: Martin Langhoff · lore

Re: Strangely hosed git install

Martin Langhoff <martin.langhoff@gmail.com> writes:
Show 20 quoted lines
> My main laptop (and part-time dev box) has a partially hosed git
> installation. This is an ubuntu intrepid machine where I have been
> building git from src for a while. Perhaps there's a way to diagnose
> this before I take more drastic measures :-)
>
> So far gc, repack and stash show errors. No dataloss AFAICS (though
> the git stash errors scared me initially).
>
> gc and repack error out thus:
>
> $ git gc
> usage: git-pack-objects [{ -q | --progress | --all-progress }]
>         [--max-pack-size=N] [--local] [--incremental]
>         [--window=N] [--window-memory=N] [--depth=N]
>         [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset]
>         [--threads=N] [--non-empty] [--revs [--unpacked | --all]*] [--reflog]
>         [--stdout | base-name] [--keep-unreachable] [<ref-list | <object-list]
> error: failed to run repack
> $ echo $?
> 255

"type --all git"? "git --exec-path"? "ls $(git --exec-path)"?

Martin Langhoff· May 28, 2009, 07:22 UTC · re: Junio C Hamano · lore

Re: Strangely hosed git install

On Thu, May 28, 2009 at 9:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "type --all git"?
> "git --exec-path"?
> "ls $(git --exec-path)"?
>
It all looks fairly correct to me:

$ type --all git git is /home/martin/bin/git $ git --exec-path /home/martin/libexec/git-core $ ls $(git --ex ec-path) git git-merge-index git-add git-merge-octopus git-add--interactive git-merge-one-file git-am git-merge-ours git-annotate git-merge-recursive git-apply git-merge-resolve git-archimport git-merge-stupid git-archive git-merge-subtree git-bisect git-mergetool git-bisect--helper git-mergetool--lib git-blame git-merge-tree git-branch git-mktag git-bundle git-mktree git-cat-file git-mv git-check-attr git-name-rev git-checkout git-pack-objects git-checkout-index git-pack-redundant git-check-ref-format git-pack-refs git-cherry git-parse-remote git-cherry-pick git-patch-id git-citool git-peek-remote git-clean git-prune git-clone git-prune-packed git-commit git-pull git-commit-tree git-push git-config git-quiltimport git-count-objects git-read-tree git-cvsexportcommit git-rebase git-cvsimport git-rebase--interactive git-cvsserver git-receive-pack git-daemon git-reflog git-describe git-relink git-diff git-remote git-diff-files git-repack git-diff-index git-repo-config git-difftool git-request-pull git-difftool--helper git-rerere git-diff-tree git-reset git-fast-export git-revert git-fast-import git-rev-list git-fetch git-rev-parse git-fetch-pack git-rm git-fetch--tool git-send-email git-filter-branch git-send-pack git-fmt-merge-msg git-shell git-for-each-ref git-shortlog git-format-patch git-show git-fsck git-show-branch git-fsck-objects git-show-index git-gc git-show-ref git-get-tar-commit-id git-sh-setup git-grep git-stage git-gui git-stash git-gui--askpass git-status git-hash-object git-stripspace git-help git-submodule git-help--browse git-svn git-http-fetch git-symbolic-ref git-http-push git-tag git-imap-send git-tar-tree git-index-pack git-unpack-file git-init git-unpack-objects git-init-db git-update-index git-instaweb git-update-ref git-log git-update-server-info git-lost-found git-upload-archive git-ls-files git-upload-pack git-ls-remote git-var git-ls-tree git-verify-pack git-mailinfo git-verify-tag git-mailsplit git-web--browse git-merge git-whatchanged git-merge-base git-write-tree git-merge-file

cheers,
m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
Michael J Gruber· May 28, 2009, 08:29 UTC · re: Martin Langhoff · lore

Re: Strangely hosed git install

Martin Langhoff venit, vidit, dixit 28.05.2009 09:22:
Show 7 quoted lines
> On Thu, May 28, 2009 at 9:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> "type --all git"?
>> "git --exec-path"?
>> "ls $(git --exec-path)"?
>>
> 
> It all looks fairly correct to me:
Yes, but your shell seems to find git-diff somewhere, so what about:

type --all git-diff echo $PATH

In any case, Ubuntu seems to do something strange about binaries which used to be installed. How can "git-diff" trigger a message about "apt-get install git-core"?

For sure it does the same strange thing for everything else which used to be in your PATH, and this makes current stash, gc etc. fail when trying to call git-pack-objects and such. A "/usr/bin time machine"???

OTOH: The git-pack-objects usage line indicates that you clearly have
older plumbing lying around. I suspect there are at least 2 issues on
that box.
Michael
Martin Langhoff· May 28, 2009, 09:34 UTC · re: Michael J Gruber · lore

Re: Strangely hosed git install

On Thu, May 28, 2009 at 10:29 AM, Michael J Gruber <git@drmicha.warpmail.net> wrote:

> Yes, but your shell seems to find git-diff somewhere, so what about:
>
> type --all git-diff
> echo $PATH

$ type --all git-diff bash: type: git-diff: not found $ echo $PATH /home/martin/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

there is _no other_ git-diff. It's bash magic. See http://popey.com/command_not_found

Note that all the key commands work. I clone, diff, commit, push, merge daily on this machine.

> OTOH: The git-pack-objects usage line indicates that you clearly have
> older plumbing lying around. I suspect there are at least 2 issues on
> that box.

Might be. Maybe ~/bin got cleaned up but not libexec? Or the bisecting back-and-forth left stray bits in ~/bin?

cheers,
m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
Martin Langhoff· May 28, 2009, 09:39 UTC · re: Martin Langhoff · lore

Re: Strangely hosed git install

On Thu, May 28, 2009 at 11:34 AM, Martin Langhoff <martin.langhoff@gmail.com> wrote:

> Might be. Maybe ~/bin got cleaned up but not libexec? Or the bisecting
> back-and-forth left stray bits in ~/bin?

The problem was with a polluted libexec. Clearing/reinstalling git in my ~/bin didn't help, but the same procedure in libexec worked.

Minor note for people bisecting random versions of git :-)
m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
Michael J Gruber· May 28, 2009, 09:47 UTC · re: Martin Langhoff · lore

Re: Strangely hosed git install

Martin Langhoff venit, vidit, dixit 28.05.2009 11:34:
Show 14 quoted lines
> On Thu, May 28, 2009 at 10:29 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Yes, but your shell seems to find git-diff somewhere, so what about:
>>
>> type --all git-diff
>> echo $PATH
> 
> $ type --all git-diff
> bash: type: git-diff: not found
> $ echo $PATH
> /home/martin/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
> 
> there is _no other_ git-diff. It's bash magic. See
> http://popey.com/command_not_found

This is insane. Don't they even distinguish between an interactive shell and a non-interactive one?

Show 10 quoted lines
> 
> Note that all the key commands work. I clone, diff, commit, push,
> merge daily on this machine.
> 
>> OTOH: The git-pack-objects usage line indicates that you clearly have
>> older plumbing lying around. I suspect there are at least 2 issues on
>> that box.
> 
> Might be. Maybe ~/bin got cleaned up but not libexec? Or the bisecting
> back-and-forth left stray bits in ~/bin?

Well, I would say go "find / git-diff-index", or simply nuke anything git you find and do a clean install... "find"ing the left over bits would help making sure that git's own search path is OK.

Michael
Martin Langhoff· May 28, 2009, 10:11 UTC · re: Michael J Gruber · lore

Re: Strangely hosed git install

On Thu, May 28, 2009 at 11:47 AM, Michael J Gruber <git@drmicha.warpmail.net> wrote:

> This is insane. Don't they even distinguish between an interactive shell
> and a non-interactive one?

Yes they do. I mentioned it but I didn't think it was the reason behind the problem.

> Well, I would say go "find / git-diff-index", or simply nuke anything
> git you find and do a clean install... "find"ing the left over bits
> would help making sure that git's own search path is OK.

well, that's not what happens when people bisect back and forth. It used to be reasonably safe, it got unsafe when we moved lots of things to libexec (and therefore the make install target got a nice warning message about it). Now there might something acting up again.

Alas, I didn't keep a backup of my libexec :-/
m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

← back to recent threads