8 ms·
I feel like something was lost along the way. git init —-bare will give you a git repo without a working set (just the contents typically in the .git dire
by jonhohle 1y ago
I feel like something was lost along the way.
git init —-bare
will give you a git repo without a working set (just the contents typically in the .git directory). This allows you to create things like `foo.git` instead of `foo/.git`.
“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. You can even namespace where you push back to the same remotes by changing fetch and push paths. At one company it was common to push back to `$user/$feature` to avoid polluting the root namespace with personal branches. It was also common to have `backup/$user` for pushing having a backup of an entire local repo.
I often add a hostname namespace when I’m working from multiple hosts and then push between them directly to another instead of going back to a central server.
For a small static site repo that has documents and server config, I have a remote like:
[remote “my-server”]
url = ssh+git://…/deploy/path.git
fetch = +refs/heads/*:refs/remotes/my-server
push = +refs/heads/*:refs/remotes/my-laptop
So I can push from my computer directly to that server, but those branches won’t overwrite the server’s branches. It acts like a reverse `git pull`, which can be useful for firewalls and other situations where my laptop wouldn’t be routable.
- Sharlin 1y agoGit was always explicitly a decentralized, "peer to peer" version control system, as opposed to centralized ones like SVN, with nothing in the protocol itself that makes a distinction between a "server" and a "client". Using it in a centralized fashion is just a workflow that you choose to use (or, realistically, one that somebody else chose for you). Any clone of a repository can be a remote to any other clone, and you can easily have a "git server" (ie. just another directory) in your local filesystem, which is a perfectly reasonable workflow in some cases.
- webstrand 1y agoIt's a little more complex than that. Yes git can work in a peer-to-peer fashion, but the porcelain is definitely set up for a hub-and-spoke model, given how cloning a remote repo only gives you a partial copy of the remote history. There's other stuff too, like git submodules can't be configured to reference another branch on the local repository and then be cloned correctly, only another remote.
- isaacremuant 1y agoI'd say git submodules have such an awkward UX that should probably not be used except in very rare and organized cases. I've done it before but it has to be worth it. But I get your larger point.
- seba_dos1 1y agoAnd they're often (not always) used where subtrees would fit better.
- webstrand 1y agoI can't get over my fear of subtrees after accidentally nuking one of my repos by doing a rebase across the subtree commit. I've found that using worktrees, with a script in the main branch to set up the worktrees, works pretty well to split history across multiple branches, like what you might want in a monorepo. Sadly doing a monorepo this way with pnpm doesn't work, since pnpm doesn't enforce package version requirements inside of a pnpm workspace. And it doesn't record installed version information for linked packages either.
- jonhohle 1y ago> given how cloning a remote repo only gives you a partial copy of the remote history When you clone you get the full remote history and all remote branches (by default). That’s painfully true when you have a repo with large binary blobs (and the reason git-lfs and others exist).
- webstrand 1y agoYou're right, I got that part wrong, git actually fetches all of the remote commits (but not all of the refs, many things are missing, for instance notes). But a clone of your clone is not going to work the same way, since remote branches are not cloned by default, either. So it'll only have partial history. This is what I was thinking about.
- jonhohle 1y agoThis is a better summary than mine. There was a thread not to long ago where people were conflating git with GitHub. Git is an incredible tool (after coming from SVN/CVS/p4/source safe) that stands on its own apart from hosting providers.
- Sharlin 1y agoAnd GitHub naturally has done nothing to disabuse people of the interpretation that git = GitHub. Meanwhile, the actual raison d'etre for the existence of git of course doesn't use GitHub, or the "pull request" based workflow that GitHub invented and is also not anything intrinsic to git in any way.
- JamesLeonis 1y agoI have a use case just for this. Sometimes my internet goes down while I'm working on my desktop computer. I'll put my work in a branch and push it to my laptop, then go to a coffee shop to continue my work.
- kragen 1y agoWhen I do this I usually push to a bare repo on a USB pendrive.
- chipsrafferty 1y agoI just copy files on a USB drive
- webstrand 1y agogit clone --mirror <remote> is another good one to know, it also makes a bare repository that is an exact clone (including all branches, tags, notes, etc) of a remote repo. Unlike a normal clone that is set up for local tracking branches of the remote. It doesn't include pull requests, when cloning from github, though.
- Cheer2171 1y ago> It doesn't include pull requests, when cloning from github, though. Because GitHub pull requests are a proprietary, centralized, cloud-dependent reimplementation of `git request-pull`. How the "free software" world slid head first into a proprietary cloud-based "open source" world still boils my blood. Congrats, Microsoft loves and owns it all, isn't that what what we always wanted?
- seba_dos1 1y agoThey are available as refs on the remote to pull though, they just aren't listed so don't end up mirrored either.
- velcrovan 1y agoWhen this kind of “sliding” happens it’s usually because the base implementation was missing functionality. Turns out CLI interfaces by themselves are (from a usability perspective) incomplete for the kind of collaboration git was designed to facilitate.
- kawsper 1y agoI always thought it would have been better, and less confusing for newcomers, if GitHub had named the default remote “github”, instead of origin, in the examples.
- masklinn 1y agoHow is it less confusing when your fork is also on github?
- grimgrin 1y agoagreed, you'd need a second name anyway. and probably "origin" and "upstream" is nicer than "github" and "my-fork" because.. the convention seems like it should apply to all the other git hosts too: codeberg, sourcehut, tfs, etc
- matrss 1y agoRequiring a fork to open pull requests as an outsider to a project is in itself a idiosyncrasy of GitHub that could be done without. Gitea and Forgejo for example support AGit: https://forgejo.org/docs/latest/user/agit-support/ https://forgejo.org/docs/latest/user/agit-support/. Nevertheless, to avoid ambiguity I usually name my personal forks on GitHub gh-<username>.
- masklinn 1y ago> Requiring a fork to open pull requests as an outsider to a project is in itself a idiosyncrasy of GitHub that could be done without. Gitea and Forgejo for example support AGit: https://forgejo.org/docs/latest/user/agit-support/ https://forgejo.org/docs/latest/user/agit-support/. Ah yes, I'm sure the remote being called "origin" is what confuses people when they have to push to a refspec with push options. That's so much more straightforward than a button "create pull request".
- mzajc 1y ago> “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.
- mckn1ght 1y agoWhenever 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.
- deleted 1y ago[deleted]
- svieira 1y agoThis sounds like submodules, but I'm guessing it's completely orthogonal ... multiple distinct remotes for the same _repository_, all of them checked out to different sub-paths; does that result in all the remotes winding up with all the commits for all the shared repositories when you push, or can you "subset" the changes as well?
- mckn1ght 1y agoYeah, it's different, I was thinking about a time I needed to combine to separate repos into one. To do that, you clone one of them, then add a remote to the other one, fetch that, and `pull --rebase` or similar, and you'll replay all of the first's commits on top of the second's. I can't remember what I was thinking about the subdirectories, I guess they'd already have to be organized that way in the various repos to avoid conflicts or smushing separate sources together.
- ompogUe 1y agoI often init a bare repo on single-use server's I'm working on. Then, have separate prod and staging clones parallel to that. Have a post-commit hook set on the bare repo that automatically pushes updates to the staging repo for testing. When ready, then pull the updates into prod. Might sound strange, but for certain clients hosting situations, I've found it allows for faster iterations. ymmv
- eru 1y agoYes, I encourage my co-workers, when pushing to a common repo, to use `$user/$whatever` exactly to have their own namespace. The main selling point I'm making is that it makes cleanup of old branches easier, and less conflict-prone. Tangentially related: when you have multiple local checkouts, often `git worktree` is more convenient than having completely independent local repository. See https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree
- imron 1y agoGitHub is full of git anti-patterns
- lloeki 1y ago> “origin” is also just the default name for the cloned remote I don't have a central dotfiles repo anymore (that I would always to forget to push to); I have SSH access to my devices - via tailscale - anyway so I'm doing git remote add $hostname $hostname:.config and can cd ~/.config && git fetch/pull/rebase $hostname anytime from anywhere. I've been considering a bare repo + setting $GITDIR (e.g via direnv) but somehow the dead simple simplicity has trumped the lack of push ability
- xk3 1y agoWhat's the benefit of this compared to rsync or scp $hostname:.config/<TAB>? I put my whole home folder in git and that has its benefits (being able to see changes to files as they happen) but if I'm just copying a file or two of config I'll just cat or scp it--introducing git seems needlessly complex if the branches are divergent
- lloeki 1y ago> just a file or two I don't have to remember which to copy > rsync or scp I don't have to remember which is most recent, nir even assume that "most recent" is a thing (i.e nonlinear) It's all just: - a git fetch --all away to get - a git log --oneline --decorate --graph --all to find out who's where and when - diff and whatchanged for contents if needed - a cherry-pick / rebase away to get what I want, complete with automatic conflict resolution I can also have local experiments in local topic branches, things I want to try out but not necessarily commit to across all of my machines yet.