261–270 of 454 posts
Earlier quoted context omitted.
The Pro Git book is available online for free https://git-scm.com/book/en/v2
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.
Earlier quoted context omitted.
Depends, what's the reasoning? Because technically anyone can start a project even without Git. Or even without a computer. Someone can use a pen to write code on a paper. Depends on what you mean by "a project". If it's policy related, maybe it's company's policy that all code that is written must be stored in a certain way for multitude of reasons.
You are missing the whole point. The OP is mentioning how people are so used to using github, that they are so oblivion on using git offline
Earlier quoted context omitted.
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
Huh. Everyone seems to use "origin" and "upstream". I've been using "origin" and "fork" the whole time.
Back when I started at my current job... 15 years ago... We had no central git server. No PR workflow. We just git pull-ed from each others machines. It worked better than you would expect. We then went to using a central bare repo on a shared server, to hosted gitlab(? I think - it was Ruby and broke constantly) eventually landing on GitHub
The thing that people really don't seem to get these days is how your master branch is a different branch from someone else's master branch. So pulling from one master to another was a normal thing. When you clone you get a copy of all the branches. You can commit to your master branch all you want, it's yours to use however you want to.
My git "server" is a folder of bare git repositories in home directory which I share with Syncthing. It'd be great if there was more specific support. But in practice? No problems so far.
Perhaps the only issue with this setup is that you lose some of the robustness of git: mess up one repo beoynd repair, and you've just messed up all the checkouts everywhere. I sync my repos manually (using GitHub as the always-on remote, but I'm not particularly attached to it). This gives me more resilience should I blow up the repo completely (hard to do, I know).
The benefit is that git repos are essentially append only in this mode.
The folder itself is scheduled into an encrypted backblaze backup too.
Earlier quoted context omitted.
Filesystems and folders are foreign and elusive concepts to gen Z. https://www.theverge.com/22684730/students-file-folder-direc...
It gets better than that... https://www.youtube.com/shorts/D1dv39-ekBM
Earlier quoted context omitted.
> 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?
When 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.
git was designed to facilitate the collaboration scheme of the Linux Kernel Mailing List, which is, as you might guess... a mailing list.
Rather than a pull-request (which tries to repurpose git's branching infrastructure to support collaboration), the intended unit of in-the-large contribution / collaboration in git is supposed to be the patch.
The patch contribution workflow is entirely CLI-based... if you use a CLI mail client (like Linus Torvalds did at the time git was designed.)
The core "technology" of this is, on the contributor side:
1. "trailer" fields on commits (for things like `Fixes`, `Link`, `Reported-By`, etc)
2. `git format-patch`, with flags like `--cover-letter` (this is where the thing you'd think of as the "PR description" goes), `--reroll-count`, etc.
3. a codebase-specific script like Linux's `./scripts/get_maintainer.pl`, to parse out (from source-file-embedded headers) the set of people to notify explicitly about the patch — this is analogous to a PR's concept of "Assignees" + "Reviewers"
4. `git send-email`, feeding in the patch-series generated in step 2, and targeting the recipients list from step 3. (This sends out a separate email for each patch in the series, but in such a way that the messages get threaded to appear as a single conversation thread in modern email clients.)
And on the maintainer side:
5. `s ~/patches/patch-foo.mbox` (i.e. a command in a CLI email client like mutt(1), in the context of the patch-series thread, to save the thread to an .mbox file)
6. `git am -3 --scissors ~/patches/patch-foo.mbox` to split the patch-series mbox file back into individual patches, convert them back into an annotated commit-series, and build that into a topic branch for testing and merging.
Subsystem maintainers, meanwhile, didn't use patches to get topic branches "upstream" [= in Linus's git repo]. Linus just had the subsystem maintainers as git-remotes, and then, when nudged, fetched their integration branches, reviewed them, and merged them, with any communication about this occurring informally out-of-band. In other words, the patch flow was for low-trust collaboration, while direct fetch was for high-trust collaboration.
Interestingly, in the LKML context, `git request-pull` is simply a formalization of the high-trust collaboration workflow (specifically, the out-of-band "hey, fetch my branches and review them" nudge email). It's not used for contribution, only integration; and it doesn't really do anything you can't do with an email — its only real advantages are in keeping the history of those requests within the repo itself, and for forcing requests to be specified in terms of exact git refs to prevent any confusion.
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…
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
Earlier quoted context omitted.
Depends, what's the reasoning? Because technically anyone can start a project even without Git. Or even without a computer. Someone can use a pen to write code on a paper. Depends on what you mean by "a project". If it's policy related, maybe it's company's policy that all code that is written must be stored in a certain way for multitude of reasons.
They don't have a reason. There's no policy that keeps them from doing this. Sure, the whole point is to ultimately have the code in a common place where backups and code review can happen, but if it's a matter of starting something sooner because it takes a few days for the request to flow through to get things set up, they are not constrained by that AT ALL. They can create a git repo with git init immediately, sta…
Earlier quoted context omitted.
Depends, what's the reasoning? Because technically anyone can start a project even without Git. Or even without a computer. Someone can use a pen to write code on a paper. Depends on what you mean by "a project". If it's policy related, maybe it's company's policy that all code that is written must be stored in a certain way for multitude of reasons.
You are missing the whole point. The OP is mentioning how people are so used to using github, that they are so oblivion on using git offline