Believe me, I understand how business is done. They get patents. We get patents. Everybody has patents. Usually, nobody sues because everybody has patents, but occasionally someone does and then all hell breaks loose. I don't need a "don't be naive, patents aren't evil, they're just the way everybody does business" speech.
The fact that that's the way business is done doesn't make it any less wrong. It's an awful world where you can't build a product because you might get sued by someone with a similar product. Sarcasm is the way I deal with the world. If you aren't a fan of it, I suggest you get off Slashdot.
Samsung are clearly infringing on Apple's right to be the only tablet device manufacturer. Just like IBM should rightly have been the only computer manufacturer.
True, I skipped that when I read your comment. But I disagree with that -- authentication isn't required at all if you don't want those features. Even SC2 went too far. If you want cloud storage, friends lists, auctions, etc, then sure you need to authenticate. But there is no reason (in the interests of the customers) to require authentication at all. You could simply disable those features until the user authenticates, and once they do, you could require them to be online to access them, but still let them play offline (there is no reason to require authentication every 30 days).
The only reason to require authentication is a) to combat piracy, b) to combat the used sales market, and c) to prevent multiple people from sharing the same copy of the game, even if they don't play at the same time. Reason a is semi-legitimate, but you're forcing legitimate customers to pay for what is really a standard cost of doing business. Reasons b and c are totally unacceptable, it's pure greed on the part of the game studio (e.g., forcing multiple family members to buy multiple copies of the game to get around the 10 character limit).
This isn't anything like the Ubisoft situation, which consists mainly of a bunch of PHBs making bad decisions about piracy.
Haha. So Blizzard makes the exact same DRM scheme as Ubisoft, but it "isn't anything like Ubisoft" because Blizzard used a different excuse to justify it.
That's better PR, not a better customer experience. Just because Ubisoft are too retarded to come up with a better excuse doesn't mean you should fall for it when somebody else does.
Honestly I think this is a good thing. It was always too tempting to load up a character editor and give myself lots of cool toys. Now, when someone sees you in D3, they know you've put effort (or money, lol) into what you've accomplished with that character.
Blizzard already solved this problem, the honest way, in Diablo II. You have "open" characters (which can be played single player, LAN or on a completely separate instance of Battle.net, but are clearly rife with cheating and there is no real economy) and you have "online" characters (which can only be played on Battle.net and require a constant Internet connection, and are protected from cheating). Diablo II already gave you, if you want it, the ability to store your characters in the cloud, to prove that you've put the effort into it, and to have an economy secured from hackers.
Now eleven years later and what progress has been made? They still have the "online" system with exactly the same benefits and drawbacks, but they have removed the "open" system. There is no legitimate reason to remove a perfectly useful, optional feature that doesn't affect anybody else's game experience.
You've made the classic mistake of assuming that the DRM is necessary for those features. That's precisely what they want you to think -- which is why they (game companies in general) always make sure to list many online-only features when they attempt to justify always-online DRM. "True, you have to be online, but look at all the good things you get while you're online!"
The fallacy is that those would be useful features with or without the DRM. You could design a game that lets you play offline without the above features, but when you come online, every single one of the features you describe becomes enabled. They are a distraction from the DRM, not benefits of the DRM. Saying "DRM is great because I can (for example) sync up my character with the cloud" is like saying "I love my new car that can't be serviced by anybody other than the original manufacturer, because it has air conditioning." It is a complete non-sequitur.
It is so easy to predict their next move, yet somehow the fanboys never look more than one step ahead.
When StarCraft II came out, and I found out about the "must authenticate with Battle.net even to play single player", I jumped on the forums and started shouting over the obtrusive DRM. Yet the Blizzard fanboys (and there were many -- they vastly outnumbered the sane people, even on non-Blizzard forums) said, "oh quit whining -- you only need to authenticate once every 30 days, and I doubt your Internet will be down for a full month at a time! This is a non-issue." (Overlooking the fact that it's not about whether my Internet has been down for 30 days, it's about whether my Internet happens to be down right now, at the time when I choose to play StarCraft after not having played in the past month, but whatever.)
Of course the next logical step is to remove the offline mode altogether. It's just moving ever closer to the time when nobody ever buys software, you just pay for the right to use somebody else's.
Granted, I do accept Pardo's argument that Diablo III is different from StarCraft, in that you can't tell if an offline character has been cheating. But so what, give me the choice of having an "offline character" (that I can play solo or online on the "open" Battle.net) or an "online" character that is always connected. Completely separate the character communities -- allow mass cheating in the "offline" mode (who cares?) and strongly protect the "online" characters, so they have a real economy. It worked just fine in Diablo II, why wouldn't it work here?
I am really not a fan of this line of reasoning. It is flawed for one reason: it assumes that democracy works.
I'm not American but let's suppose I am: who was I supposed to vote for? I vote for Obama and he sells us down the river in the interests of big business and three-letter-acronym organisations. But it's "my fault" for electing the wrong guy. Was I supposed to vote for McCain? Would he have been any better?
There is no way to kick out every last bought-and-paid-for politician when they are all bought-and-paid-for. Especially since, even the best of politicians, as soon as they take office they get a letter from the people who are really in control, "now that you're in power, here's how we run things around here." We've lost, buddy. Your vote doesn't have any power to kick these bastards out. So you can't blame "the people".
I don't know anything about your experiments, but it would be interesting to see that on real-life repositories, such as the Linux kernel or Git itself. I doubt that it will work any better than what Git does based on heuristic, but it would be interesting to see.
You doubt what will work any better than Git's heuristic? I'm talking about Git's heuristic. By definition, explicit renames will work 100% of the time (if you do it correctly, which is exceedingly easy to do). They work when you do it right, they fail when you do it wrong. Git renames work less than 100% of the time. (How much varies according to what you're trying to do, but it's provably less than 100% of the time because it's failed on me when I expected it to work.) I prefer tools that fail only when I screw up, as opposed to tools that can fail even if I do the best I can do.
As to your artificial example, it is not convincing, because it is not what you normally have during development, and the conflict is easy to resolve anyway.
My artificial example is a simplified version of something I've done all the time. Why is it not what you normally have during development. Isn't it extremely common to modify a file in both the branch and master before the merge? If so, all I have to do to trigger this is also rename the file, which can't be that rare.
Of course in my simple example the conflict is easy to resolve. But you must see that this same thing could happen on a very large file, and it would be very hard to resolve, because Git hasn't actually done a merge (it's just saying "there's a conflict between an edit and a delete, oh and by the way there is a new file as well.") That means you need to manually compare two files (the one from master, and the one from the branch) and merge them -- you may as well be using Subversion to merge branches because it will give you just as much help.
Let's suppose, I move a few functions to another file. Now how is your explicit rename/copy tracking is going to help here?
In my experience, moving code around refactoring is much more common than renaming or copying files. With Git, it is easy to find where some function came from. Somehow I have not found similar functionality in Bazaar, but maybe I did not try hard enough to find it.
I agree that moving code from one file to another is more common. Bazaar can't track that (it just shows the function deleted in one file and added in the other). But can Git actually track that? I've never seen it. I just did an experiment now -- I made a file with three reasonably-sized functions, committed it, then moved one function to another file, and committed those changes. Git didn't do anything different to Subversion or Bazaar -- it just shows many lines deleted from file A and many lines added to file B. If there is a way to get Git to properly track that function, let me know... it doesn't seem obvious.
One of key features of Git is interactive rebase.
Oh I see -- when you said Git branches are often more stable than Bazaar you mean because of this culture of editing your branches so they make sense. Fair enough -- Git does have more of a culture of that and better tools for editing history (Bazaar has "uncommit" which lets you go back as many commits as you like and redo them, but certainly not the powerful history editing capabilities of Git).
But I really don't see the point in these tools. The point of a VCS is to track the history of development. No project is going to be perfect all along. If there was a bug introduced in revision 3 and fixed in revision 6, I don't see the point of going back and editing revision 3 to pretend that bug never happened. If you're going to lie about history, you may as well not be tracking it. It's better to say "hey, we put in a bug in revision 3, I'm fixing it from here onwards."
I sort of understand the idea that if you want to submit code to a project you don't control, you would like those people you are submitting to to be able to look at your history and believe that you were perfect. But is that really helpful from a software development perspective, or just an ego thing?
When I said "I have never heard this argument before," I meant I have never heard anybody say that "explicit renames are for novices, experts prefer automatic rename detection." Believe me, I have had long, long arguments before about explicit vs automatic renames. I have argued for a long time, done experiments, collected data on both real and trivial repositories, and I have convinced hardcore Git fans that explicit is the way to go. At one point, I spent three hours converting one of my major team projects (which had carefully-annotated renames in Bazaar) to Git and then going through the entire history by hand to see which renames Git detected and which ones it didn't, and it failed a staggeringly high proportion of the time.
Maybe we weren't "doing it right" (i.e., maybe we renamed too often or we changed the files too much). But this is precisely the point: since we used Bazaar, we didn't care. We had the freedom to rename or change the files as much as we wanted, and we did so. If your argument is "you should have been using revision control more responsibly" then I would argue that the tool is controlling you and not the other way around. I don't want my tool to fail just because I am not following best practices.
So what? It seems you believe that if something merged automatically then it is good otherwise it is not.
Not at all. Merge conflicts are good. They point out the pieces of the file that need attention, so I can manually fix it up. The point of this experiment that I proposed was that if you do it in Bazaar, you get a merge conflict if necessary (that is, the pieces of the file that merge without conflict just merge, but the pieces of the file that changed in both branches get a >>>> <<<< conflict marker). Whereas in Git, you don't get any meaningful conflict -- you just end up with two completely separate files and you are on your own to a) figure out that they are in fact the same file, just with a different name, and b) do the merge yourself, including detecting and resolving any conflicts.
So, significant re-write of some file and then its rename did not happen for no reason, and in most cases, no automatic merge can handle that merge correctly.
Again, I am not saying the automatic merge should handle it. But if I did make significant changes to a file, and renamed it, who are you (or Git) to tell me that it is now a different file? Semantically, as the author of the file, I know it is still the same file, and it still makes sense to attempt to merge them (and identify any conflicts). This is what I am talking about. Say I have a file A with contents:
def foo():
xxx
print 1
yyy
def bar():
aaa
bbb
In the branch, I rename the file to B and also totally change the function bar:
def foo():
xxx
print 1
yyy
def zonk():
ppp
qqq
In the master, I make a slight change to foo:
def foo():
xxx
print 2
yyy
def bar():
aaa
bbb
Now run this experiment with Git, and you will find that Git spits out two files (when you try to merge): a file called "A" with the same contents the file had in master, and a file called "B" with the same contents the file had in the branch. Now it is up to you to realise that they are still the same file. You have to manually rename A to B, and then manually figure out that bar should have been replaced with "zonk" and foo should change its print from 1 to 2. Git does not even try to help you here, because it thinks of them as two
I see what you did there. You're just trying to not represent any positive arguments made for Git, while being free to supply whatever counterarguments you think you have in favour of Bazaar. If you're going to do that, you're just being disingenuous -- which is to say: "not constructive".
What? That's how arguments work... you accept any valid points the other guy has and move on. I wrote that paragraph so that I didn't have to waste time copy-pasting every line of your comment that I agreed with and writing "I agree" underneath it. I find it odd that you took offense to it. But if you simply require it...
"Externalized" branches are still a bad idea. I've admin'ed a Bazaar installation and the fact that every group had its own convention for laying out branches in the file system was a complete pain in ass. (Some had multiple levels of directories, others only one, etc. etc.). It's bad from a scripting perspective and from a consistency perspective.
Fair enough.
There's also the fact that disconnected development requires you to predict in advance what branches you're going to need. Having all the branches in the same repo (i.e. it costs nothing to sync all of them) is a huge advantage here.
Fair enough.
IME Bazaar is also a lot buggier than Git, presumably because of an internal model which is a lot more complicated than Git's. It's got a huge test suite, but we regularly ran it various obscure errors. It's also (still!) a lot slower than Git.
Fair enough.
There, did that satisfy your need for me to specifically address every point?
Oh, and "Linus thinks it's a good idea" is not a good argument. (Hopefully) we're arguing on technical merit.
Absolutely... if "Linus thinks it's a good idea" was a good argument, then Git would win by default. There's no sense in doing something just because Linus says so. That's why I presented my argument and said "Even Linus agrees" -- in other words, Bazaar does it this way, and Git doesn't, and I think they made a mistake (and I explained why, with a lot of detail and a lot of examples), and also, in addition, notwithstanding all of my other arguments, the creator of Git agrees with me too).
And ironically, you have accused me of not addressing your points, yet you didn't say anything about all of the other points I made in my post. Good day, sir.
As you've noted, that's because Git indexes things by their hash, not an arbitrary name. While it works in Git's favour in this case, that doesn't mean all other VCSes have to be like it. Why is it a "design flaw in bzr" that it doesn't index things by hash? The only advantage of this is that it would interoperate with Git. Now on the one hand, you're telling me "why should Git be changed to support Bazaar" (to which I said: it doesn't have to support Bazaar, it just has to support a single generic feature), and on the other hand, you're telling me "Bazaar should be changed for the sole specific purpose of supporting Git."
Also, you're wrong about git-svn (as far as I can tell). From my reading of this manpage, it does store metadata in the commit log ("git-svn-id"), which it needs in order to rebuild the Git data structure (which is richer than Subversion's, since it can have merges). There is a --no-metadata option but it "can only be used for one-shot imports as git svn will not be able to fetch again without metadata". It sounds as if Git does rely on metadata in the foreign VCS! (In this case, it is crudely shoved in the commit log, which is something that bzr-git does too.)
The fact is that all VCSes have slight (or major) differences in their data, and properly interoperating requires "polluting the dataset of the original". It's just a question of whether the original has metadata (so the additional data can be stored away where nobody has to see it unless they really want to), or if it's necessary to crudely shove that data into the commit log, like git-svn does.
Well it did totally ruin the design aesthetic. In the words of Yahtzee,
Valve should just have said: "No, you can't wear whatever hat you like. Hands up everyone in this room who hires professional character designers. Oh, just me. Right. So shut up and wear your fucking Akubra."
So... should we put the metadata in for every single external client every other random person uses?
No, of course not. I don't expect Git to support Bazaar features. By "metadata" I mean a generic key-value pair mapping per commit, which allows a client to map arbitrary strings onto arbitrary strings. That way, any third-party tool can store any data it wishes. Bazaar, for example, might create a key called "bzr_rev_id" with the value of the Bazaar revision ID for this commit, to make sure that that data is not lost when pushed up to Git.
Subversion, Bazaar, and (I think) Mercurial all allow such arbitrary key/value pairs in commit objects, making it easy to interoperate between them.
Who cares if others using bzr can't see the bzr style merge history with the svn repo at all. I for one don't.
Wow.. again my original post: "what a selfish decision." Of course you don't care about Bazaar users, because you aren't one. Bazaar users, surprisingly, do care about this sort of stuff when they have to interoperate with other systems.
Now let me explain why this is important. It isn't just because I might want to look back at the merge history one day. It breaks things if this data isn't supported. So I said above I want to be able to store Bazaar revision IDs (the immutable commit IDs equivalent to Git hashes that Bazaar uses) in Git commit objects. Here's an example of what can happen if I can't store that:
1. Create a Git repository called G1. 2. Make a Bazaar branch of G1, called B1. 3. Commit something using Bazaar to B1. Bazaar might assign it revision ID "abcd" (for example; it generates a random string). 4. Push that commit up to G1. This commit turn out to have the SHA-1 hash "1d8929a9". Note that G1 doesn't have any knowledge of the revision ID "abcd". 5. Make a Git clone of G1, called G2. 6. Make a Bazaar branch of G2, called B2. Since Bazaar doesn't have access to the metadata of B1, it looks at the commit with hash "1d8929a9" and assigns it a new revision ID "git_1d8929a9". 7. Try to pull from B1 to B2. It won't work, because the branches are diverged: they have two almost-identical commits, except in B1 the commit is called "abcd" and in B2 it is called "git_1d8929a9".
So it is impossible for Bazaar and Git to work together if any complex distributed branching is going to happen. All of this would be fixed if Git had just one simple feature: if Bazaar could store in that commit a key/value pair with the key "bzr_rev_id" and value "abcd", then in step 6, B2 could check that key and create a commit with revision ID "abcd", and thus remain in sync with B1. This is what I meant by metadata and why I think it is selfish that Git doesn't support it.
The only thing I see happening is trying to mash together some superfluous system putting data that will never be used by the majority of cases and is not necessary into the repository.
It is a simple system and a very common idea which is used all over the place for extensibility and interoperability. Look at HTTP or MIME (email), with the ability to add arbitrary headers. Look at files (xattrs) which allow metadata to be tagged on files in a file system. Bazaar, Subversion and Mercurial support it. It is a generally useful feature for a revision control system to support. It has nothing to do with incorporating metadata from other external clients; that is just a nice usage of it.
I find this interesting because I usually consider myself to be a copyright minimalist. But I feel like Lucas should have a (moral) case here, if nothing more than the branding.
I often liken it to John Williams' Star Wars score. He created it -- Lucas can't take credit for it. But he created it for Lucas, and was paid for it. Williams can't just turn around now and say "well I own the Star Wars music, so I can do what I like with it." For example, if someone paid Williams money to use the Star Wars theme for their big-budget movie, that would be wrong: Williams doesn't have the right to say "you can use my Star Wars music in your movie." If that happened, you might mistake this movie for an official Star Wars film. Isn't that essentially what this helmet guy is doing?
Then some other features like "explicit moves/renames" may sound great for novices, but it does not work well in truly distributed workflow.
Wow, I am offended that you consider me to be a "novice". I have never heard this argument before: the old mantra "explicit is better than implicit" applies here -- usually it's argued that implicit may sound great for novices, but it doesn't work well having a heuristic in the large scale, and if you have people who know what they're doing, explicit is far better.
I don't follow your argument at all. I use Bazaar's branching and merging extensively -- I have branches on branches and I merge every whichway imaginable. You're going to have to justify your statement that when "the history graph is far more complex... your explicit tracking does not work well". In Bazaar, you say "file A was renamed to file B." It doesn't matter how many branches or merges that change propagates through, or in which direction, it still remembers (because you told it) that that file was renamed. All changes made to the file in any branch, regardless of whether the changes were made to the file when it was called "A" or when it was called "B", are merged correctly. I have never encountered such a problem, nor can I imagine a situation in which a problem might arise (assuming you correctly told Bazaar that the file was renamed in the first place). With Git, on the other hand, you have to hope that the rename detection has works, and it is especially poor across merges. Even the expert cannot help in certain situations. I have encountered this problem on small trivial examples as well as on large repositories. The following is all that is required to trigger a complete merge failure on Git:
1. Create a repository with a file "A" in it, 2. Create a second branch, 3. In the branch, modify the file extensively (about 50% of the file). To make it more realistic, do it over, say, 10 commits instead of just one (this voids the argument "you shouldn't be changing so much in a single commit"), 4. In the branch still, rename the file to "B", and commit the change, 5. In the master, modify the file just a tiny bit (one byte should do it), 6. Merge from the branch to master.
You will find (if you changed the file enough in step 3) that Git hasn't detected the rename, so instead, there is a merge conflict in "A" between the change made in step 5 and the deletion of the file (Git keeps the file around and says "Deleted by them"). There is no conflict in "B"; it's just a new file. Now the user must manually merge the files "A" and "B", because Git hasn't even attempted a three-way merge. I tried this example using both Git and Bazaar. With Git it happened exactly as I described. With Bazaar, because I explicitly told it about the move, the three-way merge worked perfectly.
I would like to hear some examples of where explicitly specifying moves breaks things. I can't imagine how it could possibly be a problem, and all you've said is "it doesn't work well".
This is not true. By definition metadata is "data about data", and Git stores its own metadata in the commit object, but it does not store foreign metadata. There is two reasons for that. First, Git may not know how to deal with them during some operations (e.g. git-rebase).
Exactly -- it doesn't store foreign metadata. That's the problem: Git is hostile to foreign VCSes. Why shouldn't git know how to deal with them during some operations? Bazaar stores foreign metadata and it tracks it perfectly fine. You mention rebase: that's actually an exception. The reason a foreign VCS needs to store metadata is to make sure the same commit object contains exactly the same data. When you rebase, you're creating a commit object, so it's fine if Git were to drop the metadata at that point.
if this information does not make sense to the user and only necessary for inteeropera
Well it certainly mentions Mercurial -- it dismisses it as irrelevant at several points in the article. Fair point that it doesn't mention the other ones, but I thought Bazaar was big enough (with the full Ubuntu community behind it) to at least warrant a mention.
If I were to use a revision control system to archive my home directory, I would probably choose Git too. It is a very good versioned file system. I would prefer Bazaar over Git for an actual software project.
I'm sorry, you lost me at "Python is fine for an occasional one-off script." Do you actually think that nobody uses Python for serious applications? I still find the talk of Bazaar being slow a slightly incredulous. I think it has a reputation of being slow from five years ago when it was. I have used Bazaar for every project, small and large, for the past three years, and have never once had to wait for any noticeable period of time.
I accept that Git is faster, but when you're talking about a hundredth of a second versus a tenth of a second, you're really just arguing for the sake of it.
Perhaps it would have been better to say "I don't think git allows you to do this" rather than "git doesn't let you do this".;-)
Perhaps;) But I was replying to a comment that said that Bazaar branches "take up a linearly larger amount of space on your local storage media when checking everything out", so I afforded the same level of self-surety as the original comment.
I agree with a lot of what you said, so take my silence on any issue as agreement.
It does not add any functionality that you actually need, but it does add a lot of incidental complexity.
I understand the concern from a scripting standpoint. But I wouldn't say it does not add useful functionality. On the remote side (when a server stores branches in different directories), it gives me a unique URL handle on each branch. This is invaluable, as I can say "push from here up to lp:myproject:mybranch", for example. On the local side, it lets me have a physical directory for each branch: I often work in multiple branches simultaneously (e.g., if I am working on a feature and find a bug in trunk, I'll Alt+Tab to my already-open trunk window and fix it there and commit it -- this saves me from the temptation of fixing a bug in the feature branch, which would bloat the feature branch unnecessarily.)
Re. revision numbers: Revision numbers are a fundamentally flawed model in a distributed world. In a distributed system there can be no consistent numbering unless you can and do enforce a global total order... which neither Bazaar nor Git do... The fact that Bazaar just lies to you and pretends that there is a global total order is not a plus.
You're assuming that revision numbers need to be globally consistent in order to be useful. Once you understand how Bazaar's (admittedly complicated) revision numbering scheme works, you can find them useful even though they aren't globally consistent. Bazaar does not "lie" to you and it does not "pretend there is a global total order,"... you must have read the wrong manual. Bazaar is quite clear on the fact that revision numbers are specific to a branch. And yes, if you're communicating them, you do need to refer to the branch name and the revision number (or, if you don't, it could reasonably be assumed you are referring to the trunk). Here are some reasons why having systematically and contiguously-numbered revisions is helpful:
- Much easier to type or say than a hash (say I am communicating verbally, "hey Mike, there's a bug in trunk r135"). - Obvious order in most cases (142 clearly precedes 164; 142 clearly precedes 142.2.53). - Obvious which revisions are the "important ones" (13 and 183 are on this branch's main line -- for the trunk this means they are stable commits; 45.1.14 was clearly an unimportant commit to a branch that was merged into this one). - Most importantly, for a given merge commit, obvious which parent was the previous commit to this branch (for r14, it is r13) and which parent was from the branch that was merged in (say, r11.1.5). This is a critical advantage of Bzr over Git -- Bzr trees keep their "shape" whereas Git trees are just a pile of commits with parents. - The "distance" between two commits is clear; it is obvious that 13 and 15 are much closer together than 13 and 165. - For any two branches, all commits made before the branching point (where the two branches split) have consistent revision numbers.
All of this far outweighs the fact that you have to be educated and careful about the fact that a Bzr revision number means different things in different branches. It takes some getting used to, but so does referring to everything by a long and meaningless series of letters and numbers. Even Linus agrees: he plans to add "generation numbers" (a very weak form of Bazaar's revision numbers) and in this email, he stated that "the lack of [generation numbers] is literally the only real design mistake we have."
You strongly disagree with partial commits conceptionally
What do you mean by "partial commits"? I certainly believe you should make small logical commits and if it means you need to commit only part of your changeset, you should do that. What I said on the blog was that I prefer shelve/stash over the index/staging area, because shelve physically hides the changes so you can test that things still work, whereas the index allows you to create a commit with a file state that has never existed on disk -- that's what I disagreed with.
But anyway, I have been convinced in the past that the index is genuinely useful in certain situations (e.g., if you changed a comment, or if you changed a document that isn't code, such as HTML or text, and you know for sure that it isn't going to break anything). I would be delighted if Bazaar were to add this feature. But I disagree that it should be the default -- it is highly confusing, especially for people who have used other VCSes, that you ask it to "commit my changes" and it does not commit all of them. Git has a "commit -a" flag, which auto-stages everything. I would suggest that this should be the default, and another flag, "commit -i" or something, should commit just the index.
Slashdot Mirror
Depreciated? It's worth more now (or at least, it was last week) than ever before in its history.
Believe me, I understand how business is done. They get patents. We get patents. Everybody has patents. Usually, nobody sues because everybody has patents, but occasionally someone does and then all hell breaks loose. I don't need a "don't be naive, patents aren't evil, they're just the way everybody does business" speech.
The fact that that's the way business is done doesn't make it any less wrong. It's an awful world where you can't build a product because you might get sued by someone with a similar product. Sarcasm is the way I deal with the world. If you aren't a fan of it, I suggest you get off Slashdot.
Samsung are clearly infringing on Apple's right to be the only tablet device manufacturer. Just like IBM should rightly have been the only computer manufacturer.
What the hell? If you get sued you have to send three review units to your competitor for analysis?
Uhh... can I get three Galaxy Tabs if I sue Samsung too?
True, I skipped that when I read your comment. But I disagree with that -- authentication isn't required at all if you don't want those features. Even SC2 went too far. If you want cloud storage, friends lists, auctions, etc, then sure you need to authenticate. But there is no reason (in the interests of the customers) to require authentication at all. You could simply disable those features until the user authenticates, and once they do, you could require them to be online to access them, but still let them play offline (there is no reason to require authentication every 30 days).
The only reason to require authentication is a) to combat piracy, b) to combat the used sales market, and c) to prevent multiple people from sharing the same copy of the game, even if they don't play at the same time. Reason a is semi-legitimate, but you're forcing legitimate customers to pay for what is really a standard cost of doing business. Reasons b and c are totally unacceptable, it's pure greed on the part of the game studio (e.g., forcing multiple family members to buy multiple copies of the game to get around the 10 character limit).
Haha. So Blizzard makes the exact same DRM scheme as Ubisoft, but it "isn't anything like Ubisoft" because Blizzard used a different excuse to justify it.
That's better PR, not a better customer experience. Just because Ubisoft are too retarded to come up with a better excuse doesn't mean you should fall for it when somebody else does.
Blizzard already solved this problem, the honest way, in Diablo II. You have "open" characters (which can be played single player, LAN or on a completely separate instance of Battle.net, but are clearly rife with cheating and there is no real economy) and you have "online" characters (which can only be played on Battle.net and require a constant Internet connection, and are protected from cheating). Diablo II already gave you, if you want it, the ability to store your characters in the cloud, to prove that you've put the effort into it, and to have an economy secured from hackers.
Now eleven years later and what progress has been made? They still have the "online" system with exactly the same benefits and drawbacks, but they have removed the "open" system. There is no legitimate reason to remove a perfectly useful, optional feature that doesn't affect anybody else's game experience.
You've made the classic mistake of assuming that the DRM is necessary for those features. That's precisely what they want you to think -- which is why they (game companies in general) always make sure to list many online-only features when they attempt to justify always-online DRM. "True, you have to be online, but look at all the good things you get while you're online!"
The fallacy is that those would be useful features with or without the DRM. You could design a game that lets you play offline without the above features, but when you come online, every single one of the features you describe becomes enabled. They are a distraction from the DRM, not benefits of the DRM. Saying "DRM is great because I can (for example) sync up my character with the cloud" is like saying "I love my new car that can't be serviced by anybody other than the original manufacturer, because it has air conditioning." It is a complete non-sequitur.
It is so easy to predict their next move, yet somehow the fanboys never look more than one step ahead.
When StarCraft II came out, and I found out about the "must authenticate with Battle.net even to play single player", I jumped on the forums and started shouting over the obtrusive DRM. Yet the Blizzard fanboys (and there were many -- they vastly outnumbered the sane people, even on non-Blizzard forums) said, "oh quit whining -- you only need to authenticate once every 30 days, and I doubt your Internet will be down for a full month at a time! This is a non-issue." (Overlooking the fact that it's not about whether my Internet has been down for 30 days, it's about whether my Internet happens to be down right now, at the time when I choose to play StarCraft after not having played in the past month, but whatever.)
Of course the next logical step is to remove the offline mode altogether. It's just moving ever closer to the time when nobody ever buys software, you just pay for the right to use somebody else's.
Granted, I do accept Pardo's argument that Diablo III is different from StarCraft, in that you can't tell if an offline character has been cheating. But so what, give me the choice of having an "offline character" (that I can play solo or online on the "open" Battle.net) or an "online" character that is always connected. Completely separate the character communities -- allow mass cheating in the "offline" mode (who cares?) and strongly protect the "online" characters, so they have a real economy. It worked just fine in Diablo II, why wouldn't it work here?
I am really not a fan of this line of reasoning. It is flawed for one reason: it assumes that democracy works.
I'm not American but let's suppose I am: who was I supposed to vote for? I vote for Obama and he sells us down the river in the interests of big business and three-letter-acronym organisations. But it's "my fault" for electing the wrong guy. Was I supposed to vote for McCain? Would he have been any better?
There is no way to kick out every last bought-and-paid-for politician when they are all bought-and-paid-for. Especially since, even the best of politicians, as soon as they take office they get a letter from the people who are really in control, "now that you're in power, here's how we run things around here." We've lost, buddy. Your vote doesn't have any power to kick these bastards out. So you can't blame "the people".
You doubt what will work any better than Git's heuristic? I'm talking about Git's heuristic. By definition, explicit renames will work 100% of the time (if you do it correctly, which is exceedingly easy to do). They work when you do it right, they fail when you do it wrong. Git renames work less than 100% of the time. (How much varies according to what you're trying to do, but it's provably less than 100% of the time because it's failed on me when I expected it to work.) I prefer tools that fail only when I screw up, as opposed to tools that can fail even if I do the best I can do.
My artificial example is a simplified version of something I've done all the time. Why is it not what you normally have during development. Isn't it extremely common to modify a file in both the branch and master before the merge? If so, all I have to do to trigger this is also rename the file, which can't be that rare.
Of course in my simple example the conflict is easy to resolve. But you must see that this same thing could happen on a very large file, and it would be very hard to resolve, because Git hasn't actually done a merge (it's just saying "there's a conflict between an edit and a delete, oh and by the way there is a new file as well.") That means you need to manually compare two files (the one from master, and the one from the branch) and merge them -- you may as well be using Subversion to merge branches because it will give you just as much help.
I agree that moving code from one file to another is more common. Bazaar can't track that (it just shows the function deleted in one file and added in the other). But can Git actually track that? I've never seen it. I just did an experiment now -- I made a file with three reasonably-sized functions, committed it, then moved one function to another file, and committed those changes. Git didn't do anything different to Subversion or Bazaar -- it just shows many lines deleted from file A and many lines added to file B. If there is a way to get Git to properly track that function, let me know... it doesn't seem obvious.
Oh I see -- when you said Git branches are often more stable than Bazaar you mean because of this culture of editing your branches so they make sense. Fair enough -- Git does have more of a culture of that and better tools for editing history (Bazaar has "uncommit" which lets you go back as many commits as you like and redo them, but certainly not the powerful history editing capabilities of Git).
But I really don't see the point in these tools. The point of a VCS is to track the history of development. No project is going to be perfect all along. If there was a bug introduced in revision 3 and fixed in revision 6, I don't see the point of going back and editing revision 3 to pretend that bug never happened. If you're going to lie about history, you may as well not be tracking it. It's better to say "hey, we put in a bug in revision 3, I'm fixing it from here onwards."
I sort of understand the idea that if you want to submit code to a project you don't control, you would like those people you are submitting to to be able to look at your history and believe that you were perfect. But is that really helpful from a software development perspective, or just an ego thing?
When I said "I have never heard this argument before," I meant I have never heard anybody say that "explicit renames are for novices, experts prefer automatic rename detection." Believe me, I have had long, long arguments before about explicit vs automatic renames. I have argued for a long time, done experiments, collected data on both real and trivial repositories, and I have convinced hardcore Git fans that explicit is the way to go. At one point, I spent three hours converting one of my major team projects (which had carefully-annotated renames in Bazaar) to Git and then going through the entire history by hand to see which renames Git detected and which ones it didn't, and it failed a staggeringly high proportion of the time.
Maybe we weren't "doing it right" (i.e., maybe we renamed too often or we changed the files too much). But this is precisely the point: since we used Bazaar, we didn't care. We had the freedom to rename or change the files as much as we wanted, and we did so. If your argument is "you should have been using revision control more responsibly" then I would argue that the tool is controlling you and not the other way around. I don't want my tool to fail just because I am not following best practices.
Not at all. Merge conflicts are good. They point out the pieces of the file that need attention, so I can manually fix it up. The point of this experiment that I proposed was that if you do it in Bazaar, you get a merge conflict if necessary (that is, the pieces of the file that merge without conflict just merge, but the pieces of the file that changed in both branches get a >>>> <<<< conflict marker). Whereas in Git, you don't get any meaningful conflict -- you just end up with two completely separate files and you are on your own to a) figure out that they are in fact the same file, just with a different name, and b) do the merge yourself, including detecting and resolving any conflicts.
Again, I am not saying the automatic merge should handle it. But if I did make significant changes to a file, and renamed it, who are you (or Git) to tell me that it is now a different file? Semantically, as the author of the file, I know it is still the same file, and it still makes sense to attempt to merge them (and identify any conflicts). This is what I am talking about. Say I have a file A with contents:
def foo():
xxx
print 1
yyy
def bar():
aaa
bbb
In the branch, I rename the file to B and also totally change the function bar:
def foo():
xxx
print 1
yyy
def zonk():
ppp
qqq
In the master, I make a slight change to foo:
def foo():
xxx
print 2
yyy
def bar():
aaa
bbb
Now run this experiment with Git, and you will find that Git spits out two files (when you try to merge): a file called "A" with the same contents the file had in master, and a file called "B" with the same contents the file had in the branch. Now it is up to you to realise that they are still the same file. You have to manually rename A to B, and then manually figure out that bar should have been replaced with "zonk" and foo should change its print from 1 to 2. Git does not even try to help you here, because it thinks of them as two
What? That's how arguments work ... you accept any valid points the other guy has and move on. I wrote that paragraph so that I didn't have to waste time copy-pasting every line of your comment that I agreed with and writing "I agree" underneath it. I find it odd that you took offense to it. But if you simply require it...
Fair enough.
Fair enough.
Fair enough.
There, did that satisfy your need for me to specifically address every point?
Absolutely ... if "Linus thinks it's a good idea" was a good argument, then Git would win by default. There's no sense in doing something just because Linus says so. That's why I presented my argument and said "Even Linus agrees" -- in other words, Bazaar does it this way, and Git doesn't, and I think they made a mistake (and I explained why, with a lot of detail and a lot of examples), and also, in addition, notwithstanding all of my other arguments, the creator of Git agrees with me too).
And ironically, you have accused me of not addressing your points, yet you didn't say anything about all of the other points I made in my post. Good day, sir.
Thanks for the link. Very interesting.
As you've noted, that's because Git indexes things by their hash, not an arbitrary name. While it works in Git's favour in this case, that doesn't mean all other VCSes have to be like it. Why is it a "design flaw in bzr" that it doesn't index things by hash? The only advantage of this is that it would interoperate with Git. Now on the one hand, you're telling me "why should Git be changed to support Bazaar" (to which I said: it doesn't have to support Bazaar, it just has to support a single generic feature), and on the other hand, you're telling me "Bazaar should be changed for the sole specific purpose of supporting Git."
Also, you're wrong about git-svn (as far as I can tell). From my reading of this manpage, it does store metadata in the commit log ("git-svn-id"), which it needs in order to rebuild the Git data structure (which is richer than Subversion's, since it can have merges). There is a --no-metadata option but it "can only be used for one-shot imports as git svn will not be able to fetch again without metadata". It sounds as if Git does rely on metadata in the foreign VCS! (In this case, it is crudely shoved in the commit log, which is something that bzr-git does too.)
The fact is that all VCSes have slight (or major) differences in their data, and properly interoperating requires "polluting the dataset of the original". It's just a question of whether the original has metadata (so the additional data can be stored away where nobody has to see it unless they really want to), or if it's necessary to crudely shove that data into the commit log, like git-svn does.
Well it did totally ruin the design aesthetic. In the words of Yahtzee,
No, of course not. I don't expect Git to support Bazaar features. By "metadata" I mean a generic key-value pair mapping per commit, which allows a client to map arbitrary strings onto arbitrary strings. That way, any third-party tool can store any data it wishes. Bazaar, for example, might create a key called "bzr_rev_id" with the value of the Bazaar revision ID for this commit, to make sure that that data is not lost when pushed up to Git.
Subversion, Bazaar, and (I think) Mercurial all allow such arbitrary key/value pairs in commit objects, making it easy to interoperate between them.
Wow.. again my original post: "what a selfish decision." Of course you don't care about Bazaar users, because you aren't one. Bazaar users, surprisingly, do care about this sort of stuff when they have to interoperate with other systems.
Now let me explain why this is important. It isn't just because I might want to look back at the merge history one day. It breaks things if this data isn't supported. So I said above I want to be able to store Bazaar revision IDs (the immutable commit IDs equivalent to Git hashes that Bazaar uses) in Git commit objects. Here's an example of what can happen if I can't store that:
1. Create a Git repository called G1.
2. Make a Bazaar branch of G1, called B1.
3. Commit something using Bazaar to B1. Bazaar might assign it revision ID "abcd" (for example; it generates a random string).
4. Push that commit up to G1. This commit turn out to have the SHA-1 hash "1d8929a9". Note that G1 doesn't have any knowledge of the revision ID "abcd".
5. Make a Git clone of G1, called G2.
6. Make a Bazaar branch of G2, called B2. Since Bazaar doesn't have access to the metadata of B1, it looks at the commit with hash "1d8929a9" and assigns it a new revision ID "git_1d8929a9".
7. Try to pull from B1 to B2. It won't work, because the branches are diverged: they have two almost-identical commits, except in B1 the commit is called "abcd" and in B2 it is called "git_1d8929a9".
So it is impossible for Bazaar and Git to work together if any complex distributed branching is going to happen. All of this would be fixed if Git had just one simple feature: if Bazaar could store in that commit a key/value pair with the key "bzr_rev_id" and value "abcd", then in step 6, B2 could check that key and create a commit with revision ID "abcd", and thus remain in sync with B1. This is what I meant by metadata and why I think it is selfish that Git doesn't support it.
It is a simple system and a very common idea which is used all over the place for extensibility and interoperability. Look at HTTP or MIME (email), with the ability to add arbitrary headers. Look at files (xattrs) which allow metadata to be tagged on files in a file system. Bazaar, Subversion and Mercurial support it. It is a generally useful feature for a revision control system to support. It has nothing to do with incorporating metadata from other external clients; that is just a nice usage of it.
I find this interesting because I usually consider myself to be a copyright minimalist. But I feel like Lucas should have a (moral) case here, if nothing more than the branding.
I often liken it to John Williams' Star Wars score. He created it -- Lucas can't take credit for it. But he created it for Lucas, and was paid for it. Williams can't just turn around now and say "well I own the Star Wars music, so I can do what I like with it." For example, if someone paid Williams money to use the Star Wars theme for their big-budget movie, that would be wrong: Williams doesn't have the right to say "you can use my Star Wars music in your movie." If that happened, you might mistake this movie for an official Star Wars film. Isn't that essentially what this helmet guy is doing?
It certainly is a shade of grey here.
Wow, I am offended that you consider me to be a "novice". I have never heard this argument before: the old mantra "explicit is better than implicit" applies here -- usually it's argued that implicit may sound great for novices, but it doesn't work well having a heuristic in the large scale, and if you have people who know what they're doing, explicit is far better.
I don't follow your argument at all. I use Bazaar's branching and merging extensively -- I have branches on branches and I merge every whichway imaginable. You're going to have to justify your statement that when "the history graph is far more complex... your explicit tracking does not work well". In Bazaar, you say "file A was renamed to file B." It doesn't matter how many branches or merges that change propagates through, or in which direction, it still remembers (because you told it) that that file was renamed. All changes made to the file in any branch, regardless of whether the changes were made to the file when it was called "A" or when it was called "B", are merged correctly. I have never encountered such a problem, nor can I imagine a situation in which a problem might arise (assuming you correctly told Bazaar that the file was renamed in the first place). With Git, on the other hand, you have to hope that the rename detection has works, and it is especially poor across merges. Even the expert cannot help in certain situations. I have encountered this problem on small trivial examples as well as on large repositories. The following is all that is required to trigger a complete merge failure on Git:
1. Create a repository with a file "A" in it,
2. Create a second branch,
3. In the branch, modify the file extensively (about 50% of the file). To make it more realistic, do it over, say, 10 commits instead of just one (this voids the argument "you shouldn't be changing so much in a single commit"),
4. In the branch still, rename the file to "B", and commit the change,
5. In the master, modify the file just a tiny bit (one byte should do it),
6. Merge from the branch to master.
You will find (if you changed the file enough in step 3) that Git hasn't detected the rename, so instead, there is a merge conflict in "A" between the change made in step 5 and the deletion of the file (Git keeps the file around and says "Deleted by them"). There is no conflict in "B"; it's just a new file. Now the user must manually merge the files "A" and "B", because Git hasn't even attempted a three-way merge. I tried this example using both Git and Bazaar. With Git it happened exactly as I described. With Bazaar, because I explicitly told it about the move, the three-way merge worked perfectly.
I would like to hear some examples of where explicitly specifying moves breaks things. I can't imagine how it could possibly be a problem, and all you've said is "it doesn't work well".
Exactly -- it doesn't store foreign metadata. That's the problem: Git is hostile to foreign VCSes. Why shouldn't git know how to deal with them during some operations? Bazaar stores foreign metadata and it tracks it perfectly fine. You mention rebase: that's actually an exception. The reason a foreign VCS needs to store metadata is to make sure the same commit object contains exactly the same data. When you rebase, you're creating a commit object, so it's fine if Git were to drop the metadata at that point.
Well it certainly mentions Mercurial -- it dismisses it as irrelevant at several points in the article. Fair point that it doesn't mention the other ones, but I thought Bazaar was big enough (with the full Ubuntu community behind it) to at least warrant a mention.
If I were to use a revision control system to archive my home directory, I would probably choose Git too. It is a very good versioned file system. I would prefer Bazaar over Git for an actual software project.
I'm sorry, you lost me at "Python is fine for an occasional one-off script." Do you actually think that nobody uses Python for serious applications? I still find the talk of Bazaar being slow a slightly incredulous. I think it has a reputation of being slow from five years ago when it was. I have used Bazaar for every project, small and large, for the past three years, and have never once had to wait for any noticeable period of time.
I accept that Git is faster, but when you're talking about a hundredth of a second versus a tenth of a second, you're really just arguing for the sake of it.
Perhaps ;) But I was replying to a comment that said that Bazaar branches "take up a linearly larger amount of space on your local storage media when checking everything out", so I afforded the same level of self-surety as the original comment.
Ah OK, cool.
I agree with a lot of what you said, so take my silence on any issue as agreement.
I understand the concern from a scripting standpoint. But I wouldn't say it does not add useful functionality. On the remote side (when a server stores branches in different directories), it gives me a unique URL handle on each branch. This is invaluable, as I can say "push from here up to lp:myproject:mybranch", for example. On the local side, it lets me have a physical directory for each branch: I often work in multiple branches simultaneously (e.g., if I am working on a feature and find a bug in trunk, I'll Alt+Tab to my already-open trunk window and fix it there and commit it -- this saves me from the temptation of fixing a bug in the feature branch, which would bloat the feature branch unnecessarily.)
You're assuming that revision numbers need to be globally consistent in order to be useful. Once you understand how Bazaar's (admittedly complicated) revision numbering scheme works, you can find them useful even though they aren't globally consistent. Bazaar does not "lie" to you and it does not "pretend there is a global total order," ... you must have read the wrong manual. Bazaar is quite clear on the fact that revision numbers are specific to a branch. And yes, if you're communicating them, you do need to refer to the branch name and the revision number (or, if you don't, it could reasonably be assumed you are referring to the trunk). Here are some reasons why having systematically and contiguously-numbered revisions is helpful:
- Much easier to type or say than a hash (say I am communicating verbally, "hey Mike, there's a bug in trunk r135").
- Obvious order in most cases (142 clearly precedes 164; 142 clearly precedes 142.2.53).
- Obvious which revisions are the "important ones" (13 and 183 are on this branch's main line -- for the trunk this means they are stable commits; 45.1.14 was clearly an unimportant commit to a branch that was merged into this one).
- Most importantly, for a given merge commit, obvious which parent was the previous commit to this branch (for r14, it is r13) and which parent was from the branch that was merged in (say, r11.1.5). This is a critical advantage of Bzr over Git -- Bzr trees keep their "shape" whereas Git trees are just a pile of commits with parents.
- The "distance" between two commits is clear; it is obvious that 13 and 15 are much closer together than 13 and 165.
- For any two branches, all commits made before the branching point (where the two branches split) have consistent revision numbers.
All of this far outweighs the fact that you have to be educated and careful about the fact that a Bzr revision number means different things in different branches. It takes some getting used to, but so does referring to everything by a long and meaningless series of letters and numbers. Even Linus agrees: he plans to add "generation numbers" (a very weak form of Bazaar's revision numbers) and in this email, he stated that "the lack of [generation numbers] is literally the only real design mistake we have."
What do you mean by "partial commits"? I certainly believe you should make small logical commits and if it means you need to commit only part of your changeset, you should do that. What I said on the blog was that I prefer shelve/stash over the index/staging area, because shelve physically hides the changes so you can test that things still work, whereas the index allows you to create a commit with a file state that has never existed on disk -- that's what I disagreed with.
But anyway, I have been convinced in the past that the index is genuinely useful in certain situations (e.g., if you changed a comment, or if you changed a document that isn't code, such as HTML or text, and you know for sure that it isn't going to break anything). I would be delighted if Bazaar were to add this feature. But I disagree that it should be the default -- it is highly confusing, especially for people who have used other VCSes, that you ask it to "commit my changes" and it does not commit all of them. Git has a "commit -a" flag, which auto-stages everything. I would suggest that this should be the default, and another flag, "commit -i" or something, should commit just the index.