"Jérôme M. Berger", el 3 de junio a las 22:24 me escribiste:
> Jérôme M. Berger wrote:
> >Leandro Lucarella wrote:
> >>Why don't you test it and stop talking about what you think it's going on
> >>and start talking about what's *really* going on.
> >>
> >>It doesn't seems very fair to discard something just because you have the
> >>feeling that it wouldn't work well (specially when other people use it and
> >>say it works well).
> >>
> > I've started. I'll give you a full report tomorrow when I have tested it
> > more completely.
>
> Okay, here goes. For those who don't want to read the whole text,
> here's the short version:
Thanks for your report.
> - Git has one nice feature that Mercurial doesn't have yet, and that's the
> staging area;
It has more, I finished reading about MqExtensions and is way far away
from what you can do with git (specially git rebase -i), and how natural
is to do it in Git. But what the hell =)
> - Git isn't ready for production use on Windows. If you want to use it,
> go ahead but don't go crying if something goes wrong (the details are in
> the "Status" section below);
It's a shame you don't find it ready for production use =(
(other people does, so I guess is subjective)
> - Git's command are not very intuitive (especially coming from CVS or
> SVN), which makes it difficult to start using it (no matter how easy you
> may find it later on);
True. IMHO this is why Git is so much easy to use when you diverge from
the basic usage from a CSCM like CVS/SVN. Is a trade-off, and I think Git
made the right trade-off (is not that different either when using the
basic commands).
> - Git's built-in help system is pretty bad: it is difficult to find the
> information you want and instead of giving you the information, git will
> start a web browser to display it.
That really sucks. On Unix git cmd --help lunches the man page, wich is really
nice to me. If you need a quick summary, git cmd -h is for you.
You can configure how Git does show the help, from git config manual:
help.format
Override the default help format used by git-help(1). Values man,
info, web and html are supported. man is the default. web and
html are the same.
I don't know why it opens a web browser by default in Windows, seems pretty
lame =/
Maybe msysgit doesn't come with the man/info command? Try:
git config --global help.format man
> Help
> ====
>
> Git's help is unusable. It took me way too long to find out how to revert the
> changed files so that the working folder reflects the content of the
> repository
> and how to update the files to a specific version.
>
> Git launches a web browser instead of giving me the info I want directly. I
> then need to close the browser window or go back to the shell before I can
> continue. Plus, if I need to check on something, I need to switch back and
> forth between the browser and the shell instead of simply scrolling the shell
> window.
>
> While I wouldn't be against a command/option to start the browser, the
> default behaviour should be to print the info directly in the terminal.
>
> A nice thing about Mercurial: I can type either "hg help cmd" or "hg cmd
> help" to get help. Git only recognizes the first form.
Just as a sidenote, and as I said, you can use git cmd --help for the complete
manual page or git cmd -h for a quick summary (in Unix at least).
> Log
> ===
>
> Mercurial can identify a changeset with a simple number (valid only in the
> current repository), a short hash (valid anywhere so long as there are no
> collisions) or a long hash. The default behaviour is to only show the number
> and short hash, which is much more user-friendly. From what I could tell, git
> only uses long hashes?
You can use short hashes too (you can use the 4 first chars or more if it
is ambiguous). I agree that the Mercurial short consecutive number is nice
and handy.
> Default log output is much more readable in Mercurial:
> - Like I said above, changeset numer + short hash is easier to identify than
> full hash;
> - The different changesets are immediately identifiable. In git, it is not
> easy to see where the info for one commit ends and the next begins;
Well, this is a matter of taste, I find Git log much more readable =)
If you need a very compact log, use git log --oneline. This is an example
output (from the Linux kernel repo):
8d7bff2 Linux 2.6.29.1
bb70446 V4L: v4l2-common: remove incorrect MODULE test
5d8a29a sparc64: Fix reset hangs on Niagara systems.
b6816b7 sparc64: Flush TLB before releasing pages.
8796fc2 sparc64: Fix MM refcount check in smp_flush_tlb_pending().
716fd1d KVM: MMU: Fix another largepage memory leak
cbb76e6 cfg80211: fix incorrect assumption on last_request for 11d
4d25e3d lguest: fix spurious BUG_ON() on invalid guest stack.
ab62416 lguest: wire up pte_update/pte_update_defer
73dffc3 VM, x86, PAT: Change is_linear_pfn_mapping to not use vm_pgoff
67df642 x86: mtrr: don't modify RdDram/WrDram bits of fixed MTRRs
178e047 x86: ptrace, bts: fix an unreachable statement
393c205 x86: fix 64k corruption-check
4a78cb5 x86, uv: fix cpumask iterator in uv_bau_init()
e1b427a x86, PAT, PCI: Change vma prot in pci_mmap to reflect inherited prot
You can change the default format via (system|global|local) configuration.
>From git config manual:
format.pretty
The default pretty format for log/show/whatchanged command, See
git-log(1), git-show(1), git-whatchanged(1).
You have a few predefined formats: oneline, short (this is the one that
looks more like the hg format), medium, full, fuller, email and raw. If
you don't like those, you can use your own format. For example:
$ git log --pretty=format:"changeset: %h%nuser: %an <%ae>%ndate:
%ad%nsummary: %s%n"
changeset: 8d7bff2
user: Chris Wright <chr...@sous-sol.org>
date: Thu Apr 2 13:55:27 2009 -0700
summary: Linux 2.6.29.1
changeset: bb70446
user: Hans Verkuil <hverk...@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 <da...@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?
