On Wed, 27 Oct 2010 22:54:59 +0300, Jérôme M. Berger <jeberger@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,
 Vladimir                            mailto:vladimir@thecybershadow.net

On Wed, 27 Oct 2010 22:57:39 +0300, Jérôme M. Berger <jeberger@free.fr> 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 Torvalds" (never mind that he
> himself called it a dirty hack thrown together in an afternoon and
> most emphatically *not* a version control system).

Well, then you'll have to blame Junio Hamano for actually turning it into a VCS that human beings can use. ;)

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

Vladimir Panteleev wrote:
> On Wed, 27 Oct 2010 22:54:59 +0300, Jérôme M. Berger <jeberger@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:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

On Wed, 27 Oct 2010 23:08:02 +0300, Vladimir Panteleev <vladimir@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,
 Vladimir                            mailto:vladimir@thecybershadow.net

On Wed, 27 Oct 2010 23:29:02 +0300, Jérôme M. Berger <jeberger@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,
 Vladimir                            mailto:vladimir@thecybershadow.net

"Gour" <gour@atmarama.net> wrote in message news:20101027210750.616814d0@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?

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:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

On Thu, 28 Oct 2010 00:33:54 +0300, Jérôme M. Berger <jeberger@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,
 Vladimir                            mailto:vladimir@thecybershadow.net

On Thu, 28 Oct 2010 08:17:02 +0300
>>>>>> "Vladimir" == <vladimir@thecybershadow.net> wrote:

Vladimir> 2) Fire up git gui

git and gui? Come on...


Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA
----------------------------------------------------------------

On Thu, 28 Oct 2010 08:40:56 +0300, Gour <gour@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,
 Vladimir                            mailto:vladimir@thecybershadow.net