Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You already have a Git server

maurycyz.com

Post reply on HN
Print view View original

171–180 of 454 posts

Re: You already have a Git server

#171

Post by matrss »

masklinn wrote: post #150
kawsper wrote: post #146

Earlier quoted context omitted.

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?

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-.

Re: You already have a Git server

#172

Post by seba_dos1 »

Sophira wrote: post #148
webstrand wrote: post #131

Earlier quoted context omitted.

It'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.

> given how cloning a remote repo only gives you a partial copy of the remote history You may be thinking of the optional -depth switch, which allows you to create shallow clones that don't have the full history. If you don't include that, you'll get the full history when cloning.

You only get it actually full with "--mirror" switch, but for most use-cases what you get without it is already "full enough".

Re: You already have a Git server

#173

Post by ezst »

mbork_pl wrote: post #141
rester324 wrote: post #64

Earlier quoted context omitted.

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

Staging is immensely useful in more than one case. Case one: WiP on a branch, code is pretty stable, but I want to do some experiments which will likely be deleted. I stage everything and then make (unstaged) changes which I can then undo with two keystrokes. Case two: I'm reviewing a complex PR, so I first merge it with --no-commit, then unstage everything and then stage chunks (or even individual lines) I have alre…

Case one: you don't need staging. You can stash, or just commit and checkout HEAD^

Case two: you don't need staging. You can stash, and then unstash incrementally (I would be shocked if git doesn't have the equivalent of `hg unshelve --interactive` and its keyboard friendly TUI)

Case three: you don't need staging. You can just edit/amend the series (rebase --interactive I believe you guys call that).

That is to say, all that you want to put in your stash, you could commit directly to the DAG, and edit to your convenience, with the regular history-rewriting tools already at your disposal. And the off-DAG stuff can be handled by stash (and even there, a normal commit that you would rebase to its destination would perfectly do).

And what I described is incidentally what https://github.com/jj-vcs/jj does, which can be pretty-well described as "taking the best of all major VCSes"

Re: You already have a Git server

#175

Post by seba_dos1 »

isaacremuant wrote: post #135
webstrand wrote: post #131

Earlier quoted context omitted.

It'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.

I'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.

And they're often (not always) used where subtrees would fit better.

Re: You already have a Git server

#176

Post by matrss »

amelius wrote: post #151
imiric wrote: post #9

I've used Git over SSH for several years for personal projects. It just works with no additional overhead or maintenance. Tip: create a `git` user on the server and set its shell to `git-shell`. E.g.: sudo useradd -m -g git -d /home/git -s /usr/bin/git-shell git You might also want to restrict its directory and command access in the sshd config for extra security. Then, when you need to create a new repository you ru…

Yes, that's how I use it too. However, this setup doesn't work with git-lfs (large file support). Or, at least I haven't been able to get it working. PS: Even though git-shell is very restricted you can still put shell commands in ~/git-shell-commands

To my knowledge git-lfs is only really designed to store your large files on a central server. I think it also uses its own out-of-band (from the perspective of git) protocol and connection to talk to that server. So it doesn't work with a standard ssh remote, and breaks git's distributed nature.

For an actually distributed large file tracking system on top of git you could take a look at git-annex. It works with standard ssh remotes as long as git-annex is installed on the remote too (it provides its own git-annex-shell instead of git-shell), and has a bunch of additional awesome features.

Re: You already have a Git server

#177

Post by Dylan16807 »

seba_dos1 wrote: post #164
Dylan16807 wrote: post #129

Earlier quoted context omitted.

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 al…

If someone pushes to a repo you should expect the refs to change. In some sense doing nothing avoids surprise but it's a bad way to avoid surprise.

But my real point is that refusing to act is not "the only sane [default] option" here. Mild ergonomic issues aren't a disqualifier.

Re: You already have a Git server

#179

Post by seba_dos1 »

Dylan16807 wrote: post #177
seba_dos1 wrote: post #164

Earlier quoted context omitted.

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 al…

If someone pushes to a repo you should expect the refs to change. In some sense doing nothing avoids surprise but it's a bad way to avoid surprise. But my real point is that refusing to act is not "the only sane [default] option" here. Mild ergonomic issues aren't a disqualifier.

If you use "git branch -d" you should expect the ref to be deleted, and yet:

> error: cannot delete branch 'main' used by worktree at '/tmp/git'

You could build the system differently and what seems like a sane default would be different there, but it would be a different system. In this system, HEAD isn't being manipulated by things not meant to manipulate it.

Re: You already have a Git server

#180

Post by velcrovan »

Cheer2171 wrote: post #140
webstrand wrote: post #128

Earlier quoted context omitted.

git clone --mirror 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.

> 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.
Post reply on HN