101–110 of 124 posts
Git is a distributed version control system. Every repo can be the master repo. 'Master' is purely a function of convention. It is worth stressing that you need no software to 'host' git. Every git repository is 'self hosting', by design. Tools like this primarily provide a web client to a repository not intended as a working copy, with some optional non-git code collaboration tools, such as issues, and an inbox of p…
Git is a distributed version control system. Every repo can be the master repo. 'Master' is purely a function of convention. It is worth stressing that you need no software to 'host' git. Every git repository is 'self hosting', by design. Tools like this primarily provide a web client to a repository not intended as a working copy, with some optional non-git code collaboration tools, such as issues, and an inbox of p…
As opposed to the traditional version control model where, e.g. every commit effectively requires a rebase against the remote and the history cannot be retrieved without a connection to the remote.
The "D" in "DVCS" is about having many copies of the repository, not about having _no_ central repository, which is still a core part of having an effective delivery workflow and very much encouraged by the baked-in concept of a default remote repository.
It's a distinction of technology, not of workflow.
This is really a common misunderstanding about what makes DVCS an effective concept.
Earlier quoted context omitted.
> well-worded issue Your example is not well-worded; it's a demand. I'd expect a well-worded issue to share some story about how you were working to achieve some goal, so you tried setting up gitea to self-host the gitea repo, and were surprised that it didn't work (and share the errors etc. that you saw). Then the devss can prioritise your issue by understanding how blocked you are by the missing behaviour, and even…
The phrase between parentheses was meant as an example of the succinct title of such an issue, not the hopefully polite and well-worded body explaining why.
'Title: do this thing' is not polite or well-worded.
"Let's self-host gitea so potential users can easily see how awesome it is" is more polite, far easier to see the benefit of, and a trash-fire of proper composition.
Earlier quoted context omitted.
I think replying to "it doesn't have a single source of truth" with "actually there are multiple single sources of truth" kind of makes the OP's case for them.
What are you saying?? There is a single source of truth for a particular version of Linux.
Earlier quoted context omitted.
The index is just a cache of the metadata of files in the working directory; changing how the objects in the repo are stored won't speed up a 'git status'. When you say 'read the repo', it makes me think you're more interested in the behaviour of cloning from a remote. Loose objects would avoid the need to inspect packfiles, but… that code's all written in C and mmaps the contents & does fast seeks. Most likely the s…
I was thinking about this from the perspective of a server like Gitea. What I meant by 'read the repo' is retrieve objects like commits to display them to the user. So on the server you should only ever have packfiles, and in order to efficiently read packfiles you read the index (idx) file. I'm not positive, but I think that this file needs to be read in its entirety in order to access an object. Even if you don't h…
Parsing the packfile indexes is ridiculously fast; even in a memory-constrained environment the OS will manage loading data from disk so you only use a few pages. Inflating objects from packs is slower & will trash your memory; rendering to HTML will be even worse.
Perhaps 1GB is not enough RAM to host a webviewer of the firefox repo? Maybe if you generate a static site version of it…
Earlier quoted context omitted.
AFAIK the Linux Kernel doesn't have a single source of truth.
Before I read the other responses, I assumed it was just Linus’ personal repo
A few days ago I read about the multiple Linux distributions that all have their fork with special patches etc. pp.
Why it's considered to be an alternative? Github is all about social networking for developers, not code hosting, or am I wrong?
You are wrong. GitHub is a hosting platform for git repositories, which has collaboration tools (such as issue tracking and code review) built into it.
Why it's considered to be an alternative? Github is all about social networking for developers, not code hosting, or am I wrong?
I'd be interested to see some numbers about projects that actually leave Github. Other than FUD about the Microsoft acquisition, has something changed on Github that is making people talk about leaving? Why run away before there's a concrete reason?
Earlier quoted context omitted.
I was thinking about this from the perspective of a server like Gitea. What I meant by 'read the repo' is retrieve objects like commits to display them to the user. So on the server you should only ever have packfiles, and in order to efficiently read packfiles you read the index (idx) file. I'm not positive, but I think that this file needs to be read in its entirety in order to access an object. Even if you don't h…
GitHUb use DGit to (effectively) get loose objects on demand and cache them locally. Parsing the packfile indexes is ridiculously fast; even in a memory-constrained environment the OS will manage loading data from disk so you only use a few pages. Inflating objects from packs is slower & will trash your memory; rendering to HTML will be even worse. Perhaps 1GB is not enough RAM to host a webviewer of the firefox repo…
You're right, 1GB is not enough but it's all that I have so I have to make do.
Earlier quoted context omitted.
Independent of Gitea (which I have nothing to do with nor have any relationship with anyone involved). Your comment "It is worth stressing that you need no software to 'host' git. Every git repository is 'self hosting', by design." worries me. Yes, technically accurate, just as notepad, webstorm, atom, vi, emacs, etc. also don't need any 'host'. If you aren't working with multiple authors, a local laptop with git plu…
I took the comment as referring to hosting just a git repo on a public server. If you are working on a private project a simple option is to get a cheap VPS, give all your developers user accounts, and clone the repo into a shared folder. Everyone can pull and push with ssh and you can use Trello or whatever for issue tracking. Certainly that doesn't cover every use case, but it's worth being aware of the option and…
Sure you CAN use git without a web UI, We had that at work for a while and it was not a good experience at all compared to using gitlab which we have now and we now have so many features that let us get things done faster.