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.
 

walter and andrei (and all others)


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 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 next sibling parent 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=



 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=



 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=


 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=

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

 one that usually merges new frontend versions.


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

 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
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 next 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 next 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.


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:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

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 =

 would be ideal but mercurial is good too). That would make merging and
 branching a lot easier.
=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.


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.


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:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

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 =




 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=




 branching a lot easier.

Mercurial or Bazaar are much better in this regard.

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


 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. =20 +1 for git

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.


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/

+1 for git

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.


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.

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!
 

confusing!

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.
 

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.
 

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!


It does.
 The humble git-gui is much better.
 

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.

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:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Daniel Keep wrote:
 Incidentally, I use both.  TortoiseGit is great for anything of relativ=

 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

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).

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:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

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=



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



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

Sorry, couldn't resist ;)

git am mailbox =20 Sorry, me either ;) =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 next 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.

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
next sibling 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:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

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

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:
Jrme 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 parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Jrme 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 =)

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
next sibling parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

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=



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



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



 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 b=

 better than svn.
=20
 As for the others, you don't provide any objective reasons for WHY
 they're better than git.
=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 =)

svn would be better.

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.

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:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

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 =





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





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





 svn would be better.




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



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



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


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


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


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


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


 Windows (although I haven't tested it).

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

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

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

 say it works well).
=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=

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

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

 always migrate the repo to something else when the time is right...
=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 =


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


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


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

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

"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 =


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


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


 example to generate releases automatically).

You have a good command-line support. =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=


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


 (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).

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

 projects than DMD.
=20

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

 Leandro Lucarella wrote:
 
 "Jrme 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).
 


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 reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

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 =


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


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


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

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

 * 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

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
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.

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:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

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=




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




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

* 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.


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

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=



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



 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.) =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 next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

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

=20
 Leandro Lucarella wrote:
 You have a good command-line support.

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 g=

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

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 next 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.

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 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...

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...

"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).


- 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.


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:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

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?

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

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

 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=

 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=

 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)

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

does: According to the help it is the "same as interactive except=20 it's not"???
 git citool
=20

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

 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

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=




You need good=20
 command-line support so that you can access it easily from custom to=




 You have a good command-line support.



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


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


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

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



 projects than DMD.


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

 hand! Just do git pull or hg pull you are set!
=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?

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).


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 


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


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.


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

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 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 next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

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=

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

 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=

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

 and break "bisect"!
=20

reviewed, send an updated patch. You don't need "rebase" for that.
 - The second is the Transplant extension, which *copies* the changeset=


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


 "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 ke=

 the old history ;)
=20

that more than once on this ng ;)
 - And the third is to simply merge your changes with the incoming chan=


=20
 That's a merge, not a rebase =3D)
=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 =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

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

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




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




 branches).



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

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 =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

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

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

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 next 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:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

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.

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

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

 adapt your mind.
=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

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 parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

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=


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

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


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


 and
 say it works well).

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).


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:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

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=


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


=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=

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

 ... && 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=


 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?
=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=


 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 whe=

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

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

 When you understand Git, that name makes perfect sense =3D)
=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=

 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=


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

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

 much space is wasted. You can try: git gc
=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).

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).

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).

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:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

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=

 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=

 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=

 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

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, "Jrme 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 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.


 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=

 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=

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

 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
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=


 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,=


 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 parent 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=



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


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
prev sibling parent 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 =

 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, =

 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
prev sibling next 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
prev sibling parent "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.

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
prev sibling parent 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=



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



 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.


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.


 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