Code Repository Atlassian Buys Competitor BitBucket

Roblimo writes "Wow. Atlassian sent press releases out about this, and we're happy for them. But isn't Git easy to install and use — for free, even if your project is proprietary and secret, not open source and public? Whatever. Some people seem to feel better about proprietary software than about FOSS, and the majority of Atlassian's business comes from meeting the needs of behind-the-firewall, proprietary code repositories. At least Atlassian has free versions of its repository for FOSS and small-scale proprietary developers. Which is sort of nice."

Comments

Code Repository?

[nacturation]

Atlassian is a corporation, not a code repository.

Oh yeah, I had to google them

[MichaelSmith]

I have seen their name inside a huge mess of java COTS which I was shovelling around as a part of a my day job. I doubt their main business is going to be operating bitbucket, more likely charging ten thousand bucks a seat for use of a copy of bitbucket inside corporate intranets, probably with some useless eclipse integration thrown in.

Re:Oh yeah, I had to google them

[nacturation]

Goes to show you that kdawson + roblimo make an awesome combo.

Re:Oh yeah, I had to google them

[nOw2]

This may have modded down to Troll but it is true. Any developer that's tried doing things well should have at least heard of Atlassian, who now provide the definitive implementations of a great many essential tools.

Re:Oh yeah, I had to google them

[eennaarbrak]

...I doubt their main business is going to be operating bitbucket

Probably true

, more likely charging ten thousand bucks a seat for use of a copy of bitbucket inside corporate intranets

I can't speak of bitbucket, but we bought one of their flagship products (JIRA) at something like $100 per seat. Most of their products are very competitively priced, and usually free for open source projects.

, probably with some useless eclipse integration thrown in.

I find their Eclipse plugins to be of excellent quality and a massive productivity booster in our environment. All the devs in my team are using it.

Re:Oh yeah, I had to google them

[Anonymous Coward]

Nah, he's just been in industry for decades. Companies like this rise and fall every few years. Once you've been developing software for decades, you lose track of how many different source control systems, bug trackers, planning tools and "collaboration suites" you've had to use.

It has only gotten worse with so many of these apps becoming web-based. They're ALL shittier than real applications, and they all look like the same pile of shit, too.

Re:Oh yeah, I had to google them

[Courageous]

Their wiki is pleasant to use and a snap to manage. All of their products are quite affordable to any corporation. Typically something like $8K will get you an unlimited user edition. Sometimes less, depends on which product.

C//

Re:Oh yeah, I had to google them

[JonySuede]

I cannot talk about there other products but JIRA is really nice, the web interface does not suck and the eclipse plug-in work quite well

Your point?

[Anonymous Coward]

Yes, git is free/open/... So is mercurial. And Git Hub, the service, is not free for private reps.

Then what's your point?

Git

[spec8472]

"But isn't Git easy to install and use"
Yes, for certain users and environments.
In my experience, The folks who use Mercurial are more likely to be on Windows.

Mercurial tooling isn't as polished as the Subversion equivalents, but it's lightyears ahead of the Git tooling.

I'd be happy enough to pay for good Git tooling on Windows, but there doesn't appear to be a way to do so. Please correct me if I'm wrong.

Re:Git

[Anonymous Coward]

By tooling you mean GUI's?

http://code.google.com/p/tortoisegit/

Re:Git

[fusiongyro]

I am a Mercurial user from way back, and my platforms of choice are OS X, BSD and Linux. Don't use Windows at all. But I would admit that it is somewhat easier for Windows users to get rolling with it than Git, or at least, it has been in the past.

Re:Git

[omni123]

The folks who use Mercurial are more likely to be on Windows.

Yep that's my experience as well--most likely cause being that Windows is a second class citizen when it comes to Git. Mercurial is Python based and less platform dependant.

Re:Git

[WWWWolf]

I'd be happy enough to pay for good Git tooling on Windows, but there doesn't appear to be a way to do so.

What are you talking about? msysgit is dead simple to install, and provides you with a perfectly functional Bash shell.

Yeah, I've been wondering how to increase the usability further, by using zsh instead of Bash, but this is not really a pressing issue since Bash is pretty awesome too.

Re:Git

[Anonymous Coward]

Unfortunately, Mercurial gets one of the most important features of a DVCS horribly wrong. Not having cheap, fast, in-place branching is a deal breaker, and a mishmash of bookmarks, mq and other extensions isn't going to fix it.

Re:Git

[BasilBrush]

You're right.

But isn't Git easy to install and use -- for free, even if your project is proprietary and secret, not open source and public? Whatever. Some people seem to feel better about proprietary software than about FOSS

Git does the job. But no, it isn't easy to use. It has an unintuitive set of commands, and various rudimentary, half-assed, poorly designed visual apps.

e.g.
git reset --soft HEAD^
WTF?

The proprietary Perforce dates from an earlier generation of SCM, and has a single code repository, rather than a distributed scheme. But it's commands and it's visual tool feel like they were actually designed. They are easy to learn, and need far less referring back to the manual. That's one of the reasons why people "feel better about proprietary software than FOSS".

Re:Git

[Anonymous Coward]

git needs a new name. I suggest "fuck" or perhaps "gay".

Re:Git

[Anonymous Coward]

You should really take a look at SmartGit for Windows.

http://www.syntevo.com/smartgit/index.html

Aside from git on cygwin, it's a nice alternative.

Re:Git

[Anonymous Coward]

git needs a new name. I suggest "fuck" or perhaps "gay".

With the command "gay pull" and being able to announce that you're switching to gay, it's clearly a winner.

Re:Git

[gbjbaanb]

tell me more. My company is thinking of moving to Mercurial, and whilst I think its a fine tool, I'm a little concerned it wouldn't quite suitable for us (we have large repositories).

Re:Git

[yuriks]

It has perfectly fine branching, see http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

On another note, what kind of retarded wrote the summary? It makes no mention of who Atlassian or what Bitbucket are and instead spends time being an inflammatory git apology that doesn't even make any sense given that Mercurial is also opensource and free.

- a git/github and hg/bitbucket user

Re:Git

[Anonymous Coward]

git is a command-line tool. The "visual apps" are add-ons that aren't even part of git proper. Basically, the GUI stuff for git sucks because no one with any expertise in git thinks they are necessary. As for the commands being unintuitive, they seem no more or less intuitive than those of svn or hg. I can't comment on perforce. That's not to say that one can use git very well if you don't know what you are doing, just "figuring it out as you go" as one might try out a different web browser. But I didn't find git to be very hard to learn.

Re:Git

[asdf7890]

provides you with a perfectly functional Bash shell

There-in lies a problem. While I'd be perfectly happy to consider using Git there is no way I could recommend it in my workplace until such time as there are good "tools from noddies" like TortoiseSVN and VisualSVN. We don't really need a full DVCS, so we are not really Git's target audience, I'd guess there are many companies out there that could take advantage of a DVCS that won't consider Git for similar reasons.

Re:Git

[JerkBoB]

Crackmonkey.

Re:Git

[FictionPimp]

Here http://code.google.com/p/tortoisegit/

Now shut up and happily consider git.

Re:Git

[Anonymous Coward]

git reset --soft HEAD^
WTF?

That means "Undo the last commit, but don't change my working copy or my staging area."

I've never used perforce, so I'll tell you what the subversion equivalent command is: There isn't one. You can't do that in svn[1].

Git is strictly more powerful than svn (and I presume p4), so of course you're going to be able to find examples of git commands that don't make any sense to someone who has only ever used cvs/svn/p4, in the same way as you can find svn commands that don't make any sense to someone who has only ever used rcs.

[1] Unless you're the admin, in which case the equivalent is going to be something something like "ssh host; kill apache and svnserve; svnadmin dump | head | svnadmin load; restart apache and svnserve; logout; ", and even then it's still not quite the same. The git user is probably trying to undo a local commit, not a remote one.

Re:Git

[Anonymous Coward]

Nice to know that exists (and is presumably stable+reliable). What about tools that offer VS integration?

Re:Git

[FictionPimp]

Want want want....

Re:Git

[whoop]

You must be new 'round here. It's Roblimo (is he still a Slashdot editor?). Nothing new.

Re:Git

[Anonymous Coward]

Take a look at the OpenOffice.org, OpenSolaris or Netbeans repositories -- hg can handle huge repos quite well. And yes, hg has cheap, fast in-place branching -- dont believe the FUD by git zealots.

Re:Git

[Anonymous Coward]

I have used git for approximately 3 weeks on 2 projects, and even I know what that command does. If you've never used git, of course it would be confusing. Just like I'm sure someone who has never used an Office product would wonder what the hell

File -> Save As ...

did.

Re:Git

[Omnifarious]

You should give Mercurial a try. The thing that got me to use it in 2005, when it was pre-1.0, was how clean and obvious the command line interface was. I don't generally use graphical tools for development work, so I can't gauge the various GUIs available for it, but I do know that a lot of people like TortoiseHG.

I've used Perforce as well, and it has its strange quirks and complexities too, though I agree that git's command line interface leaves a great deal to be desired in comparison. I think Mercurial's command line interface is more intuitive and clearer than Perforce's.

Re:Git

[Anonymous Coward]

> git reset --soft HEAD^

Yet another priceless git command for when you really need just this type of rollback. Git makes perfect sense. If you really think git was not properly designed, then you don't understand it. It *is* hard to change how you think about working with your repo, but in git's case, you will come out at the other end way, way more productive.

Re:Git

[Anonymous Coward]

Once you go git you don't go back.

Re:Git

[Anonymous Coward]

You're right.

It has an unintuitive set of commands, and various rudimentary, half-assed, poorly designed visual apps.

e.g.
git reset --soft HEAD^
WTF?

My guess is that you are not happy because you are using this command described to undo and correct a commit, instead of simply using "git commit --amend"?

Really, the command line is quite good. The command you listed is not some magical incantation for some common thing to do, but obviously it does a very specific thing for each of the flags given. Here, namely "reset/move the HEAD pointer but not the index or working tree (reset --soft) to the parent(^) of HEAD.

You could -in another situation- just as well decide to do "git reset HEAD^" or "git reset --hard HEAD~2" or "git reset --hard " or a large variety of other things.

Re:Git

[Lysol]

Your company should have a real need for a DSCM, otherwise, Mercurial or Git have little value.

Merging/branching can be a little easier in Git vs. Svn. I've used it before on a team and have seen some things become easier; we had a dev working offsite with no access to our repo and we would just email back and forth the code dir every week and at the end of each week, merge in all his changes. However, this was more of a policy 'issue' on our end as I would have preferred not to merge his stuff in in the first place. Git does have some quirky things where it sometimes seems real easy to get your tree out of sync with the master. Then it becomes real fun to try to figure out what is wrong. Plus, hosting a Git server is not trivial. I hated dealing with Gitosis. An Svn server was much easier to setup in my opinion.

I liked Mercurial better than Git. For a Svn user, the commands are more in line on Mercurial. But again, you can get weird sync issues - I think that's just a side effect of a DSCM.

All this being said, I don't care much for DSCM's. If you have a small or medium team, then I honestly see no reason. The whole point of a SCM is a centralized repository. Checking into your local machine, imo, doesn't matter - there's no point. Your drive dies, so does your code. Plus, I want to do less and always having to push/pull to/from the master is an extra step - yah, lazy. Now, if you have a very distributed organization, then maybe a DSCM is valuable. But honestly, it's still hard to argue that it's more useful/valuable than Svn+ssh.

If you look at a lot of public Github projects, there's a lot of small OSS stuff that just needs a home. Github is a great service that found a good niche. But to host private repos, you gotta pay and there are no businesses out there that are gonna host their proprietary code out in the open with Github. No way.

Now, to have the best of all worlds I suggest a great service called SourceRepo. They have good pricing, like $7/mo for 1GB storage and unlimited users. You can create as many repos as you want in the big 3 - Svn, Git, and Mercurial. It's not meant to be social like Github is and I think fits businesses more. I've used their service for a few years now in multiple companies (as well as all my personal projects) and I've never had any problems. They also include (for free) each repo tying into the Redmine wiki and Trac.

Bottom line: thumbs down on Git and Mercurial unless you really, absolutely need a DSCM. 'Committing' code to your local drive with no centralized repo is complete novelty and really serves no purpose. That's where I think devs get sidetracked into thinking that DSCM's are cool - because I can just 'git ci' and I'm good. Wrong.

Re:Git

[gbjbaanb]

Yes, I think that's the main issue - DVCS are 'cool' so lots fo devs want to use them, and then start making reasons why they are so fantastic, which pulls other devs in, and eventually management hears about it and starts believing the hyped up bits. Mercurial was positioned as a perfect solution to rolling changes to multiple branches. (when I think the problem is a human one, SVN is perfectly good for merging, until things get complicated and then all VCSs are complicated).

We have a 12Gig SVN repo so thanks for the plug to sourceRepo, but we'll stick to hosting our own internally :) I have no problem with SVN, it works fine,just that some devs from HQ are pushing for the 'cool' option, probably becuase its.. well, cool.

Re:Git

[Pastis]

I think youre missing on a lot of values a DSCM can bring you.

Some of my clients use svn, I use git svn bridge. Some of the things I can do:
* have one directory extract locally
* full local history
* stash / pop when a quick fix request comes in
* local branches (I used to have multiple checkouts laying around with svn...) Particularly useful when working disconnected (travelling, or on site without access to companys network). And that helps me make multiple commits, which makes my commits easily reviewable. Otherwise I face the I might "have to merge" fear that I have with SVN.

As for some of your arguments
* you say businesses wont host in the open with github but you advice another service? I am pretty happy to use github for my business. I also have other servers for build etc
* extra step ? Crap. In many cases, the merge in git helps you to go faster. Yes you have multiple commands, but the operations are faster and save you time (merge after commit instead of update breaking your changes)
* hard disk breaking ? Thats crap. Just sync your disk with your server. You should do it anyway with subversion. And its faster than syncing your multiple checkouts directories.

Now I recognize that git is isnt easy to use. I stick to the minimal. But dont dismiss DVCS beacuse you havent found value for them. Try git svn for a week. Then come back.

YMMV

Re:Git

[Anonymous Coward]

This is no insightful, it is dead wrong... please stop spreading this propaganda about Mercurial lacking cheap, fast, in-place branching when Mercurial has had that from day one. You don't need bookmarks or any other extension for making branches, you just use the built-in commit command.

Mercurial has the exact same history model as Git, but in my opinion Mercurial comes with a better user interface.

Re:Git

[Anonymous Coward]

Wrong.

my history: svn -> git -> hg

after converting from git to hg, i don't miss a thing, especially not the pain of reading through the awful documentation...

Re:Git

[emag]

No, no he's not. http://slashdot.org/faq/slashmeta.shtml#sm100

Re:Git

[Krischi]

So, given these two commands:

git reset --soft HEAD^
hg rollback

which one do you think is more intuitive and immediately apparent to the user?

And even more important, which one is easier to find in the documentation?

Things like these are why I ditched git in favor of Mercurial.

Re:Git

[Anonymous Coward]

You don't need bookmarks or any other extension for making branches, you just use the built-in commit command.

You obviously have no clue what you're talking about. Mercurial doesn't have cheap, in-place branches and it never has. You can imitate them by using bookmarks and mq but it doesn't do it nearly as seamlessly as git.

Re:Git

[Abcd1234]

So, given these two commands:

git reset --soft HEAD^
hg rollback

which one do you think is more intuitive and immediately apparent to the user?

Unless I'm confused, those don't do the same thing. From what I can tell, "hg rollback" is used:

"to revert changes that have been commited to the local repository but not been pushed to another repository yet. You can only rollback the last hg command."

"git reset" doesn't do that. "git reset --soft revnum" move the HEAD of the repository to a given position *without changing the staging area or working copy*. So, let's say I wanted to take 5 commits and roll them up into a single commit before I push them into the remote repo. I would do a

git reset --soft HEAD^5

This would move the HEAD of the repostory up, but *keep the changes in my working copy*. So a "git status" would show a bunch of file changed, namely all the files that had been modified in the commits after the referenced commit. I would then do a "git commit", and those changes would be committed as a single changeset.

Of course, all that said, these commands *are* equivalent (I think):

git reset --hard HEAD^
hg rollback

And obviously the latter is more easy to understand. OTOH, "hg rollback" can only rollback the previous commit, while a "git reset --hard" can move up to an arbitrary commit.

Re:Git

[Krischi]

hg rollback doesn't touch other changes in your working copy. But you're right about being able to undo only one commit.

Re:Git

[Abcd1234]

hg rollback doesn't touch other changes in your working copy.

Err, I think you still misunderstand what "git reset --soft" does.

Let's say you had these commits, which changed the corresponding files:

3 - X.txt
2 - Y.txt
1 - Z.txt

And your working copy was *clean*. Now, suppose you did this:

git reset --soft 1

If you did a "git status", it would show X.txt and Y.txt as *modified* and in your index. And if you did a "git diff --cached", you'd see the changes in commit 2 and 3. You could then do a "git commit", and you'd end up with a single changeset combining those modifications. Why? Because "git reset --soft" simply moves the HEAD to point to commit 1, without actually modifying the files on disk or the index.

Of course, "git reset --soft" will *also* not touch any current changes in your working copy, since... it doesn't change the files on disk or the index. :)

Re:Git

[Krischi]

hg rollback will show the affected files as modified in your working directory. You can commit again straight from this point.It's one of the most frequent reasons why I use it: i commit, then realize that I forgot a modification or have to add one more file. hg rollback will let me do that.

I won't let me merge multiple past commits, though.

Re:Git

[BasilBrush]

Err, I think you still misunderstand what "git reset --soft" does.

I think this demonstrates my point about git being unintuitive. Even after having been given an explanation, it's still hard to understand.

Re:Git

[BasilBrush]

That means "Undo the last commit, but don't change my working copy or my staging area."

And yet none of the words that you've used to explain it appear in the command (nor abbreviations nor synonyms.) There's nothing in that command that makes it look like it means what you say it does. Your explanaion is right (I think), the fault lies with the way git commands were designed. Or rather not designed.

Git is a distributed system, as opposed to a single code repository. In that way it's more powerful than Perforce. It is a later generation of SCM. Yes the complexity of git is mostly unrelated to that fact. Git is still unintuitive even when you only use it locally.

Git is unnecessarily unintuitive. It was created with commands that made sense to the programmer(s) that created it, that revolve around the implementation details, rather than being designed for an intuitive mental model for it's users.

What for example is the difference between a working copy and a staging area? No, don't answer, it's rhetorical. The fact is that there are two concepts there that are necessary to use git, and are quite distinct things, yet the names for them could have been the other way around and made just as much (or as little) sense.

No Perforce doesn't have an equivalent for that command. That's not because it's less powerful in that way, it's because it's more sane. Git gives you the ability to "rewrite history", but then the docs go on to advise you that you shouldn't do it if anyone else knows! And gives you a more official way of doing the same thing that maintains a proper history of what happened. Perforce just doesn't give you the option to rewrite history in the first place. You want to undo a change, then you do a second change to get files back to their original state. That manoeuvre is recorded for posterity, no cheating allowed.

SCMs are of course supposed to track every change. Git effectively makes a hack to cheat that function part of the standard operating procedure. And if you make a mistake doing it, you're screwed. The history is gone. The fundamental purpose of an SCM broken.

Of course I might be wrong about this. I've read the Pragmatic Git book cover to cover, and I've still only got a vague idea of how the system works. That's how unintuitive it is.

Re:Git

[PAStheLoD]

It's just like Portal. It takes a while, then you're thinking with branches, trees, commits and git.

Though the whole Git SCM really lacks a all-in-1-click solution, so you can actually manage your source code. A competent merge tool would be good for starters. Built-in pre-commit warning about unresolved merges (conflict markers left in files), not just the "chmod +x the .git/hooks/whatever if you want a warning". And some visual branch/rebase/cherry-pick management would be nice too.

Re:Git

[Abcd1234]

Yeah, you're right, we should do away with any powerful software features that people might find a little difficult to understand initially... God forbid powerful tools should require a little thought to learn and use.

Re:Git

[BasilBrush]

It's not complex because it's pwoereful. It's accidental complexity. There's no reason why a SCM with the necessary features of git can't have an easy to understand set of commands.

It's this kind of shit - believing that accidental complexity is OK - that accounts for the reason why the open source software scene hasn't taken over from commercial software, even though it has huge advantage of usually being no cost. Most people would rather pay for something that's easy to learn and easy to use.

Re:Git

[BasilBrush]

That's what they say about learning French.

Git is a piece of software with the simple objective of keeping a history of changes, and sharing them with others. It shouldn't be like learning a foreign language. The commands should be intuitive, not a hard won skill set, which you need to use often to keep in your head.

Re:Git

[PAStheLoD]

Yes, that's why a handy, easily discoverable, fully functional GUI is not some luxury, but a very dire need especially today, when literally millions want to be software developers, and want to acquire skills fast.

Re:Git

[dmpot]

Git command line is far more intuitive and easy to use than SVN. Trying to use SVN from the command-line is like to use COMMAND.COM -- no completion for names commands or branches (in fact, there is no branches, you got to type f*cking long URLs and of course there is no completion for them either), and there are many other annoying things with SVN. Every time when I tried to write a simple convenience scripts to automatize some routine, it lead to utter frustration how ugly and inconvenient SVN command line is... When I tried Git first time, my experience where the same as moving moving from the ugly and insanely irregular command.com prompt to bash. You can do almost anything from the command line with Git. In fact, the initial version of Git was mostly shell scripts on top a few C written programs. And Git is nicely integrated with bash, so you have completion not only command names but also branches, options, etc...

Re:Git

[Omnifarious]

The equivalent in Mercurial is `hg rollback`. ;-)

Re:Git

[Omnifarious]

Oh, so git reset --soft HEAD^ is like hg debugsetparents, which sets what changeset(s) Mercurial considers the working directory to be a branch off of.

And git reset --hard HEAD^ is like hg update -C <revnum> .

Re:Git

[Omnifarious]

Those features of git are possible to do in other source control systems (like Mercurial) without the bizarre syntax that means nothing to the uninitiated and is even difficult to explain to someone who wants to understand.

I really dislike working with git because it is strange, confusing and makes no sense. And that's not just a matter of being very familiar with the Mercurial command syntax. I know how hash DAG based DVCS systems work, and git still makes no sense.

Re:Git

[Omnifarious]

Re-writing history isn't exactly bad. In a DVCS system, you have a local repository that nobody else has seen yet. You commit things to this early and often, frequently things that make no sense to anyone else. And this is because nobody can see them.

Re-writing history is often a very nice thing to do before you publish your changes to a wider audience.

In systems like Perforce, you often work on a change for days before actually committing it because once you commit it, it's in the big centralized repository forever. In Mercurial (which is very much like git, except that the command syntax actually makes sense) I commit every hour or two.

Personally, I prefer very structured means for maintaining my change history before I submit it upstream. I like using the Mercurial 'mq' extension which allows you to keep a stack of pending changes and go back and edit them into submission before you push them upstream and they become permanent.

So, you are partly right, and partly misunderstanding. The workflow for a DVCS is somewhat different than for a centralized system like Perforce.

Re:Git

[BasilBrush]

Re-writing history isn't exactly bad. In a DVCS system, you have a local repository that nobody else has seen yet. You commit things to this early and often, frequently things that make no sense to anyone else. And this is because nobody can see them.

And you should be keeping all that history for yourself to look at if needs be. If you screw up and need to go back to something from an hour ago, or a day ago, then it should still be there. history should not be rewritten so that those versions have disappeared.

Re-writing history is often a very nice thing to do before you publish your changes to a wider audience.

If you want the public to only see certain releases, then run a separate repository for public consumption, and push those releases to it. It's a DVCS, so you can have as many repositories as you like, even on the same machine.

In systems like Perforce, you often work on a change for days before actually committing it because once you commit it, it's in the big centralized repository forever. In Mercurial (which is very much like git, except that the command syntax actually makes sense) I commit every hour or two.

In my experience of perforce, everyone runs their own private branches, which they update as often as they like (perhaps every hour or so) and integrate changes into a shared mainline branch when ready for general consumption.

Personally, I prefer very structured means for maintaining my change history before I submit it upstream.

You have it with all the SCMs we're talking about here. It does not require "rewriting history".

So, you are partly right, and partly misunderstanding. The workflow for a DVCS is somewhat different than for a centralized system like Perforce.

I'm not misunderstanding. I'm pointing out where git allows a hack to "change history" that should not be there, and it's existence adds extra complexity and opportunities to shoot yourself in the foot. It should not be like that.

Re:Git

[Omnifarious]

I'm not misunderstanding. I'm pointing out where git allows a hack to "change history" that should not be there, and it's existence adds extra complexity and opportunities to shoot yourself in the foot. It should not be like that.

Well, Mercurial makes it a lot hard to change history than git does. But it's still possible.

And no Perforce shop I've ever seen has ever had a private branch for each developer. You could work that way, it's true, but I've never seen it done.

Re:Git

[BasilBrush]

The perforce shops that I've worked at all had private branches for developers. It's not unusual.
http://www.google.co.uk/search?hl=en&safe=off&client=safari&rls=en&q=perforce+private+branch&aq=f&aqi=g1&aql=&oq=&gs_rfai=

Given that it gives what you want, without the need for rewriting history, I'd say the Perforce shops you have seen have missed a useful trick.

Re:Git

[BasilBrush]

Have you heard the phrase "Damning with faint praise"?

No doubt git is better than svn, just as bash is better than command.com. But that ain't saying much.

Re:Git

[Abcd1234]

Those features of git are possible to do in other source control systems (like Mercurial) without the bizarre syntax that means nothing to the uninitiated and is even difficult to explain to someone who wants to understand

It is? Okay, so, just ooc (seriously, I am just curious), how do you do the equivalent of "git reset --soft HEAD~5" in hg? "hg rollback" only goes one commit up, so clearly that ain't it.

I know how hash DAG based DVCS systems work, and git still makes no sense.

Well, no offense, but it sounds like you're just not trying that hard. Git's terminology is slightly odd (the term 'index', referring to the staging area, is a certainly strange), but fundamentally, it's operations are just operations on the commit tree. There's nothing really that confusing going on there, save that some of git's commands allow for some fairly low-level manipulation of said tree.

Re:Git

[Omnifarious]

It is? Okay, so, just ooc (seriously, I am just curious), how do you do the equivalent of "git reset --soft HEAD~5" in hg? "hg rollback" only goes one commit up, so clearly that ain't it.

First, a few questions:

1. Does reset --soft HEAD~5 remove any revisions from the repository?
2. What does the '~5' mean?
3. How does the meaning of ~5 change if there are merges or branches in the very recent history?

If I have the answers to those questions, I can tell you which Mercurial command (or short series of commands) does it, though if your answer to the last one is particularly interesting, it may be kind of complicated.

Well, no offense, but it sounds like you're just not trying that hard. Git's terminology is slightly odd (the term 'index', referring to the staging area, is a certainly strange), but fundamentally, it's operations are just operations on the commit tree. There's nothing really that confusing going on there, save that some of git's commands allow for some fairly low-level manipulation of said tree.

That's true, but, for example, the 'reset' command suggests absolutely nothing to me. Why isn't it named 'rollback' or 'undo' or 'revert' or something else vaguely related to revisions and transactions?

Re:Git

[Omnifarious]

It still doesn't give me what I want, because I want to be able to commit on my laptop when I have no Internet connection of any kind. But yes, it comes closer.

I also feel the Perforce's tracking of merges is somewhat lacking and a bit confusing in comparison with how they're tracked in a DVCS. But it's certainly a whole ton better than either CVS or Subversion.

Re:Git

[Crayon Kid]

Does reset --soft HEAD~5 remove any revisions from the repository?

No. Not explicitly. The state of the tree would be changed to reflect a past commit. The commits after that commit are still in the history.

If a new commit is done from that past point, the tree sprouts a branch and HEAD becomes assigned to it. Still, the old "abandoned" branch of the history is not deleted. It might however be garbage collected at some point, if no branch name is explicitly assigned to any of the commits in it, since they'd be left "dangling" with no explicit reference, which git will take to mean they're of no interest anymore.

What does the '~5' mean?

It means "go up the history 5 commits from the given place". If the name isn't given, it means from the current place the worktree is at. If a branch name is given, it uses it as reference. In this case HEAD was given, which is the default branch name.

Note that, technically, using HEAD~5 doesn't say anything about where the worktree was at that time, only that we wanna switch to 5 places up the history from wherever HEAD is now. But in this particular example we're discussing we can probably assume the worktree was at HEAD, so ~5 and HEAD~5 mean the same thing: go 5 commits back.

How does the meaning of ~5 change if there are merges or branches in the very recent history?

I'm assuming by "very recent" you mean "within those 5 commits". Good question. Since this reset goes back in history, it has no interest in branches, which are going the opposite direction in the time flow. It's following the parent of each commit in turn.

However, if there were merges, that means one or more of those 5 commits may have 2 (or more) parents. In which case ~5 as specified above would pick the first one and go with that. If the user wants another parent they can use ^N, which picks the Nth parent.

Using ^ and ~ specs together allow the user to specify the "path" back up in history very exactly, because they can be chained. Example: let's say that 2 commits back there was a merge of 2 branches. Using ~5 would go up the first of them, but I want the other one. I would use ~2^2~3, which means: go back 2 commits, then pick the 2nd parent, then use that to go another 3 commits.

reset can also move forward in history, but there's no equivalent to ~ and ^ for forward moves. Not sure for the exact reason, but it's probably because ~ and ^ are also used by diff and log and so on, not just reset, they're a generic way of navigating back history. They're only one of the many ways to specify history positions.

Re:Git

[Crayon Kid]

Not exactly. I mean, assuming you understand those git commands well (I can't tell not familiar with Mercurial), you may have found some equivalent hg commands.

But that's not the point.

The point is that the git command is extremely flexible. It has 3 components (reset; --soft vs --hard [and there's more reset methods, not just those two]; and the HEAD^ which is a "treeish", a way to specify history position, one out of many). Those components can be combined in a lot of ways. Furthermore, some of them are reusable; the treeishes are used by other commands, not just reset.

What I'm getting to is that git is extremely flexible. You've picked two particular combinations and found Mercurial equivalents... but what about the others? What about HEAD^2~4? What about reset --mixed? What about forward resets? What about combinations of all these?

Re:Git

[Abcd1234]

The other commentor did a good job covering your other questions, so I won't bother with them.

That's true, but, for example, the 'reset' command suggests absolutely nothing to me. Why isn't it named 'rollback' or 'undo' or 'revert' or something else vaguely related to revisions and transactions?

Because none of those terms is accurate. What "git reset" does is move the HEAD of the current branch somewhere, and optionally affect the index and the working copy. "Rollback", "undo", and "revert" all describe a *subset* of the functionality "git reset" offers (specifically, "git reset --hard"), but they don't wholly encapsulate what it does, which is why a different term is used.

Re:Git

[Abcd1234]

It's not complex because it's pwoereful.

No, it's complex because it's powerful. "git reset" is far more flexible than "hg rollback", and using it forces the user to understand what's going on when git manages the tree, because it allows the user to perform interesting, low-level manipulations of the repository.

If you can't handle that, that's fine, use another tool. But "git reset", for example, exists, and is named the way it is, for a very good reason. This isn't "accidental complexity". This is "complexity where it's appropriate".

Now, it may be that for a lot of users, the kind of functionality git offers rarely justifies its complexity. And if that's the case, they're free to use another tool. But I frequently make use of some of git's capabilities, and am very very glad that I can do some of the things git allows, even if it means I have to actually spend some time learning my toolset ('course, I'm also a Vim user, so clearly I have no issue working with strange, esoteric, yet very powerful tools).

Re:Git

[BasilBrush]

"git reset" is far more flexible than "hg rollback", and using it forces the user to understand what's going on when git manages the tree, because it allows the user to perform interesting, low-level manipulations of the repository.

"Forces the user to understand?" Sounds rather fascist. And also unrealistic. In reality it'll be wielded by many people who don't understand, and will thus make mistakes, and possibly lose data.

No, the complexity is accidental. Using the example you give:
"hg rollback" may only go back one level, but it does have the great advantage of actually being named after what it does. It does exactly what you'd imagine it to do, given the name of the command. "git reset" doesn't. Reset implies going back to the beginning, not going back one or more steps. Someone didn't think through the command name, they just went for the first thing that entered their head.

Not that I think mercurial is right in this either. An SCM is fundamentally a journal, and should represent what happened along the way. People should't be messing about rewriting history to be something other than what actually happened. It causes more problems than it solves, and tuns the risk of unintended data loss. This breaking the fundamental purpose of an SCM.

vim is awful too.

Re:Git

[Abcd1234]

"hg rollback" may only go back one level, but it does have the great advantage of actually being named after what it does.

And it's limited as a consequence. You've illustrated my exact point for me: the tool can be powerful, or it can be simple. Take your pick.

Reset implies going back to the beginning, not going back one or more steps.

Sure, if you stop reading at "git reset". "git reset <revspec>" should make it clear something more than that is going on. But I know, you don't want to have to, like, learn things and read stuff, so I can see how it might be a bit much, asking you to read past the first two terms in a command-line...

People should't be messing about rewriting history to be something other than what actually happened.

Well, if *you* don't do it, clearly it's not useful... ::rollseyes::

Apparently you don't use cheap local working branches very often. See, if I'm working in my own local branch and am prepping a change for merge and then push to a remote repo, I *do* want the ability to clean up my commits before merging and pushing. The SCM *shouldn't* make me pause before committing. If I create a local repo, and want to commit some things to checkpoint where I'm at, expecting to clean up the commit log later, I should have that flexibility.

Well, unless you say so, right?

Let me guess, you're a big Python fan, aren't you?

vim is awful too.

Well, there's little else to say, then... have a nice day and enjoy your tools, while I enjoy mine. *shrug*

Re:Git

[BasilBrush]

Let me guess, you're a big Python fan, aren't you?

Python's not bad. Haven't used it in a few years though. Where did that come from? Because I praised the fact that Mercurial has commands named after what they do? If so the logic breaks down because I've never used Mercurial.

If it's because Python is very productive, because it's easy to understand AND powerful, guilty as charged. If we're following that line of reasoning, perhaps your tastes lie more along the lines of perl. Does the job, but it's unnecessarily hard to read.

Sure, if you stop reading at "git reset". "git reset " should make it clear something more than that is going on.

Well actually in both the git book I have and a the quick reference, the next term is typically either --hard or --soft. Which are just as lacking in intuitive meaning as the first two terms. It's amazing just how many keywords the creators of git managed to make a mess of.

Apparently you don't use cheap local working branches very often. See, if I'm working in my own local branch and am prepping a change for merge and then push to a remote repo, I *do* want the ability to clean up my commits before merging and pushing. The SCM *shouldn't* make me pause before committing. If I create a local repo, and want to commit some things to checkpoint where I'm at, expecting to clean up the commit log later, I should have that flexibility.

It shouldn't matter to the remote repo what steps you took to get to the particular revision you're pushing. The last two states of the remote repo should be what it was before, followed by the version you are pushing.

Sorry, but your opinion that hard to understand UIs are justified by unnecessary complexity of function is the reason why Linux never took more than a tiny fraction of the market. It's amazing, a product with the ultimate price advantage - free vs tens of dollars. Decent security vs poor security. Virtually no viruses vs tens of thousands of viruses. And still it lost, because people like you never realised that ease of use is important. Such a shame.

Re:Git

[Abcd1234]

If it's because Python is very productive, because it's easy to understand AND powerful, guilty as charged.

No, it's because Guido has decided precisely how you should be coding. *He* decided how the code should be indented and laid out. He decided there should only be a single, Guido-approved way of doing anything.

My point is that someone who says "you should never touch the repo!" clearly likes rigid boundaries that can't be crossed, and Python would, I'm sure, be very appealing to a person like that.

Me, I prefer the tools get out of my way because I'm a capable individual who doesn't need the training wheels and the helmet to protect me from myself.

Well actually in both the git book I have and a the quick reference, the next term is typically either --hard or --soft.

Slashdot ate my tags. The next terms are "--hard" or "--soft" followed by a revnum. The revnum should give an obvious clue that something beyond a simplistic rollback is happening.

It shouldn't matter to the remote repo what steps you took to get to the particular revision you're pushing.

That's just short-sighted and wrong. If you work with other people, who might need to read your commits, either to okay them for commit, or to post-analyze them, it's useful to have nice, clean changesets.

Now, maybe you don't give a shit about the people you're working with. But I do. And clean changesets are something I care about.

Sorry, but your opinion that hard to understand UIs are justified by unnecessary complexity of function is the reason why Linux never took more than a tiny fraction of the market.

And the audience that it took? Power users. *Developers*. People who should be able to cope with complexity in order to utilize the power of the tools. Git is a powertool. Again, if you can't handle that, fine, enjoy hg, which is, I'm sure, a very useful tool, it's just clear that it offers a subset of the functionality git provides, functionality that I and others clearly want.

Re:Git

[lewiscr]

Last Modified: 2/07/02

Re:Git

[gbjbaanb]

thing is, those things aren't so great.

1 directory extract locally... my SVN repo is 12Gb. That's a lot of network traffic and disc space for a lot of stuff I do not need to see of manage. When we migrate the core product, that'll be even larger. I suppose the git solution would be to have many repositories.. but then you'er losing the benefit you've claimed.

full local history: fair enough, but its not that big a deal, on the relatively few occasions I want history (that isn't just the previous version), a hit on the server isn't a problem.

Now, the advantage with git is that you can have local branches and stash changes locally. This is a good thing, I feel, and I'd like to have it in SVN, but ultimately you're going to send your commits to the server so the local branch is a temporary thing (its not so much for the disc crashing, but for all the other reasons you make backups. You do not want to lose your work. ever).

I think git has its place, but for a business, the DVCS advantages are not so much of an advantage, and the disadvantages usually outweigh them. For a collection of open source people working on the same product almost independantly, then the DVCS is ideal - which is exactly what it was designed for.

Re:Git

[Pastis]

> 1 directory extract locally... my SVN repo is 12Gb. [..]

I meant one extract instead of multiple checkouts. When I was working with subversion, I always had to play with multiple checkouts when working on several things at a time (not nice, but sometimes you're forced to). With SVN, no ability to stash the changes, need to be online to make a checkout or new branch, etc. And it's slow!

> That's a lot of network traffic and disc space for a lot of stuff I do not need to see of manage.

For the do not see. It's pretty educative to have the ability to understand why things are one way or another.
For the space, I don't know. I have a 320 G disk on my laptop, 12 G isn't much. And even:
* You don't need to clone all history
* if you decide to get the 12 G, then fine, it's a *one time* operation. That's less than one hour to write this on your disk (40 min at 40MB/s). Once.

> I suppose the git solution would be to have many
> repositories.. but then you're losing the
> benefit you've claimed.

I was talking of having one checkout per tree, instead of multiple checkouts per tree. Never claimed to have a single git tree.
And if you had multiple trees, you would probably not need them all.

E.g. http://android.git.kernel.org/ You can pick all trees, or just one.

> full local history: fair enough, but its not
> that big a deal, on the relatively few occasions
> I want history (that isn't just the previous
> version), a hit on the server isn't a problem.

* I use history more often than before now that it's quickly available (blame, find changes, etc)
* yes you can hit the server for history but it's damn slow, and _sometimes_ you don't have a server (server upgrade, server crash, network down, offsite, etc...)

> but ultimately you're going to send your commits to the server

I never said using git locally would remove the need for sane data handling procedure. It's the same if you work without committing to SVN.
With a DVCS, it's just faster to be able to commit anytime, and push every so often. You end up doing it more often and you make your code changes smaller, easier to review by your co-workers. YMMV

> I think git has its place, but for a business,
> the DVCS advantages are not so much of an
> advantage, and the disadvantages usually
> outweigh them

I probably didn't do a fine job selling git out.
I know many businesses that use git (or mercurial) with great pleasure and they wouldn't go back for anything.

I won't spend more time trying to convince you. I agree that for some people, especially with git, DVCS can seem a bit too complicated.

For me it's a paradigm shift.

Given your comments, I am not sure you really tried one. I advice you to try one DVCS for yourself for a full week. And start with bridging SVN with git or mercurial.

Re:Git

[bbtom]

Just like I'm sure someone who has never used any Windows, Mac or Linux GUI application would wonder what the hell

File -> Save As ...

did.

FTFY

Re:Git

[BasilBrush]

No, it's because Guido has decided precisely how you should be coding. *He* decided how the code should be indented and laid out. He decided there should only be a single, Guido-approved way of doing anything.

Ah, the paradox of choice. The incorrect assumption that more choice is necessarily a good thing. It isn't.

Take C-like languages. Block beginning and end defined with braces. Whitespace almost completely optional. So, some people put the opening brace at the end of the proceeding line. Some people on a line by itself. Some indent it to the same level as the block. Some leave it at the same level as the containing block. Similarly with closing braces. People just start out with one because the like the look of it, it was used in the book they learned from, or it's in a particular coding standard. At some point they may try another, and may end up reformatting the project to match. They'll get into arguments with colleagues or on slashdot about what the one-true-indenting style is. Someone else will join the project, with their own preferences and the indenting will either become a mix of two styles, or there will be someone annoyed at the stupidity of the indenting style they are forced to use. Then there's demo code and snippets that you need to reformat because it's not in the format you yourself use.

Etc.

It's all so very pointless, because one style is not demonstrably any better than any other style. It doesn't matter what people use, and there would be less time wasted on the topic if one way had been picked by the language creators in the first place. In fact most people, end up using the K&R indenting style, as the nearest thing to global standard.

Python is far more sensible. It does away with the opening and closing block markers entirely so the dilemma of where to put them is gone. The one thing that everyone (including the C programmers) does agree on is that the statements inside a body should be indented from the enclosing block level. So python uses that show where the blocks are.

Mind you, it's not perfect. The amount of indenting is not specified, neither is whether you use tabs or spaces for the indenting. 4 spaces is usual, but it would be better if a specific indent had been made mandatory, so that all Python uses the same formatting, for all the reasons pointed out above.

Now, maybe you don't give a shit about the people you're working with. But I do. And clean changesets are something I care about.

People you work with are better served by a SCM that tells them the truth about changes. You might try to rewrite history to how you'd prefer it to look, but they are better off seeing what really happened.

And the audience that it took? Power users. *Developers*.

Of course most power users and developers are on Windows. Rather you can define Linux's tiny userbase as lacking everybody BUT power users and developers. It's UIs are so unfriendly and unintuitive that no one else wants to use them. In fact only now is Linux beginning to get widespread usage as a client system in the form of Android. A new variety of Linux that has started from scratch on the UIs.

Re:Git

[Anonymous Coward]

At some point they may try another, and may end up reformatting the project to match. They'll get into arguments with colleagues or on slashdot about what the one-true-indenting style is.

If this sort of argument takes a measurable amount of development time, there's something seriously wrong with your team: that something would pop out in another context if it didn't come up with indenting...

I've been in this situation several times and it has never taken more than five minutes to resolve -- after that work continues and some people have to adapt to a coding style they don't like, just like with Python.

Wow.

[FuckingNickName]

I can't understand what the article summary is getting at. A reposting of a press release? An expression of /.'s parent company's interest in some organisation? Or a "tweet" accidentally posted as a /. article? A side effect of think-aloud sleep-typing?

Re:Wow.

[The_mad_linguist]

A side effect of think-aloud sleep-typing?

Nah, think-aloud sleep typing is more like

I, on the other hand, have found it quite impossible to predict orange growths with the kabbalah. Can you explain your methods and how I might improve mine?

Re:Wow.

[dncsky1530]

Yea I don't know what is going on today but the quality of many of these summaries has been awful. This one tops it off with numerous mistakes in the title alone.

I'm also not sure what Roblimo's problem with Atlassian or proprietary software is; from my experience Atlassian produces fairly good software and charges far less than competitors.

Also, how about linking to the actual press release or a news story that contains more than commentary?

Re:Wow.

[Anonymous Coward]

I can't understand what the article summary is getting at. A side effect of think-aloud sleep-typing?

I'd go with the sleep typing, but with the caveat that it's a brain-addled crack baby doing the sleep typing.

the majority of Atlassian's business comes from meeting the needs of behind-the-firewall, proprietary code repositories

That came straight out of Roblimo's crackpipe. So the majority of Atlassian's business comes from meeting the needs of proprietary code repositories? I didn't know that code repositories had needs, but I guess advanced ones like fanboy Roblimo's Git have gained sentience and are making demands, which Atlassian now makes the majority of its money from. By, uh... servicing the demands those repositories are making. Or... something.

Atlassian's cash cow has always been Jira, its bug tracker.

I think Roblimo's lost his marbles or something. The only point of this piece-o-shit article is to bash proprietary software and blow his FOSS horn out of his butthole like a Stallman-scented vuvuzela.

Re:Wow.

[MrEricSir]

That makes a hell of a lot more sense than the article summary.

Re:Wow.

[kiwimate]

No kidding. I am not one who usually comments on article submissions or the quality of the summary - I just ignore articles if I'm not interested in them - but this summary would (hopefully) be marked as troll if it was read as a comment. Given that something this rubbishy is posted by a /. editor, it's driving me to read /. less and less these days. Rationale - if this tripe is what makes it on to the front page, and from an editor, then my assurance of the quality of what's posted and what's left out is way down. What other value does /. have for me?

Re:Wow.

[Callandor]

If I had mod points, I'd mod this up. As a Mercurial user for over a year and a Bitbucket user for just under a year, I was very disappointed to read this story in my RSS. Not only is it old news (Bitbucket made this announcement on Tuesday), but it is full of inaccuracies and obviously written by a git fanboy. I've been using Jira and Confluence for several years now and I have no love for Atlassian and their products, but I don't hate them, either. At a glance, this announcement makes Bitbucket both better than it was and more attractive than GitHub. Maybe Atlassian will make some business decisions in the future that make Bitbucket less attractive, but for now, this is good news. There's no reason to be all negative about it, especially in the lead story. Troll is right.

Re:Wow.

[kiwimate]

Ah, I get it - I finally clicked on the first link, which goes straight to...an article written by one Mr. Roblimo. That article has a few more links (actually, apart from that one, the only other links are to Atlassian and Bitbucket). If I were a cynical type of chap, I'd suggest he's trying to pump up traffic to his page on this website and being too lazy to do it well.

Re:Wow.

[emag]

I've been less than pleased with the kwality of Atlassian software, namely Confluence & JIRA. Neither seems to be able to stay up much longer than 24 hours before consuming a lot of resources and refusing to respond. It's gotten to the point where, for stability's sake, I have cronjobs stop them, then kill -9 any leftover java processes, then start them. Every. Night. There are some other problems I have with them, too, but this isn't necessarily the place to air those.

I agree with you on the submitter's summary, though. Then again, he's like that all the time, and I just try to completely ignore him these days.

Re:Wow.

[bbtom]

I'm also not sure what Roblimo's problem with Atlassian or proprietary software is; from my experience Atlassian produces fairly good software and charges far less than competitors.

Ahahahahahahahahahahahaha! You are joking, right?

Confluence is classic enterprise software. Purchased by people who never have to use it. I've used it and it is unintuitive shit. They've taken what should be a fundamentally simple piece of software - a wiki - and made it into the bastard lovechild of Lotus Notes and Outlook so they can add a bunch of bullet point features. The result is a horrific monstrosity that nobody would ever use if it weren't for Enterprise Architects needing Important Enterprise Features.

This is a really really misinformed article

[Anonymous Coward]

You should spend some more time researching prior to writing articles like this. Atlassian purchased Bitbucket, which is to Mercurial like GitHub is to Git. Mercurial is just as free (in both senses) as Git is...

Why does the fact Git is free matter here?

[Omnifarious]

Mercurial is just as free, and just as easy to set up. Code hosting repositories are about someone else managing your connectivity, storage and backups for you, not about them building DVCS software for you.

Re:Why does the fact Git is free matter here?

[mysidia]

Yes.... and until there's a cheap hosting provider that offers WebDAV, Bitbucket is a good option. However, if you're an enterprise, such as a bank, you might be concerned about the risk of your code repository site getting hacked.... in that regard, Open Source projects are more amenable to services like this... at least until DVCS clients support host-proof encryption of files on the server.

OTOH they can offer web-based tools that make it easy to visualize changes and other things that would be a pain to setup.

Every minute you or people in your organization are dicking around with the DVCS and scripts on your PC that you're trying to use as an ad-hoc web server for code hosting, is a minute that you are not coding.

There's some value to having a code repository provider do all the heavy lifting.... just make sure you keep backups of your own.

Atlassian has some nice stuff

[syousef]

I'd rather use the open source product every time but I have to admit Atlassian has some nice feature rich developer and development management tools.

JIRA's just so so and Confluence just plain sucks due to horrible Rich Text editing that destroys formatting and awful proprietary markup. (I have to use it every day. It's usable for quick notes. Anything bigger or with pics goes into a Word doc). However some of the JIRA plugins and especially their FIsheye product is awesome for code analysis and comparison (provided you have sensible management)

Re:Atlassian has some nice stuff

[Anonymous Coward]

Confluence uses pretty vanilla wiki text. The complete documentation for it is less than a page. Call me old school but I prefer wiki text.

Re:Atlassian has some nice stuff

[Syberz]

Lord do I ever feel your pain.

For project management, JIRA isn't half bad with a little tweaking (we have an excel doc plugged into it which graphs our sprint progress) but Confluence is utter crap. For a standard wiki, I suppose it's passable, but here we use it for our requirement management (unfortunately), maintaining traceability between reqs/tests is a nightmare...

I agree about Fisheye, it's the bee's knees.

Re:Atlassian has some nice stuff

[metamatic]

JIRA's just so so and Confluence just plain sucks due to horrible Rich Text editing that destroys formatting and awful proprietary markup.

Uh-huh...

(I have to use it every day. It's usable for quick notes. Anything bigger or with pics goes into a Word doc).

Hahahahahaha! Nice troll.

Re:Atlassian has some nice stuff

[syousef]

How old are you? 3?

Re:Atlassian has some nice stuff

[Anonymous Coward]

For a standard wiki, I suppose it's passable, but here we use it for our requirement management (unfortunately), maintaining traceability between reqs/tests is a nightmare...

And let me tell you, hitting myself on the head with a hammer did NOTHING to solve my headache - what an utterly crap tool!

If you use a tool for a purpose it wasn't really made for... is it the tool's fault that you have problems achieving that purpose? Or is it more an operator problem?

Seriously... a wiki for requirements? Good luck making sure that your devs don't just update the requirements to match current behavior and call it done, right?

Re:Atlassian has some nice stuff

[Anonymous Coward]

Jira can require quite a bit of tuning to get running nicely, especially if you have thousands of users and over 100,000 tickets. The new AJAX stuff is slow and only works well in Chrome. Confluence's rich text editor has improved significantly over the last couple of years. The markup is the same as Jira's. Fisheye is awesome, I have a bunch of subversion repositories it talks to that are HUGE, and it makes dealing with those much easier. However, this may explain their half-hearted effort to integrate decent git support into Fisheye and Crucible.

Disclaimer: By Atlassian's admission, I run the largest private Jira and Confluence sites they know of.

Re:Atlassian has some nice stuff

[Syberz]

Before being a jackass, why don't you read the product's specs:

Requirements Gathering
A requirements specification is never complete. It is an iterative document showing only a team's intentions at a given point in time. Confluence gives development teams the flexibility to rapidly update specs and keep everyone updated as requirements change.

http://www.atlassian.com/software/confluence/tour/documentation-software.jsp

It was made for requirements, amongst other things. I didn't have the luxury of picking the tool and besides, except for Doors, I found no requirement management tool which answers all of our requirements neatly.

Git lacks tracking capabilities

[Florian Weimer]

Developers can push arbitrary data and metadata into the repository. The standard server does not map branch updates to user accounts. Here's an example: Suppose developer A merges the master branch into a development branch (which is not ready for merging into the master). Git will record a merge commit, attributed to developer A. Developer B then accidentally pushes the development branch onto the master. This is now a fast-forward merge, so no additional commit will be created, and the mistake is not attributable to developer B (and it will look like developer A's mistake, because their commit will appear at the tip).

In some (mostly corporate?) environments, this can be a problem. This is something which can be fixed with additional bookkeeping on the server side and out-of-band user interface. I believe most of the Git hosting platforms out there have this functionality, and they keep it proprietary to them.

Re:Git lacks tracking capabilities

[Anonymous Coward]

Suppose developer A merges the master branch into a development branch (which is not ready for merging into the master).

Then why do it? He should clone the master branch and work with that. Branching in git is a non-issue, it's that cheap.

Developer B then accidentally pushes the development branch onto the master.

Which development branch? B's? You do realise that since git is distributed, A's and B's and the master upstream repositories are three completely distinct repositories.

Furthermore, there's a distinction (which you're not making) between the master branch in each of those repositories and the master repository (usually referred to as "origin", not "master", for this exact reason).

So, should B push changes to the dev branch to the upstream (origin) repository, it has nothing to do with what A has been doing in his own private repository in the meantime.

This is now a fast-forward merge, so no additional commit will be created, and the mistake is not attributable to developer B (and it will look like developer A's mistake, because their commit will appear at the tip).

First of all, non-fast-forward pushes are not allowed by default. You have to override and force the push manually. Which is frowned upon or downright forbidden (since it destroys history information on the recipient repository) and the consequences will range from a bop on the head to decapitation, depending on your project/workplace policies.

Second, I don't know of what VCS you are speaking, since you're obviously not familiar with git and/or have been using it in a very awkward setup. Basically, what you're describing is not a fault in git, just an very dumb usage scenario.

If you've managed to prove anything is that git is too flexible for its own good and that it can be misused in creative ways. :/

Re:Git lacks tracking capabilities

[Anonymous Coward]

Yes and no.

What he is describing is not how push is used/intended in a true distributed environment, however, in a corporate setting, you don't have a true distributed environment. You will have a centralized repository, which everyone will be pushing to (it's the one that's backed up).

As Git was intended for a pure distributed environment, push *is* lacking in a centralized environment. It's perfect for pushing things from your private repository to *your* public repository (the one one the web server). In a centralized environment, you lack the information that Florian complains about.

On further thought, I think the problem comes from the concept of each repository having *one* owner. Anything pulled into my repository, or pushed into my public repository, will have been pulled/pushed there by me. Who actually wrote the code is tracked by Git, but I'm the one who pulled it into my repository. A centralized repository doesn't fit into that concept.

However, there are hooks (shell scripts) that run every time someone pushes to the repository. These could be set up to log which commit ids were pushed by whom, but this will be outside of Git.

Re:Git lacks tracking capabilities

[FictionPimp]

We use indefero with git. Basically we setup a project on the server. Each user has an account on indefero with their ssh key uploaded to it.

Then pull from there, do their work and push back when they are done. Works great and even allows nice workflows like this.

I have an intern, he checkouts from the server with read only permissions. He does his work and notifies me that he is done. I then pull from the server and do a checkout from him, validate his code and push it it to origin if it meets our standards.

Re:Git lacks tracking capabilities

[Anonymous Coward]

If you use a DVCS like git in a corporate environment where all developers push to a central repo, you're doing it wrong. A DVCS allows you to use the exact same model as everything else in your organization: a chain of responsibility/authority that increases upwards and decreases downwards. Do all workers deal with the CEO? No, the entire organization is based on delegating responsibility and authority.

If you have 15 developers, split them into 3 teams, and choose team leaders.. Then choose a lead developer. The master repo is only ever updated by the lead developer (pushed by him), and his repo is updated from team leaders (pulled by him), and team leaders' repos are updated from team members (pulled by team leader). Each leader has the responsibility to ensure that their master branch is clean and correct for the boss.

Backup? Do not base your workflow model on the requirement of backup. Do not push your developers to commit changes to a central repo just because you want everything backed up. Make backups using a different mechanism.

Re:Git lacks tracking capabilities

[prlawrence]

Suppose developer A merges the master branch into a development branch (which is not ready for merging into the master). Git will record a merge commit, attributed to developer A. Developer B then accidentally pushes the development branch onto the master. This is now a fast-forward merge, so no additional commit will be created, and the mistake is not attributable to developer B (and it will look like developer A's mistake, because their commit will appear at the tip).

We use git here in a corporate environment, and this problem absolutely does not happen, because:

1. Only special people have commit rights to the official repo
2. Those people always force a merge commit

Forcing a merge commit means using the --no-ff flag, which disallows any fast-forward merges. In this way, the person who is doing the merge into the official repository has a special merge commit with his name all over it.

This is not likely to be accidentally subverted; these official repo caretakers only use Git GUI (they're not really command-line types), and they use a git gui command I wrote for them that forces this behavior. Here it is, taken from .gitconfig:

[guitool "origin/pull merge request into local branch (Args = merge request number, Revision = local branch) "]
; fetch the latest from origin
; get off of the current local branch (in case it is the target)
; force the target local branch to match the origin branch it tracks
; checkout local target branch
; pull merge request into target local branch (and force merge commit)
cmd = git fetch origin && git checkout HEAD^ && git branch -f $REVISION origin/${REVISION} && git checkout $REVISION && git pull --no-ff origin refs/merge-requests/${ARGS}
argprompt = yes
revprompt = yes

If you're really paranoid about this, git offers pre-commit hooks, which could be used to reject any fast-forward merge into the master branch of the official repository.

At any rate, one would assume someone is ultimately responsible for checking official commits for their adherence to the no-fast-forward standard. If a bogus commit slips in it could always be redone, barring some ridiculous deployment system that rolls out production code instantly upon commit.

Re:Git lacks tracking capabilities

[Florian Weimer]

Which development branch? B's? You do realise that since git is distributed, A's and B's and the master upstream repositories are three completely distinct repositories.

Most projects (even non-corporate ones) have a shared, centralized repository to which more than person can push, so the push attribution problem arises.

One reason for centralized repositories is that you cannot have decentralized deployment. Your organization has only got one www.example.org server (cluster), so eventually, there is a very strong constraint which linearizes development. Certain build and testing infrastructure also strongly favors linearity.

First of all, non-fast-forward pushes are not allowed by default.

After the merge, it is a fast-forward push, and the server cannot distinguish it from new, legitimate development. The problem is not that Git doesn't prevent the push (after all, you need to be able to get new commits into the repository). The problem is that out of the box, Git does not keep track of who pushes what. Out of band solutions exist, and those hosters typically provide that.

Re:Git lacks tracking capabilities

[Crayon Kid]

The problem is that out of the box, Git does not keep track of who pushes what.

Yes, it does, what on Earth are you talking about? In Git, each changeset has an author AND a commiter, and they can be different persons. There's a clear distinction between which developer created the changeset originally and who's moving it around the repository, or to other repositories.

I don't see why a centralized repository is a problem, as long as you set the identities of the developers on the machine hosting the repository and as long as they authenticate properly.

If by "out of the box" you mean "I slapped a git repository in there and expect it to magically know who the developers are"... even that will happen, to some extent; when you do your first push git will try to infer your identity from the system account. Naturally, it cannot perform magic and deal with all possible remote setups. But I don't see how sloppy setup is Git's fault.

Nevermind that bitbucket competes with sourceforge

[Anonymous Coward]

Sf.net, which is owned by 'geeknet', which owns /. seems like the only reason this was posted despite the blatant fricking errors in it.

For the record, bitbucket is mercurial, not git. Although isn't it nice that crappy ass sf.net (which is in the same space as bitbucket although frankly sf.net still bloats goats) provides git..

I realize it's a bit tinfoil-y, but really, what other explanation is their for this postings content?

That submission is just plain wrong

[denne]

"the majority of Atlassian's business comes from meeting the needs of behind-the-firewall, proprietary code repositories"

Eh. Most products developed inhouse are hosted like that. No problem with that. Not every business want to do the "cloud-thing", but that could be illegal now?
And code repositories, most businesses uses svn, git or cvs, all of them are open source from what I know.

Has the cloud-hype been so successfull that people think that FOSS must be something in the cloud now?

Re:That submission is just plain wrong

[hrimhari]

And code repositories, most businesses uses svn, git or cvs, all of them are open source from what I know.

I regret to tell you that where I work we're forced to use MKS. But the development centers that know what version control is for end up using something else for the day-to-day work (like SVN) then exporting it off to MKS when the work is done, just to conform to Corporate rules.

Story is wrong...it's not a code repository

[Anonymous Coward]

Atlassian isn't a code repository, it integrates with them through a product called Fisheye. But their flagship product is Jira, an issue/project tracker. They also have an ldap server (Crowd), a wiki (Confluence), continuous integration (Bamboo), code review (Crucible) and more. It all works together quite well and is very flexible.

It's like Slashdot isn't even trying anymore.

Horde of shit

[Anonymous Coward]

So all you need to do to get an article on the front page of Slashdot these days is a factually incorrect, barely coherent rambling shite of text, provided it bashes proprietary software and sings the praises of FOSS.

Slashdot: news for narrow minded, deluded nerds

Re:Horde of shit

[Anonymous Coward]

I've pretty much switched to HN. I still check /. occasionally, but most of their interesting stories seem to have already appeared on HN.

Re:Horde of shit

[emag]

Well, look at the submitter, who also authored TFA. The epitome of "factually incorrect, barely coherent"...

Re:Nevermind that bitbucket competes with sourcefo

[nOw2]

I realize it's a bit tinfoil-y, but really, what other explanation is their for this postings content?

Head injury?
Everyone has a breaking point. For me and slashdot, it's this "article". I would vote it simply be removed and forgotten about.

Atlassian hosted repositories?

[Anonymous Coward]

I didn't even know Atlassian hosted repositories (does anyone know what kind? I'm guessing subversion). In my mind, I'm more familiar with them as the guys that wrote the Confluence wiki & JIRA, two fairly nice tools.

Atlassian tools are not just a code repository

[Anonymous Coward]

It seems that nobody actually knows the Atlassian tools @/. .

Jira = Ticket Tracking
Best compared with redmine (http://www.redmine.org), but 100x more customizable. We are selling and customizing Atlassian Products in Austria and only ~50% of our customers usage is for software development. The extensive workflow engine in jira can be used to manage quite a lot businesses.

Confluence = Wiki/Blog
An enterprise wiki with integration with MS products.

Fisheye = Code Repository Viewer
Explores GIT, code repositories. So its not atlassian tools OR GIT as mentioned in the article but atlassian tools AND $CODE_REPOSITORY.

Crucible = Code Review Tool

Bamboo = Build Server

Crowd = SSO/OpenID tool
Has AD/LDAP integration

And last but not least you can use any of this tools standalone or a subset of them and use the extensive integration.

The tools are OpenSource but not "free" as in beer or any other way. As soon as you buy a license you have access to the code and can write your own plugins.

So please don't compare atlassian products with GIT anymore. Its like comparing to buy a whole car or just the wheels...
I'd be happy to hear about any other toolsuite with the same functionality as the atlassian tools.

Steak

[Anonymous Coward]

"Steak makes me orgasm." I swear, that's what she said.

kdawson, master of useless summaries

[bigrat]

Atlassian makes code tracking and corporate-friendly wiki products. They're pretty nice, actually. It's pretty easy to write plugins that add flexible functionality to their products. I was and am a pretty big fan of Jira and Confluence, and they're pretty responsive to their customers. Their products are (last I checked) pretty reasonably priced, and integrate into Subversion, CVS, and other source control products pretty easily - including Git.

Last I checked, Git didn't really lend itself to project issue tracking - which is what Jira does. So if you must bitch about non-free Jira, you could at least make an *intelligent* article comparison to a open-source issue-tracker like Trac (another excellent product).

Alas, we're unlikely to see any intelligent comparisons from kdawson. The "lazy-shrug" dept is all too relevant here, but not for the reasons kdawson used it.

Re:kdawson, master of useless summaries

[Anonymous Coward]

Check again. They changed their pricing model recently. Now its unattractive for supporting customers as users.

Re:kdawson, master of useless summaries

[bigrat]

Also: way to change the article summary without an "Edit" notation, guys. That's awesome work, /. The summary is still incoherent.

roblimo a bit of an obnoxious git

[Anonymous Coward]

A bit sad that fanbois tend to have to spout their One True World View everywhere. Conveniently forgetting that if their pet system was truly the best of the best there simply would be no business case for any competitors. In reality such a situation would breed an unfortunate monoculture leaving us with a clunky beast and no improvements. Giving room to competitors. So, any large and widely used project needs a competitor or two to "stay humble", to keep each other on their toes, to avoid becoming complacent.

Besides, git isn't god. It has a couple of interesting differences over, say, svn, but its prime author is himself as obnoxious as the entire core team of svn. So STFU already and just give us the news, eh.

Don't forget github.com

[Ouija]

You are remiss in not mentioning github.com which does the favor of free, immediate online hosting of OSS projects and content under git. I don't know how many presenters I've seen with their slides and demo code all on github. It's the killer app that makes git really rock.

Ridiculous.

[Anonymous Coward]

Can the entire post be marked as -1: Troll? That's the most ridiculous summary I've heard in probably years.

Congratulations on spewing garbage from your mouth, Roblimo. I heard that's a life skill when using GNU/Linux.

Wow. So many errors in such a short summary.

[affenhund]

And i'm not happy about them. If you don't even know the difference between mercurial and git, please just stfu.

FAIL

[vr]

Wow. That summary was amazingly bad. You fail the Internets, sir.

from the lazy-shrug dept

[Anonymous Coward]

Atlassian Shrugged.

Last Straw

[Seakip18]

That's it. I'm doing what others have done and blocking kdawson. This summary is crap and should never have been posted.

Re:Last Straw

[EnglishTim]

I hadn't even realised that was possible. Thank You.

OT: Isn't Atlassian Confluence a POS?

[Nicolas MONNET]

I have to use it at work and it's a pain in the ass. The markup language is horrible, but it's a question of taste I guess. However some basic functions are missing; I couldn't find a way to list another user's contributions for instance. The ACL management is a pain in the ass. It lacks user-generated templates. The UI is rather bad.

Is there a good reason to pay that much money for such bad software?

Re:OT: Isn't Atlassian Confluence a POS?

[Anonymous Coward]

JIRA does have some defects but it is usable.

Have you looked at their database design. Ugg, XML rather than relations.

Re:OT: Isn't Atlassian Confluence a POS?

[Anonymous Coward]

The markup language is horrible, but it's a question of taste I guess. However some basic functions are missing; I couldn't find a way to list another user's contributions for instance.

I like the markup language in comparison to other's. Easy to understand and doesn't get in my way.

you are 100% correct on that missing feature, I can't understand who left that out. Frequently I know that a coworker edited a page but don't remember what it was called. Okay I'[ll look at their last edits. OH WAIT I CANT. And the search blows too.

Re:OT: Isn't Atlassian Confluence a POS?

[tpv]

You should be able to see recent edits on the user's profile:
/users/viewuserprofile.action?username=jsmith

The fact that you didn't know about that is probably a validation of the complaints about the UI.

Disclaimer: I don't have any vested interests in Atlassian, but one of the founders is a friend-of-a-friend

Horrible Summary

[Opusbloom]

Wow, is there a prize for worst summary ever?

        "majority of Atlassian's business comes from ... proprietary code repositories
1. Atlassian doesn't have any products that are code repositories. It has one product that is a viewer for code repositories; Fisheye. It supports SSubversion, Perforce, CVS, CleareCase, Git and Mercurial.
2. I'm not privy to atlassian's financials, but I'm willing to bet that most of their money comes from Jira, with confluence a close second. Fisheye was an acquisition that they did a few years back when they bought Cenequa.

News for Nerds? More like Editorializing for Nerds.

People feel better about what they pay for.

[Murdoch5]

Git is a much better SCM system then most of the thousand / million dollar systems out there. Currently I'm working perforce and I can tell you that it brings nothing to the table that I can't get with Git. When I told my prof we should just set up a Git server instead for free he made a big speech about not using Open Source. I can only imagine that his rejection is due to the fact that Open Source has been misrepresented and he fines it to lack features. As pure Linux user I can say with 100% confidence that open source projects are better then there closed source cousins, the only exception to this is highly specialized software such as autocad and similar special projects.

If you understand software then you'll understand that open source is the way to go, if you don't understand software or you've been brained wash by microsoft and apple then your going to shine towards using closed source software . If you want to spend a million to get the same function you can for free go ahead. I'll save my million and just use it to by I don't know maybe a house, car, food etc........ Open Source means better more secure software period!

Re:People feel better about what they pay for.

[Americano]

When I told my prof we should just set up a Git server instead

Thanks for this even-handed analysis, borne out of your long years of experience in the industry. It is clear that your vision and insight is hard-earned, and that you're not just parroting the standard slashdot groupthink in a karma whoring of immense proportions.

If you understand software then you'll understand that open source is the way to go,

Let's ask your prof if YOU understand software.

Open Source means better more secure software period!

Open Source is not magical pixie dust you can sprinkle on any project to turn it into a successful, well-designed software system. There are a lot of really great open source systems out there, and there are also a lot of steaming turds out there in the open source world - much like the closed source world, actually. It's simply a different development model, it does not automatically guarantee success, stability, or security.

Re:People feel better about what they pay for.

[Murdoch5]

I don't need insight to know that perforce is a steaming turd. I've used both Git and Perforce and I will say for 100% that Git is much better SCM system. Not just because it's open source but because it actually accomplishes what were looking for which is SCM and not what we think we need such as SCM + extra's + interface = perforce.

Re:People feel better about what they pay for.

[Americano]

So you're saying that the feature set of a product is more important than how it was developed?

Color me shocked.

Piece of Sh%t

[Anonymous Coward]

Atlassian products are just more proprietary, buggy, bloatware. Whoever uses this crap is a moron. Are you listening MMSI?

Give me a break

[GWBasic]

But isn't Git easy to install and use -- for free, even if your project is proprietary and secret, not open source and public? Whatever.

Give me a break. When I was looking for a repo for ObjectCloud, I listened to a one-hour video of Linus rambling about how wonderful Git and distributed SCM are. I tried Git for about two days until I got stuck in a situation where I realized I'd have to spend at least an hour "problem solving" by crawling lots of well-meaning, but difficult-to-read, forum posts. I've never had such a confusing experience with an SCM before in my life.

At that moment I switched to Mercurial. It works, and it's easier to learn. I have hit some messes, but it took me a month or so before I got stuck, which is long enough to become comfortable figuring out how to dig out of newbie mess.

Re:Give me a break

[Crayon Kid]

Git is MacGyver, Mercurial is James Bond. Use the one that fits your work style and requirements. The right tool at the right time.

Re:Give me a break

[GWBasic]

That article is 100% on the mark when it talks about Mercurial's forking problems. I've been bitten by that issue, but it wasn't until after I became comfortable with the tool and knew that I could still get my data out.

Perhaps my original post came off too much as being yet another Mercurial vs. git post; which wasn't my intention. What I was replying to is the sort of "xxx MUST be better because it's 100% open source" attitude. Even though I like the concepts behind open source, I find the "it's better because its open source" attitude silly if I just want to get something done. Sure, Mercurial isn't 100% open source, but I always have access to my entire history, which is really what's important. (For example, I dumped BitBucket because they had some horrible downtime problems earlier this year.) As long as I can get my data out of the five copies of my repository, I don't really need to worry if I can compile my own custom version of hg.

I went cvs - svn - git -hg

[Krischi]

I tried out git first, and used it in a real project. I really wanted to like it, but after having to go back to the documentation for the umpteenth time to figure out how to do something that should be dead easy, I decided to give Mercurial a try. I haven't looked back since. The commmand set is wonderfully logical, once you wrap your head around the whole DVCS and changeset concept, as opposed to working with revisions. Everything works as you would expect, and if not, is easy to look up the command in question in the documentation, quite in contrast to the git docs.

I still use git for a specific project, because I am not given a choice. But for the sake of my blood pressure, I use Mercurial for everything else.

Re:Nevermind that bitbucket competes with sourcefo

[carlfish]

A couple of years ago we (Atlassian) showed up at a trade show with a "Friends don't let friends use Sourceforge" banner. Maybe there's some latent corporate hostility. :)

Regardless, I don't understand what this article is truing to say and I sit two desks across from the Bitbucket team!