Git 2.44.0 released

Posted Feb 24, 2024 5:38 UTC (Sat) by intelfx (subscriber, #130118)
Parent article: Git 2.44.0 released

> including the git replay command for faster, server-side rebasing

I had to wonder for a few seconds what does "server-side" mean here, considering that in Git (which is distributed) there isn't supposed to be _a_ server-side...

Apparently this means merely that `git replay` does not require a worktree to operate, which makes it particularly suitable for rebase-like operations on bare repositories (which are typically found on dedicated Git hosts).

Git 2.44.0 released

Posted Feb 24, 2024 10:44 UTC (Sat) by grawity (subscriber, #80596) [Link] (4 responses)

> considering that in Git (which is distributed) there isn't supposed to be _a_ server-side...

I believe distributed means that it's not supposed to *require* a server, not that it's not supposed to *have* one. There's a difference.

Git 2.44.0 released

Posted Feb 24, 2024 11:55 UTC (Sat) by intelfx (subscriber, #130118) [Link] (3 responses)

Likewise, there is a difference between what I said and the statement that Git is not supposed to have a server. What I meant is that in Git, there is no "server-side" as in "the party that performs operations on behalf of clients" (and that there is little to no semantic difference between a Git server and a Git client).

Git 2.44.0 released

Posted Feb 24, 2024 17:09 UTC (Sat) by Nahor (subscriber, #51583) [Link] (2 responses)

> Git (which is distributed) there isn't supposed to be _a_ server-side

Quite the contrary, "distributed" means _all_ Git installations have a server side. "distributed" just means there isn't a _dedicated_ server application/machine and a dedicated client, like in centralized systems. Git is always both. And as such a part of its code _is_ dedicated to serving data (listening for and answering incoming requests, ...). And as you mentioned afterwards, that "server side" is highlighted by the notion of "bare repository".

Git 2.44.0 released

Posted Feb 25, 2024 5:05 UTC (Sun) by intelfx (subscriber, #130118) [Link] (1 responses)

> "distributed" just means there isn't a _dedicated_ server application/machine and a dedicated client, like in centralized systems

That's exactly the meaning I intended to convey, as explained in the message you were directly replying to.

Git 2.44.0 released

Posted Feb 25, 2024 17:55 UTC (Sun) by Nahor (subscriber, #51583) [Link]

>> "distributed" just means there isn't a _dedicated_ server application/machine and a dedicated client, like in centralized systems
>That's exactly the meaning I intended to convey, as explained in the message you were directly replying to.

That's not how I understood either of your posts (or how I understood the fact that you posted your confusion in the first place despite your eventual realization of what the changelog was talking about). Even in your last post, you still said:
> What I meant is that in Git, there is no "server-side" as in "the party that performs operations on behalf of clients"

My understanding is that you feel that the notion of server in Git is a stretch (*), an abuse of the word for working with bare repositories. And I'm arguing that it's the opposite, that Git is a true server (and a client, all combined into a single app), and the bare repository is a consequence of that.
You can even start that server with the `git-daemon` command.

(*) Although, I admit I'm not clear about what you mean by "performs operations", so maybe that's where the dichotomy is. It feels to me like you have some restrictive idea of what operations a server is supposed to do. Since Git can do the same "operations" as an FTP or HTTP server (put/store/save + get/load) and more, I personally don't see a distinction between them and Git, i.e. Git is as much a server as they are.

Git 2.44.0 released

Posted Feb 26, 2024 9:22 UTC (Mon) by farnz (subscriber, #17727) [Link] (6 responses)

In every networked git operation, there is a server side and a client side. Which repository is server-side and which is client-side is determined by which command you ran and where, but there is always a server side in git.

The thing that git doesn't have is a concept of an authority that resolves conflcits; both client and server are equally authoritative in any operation, and indeed it's possible for you to swap client and server in any interaction and come to the same result (albeit with different commands to get there). This contrasts to something like git-svn or SVK, where there is an authoritative server (the SVN server), and thus the authoritative server can be called upon to resolve conflicts between non-authoritative users of the repo.

Git 2.44.0 released

Posted Feb 26, 2024 14:19 UTC (Mon) by paulj (subscriber, #341) [Link] (5 responses)

If I run git clone of a git repo on a distributed FS, what is the server and the client? E.g., if I (cd /tmp; git clone /dist/repo/foo) on, say, one of the lock-servers or some-kind-of-masterish-members, and it has to fetch chunks from a "JBOD member of the distributed FS", which is the server and which is the client? :)

Git 2.44.0 released

Posted Feb 26, 2024 14:27 UTC (Mon) by farnz (subscriber, #17727) [Link] (4 responses)

From git's point of view, the client side is the repo you're running in, and the server side is the remote repo. So, in the case you describe, git sees /tmp/foo as the "client" side, and "/dist/repo/foo" as the "server" side. If you then do a "git push" from "/dist/repo/foo" to "/tmp/foo", the roles swap over - /tmp/foo becomes the "server" side.

And this applies no matter how convoluted you make the underlying storage system :-)

Git 2.44.0 released

Posted Feb 26, 2024 16:29 UTC (Mon) by paulj (subscriber, #341) [Link] (3 responses)

I think they're both just git repos really. It's not really client/server, it's "Git reads blobs from 2 repos. One, the 'remote' can be RO". It's the same git reading both repos.

At most, you're feeding it the blobs of the other repo using some kind of network connection and some helper to retrieve the blobs from the storage. E.g. git over SSH it's still git both sides, and both machines can generally be things you'd consider "clients". Least, I - not completely rarely - do git ops between ostensibly client machine (I.e. machines with GUIs that I log into).

But.. meh. ;)

Git 2.44.0 released

Posted Feb 26, 2024 17:34 UTC (Mon) by farnz (subscriber, #17727) [Link] (2 responses)

Internally, git treats one side as a server and the other as a client. But it's kinda malleable which one's which, because neither repo is "more authoritative" than the other, so all operations exist in symmetrical forms where the "local" repo uses "client" operations, and the "remote" repo uses "server" operations.

Git 2.44.0 released

Posted Feb 26, 2024 21:46 UTC (Mon) by Wol (subscriber, #4433) [Link] (1 responses)

I'd draw my distinction as the server is a bare repo, while the client is a working repo, but even there the distinction is iffy ...

Cheers,
Wol

Git 2.44.0 released

Posted Feb 27, 2024 14:25 UTC (Tue) by geert (subscriber, #98403) [Link]

The side that has a bare repo is typically only usable as a server.
If both sides are not bare repos, the fancy "new" term is not client-server, but peer2peer ;-)