On 2015-04-14 Tuesday at 20:00 +0300 Nikolay Pavlov wrote: > 2015-04-14 17:37 GMT+03:00 Roland Eggner <[email protected]>: > > @Bram, @Christian, @all > > ─────────────────────── > > During some 10 years of almost daily usage of mercurial I have learned, I > > can > > usefully apply the philosophy, which Bram has provided in his book „Seven > > habits > > of effective text editing“: > > • Usage of a version management system will _save_ workload rather than > > to > > add workload, as soon as I switch from “insane” to “sane” thinking > > patterns. > > • Examples for “insane” thinking patterns are: > > How can I undo mercurial commands? > > How can I edit the repository? > > How can I work on a remote repository? > > • Examples for “sane” thinking and usage patterns are: > > Whenever I am not absolutely sure about the consequences of my next > > action, > > I run “hg clone …” firstly. On decent file systems this is cheap because > > only file names are copied, not file contents. Dependent on the outcome > > I drop the older or the newer repository later -- this way I have no > > need for > > any kind of undo actions and can relax. > > Every “hg pull” is followed by a “hg clone” or something equivalent, > > local > > repositories used for pulling are used for nothing else -- this way in > > the > > event of a failed merge or a failed “fast forward” I can just drop the > > concerning repository clone and reuse another local clone. > > For development as a basic principle I prefer local repositories. Apart > > from > > rare emergency cases, I use remote repositories for publishing and > > nothing > > else. > > > > For the currently discussed use case of Christian this means: > > • I would consider running the script remotely _only_ in the case of > > full-fledged SSH access and after at least one remotely executed “hg > > clone”. > > • In any other case and assuming network access without WLAN shortcomings, > > I would pull, clone locally at least once, run the script locally, check > > the > > result, if it satisfies then delete the remote repository and recreate > > it by > > pushing (deletion is required in this case because pushing allows only > > appending). > > > > For _new_ projects I use git rather than mercurial since approximately two > > years. Some of the reasons are: > > • git is better documented: just compare > > http://git-htmldocs.googlecode.com/git/git.html > > http://mercurial.selenic.com/wiki/ManPages > > You need to compare `hg help {command}` and `git help {command}`. `git > help {command}` redirects to `man git-{command}`, `hg help {command}` > uses docstrings and command definitions. They both have a reason to > provide documentation the way they do it: > > - Using `man` is simpler and it assumes that software (package manager > mainly) used to install git addons is able to install man pages. > - Using docstrings is more pythonic and `--editable` installs of > mercurial extensions will for sure *not* provide man pages. This > variant is more convenient for the extension developer. > > I can also say that while git is better documented, its documentation > is *worse*. When I look at `hg help something` I usually understand > immediately what I need to do. When I look at `git help something` I > need to parse a lot of currently useless text, sometimes just to find > out that I picked help for the wrong command.
I prefer the html-documentation, it allows more convenient jumping between documents. E.g. “git help log” and “git help diff” are huge man pages, yes, but this is easily solved: I use the pager less, enter a perl search expression and libpcre does the parsing for me. > > • In my experience git was the very first tool with complete and flawless > > Unicode support -- even nowadays only few can compete in this concern > > (perl-5.12+, zsh-5.0+). This stays in contrast to mercurial: “hg diff > > …” > > occasionally outputs invalid Unicode characters, because trimming of the > > function name field ignores boundaries of multibyte characters -- this is > > even noted in the mercurial repository since several years, and there > > seems > > to be no intention to fix the bug. I have discussed two other examples > > of -- > > in my subjective view -- odd design decisions of mercurial with the > > developers; the patches I offered have been rejected; this can be > > found in > > mercurial mailing list archives. More examples on request. > > It is interesting. I can understand why trimming does this (most of > strings used by mercurial are `str` - byte strings), but do not > understand why they do not have any fixes: this should be as trivial > as “convert to `unicode` from encoding in current locale -> trim -> > convert back”. If needed more efficient solutions are also trivial to > implement, but they will contain more code. +1 > > • For good reasons mercurial documentation recommends frequent usage of > > “hg clone”, this is ok. But on the other hand mercurial offers “insane” > > usage patterns especially attractive for new users and does not warn, > > that an > > “hg clone” performed in advance would be a simpler and less error-prone > > alternative: “hg rollback”, histedit extension … > > git allows, but does not promote “insane” usage patterns, instead it > > requires > > explicit usage of non-default options for such actions: > > “git commit --amend …“, “git reset --hard …“ … > > ?! 90% of git-based projects I see expect developer to rebase > constantly. `hg commit` does not edit commit message by default. `hg > rollback` is explicitly marked as both DANGEROUS and DEPRECATED. `hg > histedit`… I do not see where it is recommended, but in any case this > works only with local, non-published history, saves backups before > removing any commits (except when using experimental mutable-history > extension which also prevents data loss, but in the other fashion) and > is not available by default. `git pull` *by default* does merging with > immediate commit and this is far less sane then simply recommending > anything because merges are dangerous and at least need testing before > committing. > > Also you are saying about “sane” and “insane” usage patterns and then > promote git which has far more options for undoing effects for its > commands and editing local repository. It is questionable who is > insane here: > > - Git does not care which commits you are going to edit with `git > rebase --interactive`. `hg histedit` is not going to work for > published commits, same for `hg rebase`. > - `hg rollback` is marked DANGEROUS and DEPRECATED and allows to undo > only one `commit` or `pull` and nothing more. Using `git reflog` you > may undo every your action, just though not always with one command > (and need to explicitly `git gc` old state with proper `--prune` to > make your actions as dangerous as `hg rollback`). > - `git push -f` with default settings of the remote server allows to > clear history on the remote repository without any way to roll back > unless you are a remote system administrator (or, at least, have > direct access to git CLI, RO access to the filesystem or something > like this) or have a copy of the remote state locally. `hg push` is > not going to delete a single commit on the remote no matter what > options you provide to it, not even with `mutable-history` extension > (though it looks like with `mutable-history` obsolete changesets will > be hard to access; this is still experimental extension though and is > only for non-publishing remotes). > > Very questionable who offers insane patterns here. I do not think that > authors of `git` were forced to add any of the above options. Maybe, we can both agree, that mercurial offers rather “hard safe guards” (phases …), whereas git offers rather “soft safe guards” (requires explicit usage of non-default options …). The former better for working mode “brain switched off”, the latter providing more power and flexibility when working mindful. It is a global pattern: a “sharper knife”, a more powerful tool requires more attention. But this was not my original point. My point was, that mercurial inveigles users into inefficient, “insane” workflows, whereas git does it not or to lesser degree. -- Roland Eggner -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
pgprKKb5ioURS.pgp
Description: PGP signature
