2015-04-14 17:37 GMT+03:00 Roland Eggner <[email protected]>:
> On 2015-04-13 Monday at 20:00 +0200 Christian Brabandt wrote:
>> On Mo, 13 Apr 2015, Bram Moolenaar wrote:
>> > Markus Heidelberg wrote:
>> > > > Some things can perhaps be done on the Mercurial repository before the
>> > > > import, but I suppose some are only possible in git. What will happen
>> > > > for the mirror in Mercurial then? We need to make sure we don't break
>> > > > anything.
>> > >
>> > > Yes, makes sense.
>> > > I was not familiar with Mercurial, only knew some commands for basic
>> > > usage, so I had to dig in first to understand the concepts behind it -
>> > > especially the differences in branches, tags and publishing compared to
>> > > Git.
>> > >
>> > > To avoid breaking the HG repo/mirror, cleanup requiring history rewrite
>> > > has to be restricted to the Git repo.
>> > >
>> > > Below the script, it is completely non-interactive:
>> >
>> > Thanks for figuring this out.
>> >
>> > I have little experience with Mercurial and git (who needs version
>> > control, I have multi-level persistent undo! :-). I would need a
>> > thorough review from a couple of people before running this.
>>
>> We could first check it with the bitbucket vim playground repository.
>> It's my experimental repository and it contains some extra commits for
>> getting the tags right (my script wasn't working correctly, but I think,
>> I just fixed it today).
>>
>> And if we screw up, I can set it up again ;) (I already said I am going
>> to reimport from the google code repository once that one is frozen, so
>> it is not much extra effort).
>
>
> @Bram, @Markus
> ──────────────
> Many thanks to Markus for the thorough work. After reading the proposed
> script
> I am convinced it will work as intended. It addresses the same odds of the
> vim
> repository, which I am seeing. I suggest just one addition:
>
> When cloned on a Linux system or another Unix-like system, the randomly set
> executability attributes of files in the vim repository are looking odd. The
> following shell script would turn the picture to a decent and useful look:
>
> find . -path ./.hg -prune -o -type f -exec chmod 640 '{}' + \\
> && find . -path ./.hg -prune -o -type f -regextype posix-extended \\
> -regex '.*(/configure|/mkinstalldirs|\.sh|\.pl)$' -exec chmod -c 750 '{}' + \\
> && hg commit -m 'Set reasonable executability attributes of files.'
>
>
> @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.
> • 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.
> • 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.
>
> Thus if the vim project will be migrated to git I would appreciate it.
> The decision should primarily depend on the question, if it saves workload for
> Bram in the long run, because his workload is the limiting factor for the
> development of vim.
>
> Both git and mercurial can save or increase workload:
> it depends on thinking and usage patterns as explained above.
>
>
> @Bram
> ─────
> As you prefer context over unified diff format:
> • Are you aware of the possibility, that both git and mercurial can be
> configured to output _every_ diff output with an increased number of
> context lines, e.g. 10 lines instead of the usual 3?
> “git log -p -1 -U10”
> gitconfig: “[diff] \n context = 10”
> “hg log -p --limit 1 --config diff.unified=10“
> hgrc: “[diff] \n unified = 10“
> “git help diff” describes even more options to tune the amount of diff
> context.
> • Are you aware of the patchutils package and the filterdiff command?
> It can give you context diff format with git and mercurial everywhere:
> just use “PAGER=/usr/bin/less” and properly include
> “filterdiff -v --format=context” in /usr/bin/lesspipe.
> If you do not use already something equivalent, maybe using any of this tips
> or
> both you like git and mercurial a bit more?
>
>
>
> --
> 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.
--
--
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.
