71–80 of 82 posts
You may want to review https://www.git-scm.com/about/trademark They have been stingy about projects with git in the name.
Earlier quoted context omitted.
The git log is a block chain.
Nope the git log is a merkle tree. The blockchain is a merkle tree plus all the layers of overengineering you need to have a consensus algorithm. And usually you "need" a consensus algorithm mostly for ideological reasons. My view is that building trust is better than assuiming it can't or shouldn't exist.
Earlier quoted context omitted.
The git log is a block chain.
Nope the git log is a merkle tree. The blockchain is a merkle tree plus all the layers of overengineering you need to have a consensus algorithm. And usually you "need" a consensus algorithm mostly for ideological reasons. My view is that building trust is better than assuiming it can't or shouldn't exist.
Block chain is a fairly generic, badly misused term that I assert also covers the git log, which is actually a chain of cryptographic blocks where each block includes the hash of the previous. It even has a consensus algorithm. You can disagree, but your assertion is just an opinion in constrast to a misuse of the term Merkle tree.
Earlier quoted context omitted.
"Keep reading and writing bugs " sounds a little off. Maybe change that to "writing bug reports"?
Strong disagree. "Keep writing bugs" makes OP sound experienced, self-deprecating, and not self-serious. These are good things.
* fix old bugs * write new bugs * ship bugs to customers
(mid 90s, "dash process" I think? it actually reflected good understanding of the methodology and helped kill it off :-)
It says it does not add files. Where does it store all the info? I see there are bridges, but I got the impression i do not need one.
The tool creates `Blob`s that are committed to a `Tree` same as git does for files.
These `Blob`s represent git_bug `Operation`s though, stored as JSON. Those operations combined make up a `Bug`. You could technically create a directory of files from what git_bug stores, as git does for regular repos, but each "file" is more like a row in a database than a file.
- https://github.com/MichaelMure/git-bug/blob/master/doc/model...
- https://www.git-scm.com/book/en/v2/Git-Internals-Git-Objects
Hi, author here. Happy to answer questions. Version 0.8 just got out[1]. For the next one, I'll try to focus on making the codebase fully ready for multi-entities and introduce a Project Board. Later we can add support for code review! If you are looking for how it works, you can have a look at the data model introduction[2]. git-bug is only pushed forward by volunteers so it's taking its time to fully grow, so I'll…
Around 2010-2015 there were a whole bunch of these distributed git bugtrackers and none of them took off. Most are completely dead. IIRC one of the biggest problems was its feature: issue state being distributed as it is, it was very easy for developers to end up with issues having different states/comments, and depending on the implementation even differed across local branches. But also in a work environment there…
Around 2010-2015 there were a whole bunch of these distributed git bugtrackers and none of them took off. Most are completely dead. IIRC one of the biggest problems was its feature: issue state being distributed as it is, it was very easy for developers to end up with issues having different states/comments, and depending on the implementation even differed across local branches. But also in a work environment there…
Yeah, I agree. I'm not against making it a built-in, but it seems to cater to a tiny usecase that I don't have. Maybe it's more people than I know, though.
Hi, author here. Happy to answer questions. Version 0.8 just got out[1]. For the next one, I'll try to focus on making the codebase fully ready for multi-entities and introduce a Project Board. Later we can add support for code review! If you are looking for how it works, you can have a look at the data model introduction[2]. git-bug is only pushed forward by volunteers so it's taking its time to fully grow, so I'll…
Quick question: is it known what Linus thinks of the idea of having bug tracker in git? Saying that Linus has a track record of making his design decisions would be an understatement, so I would like to know what he thinks.
For applications where there may be many arbitrary "bridges" (aka integrations, plugins) to integrate with external software, a great way to scale support for bridges is to make them completely separate projects in external repositories. Each bridge can be an arbitrary external executable that "speaks" a very simple protocol and schema (implemented in, say, JSON or YAML), communicating through environment variables,…