CooSoft Support <[email protected]> writes: > I loved using Monotone and agree that the merging in mtn is far superior > to the run of the mill merging you get with git (after all it's site did > refer to it as a stupid/dumb content tracker). In fact mtn's merging is > the best I've ever used. I liked the fact that changesets were stored > efficiently as compressed deltas in mtn as well. However the world has > moved on and the projects that I work on have had to switch to git. > Younger developers coming into the organisation know git but have > invariably never heard of mtn. Also git does allow for history > rewriting, which I know is a thorny issue to some, but the reality is > that it is needed and very useful (e.g. someone accidentally checks in > some creds etc). Whilst you could do this in mtn it was much more > painful. History is littered with examples of better technology losing > out over more inferior (remember the video-2000/betamx/vhs debate?).
monotone also keeps tracks of moves, renames, etc, and merges on the appropriate file. Where as git guesses. But perhaps the biggest differences aren't technical but cultural. Somebody previously mentioned git requires rebase. I think some projects really overuse git rebase which can give it a really bad name - e.g. a previous project of mine required rebasing a chosen set of patches for every test deploy. Urgghh. Git doesn't actually require rebase anymore then monotone requires it. But nobody has written an automated "rebase" tool for monotone. It has to be done manually. Plus I suspect you may not be able to reuse the same branch name except maybe in strict set of circumstances (e.g. never pushed to a remote repo, on local repo only, etc). With monotone the culture is to save/preserve everything. Just spent the last several weeks doing a rewrite only to find it was completely flawed and unusable? Keep it. Spent several weeks writing a change and your branch got merged? Keep it. Made an experimental change, rewrote parts of it numerous times before it was mergable? Keep it. etc. Where as the culture in git is to delete everything that is not important to the project anymore. That dead end branch no longer is important anymore. Delete it. You might be able to save it somewhere else but not the official repo. That merged branch isn't important anymore. Delete it. Those experimental bits?? Nobody cares about them anymore, create a new branch (or rebase) with just the important changes that are required for the project. Another words: delete it. Is use to belong in the first camp. but more and more been moving to the later camp. Sure that dead end branch could be resurrected. But chances are by that stage I probably would rewrite it anyway. And nobody wants to see 20+ commits in the commit history of me trying to update a comment on a single line to meet the overly strict standards of code review at that organisation (e.g. all comments must start with a capital letter and end in a full stop). This is just noise and adds 0 value to the project. Nor does it really matter that commit XYZ was part of branch "fix_bokren_ZZZ" or that the branch name had a spelling mistake. Or didn't meet naming conventions for the project. But I understand that some people really like being able to go back in history and understand which branch is which. Or be able to review dead ends, stuff that often gets deleted under git. I guess this is where the monotone approach really is better. As much as I like git, I am a bit disappointed that git has become the standard that everyone uses. Because git has been some arbitrary decisions and trade offs that make sense if you understand its origins in Linux kernel development space, but these may not necessarily be the best decisions for all projects. Nor is git really friendly for new developers, and this adds an extra unwanted barrier to project participation. But not using git could also be considered a barrier to project participation also, particularly with experienced developers. It would be interesting to know what monotone would look like today if it was as popular as git is today. For one thing I imagine it would have more commands developed - like it or not - to meet the requirements of the "delete it" culture. Such as rebase or something like rebase, for example. On another note, git is known to perform badly when you have a repo with a single file that is slowly and constantly growing and has a huge history. e.g. https://lwn.net/Articles/774635/ - just wondering can monotone handle this extreme case any better? -- Brian May <[email protected]>
