3 ms·

Local commits do not require the full history, only a known base. So you could in essence store the commits relative To the last pull from the server and push t

Local commits do not require the full history, only a known base. So you could in essence store the commits relative To the last pull from the server and push those later. No need for full history.

erikb 12y ago
I have to agree here. You only need a startpoint. In essence a commit is a diff on that startpoint. So "cloning" a single commit should be enough to create a new one and push it.
- falsedan 12y ago
  git has 'shallow' clones, where it checks out the tree as it was at a particular commit, and has a dummy commit which replaces the history of the repo up until that particular commit.
lmm 12y ago
You could indeed do that. But now you have two different kinds of commit that can conflict in surprising ways. I very much doubt you could manage this in a way that's simpler than what git does (remote branches and local branches are branches, you can merge one into the other using the normal tooling you use for merging branches).
- Xylakant 12y ago
  I'm fairly sure that at least on the ui-side you could improve over git, but the goal is not necessarily lower complexity. A semi-distributed system could have other advantages, for example fine-grained access control (read permissions on folder or file-level), support for partial checkouts, better support for large binaries (only the last revision on the local repo, older revisions on the server) etc. git currently can't do that because of the way it's designed and built.
marcosdumay 12y ago
A DVCS without complete history is still a DVCS. In fact, what makes a VCS distributed is much more local commits than local history. At least on my opinion. But well, anyway we decide to call that beast, a VCS with distributed commits and centrilized (fetchable) history, with a simplified evolution graph (created by the point of view of a central server) would bring 99.99% of the benefit of a centralized VCS, 99.99% of the benefit of a DVCS, and almost no problems from any of them.
- pyre 12y ago
  git practically already has this with the --depth option to git-clone. The only thing that it's missing is the ability to enforce storing the last single commit. I'm sure that you could probably build the system that you are describing on top of git, but you would still run into problems with large files and local commits, even if it was just "commits since last pull/push."
  - marcosdumay 12y ago
    Yes, git almost has the shallow repository done. It's even in the article, and that "almost" means it's almost trouble free, but will catch everybody off-guard once in a while. The other part about the simplified evolution graph is completely missing. I don't think one can solve that without completely rewriting the protocol.

Local commits do not require the full history, only a known base. So you could in essence store the commits relative To the last pull from the server and push those later. No need for full history.

erikb 12y ago

I have to agree here. You only need a startpoint. In essence a commit is a diff on that startpoint. So "cloning" a single commit should be enough to create a new one and push it.

falsedan 12y ago
git has 'shallow' clones, where it checks out the tree as it was at a particular commit, and has a dummy commit which replaces the history of the repo up until that particular commit.

lmm 12y ago

You could indeed do that. But now you have two different kinds of commit that can conflict in surprising ways. I very much doubt you could manage this in a way that's simpler than what git does (remote branches and local branches are branches, you can merge one into the other using the normal tooling you use for merging branches).

Xylakant 12y ago
I'm fairly sure that at least on the ui-side you could improve over git, but the goal is not necessarily lower complexity. A semi-distributed system could have other advantages, for example fine-grained access control (read permissions on folder or file-level), support for partial checkouts, better support for large binaries (only the last revision on the local repo, older revisions on the server) etc. git currently can't do that because of the way it's designed and built.

marcosdumay 12y ago

A DVCS without complete history is still a DVCS. In fact, what makes a VCS distributed is much more local commits than local history. At least on my opinion. But well, anyway we decide to call that beast, a VCS with distributed commits and centrilized (fetchable) history, with a simplified evolution graph (created by the point of view of a central server) would bring 99.99% of the benefit of a centralized VCS, 99.99% of the benefit of a DVCS, and almost no problems from any of them.

pyre 12y ago
git practically already has this with the --depth option to git-clone. The only thing that it's missing is the ability to enforce storing the last single commit. I'm sure that you could probably build the system that you are describing on top of git, but you would still run into problems with large files and local commits, even if it was just "commits since last pull/push."
- marcosdumay 12y ago
  Yes, git almost has the shallow repository done. It's even in the article, and that "almost" means it's almost trouble free, but will catch everybody off-guard once in a while. The other part about the simplified evolution graph is completely missing. I don't think one can solve that without completely rewriting the protocol.