Re: [OT] DVCS
On 17/11/2010 21:27, Jérôme M. Berger wrote: Bruno Medeiros wrote: But what exactly is that data corruption issue on Windows? In some cases (I didn't try to isolate the precise conditions), Git will replace '\n' with '\r\n' in binary files. This is with the default config. It might be possible to change the configuration so that this won't happen, but the simple fact that this happens with the *default* config does not fill me with confidence regarding data integrity and Git... Jerome Hum, my impression is that Git is actually pretty mindful about data integrity, not just on history, but on commits as well. However, it also seems like Git was designed with Linux in mind, so Git on Windows is kinda like a second-class platform (for example, performance is apparently lower on Windows). But hopefully that will improve on the future. The comments above made tip my preference slightly over to Mercurial. But I think ultimately the decision of whether I would use Mercurial or Git would be decided more by external factors, like the quality of IDE-integrated tools (read: Eclipse plugins), and the availability or preference of those DVCS in hosting-sites/organizations. For example Google Code only supports Mercurial. On the other hand the Eclipse Foundation is moving their repositories to Git. (if it wasn't for that I'd likely have gone with Mercurial and not looked back on Git) -- Bruno Medeiros - Software Engineer
Re: [OT] DVCS
On 11/18/10 8:20 PM, Jérôme M. Berger wrote: Performance was actually horrendous on windows last year, not just lower. That's what you say. I say that I've been happily using Git on Windows for over two years without noticing any performance problems. Now what?
Re: [OT] DVCS
klickverbot wrote: On 11/18/10 8:18 PM, Jérôme M. Berger wrote: It deserves the label data corruption since Git did the conversion when committing the file, which means that the version stored in the history was corrupted. Okay, so you I guess you were pretty unlucky since after you turned the feature on, Git promptly misdetected one of your files, and you didn't notice that when you committed your changes – if you had looked at the diff for whatever reason, you would have probably noticed that something is wrong (I have this habit of briefly looking what I am checking in, but that's probably from my SVN-based OSS work). One of the point here is that I didn't turn the feature on. It was turned on by default. Moreover, the first time it happened, I was importing data from SVN so I didn't look at all the diffs (the next time it happened, I was adding a new file, so I didn't go through the whole diff and didn't notice the difference). In any case, you might be interested in the fact that Mercurial seems to have real issues with data corruption on Windows, see for example the following reports: http://serverfault.com/questions/91681/mercurial-repository-corruption http://stackoverflow.com/questions/2563178/corrupt-mercurial-repository-cannot-update Well, at least the second one looks like the user removed some files from the .hg repository (by recursively removing all files whose name fit a certain pattern). This kind of mistake would affect Git too (or any system where the repository is located alongside the sources). Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [OT] DVCS
klickverbot wrote: On 11/18/10 8:20 PM, Jérôme M. Berger wrote: Performance was actually horrendous on windows last year, not just lower. That's what you say. I say that I've been happily using Git on Windows for over two years without noticing any performance problems. Now what? Well, I went back to the message I posted at the time (on June 6 2009 in digitalmars.D) and I need to amend that: git clone performance is horrendous (more than 4 times slower than Mercurial). Other commands are generally slightly slower than Mercurial but acceptable, except import from SVN which took several hours for Git and 5min for Mercurial (but that is not too important since you don't import from SVN every day, clone performance is a lot more problematic IMO). Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [OT] DVCS
Jérôme M. Berger wrote: Well, I went back to the message I posted at the time (on June 6 2009 in digitalmars.D) Sorry, that should read on June *3*. The thread subject was Re: Source control for all dmd source (Git propaganda =) if you want to look it up. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [OT] DVCS
add + commit is not a bad design at all. It is just design choice, and it also about patch control system, that allows more logical commit history and more precise control over VCS. It allows to code all things you want and place into commit only part of your changes. You even can stage part of file - if, for example, you done two logically different changes without commit between them. May be, good analogy will be reading file with one command versus open-read-close sequence - simplicity versus good control. This feature allows very comfortable, free coding style - you write what you want ad understand now, and later you can divide your changes to logically related sets. You do not controlled by limits imposed by VCS - work on one feature, commit, work on another. Instead VCS works in your style and rhythm. Usually you don't want run commit -a. Instead when you run git status you see several files that you do not want to commit right now. So you use add + commit sequence, may be - several times to commit different changesets as distinct entities with distinct comments. I think it's very good point of view - to track not file versions, patchsets that represent something meaningful - new features, bugfixes etc, and have VCS follow your practices and rhythm - and have understandable version tree at the end.
Re: [OT] DVCS
Alexey Khmara wrote: add + commit is not a bad design at all. It is just design choice, and it also about patch control system, that allows more logical commit history and more precise control over VCS. It allows to code all things you want and place into commit only part of your changes. You even can stage part of file - if, for example, you done two logically different changes without commit between them. May be, good analogy will be reading file with one command versus open-read-close sequence - simplicity versus good control. This feature allows very comfortable, free coding style - you write what you want ad understand now, and later you can divide your changes to logically related sets. You do not controlled by limits imposed by VCS - work on one feature, commit, work on another. Instead VCS works in your style and rhythm. Usually you don't want run commit -a. Instead when you run git status you see several files that you do not want to commit right now. So you use add + commit sequence, may be - several times to commit different changesets as distinct entities with distinct comments. I think it's very good point of view - to track not file versions, patchsets that represent something meaningful - new features, bugfixes etc, and have VCS follow your practices and rhythm - and have understandable version tree at the end. This has nothing to do with Git's staging area. Mercurial also tracks patchsets that represent something meaningful and has full support for partial commits (with record or crecord) so you can write what you want and understand now, and later [...] divide your changes to logically related sets. On the other hand, you are not forced into this model when you know you have only worked on a single feature and want to commit it. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [OT] DVCS
On 11/17/10 10:32 PM, Jérôme M. Berger wrote: […] you are not forced into this model when you know you have only worked on a single feature and want to commit it. You are not forced to use the staging area with Git either (although most of the developers I know do use it), it's just the default that is different. If you want to save the extra characters per commit, just add an alias like »ci = commit -a« to your ~/.gitconfig, just like you might want to use »nudge = push --rev .« with Mercurial…
Re: [OT] DVCS
On 11/17/10 10:27 PM, Jérôme M. Berger wrote: […]It might be possible to change the configuration so that this won't happen, but the simple fact that this happens with the *default* config does not fill me with confidence regarding data integrity and Git... This is not exactly true, at least not for the Git on Windows installer, which presents you with the three possible choices for handling line endings. Also, I am not quite sure if this deserves the label »data corruption«, because even if you have auto-conversion of line endings turned on and Git fails to auto-detect a file as binary, no history data is corrupted and you can fix the problem by just switching off auto-conversion (either globally or just for the file in question via gitattributes) – in contrast to actual history/database corruption.
Re: [OT] DVCS
Gour wrote: On Sat, 13 Nov 2010 12:24:58 +0100 Jérôme == jeber...@free.fr wrote: Jérôme 3. Git is not a VCS so much as a PMS (Patch Management Jérôme System).The difference is in the way each views history: for a Jérôme VCS, history is important in and of itself, whereas for a PMS Jérôme like Git history is just something you keep to help you merge Jérôme branches. I agree (coming from darcs world) and just switched to Fossil which is very nice keeping 'artifacts' immutable. Something for D. :-) Nice, I didn't know about Fossil. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [OT] DVCS
Bruno Medeiros wrote: Well, yes, it is every-times with regards to having to add the extra commit option. But it is just 3 extra characters, and I'm guessing it is quite easy to remember every time (maybe a little bit less if you use different VCS often, yeah). I'm not saying git would not be better designed if -a was the default, just that it's a very unimportant in terms of comparing VCS's. (It matters even less to my usage of VCS, since almost always I use Eclipse's graphical interface, which has a common behavior for the basic operations in all popular VCS. :) ) Like I said, it is a pretty minor issue in and of itself. Its importance is as a symptom of how poorly designed the interface is in general. My main objections to Git are in order of importance: 1. Data corruption on Windows. That one is the killer issue; 2. Poor interface by design! The -a option is in this category, but it is not the only issue there by far. Most of those issues taken individually would be pretty minor, but added together they make Git very uncomfortable to work with; 3. Git is not a VCS so much as a PMS (Patch Management System). The difference is in the way each views history: for a VCS, history is important in and of itself, whereas for a PMS like Git history is just something you keep to help you merge branches. Git's much touted history rewriting abilities are more a liability than an asset for a VCS. In a roundabout way, this is why most Git users view the -a issue as negligible: if you forget part of a commit, just commit the missing changes and collapse the two changesets (which is easy since we don't care about history anyway). Points 1 and 2 are real issues. That is, they are intrinsically negative points. Point 3 is more a difference between Git and everything else, so it will be negative or neutral (*) depending on what exactly you expect from a SCM. Jerome (*) I wrote neutral instead of positive, because IMO Mercurial offers similar abilities as a PMS if that is all you want. -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [OT] DVCS
On Sat, 13 Nov 2010 12:24:58 +0100 Jérôme == jeber...@free.fr wrote: Jérôme 3. Git is not a VCS so much as a PMS (Patch Management Jérôme System).The difference is in the way each views history: for a Jérôme VCS, history is important in and of itself, whereas for a PMS Jérôme like Git history is just something you keep to help you merge Jérôme branches. I agree (coming from darcs world) and just switched to Fossil which is very nice keeping 'artifacts' immutable. Something for D. :-) Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: [OT] DVCS
On 10/11/2010 10:20, Jérôme M. Berger wrote: Bruno Medeiros wrote: On 28/10/2010 18:51, Jérôme M. Berger wrote: Bruno Medeiros wrote: But isn't the staging area similar, if not identical to SVN? I mean, in svn you also have to do a command svn add to add new files to the sandbox. They won't get commit otherwise, right? (note: im somewhat familiar with SVN and Git, but not with Mercurial) No, because in Git if you make changes to an existing file, you need to add that file again. In both SVN or Mercurial, you need to add new files, but once a file is in the repository, any changes to the file get committed by default (although there are ways to commit only some files in both Mercurial and SVN and ways to commit only some changes in Mercurial). Jerome I see. Well, it's not identical then, but still, it seems very similar, since one can use git commit -a to do the same as svn commit, isn't that so? I mean, is there any aspect to Git's staging area that makes git commit -a not be equivalent to svn commit ? (obviously for this question interactions with Git-only features should not be considered) My confusion here stems not so much from the discussion in this thread, but from another discussion elsewhere on the web (not D related) where I also saw a developer comment that Git's staging index default behavior was more complex that necessary, and that it should be the simple thing by default. There was an implication, from the way he said it, that this was an issue of at least medium importance. However, from my understanding, in the whole landscape of version control issues and comparisons, this one seems of very low importance, if not borderline irrelevance. Because even if a developer using Git shoots himself in the foot with this... it will be only *once*, on the learning phase. After that you'd know and remember to use git commit -a so the mistake would not be repeated. A /one-time issue/ cannot possibly be anywhere near in importance than a /many-times issue/. Ah, but it is a many-times issue. It is even an every-times issue. The problem here is that you need to remember to add the appropriate option each and every time you want to commit. Proper interface design would be to have the common usage be the default and have an option to enable the complex usage (especially for the most common command). Additionally this makes it a lot more difficult to move back and forth between several systems: imagine if all VCSes required special options to do a simple commit, now each time you want to commit, you need to remember whether this particular VCS requires an option and which option you need to add to get the simple behaviour. Moreover, this is just the tip of the iceberg. The whole git UI is designed like that and full of small irritations and inconsistencies. Jerome Well, yes, it is every-times with regards to having to add the extra commit option. But it is just 3 extra characters, and I'm guessing it is quite easy to remember every time (maybe a little bit less if you use different VCS often, yeah). I'm not saying git would not be better designed if -a was the default, just that it's a very unimportant in terms of comparing VCS's. (It matters even less to my usage of VCS, since almost always I use Eclipse's graphical interface, which has a common behavior for the basic operations in all popular VCS. :) ) -- Bruno Medeiros - Software Engineer
Re: [OT] DVCS
Bruno Medeiros wrote: On 28/10/2010 18:51, Jérôme M. Berger wrote: Bruno Medeiros wrote: But isn't the staging area similar, if not identical to SVN? I mean, in svn you also have to do a command svn add to add new files to the sandbox. They won't get commit otherwise, right? (note: im somewhat familiar with SVN and Git, but not with Mercurial) No, because in Git if you make changes to an existing file, you need to add that file again. In both SVN or Mercurial, you need to add new files, but once a file is in the repository, any changes to the file get committed by default (although there are ways to commit only some files in both Mercurial and SVN and ways to commit only some changes in Mercurial). Jerome I see. Well, it's not identical then, but still, it seems very similar, since one can use git commit -a to do the same as svn commit, isn't that so? I mean, is there any aspect to Git's staging area that makes git commit -a not be equivalent to svn commit ? (obviously for this question interactions with Git-only features should not be considered) My confusion here stems not so much from the discussion in this thread, but from another discussion elsewhere on the web (not D related) where I also saw a developer comment that Git's staging index default behavior was more complex that necessary, and that it should be the simple thing by default. There was an implication, from the way he said it, that this was an issue of at least medium importance. However, from my understanding, in the whole landscape of version control issues and comparisons, this one seems of very low importance, if not borderline irrelevance. Because even if a developer using Git shoots himself in the foot with this... it will be only *once*, on the learning phase. After that you'd know and remember to use git commit -a so the mistake would not be repeated. A /one-time issue/ cannot possibly be anywhere near in importance than a /many-times issue/. Ah, but it is a many-times issue. It is even an every-times issue. The problem here is that you need to remember to add the appropriate option each and every time you want to commit. Proper interface design would be to have the common usage be the default and have an option to enable the complex usage (especially for the most common command). Additionally this makes it a lot more difficult to move back and forth between several systems: imagine if all VCSes required special options to do a simple commit, now each time you want to commit, you need to remember whether this particular VCS requires an option and which option you need to add to get the simple behaviour. Moreover, this is just the tip of the iceberg. The whole git UI is designed like that and full of small irritations and inconsistencies. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [OT] DVCS
On 28/10/2010 18:51, Jérôme M. Berger wrote: Bruno Medeiros wrote: But isn't the staging area similar, if not identical to SVN? I mean, in svn you also have to do a command svn add to add new files to the sandbox. They won't get commit otherwise, right? (note: im somewhat familiar with SVN and Git, but not with Mercurial) No, because in Git if you make changes to an existing file, you need to add that file again. In both SVN or Mercurial, you need to add new files, but once a file is in the repository, any changes to the file get committed by default (although there are ways to commit only some files in both Mercurial and SVN and ways to commit only some changes in Mercurial). Jerome I see. Well, it's not identical then, but still, it seems very similar, since one can use git commit -a to do the same as svn commit, isn't that so? I mean, is there any aspect to Git's staging area that makes git commit -a not be equivalent to svn commit ? (obviously for this question interactions with Git-only features should not be considered) My confusion here stems not so much from the discussion in this thread, but from another discussion elsewhere on the web (not D related) where I also saw a developer comment that Git's staging index default behavior was more complex that necessary, and that it should be the simple thing by default. There was an implication, from the way he said it, that this was an issue of at least medium importance. However, from my understanding, in the whole landscape of version control issues and comparisons, this one seems of very low importance, if not borderline irrelevance. Because even if a developer using Git shoots himself in the foot with this... it will be only *once*, on the learning phase. After that you'd know and remember to use git commit -a so the mistake would not be repeated. A /one-time issue/ cannot possibly be anywhere near in importance than a /many-times issue/. -- Bruno Medeiros - Software Engineer
Re: [OT] DVCS
On Wed, 27 Oct 2010 23:08:02 +0300 Vladimir == vladi...@thecybershadow.net wrote: Vladimir As you can see, in many places Git is the antithesis to the Vladimir Make correct and common things easy, make shooting yourself Vladimir in the foot hard principle. However, I don't think this is a Vladimir reason not to use Git for a public project. What about 'choice' or maybe we should move to the OS used by majority of people where re-installation is very common troubleshooting procedure? ;) Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: [OT] DVCS
On Wed, 2010-10-27 at 12:02 +0300, Vladimir Panteleev wrote: On Mon, 25 Oct 2010 21:42:32 +0300, Russel Winder rus...@russel.org.uk wrote: On Mon, 2010-10-25 at 10:20 -0700, Bill Baxter wrote: I'm not a huge fan of Bazaar :-p , Hummm... May I ask why? Could someone please explain to me why is a VCS other than the three big ones (SVN, Git and HG) is worth using for an open-source project such as this? Because it is good. Because there are four major players in the game, including Bazaar. I have never used Bazaar, DARCS and Monotone, and only briefly used HG, and I acknowledge that they may be better than Git in some aspects. They are, but the problem is that currently there is no scientific and objective data, all views on this are opinion and adherence to either fashion or tribalism. However, IMHO, one of the main decisions for a VCS for a public project is its accessibility. SVN is the most popular one, but it's pretty established that SVN isn't anywhere as productive as DVCSes, and obviously it can't be used in a distributed manner. The only sensible use for Subversion in a FOSS project is not to use it. Bazaar, Mercurial and Git are the VCS tools for FOSS projects. Why? Because DVCS aligns with the principles of FOSS. Subversion is all about creating an elite priesthood. Subversion is fine is a context where the entire developer population have access and are permanently connected to the Internet and are only allowed to work when so connected -- i.e. in companies where no working outside the boundary fence is allowed. But the FOSS community has outgrown the Subversion model. If I'd consider contributing to an open-source project using a VCS I'm unfamiliar with, it's quite likely that I'd get turned off by the hurdle of downloading, installing and learning to use the respective VCS. It's not the downloading that is the problem so much as the unfamiliar with. Russel wrote in another, unrelated thread: Of course using BitBucket or Launchpad may well be more likely to get support as Mercurial and Bazaar are so much more usable that Git. I'm sorry, but to me that sounds like a biased personal opinion stated as if it was an objective fact :( I seriously doubt that any project would get more support if it used an obscure (albeit possibly better in some ways) DVCS, unless the intended audience for the project's contributors is already familiar with that DVCS. Maybe Bazaar etc. is more popular with EMACS users/hackers? I'll accept that there is an element of personal opinion -- I believe that Git is over-complicated both in operational model and command line. Bazaar and Mercurial beat Git hand down in my usability. As noted above no-one to date has objective data so all statements on this are opinion. This includes your view on Git :-) I wouldn't say Bazaar was more popular with the Emacs developers, there was a huge row about it and there are still rumblings. However Bazaar is the official VCS for Emacs. Also, I think that it's pretty hard to beat the workflow that GitHub facilitates for open-source projects (with one-click forking and pull requests). For personal individual working GitHub is fine. However, as far as I know, it has no notion of team. Launchpad has both the notion of personal and of team. For uncontrolled FOSS this perhaps doesn't matter, but it makes it a lot easier to actually emulate the high priest elite that many project like to have. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: [OT] DVCS
On Wed, 2010-10-27 at 12:56 +0300, Vladimir Panteleev wrote: [ . . . ] It's not really about Git, it's about GitHub: Actually, it is about your use model of GitHub. 1. Repo creation is instant, doesn't need to go through a human approval process, etc. (big turn-off from DSource, SourceForge as I create and work on many small projects) Any FOSS project allows this, you just want to use a hosting site. Launchpad and BitBucket behave like GitHub in this respect -- I don't know about Gitorious but I suspect it is the same. 2. One-click forking - self-explanatory, you get a cheap clone of a project in your own namespace, to which you can push to to instantly publish your changes. And the difference with others -- except the one-click being replaced by a command line? 3. Pull requests - pretty self-explanatory, but integrated with the issue system. Personal workflow, the model is not special. 4. You've probably seen one of GitHub's network chart? ( e.g.: http://github.com/jquery/jquery/network ) You can instantly see activity of all of the project's forks on GitHub. This allows easily finding nice forks to merge / cherry-pick. If you're lazy, you don't even need to send your patches upstream - as long as you don't change the license, the project maintainers can cherry-pick from your fork as long as you push them to your fork. Personally, I think this feature is revolutionary, and quite hard to beat compared to the oldschool approach of mailing lists etc. ;) GitHub has other nice things, such as line-level commit comments, as well as the usual things you'll find in many other open-source project hosters (issues, wiki, HTML project homepage). And finally, IMHO a pretty convincing argument is that GitHub is one of the most popular open-source hosting websites. Not having to register and familiarize yourself with a project hosting website lowers the contribution barrier even lower. I quite like GitHub for when I use Git, but I like Launchpad for when I use Bazaar, or BitBucket for Mercurial -- and of course I host things on my own server, which means Bazaar or Mercurial or sometimes Git. It more about what the group of activists on a project choose to use, there are no absolutes. Git and GitHub are not special in any of the above points. DVCS and hosting is the underlying model and all the above mentioned have the basic model. Everything else is really just little things. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: [OT] DVCS
On Thu, 28 Oct 2010 08:54:31 +0100 Russel == Russel Winder wrote: Russel Moving to any of Bazaar, Mercurial or Git would be a huge step Russel forward for any FOSS project currently using Subversion. +1 Russel Monotone and Darcs would be a big risk because Bazaar, Russel Mercurial and Git are the main players. I agree...I just mentioned them since I am using them for personal stuff. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: [OT] DVCS
On 27/10/2010 22:33, Jérôme M. Berger wrote: Well, Mercurial offers much less opportunities to shoot oneself in the foot and is much easier to use. This is especially true if you come from another VCS like SVN: you can use the same commands for the same results on the local repository and you only need to learn a couple of commands for syncing. Git uses different commands for everything (this is actually a stated design goal: try to make things as different from CVS as possible!) The only true advantage that Git has over Mercurial is the staging area, and even that is a two edged sword: IMO it should not be enabled by default since it helps people to lose data. And the same functionality can be emulated (and superseded) in Mercurial with record and mq anyway. But isn't the staging area similar, if not identical to SVN? I mean, in svn you also have to do a command svn add to add new files to the sandbox. They won't get commit otherwise, right? (note: im somewhat familiar with SVN and Git, but not with Mercurial) -- Bruno Medeiros - Software Engineer
Re: [OT] DVCS
Vladimir Panteleev wrote: On Thu, 28 Oct 2010 00:33:54 +0300, Jérôme M. Berger jeber...@free.fr wrote: The only true advantage that Git has over Mercurial is the staging area, and even that is a two edged sword: IMO it should not be enabled by default since it helps people to lose data. And the same functionality can be emulated (and superseded) in Mercurial with record and mq anyway. Could you please explain to me how can the staging area cause you to lose data? The only way I see that can happen is if you forget that you staged some changes, then do git diff and think that your working directory (and index) are clean. git commit git push # Is that the right command to send my changes # to the main repo? # OK, I'm done working on that cd .. rm -r myrepo # Ooops - It is safer on Windows: in six years, I have never had a data loss or corruption, whereas I've had both with Git in a two days test without doing anything special; Sorry, I don't consider this to be true at the moment based on my experience. - Repositories are smaller on Windows (ok, that's not so important given the price of HDDs today); How does that make sense? Doesn't Git use the same disk storage format everywhere? :o I meant Mercurial repositories are smaller than Git repositories on Windows (didn't check anywhere else) - You really, really, really *always* need the staging area so you want to have it by default instead of using mq. If that is the case, you will probably wind up using quilt anyway (quilt is the Git equivalent for mq). I think the staging area is an amazing feature, and I use it all the time, but perhaps not in the way you imagine: 1) Hack up a bunch of changes 2) Fire up git gui 3) Quickly stage the chucks or lines you want to go into the first commit (one case where using a mouse-driven GUI is way more productive...) 4) Type commit description, Ctrl+Enter to instantly commit 5) Repeat, until working directory is clean This allows me to work freely on my code and edit different parts of it, without having to worry that I should first commit / shelve unrelated changes first. This workflow is fully supported by the crecord extension (or by TortoiseHg). Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [OT] DVCS
Bruno Medeiros wrote: On 27/10/2010 22:33, Jérôme M. Berger wrote: Well, Mercurial offers much less opportunities to shoot oneself in the foot and is much easier to use. This is especially true if you come from another VCS like SVN: you can use the same commands for the same results on the local repository and you only need to learn a couple of commands for syncing. Git uses different commands for everything (this is actually a stated design goal: try to make things as different from CVS as possible!) The only true advantage that Git has over Mercurial is the staging area, and even that is a two edged sword: IMO it should not be enabled by default since it helps people to lose data. And the same functionality can be emulated (and superseded) in Mercurial with record and mq anyway. But isn't the staging area similar, if not identical to SVN? I mean, in svn you also have to do a command svn add to add new files to the sandbox. They won't get commit otherwise, right? (note: im somewhat familiar with SVN and Git, but not with Mercurial) No, because in Git if you make changes to an existing file, you need to add that file again. In both SVN or Mercurial, you need to add new files, but once a file is in the repository, any changes to the file get committed by default (although there are ways to commit only some files in both Mercurial and SVN and ways to commit only some changes in Mercurial). Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [OT] DVCS
git and gui? Come on... Have you seen this: http://www.syntevo.com/smartgit/index.html ?
Re: [OT] DVCS
On Wed, 27 Oct 2010 13:58:56 +0300, Gour g...@atmarama.net wrote: I believe you didn't try much of the competition like Launchpad, Bitbucket, Gitorious etc. You're right, I haven't used them for my own projects, but I did look at them briefly. What you are describing is neither very special nor specific to Github. I must be blind - I just looked at all of the hosting solutions you mentioned, and this is what I saw: Launchpad: Looking at https://launchpad.net/bzr I see absolutely no mention of branching/forking. Bitbucket: http://bitbucket.org/tortoisehg/stable/descendants shows an unformatted, almost-unreadable list of forks. Gitorious: http://qt.gitorious.org/qt/repositories takes forever to load, and when it does it shows a list of widgets for each fork, with no useful information except the name of the repository (usually username~-~projectname). -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: [OT] DVCS
On Wed, 27 Oct 2010 14:36:47 +0300 Vladimir == vladi...@thecybershadow.net wrote: Vladimir Launchpad: Looking at https://launchpad.net/bzr I see Vladimir absolutely no mention of branching/forking. Try https://code.launchpad.net/bzr Vladimir Bitbucket: http://bitbucket.org/tortoisehg/stable/descendants Vladimir shows an unformatted, almost-unreadable list of forks. Well, it's question of bitbucket's interface, nothing about git. Vladimir Gitorious: http://qt.gitorious.org/qt/repositories takes Vladimir forever to load, and when it does it shows a list of widgets Vladimir for each fork, with no useful information except the name of Vladimir the repository (usually username~-~projectname). Ditto. Otoh, when I have to choose DVCS, then I primarily look at its VCS features and not so much about features of the public hosting which is of secondary concern. However, considering that there are no darcs solutions for public hosting, I've decided to use Monotone (with indefero.net) instead. Still, github with it's non-beatable workflow is not enough to persuade me to use Git 'cause I'll work more with the DVCS than with it's hosting UI. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: [OT] DVCS
On Wed, 27 Oct 2010 16:07:52 +0300, Gour g...@atmarama.net wrote: Try https://code.launchpad.net/bzr Ah, that's quite nice. Well, it's question of bitbucket's interface, nothing about git. And I wasn't talking about Git by itself. If you look at http://whygitisbetterthanx.com/ , GitHub is listed as one of the major reasons. Otoh, when I have to choose DVCS, then I primarily look at its VCS features and not so much about features of the public hosting which is of secondary concern. However, considering that there are no darcs solutions for public hosting, I've decided to use Monotone (with indefero.net) instead. Still, github with it's non-beatable workflow is not enough to persuade me to use Git 'cause I'll work more with the DVCS than with it's hosting UI. While I agree that it doesn't really matter what anyone uses for personal projects, I wouldn't choose anything non-mainstream for an open-source project where community involvement is important. For example, I think that moving DMD/Phobos/DRuntime from SVN to Bazaar/Monotone/DARCS would be a very bad idea (and I think that GitHub's featureset would fit D's community perfectly). -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: [OT] DVCS
Vladimir Panteleev wrote: While I agree that it doesn't really matter what anyone uses for personal projects, I wouldn't choose anything non-mainstream for an open-source project where community involvement is important. For example, I think that moving DMD/Phobos/DRuntime from SVN to Bazaar/Monotone/DARCS would be a very bad idea (and I think that GitHub's featureset would fit D's community perfectly). OTOH, Bazaar *is* one of the mainstream DVCSs (along with SVN, Mercurial and Git). Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [OT] DVCS
On 10/27/10 7:09 PM, Gour wrote: Otoh, Git […] stands too much on the way […] Could you give any examples for this? While I can understand people who think that the raw power Git makes it too easy to shoot yourself in the foot (I personally don't think so, but that's a different topic), I guess I don't really see how it would stand in your way, given that you can do everything you need by just chaining together a few well-known commands…
Re: [OT] DVCS
On 10/27/10 7:40 PM, Jérôme M. Berger wrote: OTOH, Bazaar *is* one of the mainstream DVCSs (along with SVN, Mercurial and Git). I guess it's not really representative (nor scientific, of course), but here are a few numbers: http://stackoverflow.com/questions/995636/popularity-of-git-mercurial-bazaar-vs-which-to-recommend http://www.ohloh.net/repositories/compare
Re: [OT] DVCS
On Wed, 27 Oct 2010 20:37:58 +0200 klickverbot == klickverbot wrote: klickverbot I guess it's not really representative (nor scientific, of klickverbot course), but here are a few numbers: Ahh, statistics...I'm the one in 5.14% minority class: http://tinyurl.com/y5bzcfh :-) Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: [OT] DVCS
On Wed, 27 Oct 2010 21:37:58 +0300, klickverbot s...@klickverbot.at wrote: http://www.ohloh.net/repositories/compare Woah! I knew Hg's user base was smaller than Git's, but I never expected the difference to be so huge. That removes any doubt I had whether to consider Hg for any of my own projects. Another page with interesting statistics: http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities#Popularity GitHub trumps pretty much everything. Its project count probably includes forks, though - but I wouldn't be surprised if it wasn't, considering how easy it is to just put anything on GitHub. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: [OT] DVCS
Vladimir Panteleev wrote: On Wed, 27 Oct 2010 21:37:58 +0300, klickverbot s...@klickverbot.at wrote: http://www.ohloh.net/repositories/compare Woah! I knew Hg's user base was smaller than Git's, but I never expected the difference to be so huge. That removes any doubt I had whether to consider Hg for any of my own projects. However, count on having trouble if you plan to use git on Windows (including data loss and data corruption)... Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [OT] DVCS
Gour wrote: Moreover, I believe that Git is over-hyped mostly due to its performance and I prefer design over raw speed. Actually, I believe git is over-hyped because it was initially written by someone named Linus Torvalds (never mind that he himself called it a dirty hack thrown together in an afternoon and most emphatically *not* a version control system). Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [OT] DVCS
On Wed, 27 Oct 2010 22:54:59 +0300, Jérôme M. Berger jeber...@free.fr wrote: However, count on having trouble if you plan to use git on Windows (including data loss and data corruption)... I use Git on Windows. Never had any problems. :D Yes, I know Git was bad on Windows. Was :) -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: [OT] DVCS
On Wed, 27 Oct 2010 21:18:43 +0300, klickverbot s...@klickverbot.at wrote: On 10/27/10 7:09 PM, Gour wrote: Otoh, Git […] stands too much on the way […] Could you give any examples for this? While I can understand people who think that the raw power Git makes it too easy to shoot yourself in the foot (I personally don't think so, but that's a different topic), I guess I don't really see how it would stand in your way, given that you can do everything you need by just chaining together a few well-known commands… Although (as you might have noticed) I prefer Git, I can answer your question. Examples: * The innocent-sounding checkout command will irreversibly destroy your work (it's especially destructive if you pass it the name of a directory) * Operations such as undoing your last commit are too cryptic (git reset --hard HEAD^) * Branch commands are clumsy (creating and switching to a new branch in one command, setting up a tracking branch) * Pushing requires verbose commands (specifying the remote and branch name), unless you configure the default remote for the current branch As you can see, in many places Git is the antithesis to the Make correct and common things easy, make shooting yourself in the foot hard principle. However, I don't think this is a reason not to use Git for a public project. The thing is, if you're an open-source developer with some experience, you'll already know how to use Git - due to the overwhelming amount of open-source projects already using it. Once you get used to the above-mentioned problems (and maybe set up some aliases to work around them), there really isn't much reason to learn another DVCS for the sake of a few of Git's shortcomings. I think that sooner or later, like with most active open-source projects, the major DVCS implementations (including Git) will converge to a high level of stability and usability (git was much harder to use in the past, so I don't see why the above-mentioned problems won't be fixed in future major versions as well). At that point there'll be fewer factors to take into account when choosing a VCS: design, performance(?) and, of course, popularity. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: [OT] DVCS
Vladimir Panteleev wrote: On Wed, 27 Oct 2010 22:54:59 +0300, Jérôme M. Berger jeber...@free.fr wrote: However, count on having trouble if you plan to use git on Windows (including data loss and data corruption)... I use Git on Windows. Never had any problems. :D Yes, I know Git was bad on Windows. Was :) Last year, someone convinced me to give git another chance on Windows with the same argument (was bad, made a lot of progress, is now very good). My conclusion was: was *very* bad, made a lot of progress, still a long way to go before I would consider it usable on windows. Anyway, I don't see any point in using Git since Mercurial can sync just fine with a Git repository :) Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [OT] DVCS
On Wed, 27 Oct 2010 23:08:02 +0300, Vladimir Panteleev vladi...@thecybershadow.net wrote: * Operations such as undoing your last commit are too cryptic (git reset --hard HEAD^) Sorry, that's probably a bad example, since it alters history (if you already pushed the current commit it'll cause problems). The problem with Git is that you really need to know what you're doing and how things work behind the scenes - the learning curve is pretty steep, however once you're over it you'll feel like King of the Hill compared to other DVCSes :) -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: [OT] DVCS
On Wed, 27 Oct 2010 23:29:02 +0300, Jérôme M. Berger jeber...@free.fr wrote: Last year, someone convinced me to give git another chance on Windows with the same argument (was bad, made a lot of progress, is now very good). My conclusion was: was *very* bad, made a lot of progress, still a long way to go before I would consider it usable on windows. I started using Git in October 2009, so I probably missed the bad times. Anyway, I don't see any point in using Git since Mercurial can sync just fine with a Git repository :) Well, the topic at hand was which VCS to use for an open-source project. Using your argument, there is no reason to use Mercurial over Git, because Mercurial users can sync just fine with Git repositories :) -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: [OT] DVCS
Gour g...@atmarama.net wrote in message news:20101027210750.61681...@atmarama.noip.me... Ahh, statistics...I'm the one in 5.14% minority class: http://tinyurl.com/y5bzcfh Readable version of the link: http://www.netmarketshare.com/os-market-share.aspx?qprid=11 Wow, I had no idea I was in such a large majority by sticking to XP over Win7 (I *really* don't like Win7 compared to XP). Then again, maybe that gap is just from a bunch of major corporations not getting around to switching just yet?
Re: [OT] DVCS
Vladimir Panteleev wrote: Anyway, I don't see any point in using Git since Mercurial can sync just fine with a Git repository :) Well, the topic at hand was which VCS to use for an open-source project. Using your argument, there is no reason to use Mercurial over Git, because Mercurial users can sync just fine with Git repositories :) Well, Mercurial offers much less opportunities to shoot oneself in the foot and is much easier to use. This is especially true if you come from another VCS like SVN: you can use the same commands for the same results on the local repository and you only need to learn a couple of commands for syncing. Git uses different commands for everything (this is actually a stated design goal: try to make things as different from CVS as possible!) The only true advantage that Git has over Mercurial is the staging area, and even that is a two edged sword: IMO it should not be enabled by default since it helps people to lose data. And the same functionality can be emulated (and superseded) in Mercurial with record and mq anyway. So, why use Mercurial? - It is safer to work with: make a change, commit, your change is in the repository. With git, you need to add your change before committing (or remember to use the correct option when committing, -a IIRC); - It is easier to use when you come from another VCS (and even when you do not: try to figure out from the Git doc how to revert a change you've made but not yet committed); - It is safer on Windows: in six years, I have never had a data loss or corruption, whereas I've had both with Git in a two days test without doing anything special; - It is faster on Windows (not by much for most operations, but sometimes spectacularly so); - Repositories are smaller on Windows (ok, that's not so important given the price of HDDs today); - If you are already a Python user, it is only a very small package to add whereas Git installs a lot of cruft that you won't be able to use anyway even if you wanted to. Why use Git? - You know someone who uses it and will be able to guide you through all the pitfalls; - You really, really, really *always* need the staging area so you want to have it by default instead of using mq. If that is the case, you will probably wind up using quilt anyway (quilt is the Git equivalent for mq). Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [OT] DVCS
On Thu, 28 Oct 2010 00:33:54 +0300, Jérôme M. Berger jeber...@free.fr wrote: The only true advantage that Git has over Mercurial is the staging area, and even that is a two edged sword: IMO it should not be enabled by default since it helps people to lose data. And the same functionality can be emulated (and superseded) in Mercurial with record and mq anyway. Could you please explain to me how can the staging area cause you to lose data? The only way I see that can happen is if you forget that you staged some changes, then do git diff and think that your working directory (and index) are clean. - It is safer on Windows: in six years, I have never had a data loss or corruption, whereas I've had both with Git in a two days test without doing anything special; Sorry, I don't consider this to be true at the moment based on my experience. - Repositories are smaller on Windows (ok, that's not so important given the price of HDDs today); How does that make sense? Doesn't Git use the same disk storage format everywhere? :o - You know someone who uses it and will be able to guide you through all the pitfalls; For the record, I wish I had found this earlier: http://eagain.net/articles/git-for-computer-scientists/ For a long time I was confused about what branches and tags really are. - You really, really, really *always* need the staging area so you want to have it by default instead of using mq. If that is the case, you will probably wind up using quilt anyway (quilt is the Git equivalent for mq). I think the staging area is an amazing feature, and I use it all the time, but perhaps not in the way you imagine: 1) Hack up a bunch of changes 2) Fire up git gui 3) Quickly stage the chucks or lines you want to go into the first commit (one case where using a mouse-driven GUI is way more productive...) 4) Type commit description, Ctrl+Enter to instantly commit 5) Repeat, until working directory is clean This allows me to work freely on my code and edit different parts of it, without having to worry that I should first commit / shelve unrelated changes first. Anyway, you make a convincing argument. I know that Hg's GUI tools are more mature than Git's Tcl/Tk hacks (the official versions saw no improvement since I started using Git), so it's worth looking at as a DVCS client. Bazaar's GUI looks pretty mature as well. (I dream of a day when I can cherry-pick by dragging and dropping commits, and rebasing by selecting a range of commits and dragging-and-dropping it on another branch. I don't think any Git GUIs have this.) -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: [OT] DVCS
On Thu, 28 Oct 2010 08:17:02 +0300 Vladimir == vladi...@thecybershadow.net wrote: Vladimir 2) Fire up git gui git and gui? Come on... Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: [OT] DVCS
On Thu, 28 Oct 2010 08:40:56 +0300, Gour g...@atmarama.net wrote: git and gui? Come on... Hey! I know git gui (and gitk) isn't the all-singing, all-dancing, command-line-shell-replacement (nor do I think that's even possible), but what it can do, it does well. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
