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
• 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.
• 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 …“ …
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.
pgpJza2jaSPZz.pgp
Description: PGP signature
