I like that this doesn't assume what editor and git remote someone uses unlike github1s which is further pushing the development community toward centralizing on Github+VScode. Diversity is good.
It doesn't do any fancy tarball magic for Github links, but the shallow clone works fast enough for me - sub 3s on modestly sized repos (especially on non-github repos since github is fairly slow to clone/push/pull).
I think it’s a big stretch to say that providing tools which interoperate with product A and not product B is pushing anyone toward anything. By that logic everything is coercive. This is like when I was informed that I was ruining free computing by personally preferring a less free desktop OS for my own usage and encouraging others to choose what they prefer.
I’m glad you made something that works for more environments. But be careful, you may be accused of pushing more people to use git over mercurial.
Good points. For the record I wasn't trying to say that github1s is "ruining free computing", I was trying to convey the opposite. More diversity is good.
If this had been published first, and github1s came along afterward to make it easier for users who don't set $EDITOR I'd be just as happy that it makes development more inclusive for all, not matter what the tools one prefers.
Good points as well and I’m sorry if I was overly defensive. I agree totally that diversity is a good thing. I mistook some of your wording. But it’s clear you’re sincere about inclusion and I’m glad we had the opportunity to expand the conversation a bit! Thank you.
it is a defensible position though, with countless examples. In the real world, mind share determines the fate of technology.
As the simplest example, take the monopoly of IE6 which was reinforced by web site makers who did not interoperate with other browsers because they expected the majority to use IE.
I was one of those website makers and while I took great pains to support Netscape, I regret to inform you that Netscape was bad and the people who didn’t want to support it were right.
Edit: lest I forget, I also took great pains to support IE, which also was bad, and the people who didn’t want to support it were also right.
I don't think it will work "as is" because github does not expose the directory structure in a way that httpfs understands out of the box. But some hacker around here could probably make an httpfs-github that does the job.
I read lots of code on GitHub, so I got really excited when I saw github1s (https://news.ycombinator.com/item?id=26083919), but was disappointed when I saw that search doesn’t work (https://news.ycombinator.com/item?id=26085540). So I hacked together `git peek` on Tuesday night. It works with any git repository, but uses GitHub’s API to be faster when it can.
Now it does. If you have the `GITHUB_TOKEN` environment variable set to a personal access token or if you happen to use the hubs github cli it will work
I also count myself between those who implemented such a script when reading about github1s on HN :)
My latest iteration involves not using the terminal at all - I open the project from emacs instead. So I `M-x peek-repo`, paste the url, and the project will be cloned and open right in my emacs (I use a GUI variant).
Also, personally I don't find the need to use a tmpdir - my tradition is cloning to ~ and just let it remain there indefinitely. I always end up with a mere 100 repos before next time I wipe my computer for whatever reason.
Author here — this is actually not a bug, but a deliberate design decision (so long as you meant, when the editor closes). I’m sorry for the confusion.
git peek is not a faster alternative to git clone. It’s for quickly reading other people’s code without needing to keep it around for writing or updating.
That being said, I could make it not delete the code after the editor closes and keep it somewhere. It just won’t have access to the git tree and other things you’d expect.
I could add a flag like —keep that doesn’t delete it and let’s you pass a place to put it.
Very good work and a excellent use a git sub-command. Although, I appreciate github1s and perhaps future is there. I am currently more likely to use git peek (with it's search feature).
I ask because I've been looking to improve my Shopify workflow. Buddy.works does the deploy to Shopify. But I'm trying to cut out the push. More or less changes + saves become commits, and then instantly deploy.
If not, perhaps someone can recommend something else?
It works with non GitHub repos, but it’s not as fast. When it detects a GitHub link, it downloads the tarball from GitHub & and separately downloads the specific file linked (or the readme) using JSDelivr as a CDN. This is much faster than a normal clone
When it’s a regular git link, it does a partial clone and opens in your editor.
You inspired me to write my own. Here is a 9-line shell script version of git-peak: https://git.sr.ht/~alexdavid/dotfiles/tree/master/bin/git-pe...
It doesn't do any fancy tarball magic for Github links, but the shallow clone works fast enough for me - sub 3s on modestly sized repos (especially on non-github repos since github is fairly slow to clone/push/pull).