The fourth paragraph in section 6.2 refers to "BitMover" with no previous context. Copy-paste error?
there is context in the intro (see bitkeeper)
I found nothing about BitMover here:
The Architecture of Git (2012)
71–80 of 85 posts
Re: The Architecture of Git (2012)
#72Earlier quoted context omitted.
It's a merkle tree, not every hash tree or chain is a blockchain thing. IMO blockchain describes the combination of a hash chain and the no-trust agreement protocol on top.
I don't agree with that. The oldest blockchain known has its hash codes published each week in the New York Times. I would agree that having the ability to prove the history hasn't been modified by externally retaining the hashes could be a component, but git qualifies for that as well.
Have a look at https://en.wikipedia.org/wiki/Linked_timestamping
This is technology from the 90s. The innovation of blockchain is the no-trust agreement protocol.
Re: The Architecture of Git (2012)
#73Earlier quoted context omitted.
Nothing. If you're lucky they'll have their own obtuse naming structure of "carrot_model_FINAL_FINAL_12.psd" With something like Unreal Engine, Maya, Photoshop, etc. you can get a few knowledgable artists and build a game with minimal technical skill. If it's not as turnkey as using Dropbox or Windows Backup, they probably won't use it. I started at a place in 2011 that had been open since 1993 and had spun off some…
I don't understand how it is possible to work like this. As soon as I started learning programming I immediately wished for and imagined some kind of version control. I didn't have to imagine much, as I very quickly learned about cvs (the standard back then). My partner, a scientist, that deals with all kind of data and code and latex has expressed the need for version control too (sadly I have not been able to expla…
I've gone back and forth (and I probably spend more time thinking about tools at the expense of solving problems). I have a lot of git repos with either 1 commit or where I never even bothered committing. If you're programming you can just tar up the source folder and call it a day. 95% of the use case for VCS is committing to a single tree. Depending on what you're doing, it's rare you'll even look backward. If so, timestamps and usernames are often good enough (you wont even look at the code). It takes a lot of upfront work to be able to write a new unit test then run it on the source history to see when the regression was introduced (even though I think that's really cool).
The huge benefit of VCS is project management, which most people brush off as much as possible. Git and SVN provide models where responsibility is clear. For one person, it's a bit ridiculous to stage, commit, push, merge, build, test, release, but necessary when you get a few people involved or what to share the source code.
Artists are a different beast. First off, artists are often delivering art and never have to open the project again. It's like if programmers were hired for a couple hours to a couple weeks and only ever handed over binaries with no expectation to ever support or revisit it. For programming, a directory along with a series of files make up a project. For a lot of artist tools there's a monolithic binary project file. Generating "deliverables" are often done manually or configured inside the monolithic project file, where programmers would write a separate build script. Both with programmings and artists they mix project files, intermediate data, and deliverables all together. Programmers and scientists are the only ones with the motivation and technical skill to tease that apart and push for changes.
Re: The Architecture of Git (2012)
#74Earlier quoted context omitted.
I don't agree with that. The oldest blockchain known has its hash codes published each week in the New York Times. I would agree that having the ability to prove the history hasn't been modified by externally retaining the hashes could be a component, but git qualifies for that as well.
I would recommend reading the Wikipedia article for a blockchain [0]. It's agreed that a blockchain is decentralized and resistant to change from bad actors. If a system doesn't meet those requirements, it's just a fancy database. I don't see how Git or the New York Times example you mentioned are inherently decentralized. [0] https://en.wikipedia.org/wiki/Blockchain
The New York Times example is by the inventors of blockchain.
Re: The Architecture of Git (2012)
#75Earlier quoted context omitted.
there is context in the intro (see bitkeeper)
I found nothing about BitMover here: http://aosabook.org/en/intro2.html
sorry, I meant in the git background section 6.2, it briefly mentions BitMover as the developer of BitKeeper, but that's all needed to know about it
Re: The Architecture of Git (2012)
#76Earlier quoted context omitted.
As a flippant replier, it's partly motivated by not really thinking other VCSes have a chance. As confusing to use as Git's UI may be, I think the only way we're getting away from it is if someone massive pushes an alternative. Alexa.com has Github trending down six places to the 66th most visited page on the internet. Worldwide. That's not just programmers that's everyone.
> not really thinking other VCSes have a chance There's no reason the world has to universally adopt one true VCS.
I can observe that other VCSes today are unlikely to thrive without making the proclamation that there can be only one. The two ideas are not mutually exclusive.
Re: The Architecture of Git (2012)
#77I loved the AOSA books, but there's been sometime that they don't publish a new one. Do anybody know if there is something new in the works? And of any other similar books?
Have you already read all of them? I was calculating how long it would take me to read and understand every chapter of every book. I usually like to write small snippets of code or look for references and stuff for books like these.
Anyway, if I read, say, one chapter every Monday, it would take me about two years to complete the books!
Probably not a problem that there's "nothing new" since the books seem to be more about timeless design principles and less about novelty.
Re: The Architecture of Git (2012)
#78Earlier quoted context omitted.
People once said that about Subversion. I believe Mercurial has a chance if they get support for large binary files right before git does.
Subversion wasn't a distributed VCS. Anything looking to displace git would have to make that kind of generational leap for the existing userbase to be remotely interested.
Most git user do not use the distributedness. So maybe Subversion will make a comeback similar to how people now realize that monoliths (instead of Microservices) are often better.
Distributed has disadvantages. For example, Subversion has nicely incrementing revisions like r42, where git has 8ab52fd9ee.
Mercurial is distributed as well.
Re: The Architecture of Git (2012)
#79Git is the VCS most suitable for bottom-up learners. Which is the VCS most suitable for top-down learners?
I'm a bit disappointed by the flippant replies. Mercurial is a very solid alternative VCS (Facebook uses it internally) and is friendlier (or at least has less gotchas) than git.
Mercurial is the obvious first alternative. It supports many of the same concepts as git but with a lower barrier to entry. A lot of this has probably been said many times before but I feel it's worth reiterating.
1. No staging area. This makes commit+push a 2 phase operation rather than 3 phase and removes a lot of confusing concepts, state and commands. Selectively commiting files and chunks of files is still possible but it is all done in the commit operation. (It doesn't track the history of an edit as git does where you can skip the last edit in one file but who really uses this feature? If you are such advanced user you might as well use stash or amend your last commit)
2. Branches are not just pointers to the tip of a graph. This makes it easier to understand what was master and what was dev after a merge and master can't suddenly point elsewhere.
3. All command line commands are sane by default as opposed to git where you almost always need at least one flag to get correct behaviour. And there is usually only one way to do things right.
4. Incremental version numbers (locally only) makes it look more friendly than commit hashes.
5. Much better GUI tools available. Dont know why since the market is smaller but probably because of a less complicated internal model it's easier to make a GUI representing it.
Even with all those i still don't know if it is easy enough for non developers, or if any scm with a commit/push/pull model ever can be. The whole concept of merge conflicts is very complicated and even seasoned developers need to go get an extra cup of coffee when a conflict pops up in the middle of what you expected to be a trivial rebase.
The only way to avoid merge conflicts fully would be instant edits such as Google docs but I don't think that would work very good for code where different people would break the build constantly.
Re: The Architecture of Git (2012)
#80Earlier quoted context omitted.
No, the author is right. Git us in its core a database for managing patches. Understanding the needs of Linus Torvalds as his role of Kernel maintainer is about the only good way to understand why git is so strangely designed.
Darcs is a database for managing patches. Nothing in Git inherently cares about patches. To a first approximation it's a database for managing full snapshots of trees of files.
Git only needs lists of files because it needs entry points into its lists of patch fragments that make up the file and to assign file names to them. Other than that, a changeset is just another name for a patch that can be added, altered, rewritten or removed. That makes git a patch database in my book.
Darcs feels more like a research project to me. The developers try to find a theoretical foundation in which they can base a VCS, but they have not managed to make their theory work with the level of perfection that they want. But if they eventually get it right, it will probably have the provably best text-based merge tool possible.