401–410 of 454 posts
Earlier quoted context omitted.
It gets better than that... https://www.youtube.com/shorts/D1dv39-ekBM
A tip, you can put the hash in a regular youtube URL to get the full interface instead of the limited shorts one: https://www.youtube.com/watch?v=D1dv39-ekBM
Earlier quoted context omitted.
This sort of thing is part of the problem. If it takes reading such a long manual to understand how to properly use Git, it's no wonder everyone's workflow is different.
I don't see it as a problem that everyone's workflow is different, and, separately, I don't see it as a problem that it takes reading such a long manual to understand all the possibilities of Git. There is no royal road to geometry. Pro Git is a lot shorter than the textbook I learned calculus from. Unlike calculus, though, you can learn enough about Git to use it usefully in ten minutes. Maybe this sets people up fo…
Earlier quoted context omitted.
> “origin” is also just the default name for the cloned remote. It could be called anything, and you can have as many remotes as you’d like. One remote can also hold more URLs! This is arguably more obscure (Eclipse's EGit doesn't even support it), but works wonders for my workflow, since I want to push to multiple mirrors at the same time.
Whenever I fork a repo I rename origin to “fork” and then add the parent repo as a remote named “upstream” so i can pull from that, rebase any of my own changes in to, and push to fork as needed. Multiple remotes is also how you can combine multiple repos into one monorepo by just fetching and pulling from each one, maybe into different subdirectories to avoid path collisions.
I wrote a HOWTO a few weeks ago: http://mikhailian.mova.org/node/305
Earlier quoted context omitted.
Instead of excluding non-public directories, I like to make an explicit `public` directory (or `doc`, `doc-root`, whatever you want to call it). Then configure your server to point to that subdirectory and don’t worry about the repo. I usually throw `etc` and `log` directories at the top level as well and out my server config in etc, and have a gitignite rule to ignore everything in logs, but it’s there and ready for…
You can still get hit by a path traversal exploit. The safest option is to only have the public files on the server.
git clone ssh://username@hostname/path/to/repo this is equivalent to: git clone username@hostname:path/to/repo and if your usernames match between local and remote: git clone hostname:path/to/repo (if the path has no leading /, it is relative to your home directory on the remote)
I never thought about this.. I've had the following problem in the past. Host A, cannot reach official github.com. But Host B can and has a local copy of a repo cloned. So Host B can 'git clone ssh://' from Host A which is essentially equivalent, but just setting origin to Host B instead of github.com, sort of acting as a manual proxy? What if Host A is natted, so Host B can ssh to Host A but not the reverse, can Hos…
I have been doing this for many years. If you want a public facing "read only" ui to public repositories you can use cgit ( https://git.zx2c4.com/cgit/about/ ) to expose them. That will enable others to git clone without using ssh. I keep my private repositories private and expose a few public ones using cgit.
I sent over a cgit web page for a take home assessment and the interviewer was horribly confused. I assume they have never seen anything apart from github before...
Until you have more users than dollars that's all you need.
My favorite git trick is using etckeeper & git subtree to manage multiple machines from a single repo . A single git repo can “fan out” to dozens of instances . It’s useful even for “managed” hosts with terraform because etckeeper snapshots config with every change, catching bugs in the terraform config. During the dev / compile / test flow, git makes a lightweight CI that reduces the exposure to your primary repo .…