www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Source control for all dmd source

reply Jason House <jason.james.house gmail.com> writes:
Over in D.anounce, the LDC devs said they would have an easier time upgrading
to newer dmd (fe) versions if the source was in source control. Even if Walter
is the only one with write access, it's still be helpful. It's helpful for more
than just the LDC folks; that's just the most recent example.

How about it Walter? IIRC, Andrei has been encouraging you to do  this for
awhile now.
May 29 2009
next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Jason House wrote:

 Over in D.anounce, the LDC devs said they would have an easier time
 upgrading to newer dmd (fe) versions if the source was in source
 control. Even if Walter is the only one with write access, it's still
 be helpful. It's helpful for more than just the LDC folks; that's
 just the most recent example.
 
 How about it Walter? IIRC, Andrei has been encouraging you to do
 this for awhile now.


I don't see that it necessarily has to be Walter.

It could even be automated. Ideas?
May 29 2009
parent "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 29 May 2009 17:53:42 +0400, Georg Wrede <georg.wrede iki.fi> wrote:


 Jason House wrote:

 Over in D.anounce, the LDC devs said they would have an easier time
 upgrading to newer dmd (fe) versions if the source was in source
 control. Even if Walter is the only one with write access, it's still
 be helpful. It's helpful for more than just the LDC folks; that's
 just the most recent example.
  How about it Walter? IIRC, Andrei has been encouraging you to do
 this for awhile now.


 I don't see that it necessarily has to be Walter.

 It could even be automated. Ideas?


There is no problem in having third-party source control system. Problem is,
commits once per month without any description are practically worthless,
everyone can diff one DMD version against another.
May 29 2009
prev sibling next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
On 29.05.2009 15:18, Jason House wrote:

 Over in D.anounce, the LDC devs said they would have an easier time upgrading
to newer dmd (fe) versions if the source was in source control. Even if Walter
is the only one with write access, it's still be helpful. It's helpful for more
than just the LDC folks; that's just the most recent example.

 How about it Walter? IIRC, Andrei has been encouraging you to do  this for
awhile now.


maybe on dsource.org like phobos 1/2 - seams to work realy good for 
walter and andrei (and all others)
May 29 2009
parent reply dennis luehring <dl.soluz gmx.net> writes:
On 29.05.2009 16:26, dennis luehring wrote:

 On 29.05.2009 15:18, Jason House wrote:

 Over in D.anounce, the LDC devs said they would have an easier time
 upgrading to newer dmd (fe) versions if the source was in source
 control. Even if Walter is the only one with write access, it's still
 be helpful. It's helpful for more than just the LDC folks; that's just
 the most recent example.

 How about it Walter? IIRC, Andrei has been encouraging you to do this
 for awhile now.


 maybe on dsource.org like phobos 1/2 - seams to work realy good for
 walter and andrei (and all others)


does all include optlink sources, too? :-)
May 29 2009
parent BCS <ao pathlink.com> writes:
Reply to dennis,


 On 29.05.2009 16:26, dennis luehring wrote:
 

 On 29.05.2009 15:18, Jason House wrote:
 

 Over in D.anounce, the LDC devs said they would have an easier time
 upgrading to newer dmd (fe) versions if the source was in source
 control. Even if Walter is the only one with write access, it's
 still be helpful. It's helpful for more than just the LDC folks;
 that's just the most recent example.
 
 How about it Walter? IIRC, Andrei has been encouraging you to do
 this for awhile now.
 


 maybe on dsource.org like phobos 1/2 - seams to work realy good for
 walter and andrei (and all others)
 


 does all include optlink sources, too? :-)
 


IIRC Walter dosn't own OPLINK and it's in ASM!
May 29 2009
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Jason House wrote:

 Over in D.anounce, the LDC devs said they would have an easier time upgrading
to newer dmd (fe) versions if the source was in source control. Even if Walter
is the only one with write access, it's still be helpful. It's helpful for more
than just the LDC folks; that's just the most recent example.


It would be nice to have DMD in version control, but I don't buy the LDC 
argument.  It's trivial to diff one release against another, regardless 
of whether version control is involved.
May 29 2009
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Sean Kelly wrote:

 Jason House wrote:

 Over in D.anounce, the LDC devs said they would have an easier time 
 upgrading to newer dmd (fe) versions if the source was in source 
 control. Even if Walter is the only one with write access, it's still 
 be helpful. It's helpful for more than just the LDC folks; that's just 
 the most recent example.


 
 It would be nice to have DMD in version control, but I don't buy the LDC 
 argument.  It's trivial to diff one release against another, regardless 
 of whether version control is involved.


It's probably just easier what a change is for[1] if it's small and 
self-contained, with a description (commit message) of what it's supposed to do.
But that's just a guess, you'd have to ask Thomas Lindquist since he's the one 
that usually merges new frontend versions.


[1]: And thus what to do in case of conflicts, as well as what may need to 
change in the backend (if anything).
May 29 2009
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Frits van Bommel wrote:

 Thomas Lindquist


Sorry about the misspelling there, Tomas. I get annoyed when people misspell my 
name, and now I'm doing it too... :(
May 29 2009
prev sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Fri, May 29, 2009 at 4:52 PM, Frits van Bommel
<fvbommel remwovexcapss.nl> wrote:

 Sean Kelly wrote:

 Jason House wrote:

 Over in D.anounce, the LDC devs said they would have an easier time
 upgrading to newer dmd (fe) versions if the source was in source contro=






l.

 Even if Walter is the only one with write access, it's still be helpful=






.

 It's helpful for more than just the LDC folks; that's just the most rec=






ent

 example.


 It would be nice to have DMD in version control, but I don't buy the LDC
 argument. =C2=A0It's trivial to diff one release against another, regard=




less of

 whether version control is involved.


 It's probably just easier what a change is for[1] if it's small and
 self-contained, with a description (commit message) of what it's supposed=


 to

 do.
 But that's just a guess, you'd have to ask Thomas Lindquist since he's th=


e

 one that usually merges new frontend versions.


 [1]: And thus what to do in case of conflicts, as well as what may need t=


o

 change in the backend (if anything).


Yes... the DMD frontend is poorly documented, and small self-contained
commits (with meaningful commit messages) would be a great way to
learn a little more, even if just about how Walter does his coding.

In the end there's a lot more to it than just version control. What
I'd really like to see is the DMD frontend made into a proper
opensource project. I don't care about the backend. It's "personal use
only". But right now you have to remove a lot of code to get down to
the part you want, the frontend.

Imagine if LDC was just a backend module that you could use pretty
much out-of-the-box with the official DMD frontend source tree !!

I've worked with a few smaller open source project communities, and
it's just a much nicer way to work than what we have with DMD right
now.

With version control, DMD will feel more like an open source project.

-Tomas
May 30 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Tomas Lindquist Olsen:

 I've worked with a few smaller open source project communities, and
 it's just a much nicer way to work than what we have with DMD right
 now.


Thank you for your relaxed comments here.
Even with my level of ignorance I can see that having such code on GIT/Hg can
be positive.

Anyway, sometimes in a discussion a good thing to do is to not start assuming
the reader knows everything you know. So I think it can be good if you use 10
minutes of your time to give as many explanations as possible about why you
think that's a "much nicer way to work" (even if they may be obvious for you).

Bye,
bearophile
May 30 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:

 It would be nice to have DMD in version control, but I don't buy the LDC 
 argument.  It's trivial to diff one release against another, regardless 
 of whether version control is involved.


A fantastic program to do this is meld on Ubuntu.

sudo apt-get install meld

It has done a lot for my productivity when merging diffs.
May 30 2009
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Walter Bright escribió:

 Sean Kelly wrote:

 It would be nice to have DMD in version control, but I don't buy the 
 LDC argument.  It's trivial to diff one release against another, 
 regardless of whether version control is involved.


 
 A fantastic program to do this is meld on Ubuntu.
 
 sudo apt-get install meld
 
 It has done a lot for my productivity when merging diffs.


Yes! I used it to port changes of DMD versions to the java version. :-)
May 30 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 30 de mayo a las 21:56 me escribiste:

 Sean Kelly wrote:

It would be nice to have DMD in version control, but I don't buy the LDC
argument.  It's trivial to diff one release against another, regardless of
whether 
version control is involved.


 
 A fantastic program to do this is meld on Ubuntu.
 
 sudo apt-get install meld
 
 It has done a lot for my productivity when merging diffs.


Meld is really nice, but it doesn't do semantic analysis to tell you why
things have changes and what change is for what =)

Meld can be used as a paliative for not having (at least) the frontend in
a SCM and doing well documented, self contained commits; not as
a solution.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Hey you, out there beyond the wall,
Breaking bottles in the hall,
Can you help me?
May 31 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:

 Over in D.anounce, the LDC devs said they would have an easier time
 upgrading to newer dmd (fe) versions if the source was in source
 control. Even if Walter is the only one with write access, it's still
 be helpful. It's helpful for more than just the LDC folks; that's
 just the most recent example.
 
 How about it Walter? IIRC, Andrei has been encouraging you to do
 this for awhile now.


It's a great idea, I just haven't gotten my act together yet.
May 30 2009
next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
Walter Bright wrote:

 Jason House wrote:

 Over in D.anounce, the LDC devs said they would have an easier time
 upgrading to newer dmd (fe) versions if the source was in source
 control. Even if Walter is the only one with write access, it's still
 be helpful. It's helpful for more than just the LDC folks; that's
 just the most recent example.

 How about it Walter? IIRC, Andrei has been encouraging you to do
 this for awhile now.


 
 It's a great idea, I just haven't gotten my act together yet.


I'm sure there are a number of people that would be willing to set it up 
for you (including myself), just say the word!
May 31 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 30 de mayo a las 21:54 me escribiste:

 Jason House wrote:

Over in D.anounce, the LDC devs said they would have an easier time
upgrading to newer dmd (fe) versions if the source was in source
control. Even if Walter is the only one with write access, it's still
be helpful. It's helpful for more than just the LDC folks; that's
just the most recent example.
How about it Walter? IIRC, Andrei has been encouraging you to do
this for awhile now.


 
 It's a great idea, I just haven't gotten my act together yet.


Well, that's great to hear! As Robert said, please tell if you need any
help. Please, please, please consider using a distributed SCM (I think git
would be ideal but mercurial is good too). That would make merging and
branching a lot easier.

Thanks!

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
¿Qué será lo que hace que una brújula siempre marque el norte?
- Ser aguja, nada más, y cumplir su misión.
	-- Ricardo Vaporeso
May 31 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:

 Walter Bright, el 30 de mayo a las 21:54 me escribiste:

 Jason House wrote:

 Over in D.anounce, the LDC devs said they would have an easier time
 upgrading to newer dmd (fe) versions if the source was in source
 control. Even if Walter is the only one with write access, it's still
 be helpful. It's helpful for more than just the LDC folks; that's
 just the most recent example.
 How about it Walter? IIRC, Andrei has been encouraging you to do
 this for awhile now.


 It's a great idea, I just haven't gotten my act together yet.


 
 Well, that's great to hear! As Robert said, please tell if you need any
 help. Please, please, please consider using a distributed SCM (I think git
 would be ideal but mercurial is good too). That would make merging and
 branching a lot easier.
 
 Thanks!
 


We should use Bartosz's Code Co-op!!!

Andrei
May 31 2009
prev sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Leandro Lucarella wrote:

 Well, that's great to hear! As Robert said, please tell if you need any=



 help. Please, please, please consider using a distributed SCM (I think =


git

 would be ideal but mercurial is good too). That would make merging and
 branching a lot easier.
=20


	Git is a bad choice because of its poor Windows support. Mercurial=20
or Bazaar are much better in this regard.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
May 31 2009
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
"Jérôme M. Berger", el 31 de mayo a las 19:03 me escribiste:

 Leandro Lucarella wrote:

Well, that's great to hear! As Robert said, please tell if you need any
help. Please, please, please consider using a distributed SCM (I think git
would be ideal but mercurial is good too). That would make merging and
branching a lot easier.


 	Git is a bad choice because of its poor Windows support. Mercurial or Bazaar
are much better in this regard.


That's a mith, Git is pretty much supported in Windows now. I know people
that uses it in a regular basis. See:
http://code.google.com/p/msysgit/

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
No debemos temer a la muerte, porque es la mejor recompensa de la vida.
	-- Ren & Stimpy
May 31 2009
next sibling parent reply hasen <hasan.aljudy gmail.com> writes:
Leandro Lucarella wrote:

 "Jérôme M. Berger", el 31 de mayo a las 19:03 me escribiste:

 Leandro Lucarella wrote:

 Well, that's great to hear! As Robert said, please tell if you need any
 help. Please, please, please consider using a distributed SCM (I think git
 would be ideal but mercurial is good too). That would make merging and
 branching a lot easier.


 	Git is a bad choice because of its poor Windows support. Mercurial or Bazaar
are much better in this regard.


 
 That's a mith, Git is pretty much supported in Windows now. I know people
 that uses it in a regular basis. See:
 http://code.google.com/p/msysgit/
 


Yea, I use git on windows (msysgit), works like a charm.

+1 for git
May 31 2009
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
hasen wrote:

 Leandro Lucarella wrote:

 "J=C3=A9r=C3=B4me M. Berger", el 31 de mayo a las 19:03 me escribiste:=





 Leandro Lucarella wrote:

 Well, that's great to hear! As Robert said, please tell if you need =








any

 help. Please, please, please consider using a distributed SCM (I=20
 think git
 would be ideal but mercurial is good too). That would make merging a=








nd

 branching a lot easier.


     Git is a bad choice because of its poor Windows support.=20
 Mercurial or Bazaar are much better in this regard.


 That's a mith, Git is pretty much supported in Windows now. I know peo=




ple

 that uses it in a regular basis. See:
 http://code.google.com/p/msysgit/


=20
 Yea, I use git on windows (msysgit), works like a charm.
=20
 +1 for git


	You just have to look at the name to see that it doesn't really=20
work on Windows: it requires a Unix emulation layer (msys in your=20
case, others do it with cygwin) which a lot of people won't want to=20
install/use.

		Jerome

PS: I usually use Linux at home and Windows at work. I do have msys=20
installed on the Windows machine and I don't consider it really=20
usable (the only reason I have it is to compile open source=20
autoconf-based packages). Mercurial (or Bazaar) work in a standard=20
Windows command shell as well as inside a cygwin/msys shell or any=20
of the alternative shells if you prefer.
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
May 31 2009
parent Leandro Lucarella <llucax gmail.com> writes:
"Jérôme M. Berger", el 31 de mayo a las 22:49 me escribiste:

 hasen wrote:

Leandro Lucarella wrote:

"Jérôme M. Berger", el 31 de mayo a las 19:03 me escribiste:

Leandro Lucarella wrote:

Well, that's great to hear! As Robert said, please tell if you need any
help. Please, please, please consider using a distributed SCM (I think git
would be ideal but mercurial is good too). That would make merging and
branching a lot easier.


    Git is a bad choice because of its poor Windows support. Mercurial or
Bazaar are much better in this regard.


That's a mith, Git is pretty much supported in Windows now. I know people
that uses it in a regular basis. See:
http://code.google.com/p/msysgit/


Yea, I use git on windows (msysgit), works like a charm.
+1 for git


 	You just have to look at the name to see that it doesn't really
 	work on Windows: it requires a Unix emulation layer (msys in your
 	case, others do it with cygwin) which a lot of people won't want
 	to install/use.


That project provides an easy installer that have all you need to run git
(in 10MB, I wonder how much software is available for Windows with an
installer of only 10MB).

Why do you care if it installs some "Unix emulation layer" (which are just
some tools common in Unix OS, is not that Git runs in a VM or something)?
You don't even need to install it if you don't want, you can use the
"portable app" package =)

It does works on Windows.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
This is what you get,
when you mess with us.
May 31 2009
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Leandro Lucarella wrote:

 "Jérôme M. Berger", el 31 de mayo a las 19:03 me escribiste:

 Leandro Lucarella wrote:

 Well, that's great to hear! As Robert said, please tell if you need any
 help. Please, please, please consider using a distributed SCM (I think git
 would be ideal but mercurial is good too). That would make merging and
 branching a lot easier.


 	Git is a bad choice because of its poor Windows support. Mercurial or Bazaar
are much better in this regard.


 
 That's a mith, Git is pretty much supported in Windows now. I know people
 that uses it in a regular basis. See:
 http://code.google.com/p/msysgit/


I've used tortoise-git: http://code.google.com/p/tortoisegit/

It worked pretty well, though I didn't spend much time with it.
May 31 2009
parent reply hasen <hasan.aljudy gmail.com> writes:
Christopher Wright wrote:

 Leandro Lucarella wrote:

 "Jérôme M. Berger", el 31 de mayo a las 19:03 me escribiste:

 Leandro Lucarella wrote:

 Well, that's great to hear! As Robert said, please tell if you need any
 help. Please, please, please consider using a distributed SCM (I 
 think git
 would be ideal but mercurial is good too). That would make merging and
 branching a lot easier.


     Git is a bad choice because of its poor Windows support. 
 Mercurial or Bazaar are much better in this regard.


 That's a mith, Git is pretty much supported in Windows now. I know people
 that uses it in a regular basis. See:
 http://code.google.com/p/msysgit/


 
 I've used tortoise-git: http://code.google.com/p/tortoisegit/
 
 It worked pretty well, though I didn't spend much time with it.


Wow, tortoisegit? Seems so bloated, look at those screen shots, it's so 
confusing!

IMO it's wrong to just put the same command-line commands on the 
right-click menu, and call that a gui.

The humble git-gui is much better.
Jun 01 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
hasen wrote:

 ...
 
 Wow, tortoisegit? Seems so bloated, look at those screen shots, it's so
 confusing!


Wow, git cli?  Seems so bloated, look at all those commands, it's so
confusing!

add am annotate apply archive bisect blame branch bundle cat-file
check-attr checkout checkout-index check-ref-format cherry cherry-pick
citool clean clone commit commit-tree config count-objects describe diff
diff-files diff-index diff-tree fast-export fast-import fetch fetch-pack
fetch--tool fmt-merge-msg got-for-each-ref format-patch fsck
fsck-objects gc get-tar-commit-id grep hash-object http-fetch http-push
index-pack init init-db log lost-found ls-files ls-remote ls-tree
mailinfo mailsplit merge merge-base merge-index merge-octopus (wtf?)
merge-one-file merge-our merge-recursive merge-resolve merge-subtree
mergetool merge-tree mktag mktree mv name-rev pack-objects
pack-redundant pack-refs parse-remote patch-id peek-remote prune
prune-packed pull push quiltimport read-tree rebase rebase-interactive
receive-pack reflog relink remote repack repo-config request-pull rerere
reset revert rev-list rev-parse rm send-pack shortlog show show-branch
show-index show-ref sh-setup stage stash status stripspace submodule svn
symbolic-ref tag tar-tree unpack-file unpack-objects update-index
update-ref update-server-info upload-archive upload-pack var verify-pack
verify-tag web-browse whatchanged write-tree

As for your assertion that tortoisegit is confusing, let's look at those
screenshots.

The first is a context-dependant list of git commands.  If you think
that's confusing, then I can't imagine you're able to use the git cli at
all, so let's assume you don't mean that one.

Next we have a shot of it detecting a patch set and giving you context
commands for those.  I fail to see how that could be confusing.

The commit dialog?  Well, that's basically git commit -a, except you can
actually modify what files are being committed in the dialog itself and
it has a built-in editor.

Actually, if you look at them, the dialogs are all just GUI versions of
the various git tools themselves.  So if you really find those
confusing, I can only assume you find Git itself confusing.


 IMO it's wrong to just put the same command-line commands on the
 right-click menu, and call that a gui.


Yes, because heaven forbid anyone makes our lives as developers easier.
 After all, no developer should EVER use a simplified interface when
what they SHOULD be doing is memorising every command and all of its
switches.

The heresy!


 The humble git-gui is much better.


Integrating those commands into the shell itself so that only the
commands that make sense in context are shown, and actually tell the
user what they're going to do is much better.

Incidentally, I use both.  TortoiseGit is great for anything of relative
complexity as it actually helps you do it correctly (it took me a while
to work out how to properly apply patch sets without it).

What's more, it also helps you learn how to use git without constantly
screwing up.
Jun 01 2009
next sibling parent reply hasen <hasan.aljudy gmail.com> writes:
Daniel Keep wrote:

 
 hasen wrote:

 ...

 Wow, tortoisegit? Seems so bloated, look at those screen shots, it's so
 confusing!


 
 Wow, git cli?  Seems so bloated, look at all those commands, it's so
 confusing!


It *is* confusing, it doesn't claim to be intuitive, it's aimed for 
developers, they're supposed to read tutorials/man pages to know how it 
works.

Providing a gui that maps a "pull" button to a pull command is confusing 
because GUI's are supposed to be "discoverable" and "intuitive".

No wonder I never knew how to properly use svn, I was so dependant on 
those GUIs, that I never knew what was going on under the surface.

At least for me, the only sensible way to use svn is through the command 
line.

GUIs for svn and git are confusing because well, you're not exactly sure 
what they're doing.




 As for your assertion that tortoisegit is confusing, let's look at those
 screenshots.
 
 The first is a context-dependant list of git commands.  If you think
 that's confusing, then I can't imagine you're able to use the git cli at
 all, so let's assume you don't mean that one.


Yes, I think it's confusing. Read above.

I do use the git cli, it's easier because it makes more sense.


 
 Next we have a shot of it detecting a patch set and giving you context
 commands for those.  I fail to see how that could be confusing.


I haven't used patches with git, so I don't know what's in that corner 
of git.


 
 The commit dialog?  Well, that's basically git commit -a, except you can
 actually modify what files are being committed in the dialog itself and
 it has a built-in editor.


Yea? What are these options? [Sign] [OK] what's the difference between them?


 
 Actually, if you look at them, the dialogs are all just GUI versions of
 the various git tools themselves.  So if you really find those
 confusing, I can only assume you find Git itself confusing.


Look at this and tell me it's not confusing:
http://www.jensroesner.de/wgetgui/wgetgui.png



 IMO it's wrong to just put the same command-line commands on the
 right-click menu, and call that a gui.


 
 Yes, because heaven forbid anyone makes our lives as developers easier.
  After all, no developer should EVER use a simplified interface when
 what they SHOULD be doing is memorising every command and all of its
 switches.
 
 The heresy!


Well, if it makes your life easier, good for you.


 

 The humble git-gui is much better.


 
 Integrating those commands into the shell itself so that only the
 commands that make sense in context are shown, and actually tell the
 user what they're going to do is much better.
 
 Incidentally, I use both.  TortoiseGit is great for anything of relative
 complexity as it actually helps you do it correctly (it took me a while
 to work out how to properly apply patch sets without it).
 
 What's more, it also helps you learn how to use git without constantly
 screwing up.


I think if you don't know what you're doing you'll screw up anyway. I 
used to use SmartSVN, TortoiseSVN, and probably some other GUIs, and 
every so often I would screw something up and have no idea how to fix it.

Why? because the GUI made me feel comfortable using svn without really 
knowing what the hell was going on. Many items under menus were 
confusing as hell. Many options for various tasks were also confusing as 
hell.
Jun 01 2009
parent reply BCS <ao pathlink.com> writes:
Reply to hasen,


 Daniel Keep wrote:
 

 hasen wrote:
 

 ...
 
 Wow, tortoisegit? Seems so bloated, look at those screen shots, it's
 so confusing!
 


 Wow, git cli?  Seems so bloated, look at all those commands, it's so
 confusing!
 


 It *is* confusing, it doesn't claim to be intuitive, it's aimed for
 developers, they're supposed to read tutorials/man pages to know how
 it works.


No they're not. The difference between a technical and non-technical user 
is that the technical one *will* read manual if they have to. If there is 
any other choice, no program should *ever* be designed so that the user is 
forced to read the manual. Whenever possible, no matter the user, the UI 
should be intuitive. (OK I'll grant that in the technical user case some 
intuitiveness can be traded for speed of use but in this case I don't think 
their is a conflict)


 Providing a gui that maps a "pull" button to a pull command is
 confusing because GUI's are supposed to be "discoverable" and
 "intuitive".


Both GUIs and CLIs are.


 
 No wonder I never knew how to properly use svn, I was so dependant on
 those GUIs, that I never knew what was going on under the surface.


Odd, I started using SVN via a GUI and now I rarely if ever use the CLI and 
I never had a problem figuring out what was going on under the surface.


 At least for me, the only sensible way to use svn is through the
 command line.
 
 GUIs for svn and git are confusing because well, you're not exactly
 sure what they're doing.
 


That is not true. I am sure of what my SVN GUI is doing. As for Git, I have 
yet to have any problem with it that were cause by it hiding what it was 
doing (the only problem I've had is it not even showing some functionality)


 Actually, if you look at them, the dialogs are all just GUI versions
 of the various git tools themselves.  So if you really find those
 confusing, I can only assume you find Git itself confusing.
 


 Look at this and tell me it's not confusing:
 http://www.jensroesner.de/wgetgui/wgetgui.png


Is that from TortoiusGit?


 IMO it's wrong to just put the same command-line commands on the
 right-click menu, and call that a gui.
 


 Yes, because heaven forbid anyone makes our lives as developers
 easier. After all, no developer should EVER use a simplified
 interface when what they SHOULD be doing is memorising every command
 and all of its switches.
 
 The heresy!
 


 Well, if it makes your life easier, good for you.
 


It does.


 The humble git-gui is much better.
 


 Integrating those commands into the shell itself so that only the
 commands that make sense in context are shown, and actually tell the
 user what they're going to do is much better.
 
 Incidentally, I use both.  TortoiseGit is great for anything of
 relative complexity as it actually helps you do it correctly (it took
 me a while to work out how to properly apply patch sets without it).
 
 What's more, it also helps you learn how to use git without
 constantly screwing up.
 


 I think if you don't know what you're doing you'll screw up anyway. I
 used to use SmartSVN, TortoiseSVN, and probably some other GUIs, and
 every so often I would screw something up and have no idea how to fix
 it.


Yup, I known what you are talking about. But what does that have to do with 
GUIs?


 Why? because the GUI made me feel comfortable using svn without really
 knowing what the hell was going on.


I wouldn't feel very comfortable using svn or git without knowing what it's 
doing regardless of the UI.

It seems you don't like GUIs. Obviously, others doesn't agree with you.
Jun 01 2009
parent reply hasen <hasan.aljudy gmail.com> writes:
BCS wrote:

 It seems you don't like GUIs. Obviously, others doesn't agree with you.
 


Actually no, I don't hate guis, but I come from windows, and in the 
world of windows, you get used to expect programs to work without you 
having to read manuals.

For example, I used to play with the Half-Life SDK, and while I had to 
read some tutorials about how to download it and set it up, etc, the 
rest just worked in an out-of-the-box kind of way.

I never had to read any manuals for Visual Studio, it just kinda worked, 
the expectations you have about it turn out to be true most of the time, 
and if they're not, you can sort if work it out in your head and 
discover how it works.

With something like svn, you can't have any expectation; you just have 
to learn it through the manual/tutorials. What the hell is a commit? 
what's a log? what's revert? etc etc. There's just no other way around 
it other than to read and learn all these concepts. And just what the 
hell is a "working directory"? That thing kept confusing the hell out of me.

Now, git comes with its own set of concepts, that are completely 
different from svn. "checkout" in git has nothing to do with "checkout" 
in svn. What's a branch? what's merging? where/how does merging happen?

There's just no way you could work with git without knowing about all of 
this. It's not complicated or anything, but you have to learn it.

So, when you learn to use it from the command line, then what's the 
point of the gui?

See, because I come from windows, GUI to me means that I don't have to 
learn anything; that I can just sail through it and it will somehow work 
out on its own.

That's why GUIs that just offer buttons that map directly to CLI 
commands are confusing.

Imagine a file explorer where you have to right click a directory and 
choose "cd" from the menu. and then it will cd into that directory, but 
not show you the files inside it, instead it shows a blank, and then you 
right click somewhere in that empty area and choose "ls". better yet, 
"ls" would bring a sub-menu, where one of the choices is "-al", or maybe 
just be smart and write it out as "all", to confuse the user, and make 
him think "Oh, so it usually lists the first 10 files only unless I 
choose all? To conserve screen space maybe?"
Jun 01 2009
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
hasen wrote:

 BCS wrote:

 It seems you don't like GUIs. Obviously, others doesn't agree with you.


 
 Actually no, I don't hate guis, but I come from windows, and in the 
 world of windows, you get used to expect programs to work without you 
 having to read manuals.
 
 For example, I used to play with the Half-Life SDK, and while I had to 
 read some tutorials about how to download it and set it up, etc, the 
 rest just worked in an out-of-the-box kind of way.
 
 I never had to read any manuals for Visual Studio, it just kinda worked, 
 the expectations you have about it turn out to be true most of the time, 
 and if they're not, you can sort if work it out in your head and 
 discover how it works.
 
 With something like svn, you can't have any expectation; you just have 
 to learn it through the manual/tutorials. What the hell is a commit? 
 what's a log? what's revert? etc etc. There's just no other way around 
 it other than to read and learn all these concepts. And just what the 
 hell is a "working directory"? That thing kept confusing the hell out of 
 me.
 
 Now, git comes with its own set of concepts, that are completely 
 different from svn. "checkout" in git has nothing to do with "checkout" 
 in svn. What's a branch? what's merging? where/how does merging happen?
 
 There's just no way you could work with git without knowing about all of 
 this. It's not complicated or anything, but you have to learn it.
 
 So, when you learn to use it from the command line, then what's the 
 point of the gui?
 
 See, because I come from windows, GUI to me means that I don't have to 
 learn anything; that I can just sail through it and it will somehow work 
 out on its own.
 
 That's why GUIs that just offer buttons that map directly to CLI 
 commands are confusing.


I don't see TortoiseSVN as a one-to-one mapping between buttons and 
command-line actions. For example when you select SVN Commit you can add 
files from there, ignore files, revert changes, see differences. So it 
basically unified all the tools in a comfortable way. It also lets you 
see which files are now and gives you the option to add them. How do you 
do that with the command line?
Jun 01 2009
prev sibling parent BCS <ao pathlink.com> writes:
Reply to hasen,


 BCS wrote:
 

 It seems you don't like GUIs. Obviously, others doesn't agree with
 you.
 


 Now, git comes with its own set of concepts, that are completely
 different from svn. "checkout" in git has nothing to do with
 "checkout" in svn. What's a branch? what's merging? where/how does
 merging happen?
 
 There's just no way you could work with git without knowing about all
 of this. It's not complicated or anything, but you have to learn it.
 
 So, when you learn to use it from the command line, then what's the
 point of the gui?
 
 See, because I come from windows, GUI to me means that I don't have to
 learn anything; that I can just sail through it and it will somehow
 work out on its own.
 
 That's why GUIs that just offer buttons that map directly to CLI
 commands are confusing.


OK I see where you are coming from and why we are seeing things so differently. 
To me, a GUI is not about "It just works" kinds of things. That's just good 
design and can be had (with more design work) in a CLI as well. To me, a 
GUI is about having more dimensions of input, more simultaneous channels 
of communication. I can see many different bits of information in a non linear 
way. I can have many contexts available at the same time. I can access many 
action from the same point. I'd much rather select from a set of files with 
check boxes than by typing in file names.


 
 Imagine a file explorer where you have to right click a directory and
 choose "cd" from the menu. and then it will cd into that directory,
 but not show you the files inside it, instead it shows a blank, and
 then you right click somewhere in that empty area and choose "ls".
 better yet, "ls" would bring a sub-menu, where one of the choices is
 "-al", or maybe just be smart and write it out as "all", to confuse
 the user, and make him think "Oh, so it usually lists the first 10
 files only unless I choose all? To conserve screen space maybe?"
 


There is a big difference; with Git/SVN many of the commands have side effect 
and many of the others take a bit of time and space to operate on. The way 
I've got SVN/Git set up the most useful information (file status) is shown 
right up front as icon overlays. I don't /want/ any more information that 
that because the next most useful bits (diffs for instance) wouldn't fit 
on any screen I could use.
Jun 01 2009
prev sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Daniel Keep wrote:

 Incidentally, I use both.  TortoiseGit is great for anything of relativ=


e

 complexity as it actually helps you do it correctly (it took me a while=



 to work out how to properly apply patch sets without it).
=20


hg unbundle patchset

	Sorry, couldn't resist ;)

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jun 01 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
"Jérôme M. Berger", el  1 de junio a las 12:23 me escribiste:

 Daniel Keep wrote:

Incidentally, I use both.  TortoiseGit is great for anything of relative
complexity as it actually helps you do it correctly (it took me a while
to work out how to properly apply patch sets without it).


 hg unbundle patchset
 
 	Sorry, couldn't resist ;)


git am mailbox

Sorry, me either ;)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Jun 01 2009
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Leandro Lucarella wrote:

 "J=C3=A9r=C3=B4me M. Berger", el  1 de junio a las 12:23 me escribiste:=



 Daniel Keep wrote:

 Incidentally, I use both.  TortoiseGit is great for anything of relat=






ive

 complexity as it actually helps you do it correctly (it took me a whi=






le

 to work out how to properly apply patch sets without it).


 hg unbundle patchset

 	Sorry, couldn't resist ;)


=20
 git am mailbox
=20
 Sorry, me either ;)
=20


	Well, *I* am not the one who said it was difficult to find out with=20
git ;)

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jun 01 2009
prev sibling parent BCS <ao pathlink.com> writes:
Reply to hasen,


 IMO it's wrong to just put the same command-line commands on the
 right-click menu, and call that a gui.
 


I like exactly that kind of approach, it gives you the full power of the 
command line without having to keep a command shell(s) around in the correct 
directory(s). All the advantages of both the CLI word and the GUI world. 
OTOH that is all theoretical as I just installed it about a week ago and 
have already discovered that several key features are unavailable from it 
(not hooked up it would seem).
Jun 01 2009
prev sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Jérôme M. Berger wrote:

 Leandro Lucarella wrote:

 Well, that's great to hear! As Robert said, please tell if you need any
 help. Please, please, please consider using a distributed SCM (I think
 git
 would be ideal but mercurial is good too). That would make merging and
 branching a lot easier.


     Git is a bad choice because of its poor Windows support. Mercurial
 or Bazaar are much better in this regard.
 
         Jerome


Lies.

I've been using it daily for about a month and a half now.  I've got
both TortoiseGIT and msysGit installed.  Both were installed with
regular Windows installers that required me to click "Next" a few times
and maybe a "Finish" or two.

You DO NOT need to run Git from inside a weird shell or anything; git
commands work directly from the standard sucky Windows command-line.
And it appears to be quite fast, too.  Hell, it seems to be even faster
than svn.

It's beautiful and I'm now looking to convert my existing projects in
svn over to Git because it's just so much better.
May 31 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Daniel Keep, el  1 de junio a las 13:22 me escribiste:

 It's beautiful and I'm now looking to convert my existing projects in
 svn over to Git because it's just so much better.


Usability features of Git are just unique, I never saw other SCMs more
usable than Git. Even when mercurial is nice, I miss Git so much when
I use it, it hurts! =)

A trivial example of this is all git commands with long outputs (like diff
or log) runs through a pager (*if* their output don't fit the current
console). This feature makes a *huge* difference in the day to day work.
Colored output is great too, and the local/remote branching management is
really great. Not to mention git rebase... What a command!

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Nos retiramos hasta la semana que viene reflexionando sobre nuestras
vidas: "Qué vida de mier'... Qué vida de mier'!"
	-- Sidharta Kiwi
May 31 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Anyways, my point was, putting DMDFE in a SCM would be great, even when
it's svn. For me the ideal would be Git, Mercurial or other distributed
SCM would be nice, but even svn is better than we have now =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Jun 01 2009
next sibling parent hasen <hasan.aljudy gmail.com> writes:
Leandro Lucarella wrote:

 Anyways, my point was, putting DMDFE in a SCM would be great, even when
 it's svn. For me the ideal would be Git, Mercurial or other distributed
 SCM would be nice, but even svn is better than we have now =)
 


Even under svn, we can track it with git-svn
Jun 01 2009
prev sibling parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Leandro Lucarella wrote:

 Anyways, my point was, putting DMDFE in a SCM would be great, even when=



 it's svn. For me the ideal would be Git, Mercurial or other distributed=



 SCM would be nice, but even svn is better than we have now =3D)
=20


	Oh, I agree. However, IMO git is a poor choice. Mercurial, Bazaar=20
or svn would be better.

	For some interesting reading:

- Here are the reasons that pushed Python to use Mercurial (includes=20
the reasons for the change from centralized to distributed SCM and=20
the reasons for choosing Mercurial):=20
http://www.python.org/dev/peps/pep-0374/

- Here's the same for Mozilla:=20
http://weblogs.mozillazine.org/preed/2007/04/version_control_system_shoot=
ou_1.html

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jun 01 2009
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Jérôme M. Berger wrote:

 - Here's the same for Mozilla: 
 http://weblogs.mozillazine.org/preed/2007/04/version_control_s
stem_shootou_1.html 


 From the article:
While they've made recent progress, Git was lacking in Win32 support and 
it was unclear that this would ever change and if it did change, it was 
unclear that Git-on-Win32 would ever become something more than a 
second-class citizen. As good, performant Win32 (and Mac and Linux) is a 
hard-requirement, Git lost in early Kombat rounds. This is unfortunate 
because (as we would soon find out), lots of issues with the other 
systems did "just work" in Git.

git's Win32 support via TortoiseGit is nearly as good as SVN's now, so I 
can't see that being an issue here. So I'd say Git is a great choice for 
the DMDFE.
Jun 01 2009
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Jérôme M. Berger wrote:

 Leandro Lucarella wrote:

 Anyways, my point was, putting DMDFE in a SCM would be great, even when
 it's svn. For me the ideal would be Git, Mercurial or other distributed
 SCM would be nice, but even svn is better than we have now =)


     Oh, I agree. However, IMO git is a poor choice. Mercurial, Bazaar or
 svn would be better.


After having used both git and svn, I'll have to VERY strongly disagree
with that last part.  I'd imagine that *any* half-way sane DVCS would be
better than svn.

As for the others, you don't provide any objective reasons for WHY
they're better than git.


     For some interesting reading:
 
 - Here are the reasons that pushed Python to use Mercurial (includes the
 reasons for the change from centralized to distributed SCM and the
 reasons for choosing Mercurial): http://www.python.org/dev/peps/pep-0374/


The weakness of Git's support for Windows relative to the others is
probably a valid point; I haven't used the other two.

It's worth noting, however, that I *do* use Git in both Windows and
Linux and I've only felt disadvantaged on Windows in one specific case:
the Windows build lacks svn integration. [1]

Another reason was "it's not Python," which is obviously irrelevant in
this case.

The only other reason was popularity.  The table doesn't really specify
WHY the others were more popular.  This could be either that mercurial
is much easier to use, or the majority of Python devs prefer typing two
characters instead of three.  :P


 - Here's the same for Mozilla:
 http://weblogs.mozillazine.org/preed/2007/04/version_control_system_shootou_1.html


That's over three years old and the only reason stated is that it is
"lacking Win32 support" which is obviously no longer true.


[1] Apparently this is because the svn integration depends on the perl
svn bindings, and no one can get both perl AND perl-svn compiling with msys.
Jun 01 2009
parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Daniel Keep wrote:

=20
 J=E9r=F4me M. Berger wrote:

 Leandro Lucarella wrote:

 Anyways, my point was, putting DMDFE in a SCM would be great, even wh=






en

 it's svn. For me the ideal would be Git, Mercurial or other distribut=






ed

 SCM would be nice, but even svn is better than we have now =3D)


     Oh, I agree. However, IMO git is a poor choice. Mercurial, Bazaar =




or

 svn would be better.


=20
 After having used both git and svn, I'll have to VERY strongly disagree=



 with that last part.  I'd imagine that *any* half-way sane DVCS would b=


e

 better than svn.
=20
 As for the others, you don't provide any objective reasons for WHY
 they're better than git.
=20


	Well, the reason *I* don't use git is that at the time I started=20
using a DVCS, it didn't run at all on Windows (some people reported=20
partial success with cygwin but that was all). Even if support has=20
improved, it still seems to me like Windows is a second rate citizen=20
in the git world, and this leads me to worry about how git handles=20
the idiosyncrasies of Windows. Plus, my experience with other=20
cygwin/msys based projects leave me worried about git's speed on=20
Windows (although I haven't tested it).

	Moreover, everything I've read on the web seems to indicate that=20
git is difficult to use if you want to do more than=20
add/commit/update. Mercurial is *very* easy to both setup and use on=20
windows as well as linux. I'm less familiar with Bazaar, but from=20
what I've seen it's very similar to Mercurial.

	Finally, no matter how good it is, TortoiseGIT is not enough (in=20
the same way that TortoiseCVS, TortoiseSVN and TortoiseHg are not=20
enough). You need good command-line support so that you can access=20
it easily from custom tools (for example to generate releases=20
automatically).

	On a side note, we have to ask ourselves: is a DSCM really needed=20
for D? So long as there are only a few developers, a centralized=20
system might be enough (in which case svn becomes the only real choice).

		Jerome

PS: http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jun 01 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
"Jérôme M. Berger", el  1 de junio a las 19:55 me escribiste:

 Daniel Keep wrote:

Jérôme M. Berger wrote:

Leandro Lucarella wrote:

Anyways, my point was, putting DMDFE in a SCM would be great, even when
it's svn. For me the ideal would be Git, Mercurial or other distributed
SCM would be nice, but even svn is better than we have now =)


    Oh, I agree. However, IMO git is a poor choice. Mercurial, Bazaar or
svn would be better.


After having used both git and svn, I'll have to VERY strongly disagree
with that last part.  I'd imagine that *any* half-way sane DVCS would be
better than svn.
As for the others, you don't provide any objective reasons for WHY
they're better than git.


 	Well, the reason *I* don't use git is that at the time I started using a
DVCS, 
 it didn't run at all on Windows (some people reported partial success with 
 cygwin but that was all). Even if support has improved, it still seems to me 
 like Windows is a second rate citizen in the git world, and this leads me to 
 worry about how git handles the idiosyncrasies of Windows. Plus, my experience 
 with other cygwin/msys based projects leave me worried about git's speed on 
 Windows (although I haven't tested it).


Why don't you test it and stop talking about what you think it's going on
and start talking about what's *really* going on.

It doesn't seems very fair to discard something just because you have the
feeling that it wouldn't work well (specially when other people use it and
say it works well).

Anyway, I insist that the main point is having DMDFE in a SCM. If Walter
feels comfortable with svn *now*, I think it should be svn *now*. I prefer
some no-ideal SCM *now* than the ideal SCM *in a distant future*. We can
always migrate the repo to something else when the time is right...


 	Moreover, everything I've read on the web seems to indicate that git is 
 difficult to use if you want to do more than add/commit/update. Mercurial is 
 *very* easy to both setup and use on windows as well as linux. I'm less
familiar 
 with Bazaar, but from what I've seen it's very similar to Mercurial.


Again "I've read". =)

I'm telling you, git is easy, it just a little harder to get used to it,
but it's so much better when you do...


 	Finally, no matter how good it is, TortoiseGIT is not enough (in the same way 
 that TortoiseCVS, TortoiseSVN and TortoiseHg are not enough). You need good 
 command-line support so that you can access it easily from custom tools (for 
 example to generate releases automatically).


You have a good command-line support.


 	On a side note, we have to ask ourselves: is a DSCM really needed for D? So 
 long as there are only a few developers, a centralized system might be enough 
 (in which case svn becomes the only real choice).


I think it's not *needed*, as a SCM is not *needed* either. Having one
(SCM) just would make things easier (and might encourage developers to
hack DMDFE, as following the changes in a repo might give you a better
insight about how is written and maybe people can spot bugs too). Having
a DSCM would make things easier for people that integrates DMDFE in other
projects than DMD.


-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Jun 01 2009
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Leandro Lucarella wrote:

 "J=C3=A9r=C3=B4me M. Berger", el  1 de junio a las 19:55 me escribiste:=



 Daniel Keep wrote:

 J=C3=A9r=C3=B4me M. Berger wrote:

 Leandro Lucarella wrote:

 Anyways, my point was, putting DMDFE in a SCM would be great, even =










when

 it's svn. For me the ideal would be Git, Mercurial or other distrib=










uted

 SCM would be nice, but even svn is better than we have now =3D)


    Oh, I agree. However, IMO git is a poor choice. Mercurial, Bazaar=








 or

 svn would be better.


 After having used both git and svn, I'll have to VERY strongly disagr=






ee

 with that last part.  I'd imagine that *any* half-way sane DVCS would=






 be

 better than svn.
 As for the others, you don't provide any objective reasons for WHY
 they're better than git.


 	Well, the reason *I* don't use git is that at the time I started usin=




g a DVCS,=20

 it didn't run at all on Windows (some people reported partial success =




with=20

 cygwin but that was all). Even if support has improved, it still seems=




 to me=20

 like Windows is a second rate citizen in the git world, and this leads=




 me to=20

 worry about how git handles the idiosyncrasies of Windows. Plus, my ex=




perience=20

 with other cygwin/msys based projects leave me worried about git's spe=




ed on=20

 Windows (although I haven't tested it).


=20
 Why don't you test it and stop talking about what you think it's going =


on

 and start talking about what's *really* going on.
=20
 It doesn't seems very fair to discard something just because you have t=


he

 feeling that it wouldn't work well (specially when other people use it =


and

 say it works well).
=20


	I've started. I'll give you a full report tomorrow when I have=20
tested it more completely, but I have to tell you that it doesn't=20
look good for Git. Now, I have to ask: have *you* tried Mercurial or=20
Bazaar? And what, in your opinion, is the main advantage of Git over=20
the other two?


 Anyway, I insist that the main point is having DMDFE in a SCM. If Walte=


r

 feels comfortable with svn *now*, I think it should be svn *now*. I pre=


fer

 some no-ideal SCM *now* than the ideal SCM *in a distant future*. We ca=


n

 always migrate the repo to something else when the time is right...
=20


	I agree completely with you there. That's more or less why I asked=20
if we really needed a distributed SCM rather than a simple svn.


 	Moreover, everything I've read on the web seems to indicate that git =




is=20

 difficult to use if you want to do more than add/commit/update. Mercur=




ial is=20

 *very* easy to both setup and use on windows as well as linux. I'm les=




s familiar=20

 with Bazaar, but from what I've seen it's very similar to Mercurial.


=20
 Again "I've read". =3D)
=20
 I'm telling you, git is easy, it just a little harder to get used to it=


,

 but it's so much better when you do...
=20


	Anything concrete to back your affirmation? Maybe all I've said is=20
"I've read", but at least I'm giving reasons. All you're saying is=20
"it's better", without saying what makes it better.


 	Finally, no matter how good it is, TortoiseGIT is not enough (in the =




same way=20

 that TortoiseCVS, TortoiseSVN and TortoiseHg are not enough). You need=




 good=20

 command-line support so that you can access it easily from custom tool=




s (for=20

 example to generate releases automatically).


=20
 You have a good command-line support.
=20


	Maybe you do, but that's not the impression the Git fans here were=20
giving:
  - Robert Fraser on win32 support: "git's Win32 support via=20
TortoiseGit is nearly as good as SVN's now"
  - All the discussion between BCS, hasen and Daniel Keep on=20
tortoise git.


 	On a side note, we have to ask ourselves: is a DSCM really needed for=




 D? So=20

 long as there are only a few developers, a centralized system might be=




 enough=20

 (in which case svn becomes the only real choice).


=20
 I think it's not *needed*, as a SCM is not *needed* either. Having one
 (SCM) just would make things easier (and might encourage developers to
 hack DMDFE, as following the changes in a repo might give you a better
 insight about how is written and maybe people can spot bugs too).


	Agreed


 Having a DSCM would make things easier for people that integrates DMDFE=


 in other

 projects than DMD.
=20


	If you say so...

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jun 02 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
2009/6/2 "J=E9r=F4me M. Berger" <jeberger free.fr>:

 Leandro Lucarella wrote:
 =A0 =A0 =A0 =A0I've started. I'll give you a full report tomorrow when I =


have tested

 it more completely, but I have to tell you that it doesn't look good for
 Git. Now, I have to ask: have *you* tried Mercurial or Bazaar? And what, =


in

 your opinion, is the main advantage of Git over the other two?


My faves:

* Ability to do commits on particular source line diffs so you don't
have to do gymnastics to prevent that unrelated one-line fix you made
from going into your commit that fixes bug 1234.

* Staging area (I think that's what the Git boys call it). Again makes
it easier to get just the things you want into a commit, and nothing
you don't.

I've used Mercurial and Bazaar a fair amount.   For personal projects
I might still choose Mercurial, just because it's got a simpler model
than the other two.  Bazaar tries to offer you all these ways to
configure a project (from more svn-like central repo to fully
distributed) but to me that ended up just making it seem more
complicated than hg.  But on the other hand if you want flexibility,
Bazaar is still not anywhere as flexible as git.

This is a fantastic Git tutorial:
http://excess.org/article/2008/07/ogre-git-tutorial/
That's the thing that really convinced me that the Linux folks aren't
smoking crack and that git really is the way to go, ultimately, even
on Windows.

--bb
Jun 02 2009
next sibling parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Bill Baxter wrote:

 2009/6/2 "J=E9r=F4me M. Berger" <jeberger free.fr>:

 Leandro Lucarella wrote:
        I've started. I'll give you a full report tomorrow when I have =




tested

 it more completely, but I have to tell you that it doesn't look good f=




or

 Git. Now, I have to ask: have *you* tried Mercurial or Bazaar? And wha=




t, in

 your opinion, is the main advantage of Git over the other two?


=20
 My faves:
=20
 * Ability to do commits on particular source line diffs so you don't
 have to do gymnastics to prevent that unrelated one-line fix you made
 from going into your commit that fixes bug 1234.
=20


hg record


 * Staging area (I think that's what the Git boys call it). Again makes
 it easier to get just the things you want into a commit, and nothing
 you don't.
=20


	I'll have to look at this one, any pointer to specific docs I=20
should read?


 This is a fantastic Git tutorial:
 http://excess.org/article/2008/07/ogre-git-tutorial/


	I'll take a look too.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jun 02 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
2009/6/2 "J=E9r=F4me M. Berger" <jeberger free.fr>:

 Bill Baxter wrote:

 2009/6/2 "J=E9r=F4me M. Berger" <jeberger free.fr>:

 Leandro Lucarella wrote:
 =A0 =A0 =A0 I've started. I'll give you a full report tomorrow when I h=






ave

 tested
 it more completely, but I have to tell you that it doesn't look good fo=






r

 Git. Now, I have to ask: have *you* tried Mercurial or Bazaar? And what=






,

 in
 your opinion, is the main advantage of Git over the other two?


 My faves:

 * Ability to do commits on particular source line diffs so you don't
 have to do gymnastics to prevent that unrelated one-line fix you made
 from going into your commit that fixes bug 1234.


 hg record


Great.  Didn't know about that one.  Is there a gui that will make it
so you don't have to say yes or no to each one but browse the changes?
  Git's gui does that.  I don't think I'd use that particular feature
without some kind of gui.   Also I find it nice that the major Git
commands also work in an ncurses kind of mode.  So you can get some of
the ease of the gui without actually having to open up a separate
window.  I think most of curses stuff is working in the msys-git now
too.


 * Staging area (I think that's what the Git boys call it). Again makes
 it easier to get just the things you want into a commit, and nothing
 you don't.


 =A0 =A0 =A0 =A0I'll have to look at this one, any pointer to specific doc=


s I should

 read?


It's demoed in that video I linked to.
But basically checkin is a two-step process.  Specify what you want to
go into the commit in step 1, then actually do the commit in step 2.
(And of course "what you want to go in" can also be parts of files
instead of whole files.)


 This is a fantastic Git tutorial:
 http://excess.org/article/2008/07/ogre-git-tutorial/


 =A0 =A0 =A0 =A0I'll take a look too.


--bb

--bb
Jun 02 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Bill Baxter, el  2 de junio a las 13:44 me escribiste:

 * Staging area (I think that's what the Git boys call it). Again makes
 it easier to get just the things you want into a commit, and nothing
 you don't.


        I'll have to look at this one, any pointer to specific docs I should
 read?


 
 It's demoed in that video I linked to.
 But basically checkin is a two-step process.  Specify what you want to
 go into the commit in step 1, then actually do the commit in step 2.
 (And of course "what you want to go in" can also be parts of files
 instead of whole files.)


It's like the add command in each SCM I've used in my life, but with all
changes. You first add your changes to the index (stage area), entire new
files or small hunks, or whatever, and then commit what's in the stage.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Si pusieramos la máquina de cortar boludos dentro de la máquina del tiempo
y se pusiera a cortar boludos históricos con retroactividad,
otra sería la historieta hoy.
	-- Tato Bores
Jun 02 2009
prev sibling parent =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Bill Baxter wrote:

 2009/6/2 "J=E9r=F4me M. Berger" <jeberger free.fr>:

 Bill Baxter wrote:

 2009/6/2 "J=E9r=F4me M. Berger" <jeberger free.fr>:

 Leandro Lucarella wrote:
       I've started. I'll give you a full report tomorrow when I have=









 tested
 it more completely, but I have to tell you that it doesn't look good=








 for

 Git. Now, I have to ask: have *you* tried Mercurial or Bazaar? And w=








hat,

 in
 your opinion, is the main advantage of Git over the other two?


 My faves:

 * Ability to do commits on particular source line diffs so you don't
 have to do gymnastics to prevent that unrelated one-line fix you made=







 from going into your commit that fixes bug 1234.


 hg record


=20
 Great.  Didn't know about that one.  Is there a gui that will make it
 so you don't have to say yes or no to each one but browse the changes?
   Git's gui does that.  I don't think I'd use that particular feature
 without some kind of gui.   Also I find it nice that the major Git
 commands also work in an ncurses kind of mode.  So you can get some of
 the ease of the gui without actually having to open up a separate
 window.  I think most of curses stuff is working in the msys-git now
 too.
=20


	Record doesn't have a GUI and it is limited to diff chunks instead=20
of being able to operate on line by line basis. However, I just=20
found out about crecord which has a curses GUI and allows to select=20
individual lines.


 * Staging area (I think that's what the Git boys call it). Again make=






s

 it easier to get just the things you want into a commit, and nothing
 you don't.


        I'll have to look at this one, any pointer to specific docs I s=




hould

 read?


=20
 It's demoed in that video I linked to.
 But basically checkin is a two-step process.  Specify what you want to
 go into the commit in step 1, then actually do the commit in step 2.
 (And of course "what you want to go in" can also be parts of files
 instead of whole files.)
=20


	That one is nice and Mercurial doesn't have an equivalent yet.=20
They're working on it, but they want to get the UI right. Here's=20
what they have to say on the subject for the moment:=20
http://www.selenic.com/mercurial/wiki/IndexesExtension

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jun 03 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Bill Baxter, el  2 de junio a las 13:02 me escribiste:

 2009/6/2 "Jérôme M. Berger" <jeberger free.fr>:

 Leandro Lucarella wrote:
        I've started. I'll give you a full report tomorrow when I have
tested
 it more completely, but I have to tell you that it doesn't look good for
 Git. Now, I have to ask: have *you* tried Mercurial or Bazaar? And what, in
 your opinion, is the main advantage of Git over the other two?


 
 My faves:
 
 * Ability to do commits on particular source line diffs so you don't
 have to do gymnastics to prevent that unrelated one-line fix you made
 from going into your commit that fixes bug 1234.
 
 * Staging area (I think that's what the Git boys call it). Again makes
 it easier to get just the things you want into a commit, and nothing
 you don't.


Yes! Yes! Yes! I forgot about that, the staging area/index is a fabulous
approach. It's hard to get used to, but you can't live without it when you
adapt your mind.

And another big feature is git stash. Is so, so, so convenient... Maybe
that place can be taken by MqExtension in hg, but I think is easier in
Git.


 This is a fantastic Git tutorial:
 http://excess.org/article/2008/07/ogre-git-tutorial/
 That's the thing that really convinced me that the Linux folks aren't
 smoking crack and that git really is the way to go, ultimately, even
 on Windows.


Here is a very good kinda-tutorial for Git too:
http://www-cs-students.stanford.edu/~blynn/gitmagic/

BTW, Git has a very clean design on how the repository is organized, and
understanding that, you can almost fully understand Git. I suggest reading
something about it, like:
http://book.git-scm.com/1_the_git_object_model.html

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Pa' ella cociné, pa' ella lavé, pa' ella soñe
Paella completa, $2,50
Pero, la luz mala me tira, y yo? yo soy ligero pa'l trote
La luz buena, está en el monte, allá voy, al horizonte
Jun 02 2009
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Leandro Lucarella wrote:

 Bill Baxter, el  2 de junio a las 13:02 me escribiste:

 * Staging area (I think that's what the Git boys call it). Again makes=





 it easier to get just the things you want into a commit, and nothing
 you don't.


=20
 Yes! Yes! Yes! I forgot about that, the staging area/index is a fabulou=


s

 approach. It's hard to get used to, but you can't live without it when =


you

 adapt your mind.
=20


	This is indeed a nice feature that Mercurial doesn't have yet. I=20
wouldn't go so far as to consider it a killer feature however,=20
especially when you can already do partial commits anyway and all it=20
does is allow you to build a partial commit step by step.


 And another big feature is git stash. Is so, so, so convenient... Maybe=



 that place can be taken by MqExtension in hg, but I think is easier in
 Git.
=20


	Mq cannot take the place of stash. The Git equivalent for Mq is=20
Quilt. Mercurial does have a feature equivalent to stash however,=20
that's in the Attic extension which provides the "shelve" and=20
"unshelve" commands.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jun 03 2009
prev sibling next sibling parent reply "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Tue, 02 Jun 2009 22:29:28 +0300, Jérôme M. Berger <jeberger free.fr> wrote:


 Leandro Lucarella wrote:

 You have a good command-line support.


 	Maybe you do, but that's not the impression the Git fans here were
 giving:
   - Robert Fraser on win32 support: "git's Win32 support via
 TortoiseGit is nearly as good as SVN's now"
   - All the discussion between BCS, hasen and Daniel Keep on
 tortoise git.


I don't get it - how can you assume that just because people say that git has a
good GUI for Windows (TortoiseGit), it doesn't have a decent command-line
version? Making a port of the command-line version is much easier that creating
a Win32 GUI. Like someone else mentioned in this thread - git's Win32
command-line support is now on par with Linux, and it doesn't require you to
install cygwin or use a separate shell (bash).

-- 
Best regards,
 Vladimir                          mailto:thecybershadow gmail.com
Jun 02 2009
next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Vladimir Panteleev wrote:

 On Tue, 02 Jun 2009 22:29:28 +0300, J=C3=A9r=C3=B4me M. Berger <jeberge=


r free.fr> wrote:

=20

 Leandro Lucarella wrote:

 You have a good command-line support.


 	Maybe you do, but that's not the impression the Git fans here were
 giving:
   - Robert Fraser on win32 support: "git's Win32 support via
 TortoiseGit is nearly as good as SVN's now"
   - All the discussion between BCS, hasen and Daniel Keep on
 tortoise git.


=20
 I don't get it - how can you assume that just because people say that g=


it has a good GUI for Windows (TortoiseGit), it doesn't have a decent com=
mand-line version? Making a port of the command-line version is much easi=
er that creating a Win32 GUI. Like someone else mentioned in this thread =
- git's Win32 command-line support is now on par with Linux, and it doesn=
't require you to install cygwin or use a separate shell (bash).

=20


	I said "git support on windows is subpar: it requires cygwin or the=20
msys shell" and people answered: "no, tortoiseGIT is a great GUI".=20
To me, this implied that they couldn't dispute my original claim.=20
Nobody said anything about its command line support until I said=20
that a GUI was not enough.

	Regarding your point about porting a command-line being easier:=20
that is true in theory but not always in practice. Since git is=20
partly written in bash shell scripts, porting it to Windows so that=20
it could run in any shell is not that easy at all.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jun 02 2009
parent Tim Matthews <tim.matthews7 gmail.com> writes:
I use the cygwin git on my windows box and have never used a git gui 
because I just dont trust them.

Jérôme M. Berger wrote:


     I said "git support on windows is subpar: it requires cygwin or the 
 msys shell" 


I don't use the cygwin bash shell but just add C:/cygwin/bin to my path 
and it works fine.

For mercurial/hg this also works but first I created 
C:/cygwin/bin/hg.bat like this as it is python scripts and bash 
understands hash bang line:

 echo off
C:\cygwin\bin\bash.exe -c "/bin/hg %*"
Jun 02 2009
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Vladimir Panteleev wrote:

 On Tue, 02 Jun 2009 22:29:28 +0300, Jérôme M. Berger <jeberger free.fr>
wrote:
 

 Leandro Lucarella wrote:

 You have a good command-line support.


 	Maybe you do, but that's not the impression the Git fans here were
 giving:
   - Robert Fraser on win32 support: "git's Win32 support via
 TortoiseGit is nearly as good as SVN's now"
   - All the discussion between BCS, hasen and Daniel Keep on
 tortoise git.


 
 I don't get it - how can you assume that just because people say that git has
a good GUI for Windows (TortoiseGit), it doesn't have a decent command-line
version? Making a port of the command-line version is much easier that creating
a Win32 GUI. Like someone else mentioned in this thread - git's Win32
command-line support is now on par with Linux, and it doesn't require you to
install cygwin or use a separate shell (bash).
 


FWIW, TortoiseGit is leagues better than TortoiseHg (TortoiseHg doesn't 
even work on 64-bit Windows), and there are fairly complete command-line 
ports of both.
Jun 02 2009
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to Jérôme,


 Leandro Lucarella wrote:
 

 "Jérôme M. Berger", el  1 de junio a las 19:55 me escribiste:
 

 Finally, no matter how good it is, TortoiseGIT is not enough (in the
 same way that TortoiseCVS, TortoiseSVN and TortoiseHg are not
 enough). You need good command-line support so that you can access
 it easily from custom tools (for example to generate releases
 automatically).
 


 You have a good command-line support.
 


 Maybe you do, but that's not the impression the Git fans here were
 giving:


[...]

 - All the discussion between BCS, hasen and Daniel Keep on
 tortoise git.


I hate to butt in, but that thread was more about GUI vs. CLI in general 
and never said anything about any shortcomings of the Git CLI (which BTW, 
I have never used).
Jun 02 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jun 2, 2009 at 4:02 PM, Bill Baxter <wbaxter gmail.com> wrote:

 2009/6/2 "J=E9r=F4me M. Berger" <jeberger free.fr>:

 Leandro Lucarella wrote:
 =A0 =A0 =A0 =A0I've started. I'll give you a full report tomorrow when I=




 have tested

 it more completely, but I have to tell you that it doesn't look good for
 Git. Now, I have to ask: have *you* tried Mercurial or Bazaar? And what,=




 in

 your opinion, is the main advantage of Git over the other two?


 My faves:

 * Ability to do commits on particular source line diffs so you don't
 have to do gymnastics to prevent that unrelated one-line fix you made
 from going into your commit that fixes bug 1234.

 * Staging area (I think that's what the Git boys call it). Again makes
 it easier to get just the things you want into a commit, and nothing
 you don't.


I like the idea of the staging area.  TortoiseSVN has something
similar and I use it quite a bit - when you choose to commit a
directory, you can choose exactly which files you want to commit.  Not
quite line-by-line granularity, but still rather nice.
Jun 02 2009
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
"Jérôme M. Berger", el  2 de junio a las 21:29 me escribiste:

 	I've started. I'll give you a full report tomorrow when I have
 	tested it more completely, but I have to tell you that it doesn't
 	look good for Git. Now, I have to ask: have *you* tried Mercurial
 	or Bazaar? And what, in your opinion, is the main advantage of Git
 	over the other two?


I've tried Mercurial. I'm using it now because some Pythons projects I'm
working with (and LDC) use it. I think I tried Bazaar a long time ago, and
it was awful in terms of usability (or maybe it was GNU arch?), but
I definitely can't speak about Bazaar.

Why I think Git is better? Mainly because of how flexible it is in terms
of repository manipulations (aka git rebase -i [*] =), and because it
supports local branches (I didn't read about how branches are managed in
Mercurial yet, but I understand that Mercurial doesn't support local
branches). And then there are the details, which I mention in another
post:
* Syntax highlight in the output of commands (status, diff, log, branch,
  grep)
* Large output goes through a pager by default
* git add -p / git citool

They are trivialities, but they greatly improve the experience.

And maybe some of this things can be done too with Mercurial, I'm just
starting to learn something about it.

[*] I'm now reading about the MqExtension, which let you do something
    *similar* to rebase -i, but it's much more messy and hackish than Git.


Anyway, I insist that the main point is having DMDFE in a SCM. If Walter
feels comfortable with svn *now*, I think it should be svn *now*. I prefer
some no-ideal SCM *now* than the ideal SCM *in a distant future*. We can
always migrate the repo to something else when the time is right...


 	I agree completely with you there. That's more or less why I asked
 	if we really needed a distributed SCM rather than a simple svn.


Great, I think this is the whole point. Again, I think a DSCM could
improve even more the situation, but any SCM would be a big step forward.


	Moreover, everything I've read on the web seems to indicate that
	git is difficult to use if you want to do more than
	add/commit/update. Mercurial is *very* easy to both setup and use
	on windows as well as linux. I'm less familiar with Bazaar, but
	from what I've seen it's very similar to Mercurial.






I think this is a matter of taste/experience. I find Mercurial much more
harder to use than Git. Git could be hard to *understand* at first, but
I swear it's not hard to *use*. Install is trivial (use the package it
comes with your distribution in Linux or msysgit installer in Windows).

Maybe you have a wrong concept because Git *was* hard to use at the
beginning, there were even "frontends" called porcelains to ease the use
of Git itself. But right now, I think Git is the most usable SCM I've
tried.


Again "I've read". =)
I'm telling you, git is easy, it just a little harder to get used to it,
but it's so much better when you do...


 	Anything concrete to back your affirmation? Maybe all I've said is
 	"I've read", but at least I'm giving reasons.


I'm using it for work, school and spare time projects in a daily basis.
I'm telling from experience. Is really hard to give you reasons (besides
the ones I've put above).


 	All you're saying is "it's better", without saying what makes it
 	better.


I tried to give you a few reasons above, if you need to know how to do
something in particular with Git I'll happily give you an example.


	Finally, no matter how good it is, TortoiseGIT is not enough (in the same way
that TortoiseCVS, TortoiseSVN and TortoiseHg are not enough). You need good 
command-line support so that you can access it easily from custom tools (for
example to generate releases automatically).


You have a good command-line support.


 	Maybe you do, but that's not the impression the Git fans here were giving:
  - Robert Fraser on win32 support: "git's Win32 support via TortoiseGit is
nearly as good as SVN's now"
  - All the discussion between BCS, hasen and Daniel Keep on tortoise git.


TortoiseGIT is not command line =)


Having a DSCM would make things easier for people that integrates DMDFE in other
projects than DMD.


 	If you say so...


Come on! Is easier to pull and merge patches, you don't have to do it by
hand! Just do git pull or hg pull you are set!

Well, if you use Git you can always use git-svn and feel at home, but
still =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
In Minnesota there's a law
That prevents men from having sex with living fish
Jun 02 2009
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Leandro Lucarella wrote:

 "J=C3=A9r=C3=B4me M. Berger", el  2 de junio a las 21:29 me escribiste:=



 	I've started. I'll give you a full report tomorrow when I have
 	tested it more completely, but I have to tell you that it doesn't
 	look good for Git. Now, I have to ask: have *you* tried Mercurial
 	or Bazaar? And what, in your opinion, is the main advantage of Git
 	over the other two?


=20
 I've tried Mercurial. I'm using it now because some Pythons projects I'=


m

 working with (and LDC) use it. I think I tried Bazaar a long time ago, =


and

 it was awful in terms of usability (or maybe it was GNU arch?), but
 I definitely can't speak about Bazaar.
=20
 Why I think Git is better? Mainly because of how flexible it is in term=


s

 of repository manipulations (aka git rebase -i [*] =3D),


	First I should say that I consider rebase to be a complete=20
misfeature of any version control system. One of the main points of=20
version control is that you can go back in time to find when, where=20
and how a bug appeared (which makes the "bisect" command, which both=20
Git and Mercurial have, *the* killer feature of any SCM).

	Second, Mercurial has three ways to do what "git rebase" does:
- The first is the Rebase extension, which does the same thing with=20
the same drawbacks;
- The second is the Transplant extension, which *copies* the=20
changesets instead of moving them, so you keep the old history (you=20
can always use "strip" to remove it later if you really want to);
- And the third is to simply merge your changes with the incoming=20
changesets with "hg merge".


 and because it
 supports local branches (I didn't read about how branches are managed i=


n

 Mercurial yet, but I understand that Mercurial doesn't support local
 branches).


	It does through the LocalBranch extension.


 And then there are the details, which I mention in another
 post:
 * Syntax highlight in the output of commands (status, diff, log, branch=


,

   grep)


	This didn't work out of the box for me on Windows. I haven't tried=20
to activate it, so I don't know if it cans.

	Mercurial has it too on Linux. The Windows version will be=20
available as soon as I have the time to clean up the patch and send=20
it upstream :)


 * Large output goes through a pager by default


	I actually don't like that one, but Mercurial has it too with the=20
AutoPager extension.=09


 * git add -p=20


	I've read the help on that one and I still don't understand what it=20
does: According to the help it is the "same as interactive except=20
it's not"???


 git citool
=20


	Available through the qct extension.


 I think this is a matter of taste/experience. I find Mercurial much mor=


e

 harder to use than Git. Git could be hard to *understand* at first, but=



 I swear it's not hard to *use*. Install is trivial (use the package it
 comes with your distribution in Linux or msysgit installer in Windows).=



=20


	"Understand at first" and "Use" are almost the same. The only time=20
they will differ is if the first masks some extra features that the=20
second doesn't have, but this does not seem to be the case here.


 	Finally, no matter how good it is, TortoiseGIT is not enough (in th=








e same way that TortoiseCVS, TortoiseSVN and TortoiseHg are not enough). =
You need good=20

 command-line support so that you can access it easily from custom to=








ols (for example to generate releases automatically).

 You have a good command-line support.


 	Maybe you do, but that's not the impression the Git fans here were gi=




ving:

  - Robert Fraser on win32 support: "git's Win32 support via TortoiseGi=




t is nearly as good as SVN's now"

  - All the discussion between BCS, hasen and Daniel Keep on tortoise g=




it.

=20
 TortoiseGIT is not command line =3D)
=20


	Precisely my point.


 Having a DSCM would make things easier for people that integrates DMD=






FE in other

 projects than DMD.


 	If you say so...


=20
 Come on! Is easier to pull and merge patches, you don't have to do it b=


y

 hand! Just do git pull or hg pull you are set!
=20


	Well, just do "svn update" and you are set :) DSCMs are useful when=20
your development follows the "Bazaar" model (*) with lots of=20
contributors working independently and exchanging their=20
modifications. They are much less useful if you follow the=20
"Cathedral" model, with a strict hierarchy and a small number of=20
actual committers.

	I'd say that the main point when choosing between a centralized and=20
distributed SCM is the number of actual committers, not the number=20
of users. For users, pulling the changes from a distributed system=20
is exactly the same as pulling them from a centralized repository.

	Again, I'm not really arguing against DSCMs in general here. I'm=20
mainly saying that there is no point in going for a DSCM later if we=20
can have a centralized SCM now, since the DSCM won't bring that many=20
advantages for D anyway.

		Jerome

(*)=20
http://webyes.com.br/wp-content/uploads/ebooks/book_cathedral_bazaar.pdf =



--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jun 03 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
"Jérôme M. Berger", el  3 de junio a las 23:09 me escribiste:

 Leandro Lucarella wrote:

"Jérôme M. Berger", el  2 de junio a las 21:29 me escribiste:

	I've started. I'll give you a full report tomorrow when I have
	tested it more completely, but I have to tell you that it doesn't
	look good for Git. Now, I have to ask: have *you* tried Mercurial
	or Bazaar? And what, in your opinion, is the main advantage of Git
	over the other two?


I've tried Mercurial. I'm using it now because some Pythons projects I'm
working with (and LDC) use it. I think I tried Bazaar a long time ago, and
it was awful in terms of usability (or maybe it was GNU arch?), but
I definitely can't speak about Bazaar.
Why I think Git is better? Mainly because of how flexible it is in terms
of repository manipulations (aka git rebase -i [*] =),


 
 	First I should say that I consider rebase to be a complete
 	misfeature of any version control system. One of the main points
 	of version control is that you can go back in time to find when,
 	where and how a bug appeared (which makes the "bisect" command,
 	which both Git and Mercurial have, *the* killer feature of any
 	SCM).


Rebase is crucial for some open distributed development model, like the
Linux kernel one. People send patches, other people review and critize
them so they get amended and resent. All this *before* the actual commit
is done. Is amazing how bad tend to get the commits when this model is not
encouraged (I see "ooops! forgot to add one file in the previous
commit"-kind of commits everywere and it just make me mad =). Specially
when you want "bisect" to work! That kind of changes don't even compile
and break "bisect"!


 	Second, Mercurial has three ways to do what "git rebase" does:
 - The first is the Rebase extension, which does the same thing with the same
drawbacks;


I have to take a look at it.


 - The second is the Transplant extension, which *copies* the changesets
 instead of moving them, so you keep the old history (you can always use
 "strip" to remove it later if you really want to);


In git you always keep the old history unless you run the gc (or well,
it's ran automatically if you don't configure it otherwise). You can
always make a local branch if you *really really* feel like you must keep
the old history ;)


 - And the third is to simply merge your changes with the incoming changesets
with "hg merge".


That's a merge, not a rebase =)


and because it
supports local branches (I didn't read about how branches are managed in
Mercurial yet, but I understand that Mercurial doesn't support local
branches).


 	It does through the LocalBranch extension.


Ok, lots of extensions! =O


* Large output goes through a pager by default


 
 	I actually don't like that one, but Mercurial has it too with the AutoPager
extension.	


If you mean this:
http://bitbucket.org/brodie/autopager/overview/

I just tried it but I get this error:
abort: could not import module encoding!
=/


* git add -p 


 	I've read the help on that one and I still don't understand what it does:
According to the help it is the "same as interactive except it's not"???


Is hg record but you with some extra options. Git add -i has even more
options ;)


git citool


 	Available through the qct extension.


Ok, it seems there is Mercurial, and Mercurial+lots of extensions. They
seems to be 2 different SCMs =)

And wait, that an entire third-party application!


Having a DSCM would make things easier for people that integrates DMDFE in other
projects than DMD.


	If you say so...


Come on! Is easier to pull and merge patches, you don't have to do it by
hand! Just do git pull or hg pull you are set!


 	Well, just do "svn update" and you are set :) DSCMs are useful
 	when your development follows the "Bazaar" model (*) with lots of
 	contributors working independently and exchanging their
 	modifications. They are much less useful if you follow the
 	"Cathedral" model, with a strict hierarchy and a small number of
 	actual committers.


svn now nothing about merges, conflicts will be much more common.


 	I'd say that the main point when choosing between a centralized
 	and distributed SCM is the number of actual committers, not the
 	number of users.


I completelly disagree. I wont consider using svn even for personal
projects because it lacks so many features, and is so slow it makes me
want to cry =)

For example, being able to amend patches is a must for me. But we are
getting too much in personal taste here.


 	For users, pulling the changes from a distributed
 	system is exactly the same as pulling them from a centralized
 	repository.


That's not true! DSCM does extremely better job merging than CSCM (at
least Git does). And you can't even maintain your own branch! That's
useless for LDC for example[*].


 	Again, I'm not really arguing against DSCMs in general here. I'm
 	mainly saying that there is no point in going for a DSCM later if
 	we can have a centralized SCM now, since the DSCM won't bring that
 	many advantages for D anyway.


And I still think you are wrong =)

But anyways, this is getting way too off-topic, and Walter didn't even
talked about it after saying "nice idea" so I think I'll stop posting in
this thread for now.

Thanks for all the nice Mercurial tips, I hope they make my Mercurial
experience a little happier =)

[*] I mean, for LDC, is the same if Walter post raw patches with a nice
comment about what the do or if he use SVN. You can't modify your own copy
of a SVN repo without committing. Having those nice patches with nice
comments are a *huge* step still, and that's why I prefer to have SVN over
nothing, because I know Walter won't post raw patches ever ;)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Parece McGuevara's o CheDonald's
Jun 03 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Wed, Jun 3, 2009 at 3:14 PM, Leandro Lucarella <llucax gmail.com> wrote:

and because it
supports local branches (I didn't read about how branches are managed i=






n

Mercurial yet, but I understand that Mercurial doesn't support local
branches).


 =A0 =A0 =A0 It does through the LocalBranch extension.


 Ok, lots of extensions! =3DO


This lots of extensions thing does make me nervous.  The idea of
making an SCM pluggable is nice in many ways, but the fact that these
things are not included means you're subject to version
incompatibilities and some plugins working on Unix but not Windows,
and maybe just plugins that aren't QA'ed very well, or plugins that
conflict with other plugins, or competing plugins that do very similar
things but don't work well together.

All this makes me really prefer to get all the key bits of my SCM from
one source.  Then, for instance, I know that that source will consider
it *their* problem if, say, the XYZ function doesn't work on Windows.
I.e. you're less likely to find yourself in a situation where core
devs say the XYZ plugin solves your problem so they won't fix it, but
XYZ doesn't work and the guys that made XYZ have disappeared or happen
not to care about your platform.

Does that make sense?  I feel pretty confident that all the commands
that come with git play nice with each other (or at least the ways in
which they don't are clearly documented).   I feel less so about a
loose confederation of plugins from various sources.

--bb
Jun 03 2009
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Bill Baxter, el  3 de junio a las 15:35 me escribiste:

 Does that make sense?  I feel pretty confident that all the commands
 that come with git play nice with each other (or at least the ways in
 which they don't are clearly documented).   I feel less so about a
 loose confederation of plugins from various sources.


Same here, for example, I'm seeing the AtticExtension[1] now, and there is
a lot of feature duplication with MqExtension and other extensions too
(ShelveExtension, PatchBranchExtension).

[1] http://www.selenic.com/mercurial/wiki/AtticExtension

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Your success is measured by your ability to finish things
Jun 03 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Leandro Lucarella, el  3 de junio a las 19:51 me escribiste:

 Bill Baxter, el  3 de junio a las 15:35 me escribiste:

 Does that make sense?  I feel pretty confident that all the commands
 that come with git play nice with each other (or at least the ways in
 which they don't are clearly documented).   I feel less so about a
 loose confederation of plugins from various sources.


 
 Same here, for example, I'm seeing the AtticExtension[1] now, and there is
 a lot of feature duplication with MqExtension and other extensions too
 (ShelveExtension, PatchBranchExtension).


I'm having another problem because of this. The qct extension (~= git
citool) doesn't work if the color extension is enabled (the files show
with the color codes and qct gets confused).

Bummer!

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
3 people die every year, testing if a 9 volts battery works on their tongue
Jun 04 2009
prev sibling parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Bill Baxter wrote:

 On Wed, Jun 3, 2009 at 3:14 PM, Leandro Lucarella <llucax gmail.com> wr=


ote:

 and because it
 supports local branches (I didn't read about how branches are manage=








d in

 Mercurial yet, but I understand that Mercurial doesn't support local=









 branches).


       It does through the LocalBranch extension.


 Ok, lots of extensions! =3DO


=20
 This lots of extensions thing does make me nervous.  The idea of
 making an SCM pluggable is nice in many ways, but the fact that these
 things are not included means you're subject to version
 incompatibilities and some plugins working on Unix but not Windows,
 and maybe just plugins that aren't QA'ed very well, or plugins that
 conflict with other plugins, or competing plugins that do very similar
 things but don't work well together.
=20
 All this makes me really prefer to get all the key bits of my SCM from
 one source.  Then, for instance, I know that that source will consider
 it *their* problem if, say, the XYZ function doesn't work on Windows.
 I.e. you're less likely to find yourself in a situation where core
 devs say the XYZ plugin solves your problem so they won't fix it, but
 XYZ doesn't work and the guys that made XYZ have disappeared or happen
 not to care about your platform.
=20
 Does that make sense?  I feel pretty confident that all the commands
 that come with git play nice with each other (or at least the ways in
 which they don't are clearly documented).   I feel less so about a
 loose confederation of plugins from various sources.
=20


	Note that a lot of these "extensions" are maintained by the core=20
Mercurial team and distributed as part of the official Mercurial=20
releases. With git, you have over a hundred executables hidden in=20
the lib folder and only some of them get called depending on the=20
commands you call and the options you set. In Mercurial some of=20
those are called "extensions" and the nice thing is that you are not=20
limited to those that come with the official release.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jun 04 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
2009/6/4 "J=E9r=F4me M. Berger" <jeberger free.fr>:

 Bill Baxter wrote:

 On Wed, Jun 3, 2009 at 3:14 PM, Leandro Lucarella <llucax gmail.com>
 wrote:

 and because it
 supports local branches (I didn't read about how branches are managed
 in
 Mercurial yet, but I understand that Mercurial doesn't support local
 branches).


 =A0 =A0 =A0It does through the LocalBranch extension.


 Ok, lots of extensions! =3DO


 This lots of extensions thing does make me nervous. =A0The idea of
 making an SCM pluggable is nice in many ways, but the fact that these
 things are not included means you're subject to version
 incompatibilities and some plugins working on Unix but not Windows,
 and maybe just plugins that aren't QA'ed very well, or plugins that
 conflict with other plugins, or competing plugins that do very similar
 things but don't work well together.

 All this makes me really prefer to get all the key bits of my SCM from
 one source. =A0Then, for instance, I know that that source will consider
 it *their* problem if, say, the XYZ function doesn't work on Windows.
 I.e. you're less likely to find yourself in a situation where core
 devs say the XYZ plugin solves your problem so they won't fix it, but
 XYZ doesn't work and the guys that made XYZ have disappeared or happen
 not to care about your platform.

 Does that make sense? =A0I feel pretty confident that all the commands
 that come with git play nice with each other (or at least the ways in
 which they don't are clearly documented). =A0 I feel less so about a
 loose confederation of plugins from various sources.


 =A0 =A0 =A0 =A0Note that a lot of these "extensions" are maintained by th=


e core

 Mercurial team and distributed as part of the official Mercurial releases=


.

 With git, you have over a hundred executables hidden in the lib folder an=


d

 only some of them get called depending on the commands you call and the
 options you set. In Mercurial some of those are called "extensions" and t=


he

 nice thing is that you are not limited to those that come with the offici=


al

 release.


Yeh, I have to believe that eventually things will settle down, and
all the plugins that prove to be indispensable will be folded into the
Mercurial core.

Similarly I'm pretty sure the remaining issues with Git on Windows
will be fixed before too long.

As for ability to add functionality to Hg vs Git, I'm talking out of
my ass here, but my guess is what you're seeing there with those 100
commands in the Git directory is basically the Git "plug-in API".  It
just happens to be exposed as shell commands, instead of Python entry
points like you find in Mercurial's API.  At least I seem to recall
reading somewhere that Git was designed like Unix, with lots of little
commands that do one specific thing, and higher-level commands built
out of those lower-level commands.

But anyway, I don't think anyone has yet pointed out a single
functionality so far that Mercurial has (in plugin or otherwise) which
Git does not.  So whether or not you can extend Git as easily as
Mercurial may be kind of a moot point.

--bb
Jun 04 2009
parent =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Bill Baxter wrote:

 As for ability to add functionality to Hg vs Git, I'm talking out of
 my ass here, but my guess is what you're seeing there with those 100
 commands in the Git directory is basically the Git "plug-in API".  It
 just happens to be exposed as shell commands, instead of Python entry
 points like you find in Mercurial's API.  At least I seem to recall
 reading somewhere that Git was designed like Unix, with lots of little
 commands that do one specific thing, and higher-level commands built
 out of those lower-level commands.
=20


	I wasn't really talking about the ways to add functionality to=20
Mercurial or Git. I was more, like, pointing out that Git has over a=20
hundred "plugins" in the form of executables and shell scripts in=20
the same way that Mercurial has "plugins" in the form of extensions=20
in hgext. That was in answer to your: "This lots of extensions thing=20
does make me nervous.": most of the so-called "extensions" are=20
simply optional functions that come with Mercurial and can be=20
enabled or disabled at will. Some of the equivalent features don't=20
need to be activated with Git and some need to be enabled (or=20
disabled) through global options. Six of one, half a dozen of the=20
other I think.


 But anyway, I don't think anyone has yet pointed out a single
 functionality so far that Mercurial has (in plugin or otherwise) which
 Git does not.  So whether or not you can extend Git as easily as
 Mercurial may be kind of a moot point.
=20


	"Works on Windows without problems"? "Easier to learn"? "Better=20
documentation"? ;) Conversely, the only Git feature that Mercurial=20
doesn't have is the staging area. I'll take "works on Windows=20
without problems" over that one any day ;)

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jun 04 2009
prev sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Leandro Lucarella wrote:

 Rebase is crucial for some open distributed development model, like the=



 Linux kernel one. People send patches, other people review and critize
 them so they get amended and resent. All this *before* the actual commi=


t

 is done. Is amazing how bad tend to get the commits when this model is =


not

 encouraged (I see "ooops! forgot to add one file in the previous
 commit"-kind of commits everywere and it just make me mad =3D). Special=


ly

 when you want "bisect" to work! That kind of changes don't even compile=



 and break "bisect"!
=20


	So? This is a basic code review procedure: send a patch, have it=20
reviewed, send an updated patch. You don't need "rebase" for that.


 - The second is the Transplant extension, which *copies* the changeset=




s

 instead of moving them, so you keep the old history (you can always us=




e

 "strip" to remove it later if you really want to);


=20
 In git you always keep the old history unless you run the gc (or well,
 it's ran automatically if you don't configure it otherwise). You can
 always make a local branch if you *really really* feel like you must ke=


ep

 the old history ;)
=20


	The default behaviour should be the safe one (I believe I've heard=20
that more than once on this ng ;)


 - And the third is to simply merge your changes with the incoming chan=




gesets with "hg merge".

=20
 That's a merge, not a rebase =3D)
=20


	The point was that "rebase" doesn't bring all that much advantage=20
over a merge.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jun 04 2009
prev sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
J=C3=A9r=C3=B4me M. Berger wrote:

 Leandro Lucarella wrote:

 Why don't you test it and stop talking about what you think it's going=




 on

 and start talking about what's *really* going on.

 It doesn't seems very fair to discard something just because you have =




the

 feeling that it wouldn't work well (specially when other people use it=




=20

 and
 say it works well).


     I've started. I'll give you a full report tomorrow when I have=20
 tested it more completely.


	Okay, here goes. For those who don't want to read the whole text,=20
here's the short version:
- Git has one nice feature that Mercurial doesn't have yet, and=20
that's the staging area;
- Git isn't ready for production use on Windows. If you want to use=20
it, go ahead but don't go crying if something goes wrong (the=20
details are in the "Status" section below);
- Git's command are not very intuitive (especially coming from CVS=20
or SVN), which makes it difficult to start using it (no matter how=20
easy you may find it later on);
- Git's built-in help system is pretty bad: it is difficult to find=20
the information you want and instead of giving you the information,=20
git will start a web browser to display it.

	And here's the long version:


Introduction
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I've run a quick comparison of Git and Mercurial on Windows. The=20
tests consisted of importing a Subversion repository with 364=20
revisions, then running some standard commands: help, clone, log,=20
status, diff, commit.

Git version used: 1.6.3.msysgit.0
Mercurial version used: 1.2.1 + custom patch to enable coloured=20
output on Windows.

Install
=3D=3D=3D=3D=3D=3D=3D

Ok, no problem. Git has made a lot of progress here.


Import from svn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Git is sloooowwwww (a couple of hours to import, Mercurial did it in=20
about five minutes). But then you don't import an SVN repository=20
everyday, so speed isn't that much of an issue here (actually I only=20
imported that svn repository to have some real life data rather than=20
testing on a mostly empty artificial repository, not to test SVN=20
import per se).


Help
=3D=3D=3D=3D

Git's help is unusable. It took me way too long to find out how to=20
revert the changed files so that the working folder reflects the=20
content of the repository and how to update the files to a specific=20
version.

Git launches a web browser instead of giving me the info I want=20
directly. I then need to close the browser window or go back to the=20
shell before I can continue. Plus, if I need to check on something,=20
I need to switch back and forth between the browser and the shell=20
instead of simply scrolling the shell window.

While I wouldn't be against a command/option to start the browser,=20
the default behaviour should be to print the info directly in the=20
terminal.

A nice thing about Mercurial: I can type either "hg help cmd" or "hg=20
cmd help" to get help. Git only recognizes the first form.


Clone
=3D=3D=3D=3D=3D

Command syntax is the same. Git took 57s where Mercurial only took 17s.


Log
=3D=3D=3D

Mercurial can identify a changeset with a simple number (valid only=20
in the current repository), a short hash (valid anywhere so long as=20
there are no collisions) or a long hash. The default behaviour is to=20
only show the number and short hash, which is much more=20
user-friendly. From what I could tell, git only uses long hashes?

Default log output is much more readable in Mercurial:
- Like I said above, changeset numer + short hash is easier to=20
identify than full hash;
- The different changesets are immediately identifiable. In git, it=20
is not easy to see where the info for one commit ends and the next=20
begins;

Clock time: 1.1s for Mercurial, 1.4s for Git.


Status
=3D=3D=3D=3D=3D=3D

Git reported some modified files immediately after the clone and=20
even though I hadn't changed anything and the files were identical=20
to the original folder, in which Git didn't report any modified=20
files. I was unable to fix it so that "status" reported no changes=20
(even deleting the files and checking them out again didn't fix it).

The problem is probably due to incorrect handling of line endings,=20
but I have been unable to determine the precise conditions that make=20
it manifest on those files and not others. This does not exactly=20
fill me with confidence for Git's reliability as a whole.

- Time for an empty status report: 1s for Mercurial, 1.1s for Git;
- Time for a status report with an added unknown file: 0.4s for=20
Mercurial, 1s for Git (obviously, we have reached the precision of=20
my timing method);
- Time for a status report with a changed file: 1s each.


Commit
=3D=3D=3D=3D=3D=3D

Git has three ways to commit files to the repository:

- Commit everything with "git commit -a";
- Commit only some files with "git commit file1 file2...";
- The staging area. This allows you to specify which files (or which=20
changes) you want to commit using "git add" before doing the actual=20
commit with "git commit". This is nice for some complicated=20
situations, but I feel that it is not that common.

Mercurial currently only supports the first two ways. Reflections=20
are in progress to add the third way, but they want to design the UI=20
properly before implementing it:=20
http://www.selenic.com/mercurial/wiki/IndexesExtension


General Remarks
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I found the Mercurial command line much easier to use than Git's.=20
For example:

- Mercurial and Git both have global options which apply to all=20
commands and specific options that only apply to the current=20
command. With Mercurial, the options may be put in any order, and in=20
particular, you can do "hg cmd <options>". With Git the global=20
options must be put before the command and the specific options must=20
be put after: "git <global options> cmd <specific options>";

- Mercurial accepts either "hg help cmd" or "hg cmd help". Git only=20
accepts "git help cmd";

- Mercurial command names are much more intuitive (especially coming=20
from cvs/svn). For example, in order to return a modified file to=20
its repository state: "cvs revert", "svn revert", "hg revert", "git=20
checkout". Even in absolute terms, "checkout" is not the first word=20
that comes to mind, I would have understood "revert" (obviously),=20
"restore", "backout" or an extra option to "update" (which Git=20
doesn't have anyway).

- Default Git behaviour is to send command output to a pager.=20
Default Mercurial behaviour is to simply send it to the terminal. I=20
personally prefer Mercurial's way, but this can be argued either=20
way. Anyway, it is possible to change the default.

The speed difference isn't that big or important for most=20
operations, except for clone.

Mercurial is also slightly better in terms of disk space used,=20
although this does not mean much given the capacity of today's HDDs.

Git is supposed to have coloured output, but it wasn't enabled by=20
default and I didn't try to find how to do it. Mercurial has=20
coloured output on Unix, but not on Windows (I have written a patch=20
to allow it to work on Windows but I haven't sent it upstream yet).


Conclusion
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Git weak points:
- speed (although most common operations are fast enough that it=20
shouldn't really be a problem except for "clone");
- unintuitive command names;
- poor help system;
- inconsistent behaviour of the status command which may hide other=20
more serious problems.

Git strong points:
- the staging area is a nice feature with no Mercurial equivalent=20
(although they're working on it). But I wouldn't call it a killer=20
feature.

Note that all my tests were done on Windows. It is quite possible=20
that the speed and inconsistent behaviour issues would not occur on=20
Unix, but they are enough to justify my claims that Git doesn't=20
really work on Windows.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jun 03 2009
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
"Jérôme M. Berger", el  3 de junio a las 22:24 me escribiste:

 Jérôme M. Berger wrote:

Leandro Lucarella wrote:

Why don't you test it and stop talking about what you think it's going on
and start talking about what's *really* going on.

It doesn't seems very fair to discard something just because you have the
feeling that it wouldn't work well (specially when other people use it and
say it works well).


    I've started. I'll give you a full report tomorrow when I have tested it
more completely.


 
 	Okay, here goes. For those who don't want to read the whole text, here's the
short version:


Thanks for your report.


 - Git has one nice feature that Mercurial doesn't have yet, and that's the
staging area;


It has more, I finished reading about MqExtensions and is way far away
from what you can do with git (specially git rebase -i), and how natural
is to do it in Git. But what the hell =)


 - Git isn't ready for production use on Windows. If you want to use it,
 go ahead but don't go crying if something goes wrong (the details are in
 the "Status" section below);


It's a shame you don't find it ready for production use =(
(other people does, so I guess is subjective)


 - Git's command are not very intuitive (especially coming from CVS or
 SVN), which makes it difficult to start using it (no matter how easy you
 may find it later on);


True. IMHO this is why Git is so much easy to use when you diverge from
the basic usage from a CSCM like CVS/SVN. Is a trade-off, and I think Git
made the right trade-off (is not that different either when using the
basic commands).


 - Git's built-in help system is pretty bad: it is difficult to find the
 information you want and instead of giving you the information, git will
 start a web browser to display it.


That really sucks. On Unix git cmd --help lunches the man page, wich is really
nice to me. If you need a quick summary, git cmd -h is for you.

You can configure how Git does show the help, from git config manual:

       help.format
           Override the default help format used by git-help(1). Values man,
           info, web and html are supported.  man is the default.  web and
           html are the same.

I don't know why it opens a web browser by default in Windows, seems pretty
lame =/

Maybe msysgit doesn't come with the man/info command? Try:
git config --global help.format man


 Help
 ====
 
 Git's help is unusable. It took me way too long to find out how to revert the
changed files so that the working folder reflects the content of the repository 
 and how to update the files to a specific version.
 
 Git launches a web browser instead of giving me the info I want directly. I
then need to close the browser window or go back to the shell before I can 
 continue. Plus, if I need to check on something, I need to switch back and
forth between the browser and the shell instead of simply scrolling the shell 
 window.
 
 While I wouldn't be against a command/option to start the browser, the default
behaviour should be to print the info directly in the terminal.
 
 A nice thing about Mercurial: I can type either "hg help cmd" or "hg cmd help"
to get help. Git only recognizes the first form.


Just as a sidenote, and as I said, you can use git cmd --help for the complete
manual page or git cmd -h for a quick summary (in Unix at least).


 Log
 ===
 
 Mercurial can identify a changeset with a simple number (valid only in the
current repository), a short hash (valid anywhere so long as there are no 
 collisions) or a long hash. The default behaviour is to only show the number
and short hash, which is much more user-friendly. From what I could tell, git 
 only uses long hashes?


You can use short hashes too (you can use the 4 first chars or more if it
is ambiguous). I agree that the Mercurial short consecutive number is nice
and handy.


 Default log output is much more readable in Mercurial:
 - Like I said above, changeset numer + short hash is easier to identify than
full hash;
 - The different changesets are immediately identifiable. In git, it is not
easy to see where the info for one commit ends and the next begins;


Well, this is a matter of taste, I find Git log much more readable =)
If you need a very compact log, use git log --oneline. This is an example
output (from the Linux kernel repo):

8d7bff2 Linux 2.6.29.1
bb70446 V4L: v4l2-common: remove incorrect MODULE test
5d8a29a sparc64: Fix reset hangs on Niagara systems.
b6816b7 sparc64: Flush TLB before releasing pages.
8796fc2 sparc64: Fix MM refcount check in smp_flush_tlb_pending().
716fd1d KVM: MMU: Fix another largepage memory leak
cbb76e6 cfg80211: fix incorrect assumption on last_request for 11d
4d25e3d lguest: fix spurious BUG_ON() on invalid guest stack.
ab62416 lguest: wire up pte_update/pte_update_defer
73dffc3 VM, x86, PAT: Change is_linear_pfn_mapping to not use vm_pgoff
67df642 x86: mtrr: don't modify RdDram/WrDram bits of fixed MTRRs
178e047 x86: ptrace, bts: fix an unreachable statement
393c205 x86: fix 64k corruption-check
4a78cb5 x86, uv: fix cpumask iterator in uv_bau_init()
e1b427a x86, PAT, PCI: Change vma prot in pci_mmap to reflect inherited prot

You can change the default format via (system|global|local) configuration.
From git config manual:

       format.pretty
           The default pretty format for log/show/whatchanged command, See
           git-log(1), git-show(1), git-whatchanged(1).

You have a few predefined formats: oneline, short (this is the one that
looks more like the hg format), medium, full, fuller, email and raw. If
you don't like those, you can use your own format. For example:
$ git log --pretty=format:"changeset:   %h%nuser:        %an <%ae>%ndate:      
 %ad%nsummary:     %s%n"
changeset:   8d7bff2
user:        Chris Wright <chrisw sous-sol.org>
date:        Thu Apr 2 13:55:27 2009 -0700
summary:     Linux 2.6.29.1

changeset:   bb70446
user:        Hans Verkuil <hverkuil xs4all.nl>
date:        Tue Mar 31 09:23:04 2009 -0400
summary:     V4L: v4l2-common: remove incorrect MODULE test

changeset:   5d8a29a
user:        David S. Miller <davem davemloft.net>
date:        Sun Mar 29 15:40:33 2009 -0700
summary:     sparc64: Fix reset hangs on Niagara systems.

[...]

If you want to make it the default just add:
[format]
        pretty = "format:changeset:   %h%nuser:        %an <%ae>%ndate:       
ad%nsummary:     %s%n"
To the .git/config.


 Status
 ======
 
 Git reported some modified files immediately after the clone and even
 though I hadn't changed anything and the files were identical to the
 original folder, in which Git didn't report any modified files. I was
 unable to fix it so that "status" reported no changes (even deleting the
 files and checking them out again didn't fix it).
 
 The problem is probably due to incorrect handling of line endings, but
 I have been unable to determine the precise conditions that make it
 manifest on those files and not others. This does not exactly fill me
 with confidence for Git's reliability as a whole.


That's odd. =/


 Commit
 ======
 
 Git has three ways to commit files to the repository:
 
 - Commit everything with "git commit -a";
 - Commit only some files with "git commit file1 file2...";
 - The staging area. This allows you to specify which files (or which changes)
you want to commit using "git add" before doing the actual commit with "git 
 commit". This is nice for some complicated situations, but I feel that it is
not that common.


The truth is Git supports just one way to commit stuff and it's always
through the staging area. git commit -a and git commit f1 f2 ... are just
shortcuts for git add [every "dirty" file] && git commit and git add f1 f2
... && git commit respectively. git add is where the magic happens, try
git add -p and git add -i. You can even edit the patch to apply in the
staging are without actually modifying any files! =P

Git gui/citool are really useful too to manipulate the staging area. Very
handy to pick which changes to commit (with a line by line granularity!).


 Mercurial currently only supports the first two ways. Reflections are in
 progress to add the third way, but they want to design the UI properly
 before implementing it:
 http://www.selenic.com/mercurial/wiki/IndexesExtension


Ok. It looks like at the end most SCM will offer exactly the same
features (all of them!) and it will be just a matter of implementation =P

What I like from Git is that it was designed that way, and all the things
that Mercurial handles to add using extensions comes very natural with the
Git design.


 General Remarks
 ===============
 
 I found the Mercurial command line much easier to use than Git's. For example:
 
 - Mercurial and Git both have global options which apply to all commands
 and specific options that only apply to the current command. With
 Mercurial, the options may be put in any order, and in particular, you
 can do "hg cmd <options>". With Git the global options must be put
 before the command and the specific options must be put after: "git
 <global options> cmd <specific options>";


I never noticed that. I think because I think I never used git "global"
options. What are you using?


 - Mercurial accepts either "hg help cmd" or "hg cmd help". Git only accepts
"git help cmd";


Technically true, but practically not true =)


 - Mercurial command names are much more intuitive (especially coming
 from cvs/svn). For example, in order to return a modified file to its
 repository state: "cvs revert", "svn revert", "hg revert", "git
 checkout". Even in absolute terms, "checkout" is not the first word that
 comes to mind, I would have understood "revert" (obviously), "restore",
 "backout" or an extra option to "update" (which Git doesn't have
 anyway).


I think the Git names are right. It's true that it is not intuitive when
coming from SVN/CVS, but what you are doing with that command is exactly
that. You are checking out the file again (overwriting the current file).
When you understand Git, that name makes perfect sense =)

You can't use an alias for revert because it already is a Git command, but
in other cases you can setup an alias:
git config --global alias.revert2 checkout

Now you can use git revert2 to checkout (revert? ;) a file.

About update, git doesn't have update because you have more flexibility on
how to "update" the repo. You can merge the changes (Mercurial default
and, AFAIK, only way, unless you make the trickery yourself using mq), or
you can *rebase* your changes (that is, remove your changes from the tree
until the common parent, apply the changes from the branch you are
"updating" to, then re-apply all your changes; no merges are involved).
Maybe you think this is not useful, but it is. Mercurial have an especial
section explaining how to do this using mq (which by the way is really
messy).

If you want something like hg pull, then use git fetch (or git remote
update). If you want something like hg pull -u, the use git pull (which is
a shortcut for git fetch + git merge). If you want to rebase your changes,
use git pull --rebase (which is a shortcut for git fetch + git rebase).

Again, when you understand how Git works, all the commands makes perfect
sense. I agree that at first is a little confusing.


 - Default Git behaviour is to send command output to a pager. Default
 Mercurial behaviour is to simply send it to the terminal. I personally
 prefer Mercurial's way, but this can be argued either way. Anyway, it is
 possible to change the default.


Is possible to change the default in Mercurial? How? I hate to pipe
through the pager myself =)


 Mercurial is also slightly better in terms of disk space used, although
 this does not mean much given the capacity of today's HDDs.


Git have a packing mechanism that is ran when some heuristics detects too
much space is wasted. You can try: git gc


 Git is supposed to have coloured output, but it wasn't enabled by
 default and I didn't try to find how to do it. Mercurial has coloured
 output on Unix, but not on Windows (I have written a patch to allow it
 to work on Windows but I haven't sent it upstream yet).


Mercurial doesn't have coloured output in Unix (at least Debian package
1.2.1). How can I turn it on? AFAIK git uses colouring by default for just
some commands (log for example). You can activate all colouring in Git
with this: git config --global color.ui=auto

(auto if for terminal detection, so output don't get coloured when it's
piped or something, you can use "always" or "never" too)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Relax.
I'll need some information first.
Just the basic facts.
Can you show me where it hurts?
Jun 03 2009
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Leandro Lucarella wrote:

 "J=C3=A9r=C3=B4me M. Berger", el  3 de junio a las 22:24 me escribiste:=



 Commit
 =3D=3D=3D=3D=3D=3D

 Git has three ways to commit files to the repository:

 - Commit everything with "git commit -a";
 - Commit only some files with "git commit file1 file2...";
 - The staging area. This allows you to specify which files (or which c=




hanges) you want to commit using "git add" before doing the actual commit=
 with "git=20

 commit". This is nice for some complicated situations, but I feel that=




 it is not that common.

=20
 The truth is Git supports just one way to commit stuff and it's always
 through the staging area. git commit -a and git commit f1 f2 ... are ju=


st

 shortcuts for git add [every "dirty" file] && git commit and git add f1=


 f2

 ... && git commit respectively.


	That's an implementation detail. From the user's point of view,=20
they introduce different workflow (which is good: more flexibility=20
is better so long as it doesn't add undue complexity, which this=20
doesn't).


 - Mercurial and Git both have global options which apply to all comman=




ds

 and specific options that only apply to the current command. With
 Mercurial, the options may be put in any order, and in particular, you=





 can do "hg cmd <options>". With Git the global options must be put
 before the command and the specific options must be put after: "git
 <global options> cmd <specific options>";


=20
 I never noticed that. I think because I think I never used git "global"=



 options. What are you using?
=20


	That was to deactivate the pager. I had first typed "git log" which=20
showed the pager, then I simply typed the "up" key and added=20
"--no-pager" to the command line, which didn't work and I had to=20
change the command line a third time to get what I wanted (see what=20
I said above about more flexibility being good)


 - Mercurial command names are much more intuitive (especially coming
 from cvs/svn). For example, in order to return a modified file to its
 repository state: "cvs revert", "svn revert", "hg revert", "git
 checkout". Even in absolute terms, "checkout" is not the first word th=




at

 comes to mind, I would have understood "revert" (obviously), "restore"=




,

 "backout" or an extra option to "update" (which Git doesn't have
 anyway).


=20
 I think the Git names are right. It's true that it is not intuitive whe=


n

 coming from SVN/CVS, but what you are doing with that command is exactl=


y

 that. You are checking out the file again (overwriting the current file=


).

 When you understand Git, that name makes perfect sense =3D)
=20


	I'd say "when you understand Git" is the issue. Once you know them,=20
I don't think there's that much difference between Git, Mercurial=20
and Bazaar. The difference is, you don't really need to *know*=20
Mercurial or Bazaar to use them, which makes them a lot easier to learn.


 About update, git doesn't have update because you have more flexibility=


 on

 how to "update" the repo.


	"hg update" doesn't update the repo, it updates the working copy.=20
AIUI, git does it with the "merge" command. In absolute terms, I=20
have no problem with this: the Git name makes as much sense as the=20
Mercurial term. However, more than 20 years of SCMs (starting with=20
RCS) have used "update" for that particular command. Using a=20
different name simply makes it harder to learn Git if you have=20
experience of another SCM.


 Mercurial is also slightly better in terms of disk space used, althoug=




h

 this does not mean much given the capacity of today's HDDs.


=20
 Git have a packing mechanism that is ran when some heuristics detects t=


oo

 much space is wasted. You can try: git gc
=20


	Didn't help, but as I said this is not really an issue with modern=20
disk sizes.


 Git is supposed to have coloured output, but it wasn't enabled by
 default and I didn't try to find how to do it. Mercurial has coloured
 output on Unix, but not on Windows (I have written a patch to allow it=





 to work on Windows but I haven't sent it upstream yet).


=20
 Mercurial doesn't have coloured output in Unix (at least Debian package=



 1.2.1). How can I turn it on?


	Enable the "color" extension (it's one of the standard extensions,=20
so you only need to add "hgext.color=3D" to the "[extensions]" section=20
of your hgrc, no need to install anything).

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jun 04 2009
prev sibling next sibling parent Don <nospam nospam.com> writes:
Jérôme M. Berger wrote:

 Jérôme M. Berger wrote:

 Leandro Lucarella wrote:

 Why don't you test it and stop talking about what you think it's 
 going on
 and start talking about what's *really* going on.

 It doesn't seems very fair to discard something just because you have 
 the
 feeling that it wouldn't work well (specially when other people use 
 it and
 say it works well).


     I've started. I'll give you a full report tomorrow when I have 
 tested it more completely.




Thanks, your report is excellent.


 
     Okay, here goes. For those who don't want to read the whole text, 
 here's the short version:
 - Git has one nice feature that Mercurial doesn't have yet, and that's 
 the staging area;
 - Git isn't ready for production use on Windows. If you want to use it, 
 go ahead but don't go crying if something goes wrong (the details are in 
 the "Status" section below);



The msysgit home page reinforces that impression 
(http://code.google.com/p/msysgit/):

"Once you installed msysGit, git will be compiled and the repository 
will be fetched, so you are good to go. Play with git a little, and you 
will find plenty of stuff that is not quite optimal."

Nonetheless, it's come a very long in the past year or so, and it sounds 
as though in another six months or so, there may not be much to complain 
about.
Jun 03 2009
prev sibling next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Jérôme M. Berger wrote:

 Jérôme M. Berger wrote:

 Leandro Lucarella wrote:

 Why don't you test it and stop talking about what you think it's 
 going on
 and start talking about what's *really* going on.

 It doesn't seems very fair to discard something just because you have 
 the
 feeling that it wouldn't work well (specially when other people use 
 it and
 say it works well).


     I've started. I'll give you a full report tomorrow when I have 
 tested it more completely.


 
     Okay, here goes. For those who don't want to read the whole text, 
 here's the short version:
 - Git has one nice feature that Mercurial doesn't have yet, and that's 
 the staging area;
 - Git isn't ready for production use on Windows. If you want to use it, 
 go ahead but don't go crying if something goes wrong (the details are in 
 the "Status" section below);
 - Git's command are not very intuitive (especially coming from CVS or 
 SVN), which makes it difficult to start using it (no matter how easy you 
 may find it later on);
 - Git's built-in help system is pretty bad: it is difficult to find the 
 information you want and instead of giving you the information, git will 
 start a web browser to display it.
 
     And here's the long version:
 
 
 Introduction
 ============
 
 I've run a quick comparison of Git and Mercurial on Windows. The tests 
 consisted of importing a Subversion repository with 364 revisions, then 
 running some standard commands: help, clone, log, status, diff, commit.
 
 Git version used: 1.6.3.msysgit.0
 Mercurial version used: 1.2.1 + custom patch to enable coloured output 
 on Windows.
 
 Install
 =======
 
 Ok, no problem. Git has made a lot of progress here.
 
 
 Import from svn
 ===============
 
 Git is sloooowwwww (a couple of hours to import, Mercurial did it in 
 about five minutes). But then you don't import an SVN repository 
 everyday, so speed isn't that much of an issue here (actually I only 
 imported that svn repository to have some real life data rather than 
 testing on a mostly empty artificial repository, not to test SVN import 
 per se).
 
 
 Help
 ====
 
 Git's help is unusable. It took me way too long to find out how to 
 revert the changed files so that the working folder reflects the content 
 of the repository and how to update the files to a specific version.
 
 Git launches a web browser instead of giving me the info I want 
 directly. I then need to close the browser window or go back to the 
 shell before I can continue. Plus, if I need to check on something, I 
 need to switch back and forth between the browser and the shell instead 
 of simply scrolling the shell window.
 
 While I wouldn't be against a command/option to start the browser, the 
 default behaviour should be to print the info directly in the terminal.
 
 A nice thing about Mercurial: I can type either "hg help cmd" or "hg cmd 
 help" to get help. Git only recognizes the first form.
 
 
 Clone
 =====
 
 Command syntax is the same. Git took 57s where Mercurial only took 17s.
 
 
 Log
 ===
 
 Mercurial can identify a changeset with a simple number (valid only in 
 the current repository), a short hash (valid anywhere so long as there 
 are no collisions) or a long hash. The default behaviour is to only show 
 the number and short hash, which is much more user-friendly. From what I 
 could tell, git only uses long hashes?
 
 Default log output is much more readable in Mercurial:
 - Like I said above, changeset numer + short hash is easier to identify 
 than full hash;
 - The different changesets are immediately identifiable. In git, it is 
 not easy to see where the info for one commit ends and the next begins;
 
 Clock time: 1.1s for Mercurial, 1.4s for Git.
 
 
 Status
 ======
 
 Git reported some modified files immediately after the clone and even 
 though I hadn't changed anything and the files were identical to the 
 original folder, in which Git didn't report any modified files. I was 
 unable to fix it so that "status" reported no changes (even deleting the 
 files and checking them out again didn't fix it).
 
 The problem is probably due to incorrect handling of line endings, but I 
 have been unable to determine the precise conditions that make it 
 manifest on those files and not others. This does not exactly fill me 
 with confidence for Git's reliability as a whole.
 
 - Time for an empty status report: 1s for Mercurial, 1.1s for Git;
 - Time for a status report with an added unknown file: 0.4s for 
 Mercurial, 1s for Git (obviously, we have reached the precision of my 
 timing method);
 - Time for a status report with a changed file: 1s each.
 
 
 Commit
 ======
 
 Git has three ways to commit files to the repository:
 
 - Commit everything with "git commit -a";
 - Commit only some files with "git commit file1 file2...";
 - The staging area. This allows you to specify which files (or which 
 changes) you want to commit using "git add" before doing the actual 
 commit with "git commit". This is nice for some complicated situations, 
 but I feel that it is not that common.
 
 Mercurial currently only supports the first two ways. Reflections are in 
 progress to add the third way, but they want to design the UI properly 
 before implementing it: 
 http://www.selenic.com/mercurial/wiki/IndexesExtension
 
 
 General Remarks
 ===============
 
 I found the Mercurial command line much easier to use than Git's. For 
 example:
 
 - Mercurial and Git both have global options which apply to all commands 
 and specific options that only apply to the current command. With 
 Mercurial, the options may be put in any order, and in particular, you 
 can do "hg cmd <options>". With Git the global options must be put 
 before the command and the specific options must be put after: "git 
 <global options> cmd <specific options>";
 
 - Mercurial accepts either "hg help cmd" or "hg cmd help". Git only 
 accepts "git help cmd";
 
 - Mercurial command names are much more intuitive (especially coming 
 from cvs/svn). For example, in order to return a modified file to its 
 repository state: "cvs revert", "svn revert", "hg revert", "git 
 checkout". Even in absolute terms, "checkout" is not the first word that 
 comes to mind, I would have understood "revert" (obviously), "restore", 
 "backout" or an extra option to "update" (which Git doesn't have anyway).
 
 - Default Git behaviour is to send command output to a pager. Default 
 Mercurial behaviour is to simply send it to the terminal. I personally 
 prefer Mercurial's way, but this can be argued either way. Anyway, it is 
 possible to change the default.
 
 The speed difference isn't that big or important for most operations, 
 except for clone.
 
 Mercurial is also slightly better in terms of disk space used, although 
 this does not mean much given the capacity of today's HDDs.
 
 Git is supposed to have coloured output, but it wasn't enabled by 
 default and I didn't try to find how to do it. Mercurial has coloured 
 output on Unix, but not on Windows (I have written a patch to allow it 
 to work on Windows but I haven't sent it upstream yet).
 
 
 Conclusion
 ==========
 
 Git weak points:
 - speed (although most common operations are fast enough that it 
 shouldn't really be a problem except for "clone");
 - unintuitive command names;
 - poor help system;
 - inconsistent behaviour of the status command which may hide other more 
 serious problems.
 
 Git strong points:
 - the staging area is a nice feature with no Mercurial equivalent 
 (although they're working on it). But I wouldn't call it a killer feature.
 
 Note that all my tests were done on Windows. It is quite possible that 
 the speed and inconsistent behaviour issues would not occur on Unix, but 
 they are enough to justify my claims that Git doesn't really work on 
 Windows.
 
         Jerome


disclaimer: I'm a git user, mainly on Unix but also on windows.

It seems to me from reading the above that this is not a fair and 
objective comparison. you're saying that A is better than B just because 
you are used to A.
more specifically, git's command line structure of:
git <global options> <cmd> <cmd options> is more organized than what you 
describe in mercurial.
saying that "Mercurial command names are much more intuitive (especially 
coming from cvs/svn)" is also misleading since git has a completely 
different conceptual model that IMO should not try to fit with CVS 
concepts. If that is really a big issue for you just set up aliases in 
.gitconfig with your preferred command names (I was a subversion user 
myself and initially did exactly that)
colored output - you didn't even try to enable it in git (which is 
trivial) but you have written a patch to do the same for mercurial.

I have no problem with your preference to use mercurial, just don't 
claim that git is not ready to be used on windows because of that 
preference.
Jun 04 2009
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Yigal Chripun wrote:

 disclaimer: I'm a git user, mainly on Unix but also on windows.
=20
 It seems to me from reading the above that this is not a fair and=20
 objective comparison. you're saying that A is better than B just becaus=


e=20

 you are used to A.
 more specifically, git's command line structure of:
 git <global options> <cmd> <cmd options> is more organized than what yo=


u=20

 describe in mercurial.


	The point here is that Mercurial's way is more flexible. It's a=20
small thing but it can be very useful. For example, when you type a=20
command, if you realize that you forgot an option, with Mercurial=20
you can just add that option then and there. With Git, you have to=20
ask yourself "is this a global option?" then depending on the answer=20
you can add it immediately or you need to move to the right place so=20
that you can add the option then move back to the end of the line to=20
finish typing. It's a small thing but it makes life so much easier...


 saying that "Mercurial command names are much more intuitive (especiall=


y=20

 coming from cvs/svn)" is also misleading since git has a completely=20
 different conceptual model that IMO should not try to fit with CVS=20
 concepts. If that is really a big issue for you just set up aliases in =



 .gitconfig with your preferred command names (I was a subversion user=20
 myself and initially did exactly that)


	The main issue here isn't day to day usage once you know Git=20
perfectly. The issue is about how easy it is to learn Git (with a=20
minor point added when you need to use different SCMs for different=20
projects, having similar command names for similar operations is=20
much easier than having to remember several completely different=20
command sets).


 colored output - you didn't even try to enable it in git (which is=20
 trivial)


	That one was too minor a point for me to loose much time on it. If=20
I were to start using Git on a regular basis, I would look more deeply.


 but you have written a patch to do the same for mercurial.
=20


	Yes, when I use an open source soft, I try to give something back=20
to the community (time permitting), either in the form of patches,=20
bug reports or suggestions.


 I have no problem with your preference to use mercurial, just don't=20
 claim that git is not ready to be used on windows because of that=20
 preference.


	You've missed the point. All the answers you gave can be argued as=20
a matter of preference and none of them are the reason I claim Git=20
is not ready to be used on Windows (hell, if they were I would have=20
claimed that Git is not ready for use, period).

	The reason why I claim that Git is not ready is that it exhibits=20
suspicious behaviour when cloning repositories and checking out=20
files. I would expect that immediately after a checkout, the=20
"status" command would report the file to be unmodified. I would=20
also expect that cloning a repository with no changes would give me=20
an identical repository with no reported changes. Since Git didn't=20
fulfil those basic expectations, I am worried about what *else* it=20
might be doing wrong with my files.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jun 04 2009
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-06-03 16:24:14 -0400, "Jérôme M. Berger" <jeberger free.fr> said:


 Note that all my tests were done on Windows. It is quite possible
 that the speed and inconsistent behaviour issues would not occur on
 Unix, but they are enough to justify my claims that Git doesn't
 really work on Windows.


I just want to note that we're using git on Windows at work pretty 
heavily, but not the one from msysgit. I'm using the one that comes 
from Cygwin. It works pretty well, doesn't try to open help files in 
the web browser, nor does it attempt to convert line endings. So you 
may get a better git experience going that way instead of msysgit.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jun 04 2009
prev sibling parent "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Mon, 01 Jun 2009 18:20:49 +0300, Jérôme M. Berger <jeberger free.fr> wrote:


 [snip]


Since no one posted this link in this thread yet:

  http://whygitisbetterthanx.com/

-- 
Best regards,
 Vladimir                          mailto:thecybershadow gmail.com
Jun 01 2009