I do this for blog posts, but for server side work I just rsync my dir, much easier
You already have a Git server
381–390 of 454 posts
Re: You already have a Git server
#382Earlier quoted context omitted.
> 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 i…
I'm assuming a "patch" is a group of commits. So would a "patch series" be similar to GitLabs notion of dependent MRs?
There's basically 2 major schools of thought for submitting patches under git:
* Pile of commits - each individual commit doesn't matter as much as they all work combined. As a general rule, the only requirement for a valid patch is that the final version does what you say it does. Either the final result is squashed together entirely and then merged onto "master" (or whatever branch you've set up to be the "stable" one) or it's all piled together. Keeping the commit history one linear sequence of events is the single most important element here - if you submit a patch, you will not be updating the git hashes because it could force people to reclone your version of the code and that makes it complicated. This is pretty easy to mentally wrap your head around for a small project, but for larger projects quickly makes a lot of the organizatory tools git gives you filled with junk commits that you have to filter through. Most git forges encourage this PR system because it's again, newbie friendly.
* Patch series. Here, a patch isn't so much a series of commits you keep adding onto, but is instead a much smaller set of commits that you curate into its "most perfect form" - each individual commit has its own purpose and they don't/shouldn't bleed into each other. It's totally okay to change the contents of a patch series, because until it's merged, the history of the patch series is irrelevant as far as git is concerned. This is basically how the LKML (and other mailing list based) software development works, but it can be difficult to wrap your head around (+years of advice that "changing history" is the biggest sin you can do with git, so don't you dare!). It tends to work the best with larger projects, while being completely overkill for a smaller tool. Most forges usually offer poor support for patch series based development, unless the forge is completely aimed at doing it that way.
Re: You already have a Git server
#383I 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…
> “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
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
Re: You already have a Git server
#384Earlier quoted context omitted.
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…
Agreed. I'd read the manual if there was something I needed from it, but everything is working fine. Yeah I might've rsynced between some local folders once or twice when I could've used git, maybe that was an inelegant approach, but the marginal cost of that blunder was... about as much time I've spent in this thread so whatever.
The nice thing about knowing more about git is that it unlocks another dimension in editing code. It’s a very powerful version of undo-redo, aka time travelling. Then you start to think in term of changes and patches.
Ane example of that is the suckless philosophy where extra features comes as patches and diff.
Re: You already have a Git server
#385I remember the first time I tried git, circa 2006, and the first 3 commands I tried were: git init git commit -am Initial\ commit git clone . ssh://server/path/to/repo And it didn’t work. You have to ssh to the remote server and “git init” on a path first. How uncivilized. Bitkeeper and a few other contemporaries would let you just push to a remote path that doesn’t exist yet and it’d create it. Maybe git added this…
[flagged]
Lol I have no idea why you came away with “… and I never used git again!” from all that.
I love git. It’s unironically one of my favorite pieces of software in the world. I’ve used it nearly every day for almost 20 years.
Maybe take a break from HN for a bit, I mean that sincerely.
Re: You already have a Git server
#386Earlier quoted context omitted.
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/ . Nevertheless, to avoid ambiguity I usually name my personal forks on GitHub gh- .
No, it's a normal feature of Git. If I want you to pull my changes, I need to host those changes somewhere that you can access. If you and I are both just using ssh access to our separate Apache servers, for example, I am going to have to push my changes to a fork on my server before you can pull them. And of course in Git every clone is a fork. AGit seems to be a new alternative where apparently you can push a new b…
> in Git every clone is a fork
That's backwards. In Github every fork is just a git clone. Before GitHub commandeered the term "fork' was already in common use and it had a completely different meaning.
Re: You already have a Git server
#387Earlier quoted context omitted.
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).
They're not checked out repos. They're bare repos, which I then checkout from. The benefit is that git repos are essentially append only in this mode. The folder itself is scheduled into an encrypted backblaze backup too.
Ok, fair!
Re: You already have a Git server
#388Earlier quoted context omitted.
You normally have one patch per commit. The patch is the diff between that commit and its parent. (I forget how git format-patch handles the case where there are two parents.)
> (I forget how git format-patch handles the case where there are two parents.) As per [0] merge commits are dropped: Note that format-patch will omit merge commits from the output, even if they are part of the requested range. A simple "patch" does not include enough information for the receiving end to reproduce the same merge commit. I originally thought it would use --first-parent (so just diff vs the first paren…
Thanks! I had no idea.
Re: You already have a Git server
#389Re: You already have a Git server
#390Earlier quoted context omitted.
No, it's a normal feature of Git. If I want you to pull my changes, I need to host those changes somewhere that you can access. If you and I are both just using ssh access to our separate Apache servers, for example, I am going to have to push my changes to a fork on my server before you can pull them. And of course in Git every clone is a fork. AGit seems to be a new alternative where apparently you can push a new b…
> in Git every clone is a fork That's backwards. In Github every fork is just a git clone. Before GitHub commandeered the term "fork' was already in common use and it had a completely different meaning.
As I remember it, it was already in common use with exactly the same denotation; they just removed the derogatory connotation.