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.
Jero
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.
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 a
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
featur
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?
Bruno Medeiros wrote:
> 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, performan
klickverbot wrote:
> 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...
>
> T
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 b
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
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 defa
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 change
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
"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
On 13/11/2010 11:24, "Jérôme M. Berger" wrote:
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 o
Gour wrote:
> On Sat, 13 Nov 2010 12:24:58 +0100
>>> "Jérôme" == 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>
On Sat, 13 Nov 2010 12:24:58 +0100
>> "Jérôme" == 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
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 no
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
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?
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 SV
git and gui? Come on...
Have you seen this: http://www.syntevo.com/smartgit/index.html ?
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 res
Vladimir Panteleev wrote:
> On Thu, 28 Oct 2010 00:33:54 +0300, Jérôme M. Berger
> 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
On Thu, 28 Oct 2010 10:48:26 +0300, Russel Winder
wrote:
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.
I would expect nothing less. Human approval of
On Thu, 28 Oct 2010 15:45:08 +0300, 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 t
On Thu, 28 Oct 2010 10:40:03 +0300, Russel Winder
wrote:
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 easi
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 a
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 a
On Wed, 2010-10-27 at 17:25 +0300, Vladimir Panteleev wrote:
[ . . . ]
> 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
>
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, SourceF
On Wed, 2010-10-27 at 12:02 +0300, Vladimir Panteleev wrote:
> On Mon, 25 Oct 2010 21:42:32 +0300, Russel Winder
> 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 w
On Thu, 28 Oct 2010 09:26:32 +0300, Gour wrote:
What about 'choice' or maybe we should move to the OS used by majority
of people where re-installation is very common troubleshooting
procedure?
That's a bad analogy. A good analogy is writing software only for Linux,
because the major OS is s
On Wed, 27 Oct 2010 23:08:02 +0300
>> "Vladimir" == 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
On Thu, 28 Oct 2010 08:17:02 +0300
>> "Vladimir" == 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
On Thu, 28 Oct 2010 08:40:56 +0300, Gour 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,
Vladimir
On Thu, 28 Oct 2010 00:33:54 +0300, Jérôme M. Berger
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 emulat
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 Mer
"Gour" 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 maj
On Wed, 27 Oct 2010 23:29:02 +0300, Jérôme M. Berger
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
On Wed, 27 Oct 2010 23:08:02 +0300, Vladimir Panteleev
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
Vladimir Panteleev wrote:
> On Wed, 27 Oct 2010 22:54:59 +0300, Jérôme M. Berger
> 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 b
On Wed, 27 Oct 2010 22:57:39 +0300, Jérôme M. Berger
wrote:
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 Torv
On Wed, 27 Oct 2010 21:18:43 +0300, klickverbot 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 pers
On Wed, 27 Oct 2010 22:54:59 +0300, Jérôme M. Berger
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,
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
Vladimir Panteleev wrote:
> On Wed, 27 Oct 2010 21:37:58 +0300, klickverbot 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
On Wed, 27 Oct 2010 21:37:58 +0300, klickverbot 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
On Wed, 27 Oct 2010 20:18:43 +0200
>> "klickverbot" == klickverbot wrote:
klickverbot> Could you give any examples for this?
man git
It's simply too complex with huge command set which makes it too
difficult to understand what's going on 'under the hood'.
klickverbot> While I can understan
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
:-)
Sincer
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-gi
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 gu
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
> Baz
On Wed, 27 Oct 2010 16:07:52 +0300, Gour 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
o
On Wed, 27 Oct 2010 14:36:47 +0300
>> "Vladimir" == 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
Vladimi
On Wed, 27 Oct 2010 13:58:56 +0300, Gour 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
On Wed, 27 Oct 2010 12:56:51 +0300
>> "Vladimir" == "Vladimir Panteleev" wrote:
Vladimir> IIRC even those commands differ across these DVCSes.
In some details, yes.
Vladimir> Anyway, when you want to do something non-trivial
Vladimir> (branching/merging/history editing) you're forced to con
On Wed, 27 Oct 2010 12:31:49 +0300, Gour wrote:
I think that any capable developer can quickly grasp any of the
'standard' (bzr,hg,git,mtn) DVCS-es (darcs is a little bit different
considering it's patch-oriented) and can do:
dvcs init; dvcs pull; dvcs commit; dvcs push;
easily.
IIRC even tho
On Wed, 27 Oct 2010 12:02:06 +0300
>> "Vladimir" == wrote:
Vladimir> Could someone please explain to me why is a VCS other than
Vladimir> the three big ones (SVN, Git and HG) is worth using for an
Vladimir> open-source project such as this?
Maybe it's personal preference...I still find darcs
58 matches
Mail list logo
