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
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?
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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.
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
git and gui? Come on...
Have you seen this: http://www.syntevo.com/smartgit/index.html ?
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
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:
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
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
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
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:
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
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
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
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
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 :)
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
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
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
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,
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
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
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
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
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,
43 matches
Mail list logo
