2015-04-16 9:36 GMT+03:00 Roland Eggner <ed...@systemanalysen.net>: > On 2015-04-14 Tuesday at 20:00 +0300 Nikolay Pavlov wrote: >> 2015-04-14 17:37 GMT+03:00 Roland Eggner <ed...@systemanalysen.net>: >> > @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.
This only works as long as the search succeeds. If it does not you have no way to know whether it does not succeed because functionality is missing (at least from this command) or because man page authors use different wording other then reading the whole documentation. > > >> > • 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. More powerful?! Try to add phases/changeset obsolescense/branches/etc to git. The point is that this “sharper knife” has an architecture that prevents adding feature to the core. You can do almost anything with the core using plugins for mercurial, but maximum thing you can do with git is add a special version-controlled file or put metadata in other non-related metadata to be treated specially if user on the other side has the same plugin (though this is the case for mercurial as well, just that users without plugins may not receive new metadata). Its architecture also allows modifying core in backwards-compatible fashion. Mercurial is already more powerful. Just its main powers are different. You can’t take mercurial and smash your legs with it. And you can’t take git and make yourself use legs for walking on the wall. > > 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. It looks like we were reading different books. `hg rollback` was always described as dangerous (though I did see recommendations to use it somewhere), `hg histedit`/`hg rebase` are almost always advertised only by users because this loves to fail because of phases. You may argue that `hg help commit` advertises `hg commit --amend`, but I would say that a person who thinks that each commit must be done in a separate clone *because* you are not sure you don’t make a typo that needs to be corrected with `hg commit --amend` is who is insane, not `hg commit --amend`. (Though I have no idea why mercurial authors made `hg commit --amend` also commit changes done after amended commit which is both dangerous and inconvenient should you mention typo after you did some more coding.) Also note: I have failed to find any materials that “advertise” `hg histedit` or `hg rebase` in materials linked on http://mercurial.selenic.com/wiki/Tutorial and found a single book that talks about `hg rollback` (which even was not linked there *directly*). *All reading* (three: Pro Git, two cheatsheets) materials directly linked from http://www.git-scm.com/doc have a note at least about `git reset --hard`. Though I did not saw any advertising anywhere. I also don’t know why you call `hg histedit` insane. This is very common when using remote CI server: “commit -> push to CI server -> tests fail -> make short commit -> push to CI server -> tests fail -> … -> clean up history -> update the main repository”. Needs non-publishing repository in mercurial case though. > > > -- > 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 vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
