Maybe I'm too old, but are there people that really didn't know that any ssh access is sufficient for using git?
Yes. I've been subject to claims that a single person can't start a project unless and until an official, centralized repo is setup for them. I've responded with "git init is all that is necessary to get started", but they wouldn't hear it.
You must work at Microsoft? A pound of paperwork for every new repo really shuts down experimental side projects. I showed my colleagues that we can share code via ssh or (painfully) one-drive anytime instead. They reacted like I was asking them to smoke crack behind the dumpsters. “That’s dangerous, gonna get in trouble, no way bro”
Did you know that you can use git locally? It works just like that because ssh is a remote shell. Read https://git-scm.com/docs/git-init#Documentation/git-init.txt... Anyway it sounds like you have a lot of holes in your git-knowledge and should read some man pages
No, you're wrong. These are holes in my ssh knowledge, and your comment makes me think you have the same holes.
I've been using git since 2007, this only dawned on me last year. Git is especially prone to the sort of confusion where all the experts you know use it in slightly different ways so the culture is to just wing it until you're your own unique kind of wizard who can't tie his shoes because he favors sandals anyhow.
> all the experts you know use it in slightly different ways What? Knowing that a git repo is just a folder is nowhere near "expert" level. That's basic knowledge, just like knowing that the commits are nodes of a DAG. Sadly, most git users have no idea how the tool works. It's a strange situation, it'd be like if a majority of drivers didn't know how to change gears.
My point is only that the understanding is uneven. I'm ready to debate the merits of subtrees vs submodules but I didn't know the folder thing. Am I weird? Yes, but here is a place where weird is commonplace.
> Yes the commit won't be on the branch you want, but you'd get about the same issue if the two repos had a bare upstream. Not at all. The commit would have "landed" on the exact branch you thought it will. How it will be reconciled with a diverged remote branch is completely orthogonal and may not even be of concern in some use cases at all.
The situation is almost identical except you don't have a cute name for your new commit. Let's say you add a ref to your detached commit, perhaps local/foo. Then you're looking at a divergence between foo and local/foo. If you had a bare upstream it would be a divergence between origin/foo and foo. No real difference. And if you don't want to reconcile then you don't have to. If git was a tiny bit smarter it could re…
Of course it could, but that doesn't yet mean it should. A checked-out ref is considered to be in-use and not to be manipulated (unless done in tandem with HEAD), not just by "git push" but also other tools like "git branch". It's consistent and, IMO, less surprising than what you propose. It could be an optional behavior configured by receive.denyCurrentBranch, though I don't see a good use-case for it that isn't already handled by updateInstead.
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 th…
Git 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…
I 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.
As a git user "not by choice" (my preference going for mercurial every single day), I never understood why git needs this distinction between bare/non-bare (or commit vs staging for that matter). Seems like yet another leaky abstraction/bad design choice.
A repo is as database containing a tree of commits. Then you got the concept of branch, which points to a specific commit. Then there's the special pointer HEAD which is the latest commit for the current worktree. When you checkout (now switch) a branch, HEAD is now the same as the branch (they point to the same commit). When you do operation like commit, reset, reset,... both the head and the branch are updated. So…
So, exactly as DrinkyBird said: I still don't see a good reason for this distinction to exist, what's in the repo's history and in its working directory are orthogonal concepts that are tied together by a bad UX for no apparent gain.
As a git user "not by choice" (my preference going for mercurial every single day), I never understood why git needs this distinction between bare/non-bare (or commit vs staging for that matter). Seems like yet another leaky abstraction/bad design choice.
Yeah, I am in the same boat. My files are either non-staged or committed about 99.99% of the time. For me the concept of staging is completely useless
Though I wasn't trying to say that there is no need for staging-based workflows,
I was just saying that there is nothing in terms of convenience or capabilities that the staging area does that can't be achieved with just regular commits and amending/rewriting.
The immediate response from many git users when confronted to alternative VCSes is "well, it doesn't have a staging area, so it's obviously inferior" instead of going with "let's see how differently they approach this problem, and perhaps I will like it/git isn't all perfect after all".
I 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.
How is it less confusing when your fork is also on github?
agreed, 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
What is it with code on blog posts where fonts have uneven size and/or font types (e.g. italics mixed in with regular)? I see this from time to time and I wonder if it’s intentional.
This is definitely nice but it doesn’t really support the full range of features of Git, because for example submodules cannot be local references. It’s really just easier to set up gitolite and use that in almost the same exact way but it’s much better.