On 09/16/2015 02:20 AM, Oleg Broytman wrote:
Hi!
On Tue, Sep 15, 2015 at 07:44:28PM +0000, Augie Fackler <r...@durin42.com>
wrote:
Hi! I work on Mercurial. I???ve got some inline responses, but I want to
summarize and put this in context for those without much energy for the topic.
Thank you!
There are a lot of reasons to prefer one tool over another. Common ones are
familiarity, simplicity, and power.
Add here documentation, speed, availability of extensions and
3rd-party tools, hosting options (both locally installable and web
services).
Oleg Broytman <phd <at> phdru.name> writes:
With git we can have
per-directory .gitignore and .gitattributes.
No per-directory .hgignore? Never? Quite useful in a big project
where subproject live in subdirectories and are developed by separate
teams.
tags point exactly to the commits they tag.
I'm chalking these up to personal taste, but know that the tagging behavior
of git vs hg is a very complicated tradeoff. Mercurial chose a path that
makes tags audit-able in the future, whereas in Git a tag could disappear
and it'd be hard to prove.
I think signed tags can help.
I learned commit editing and found that it was the thing I wanted so
badly in hg. When I started Mercurial was at version 1.7 and there was
no commit editing at all; there was ``hg rollback`` but it only could
undo one transaction.
Please forget rollback exists. It's dangerous, and we're hiding it from new
users for a reason. :)
Sure, I forgot them many years ago. ;-)
``git add -p``
allows me to review and edit patches before commit while ``hg record``
commits immediately.
FWIW, I totally *get* wanting a staging area. That said, other than the
staging area, record (aka commit --interactive) and git add -p are identical
functionality-wise.
Functionality-wise - yes, but staging area still makes the process
much more convenient.
Matter of habit probably. I find the staging area a significant
annoyance for new users. I get the exact same process flexibility by
amending my last commit over and over, interactively getting new stuff
in and out of it. And having this extra context of stagging area is just
a pain to me as you have to remember all this various config flag you
have to use to see its content. The interactive tool around it are nice
but they do not really need the staging area concept in itself to exists.
``git log --grep=`` (and all related search options,
especially ``-G``)
Remember how I mentioned revsets replace a lot of Git command line flags?
This is an example. hg help -r 'grep(foo)'.
$ hg help -r 'grep(foo)'
hg help: option -r not recognized
hg help [-ec] [TOPIC]
I think Augie meant: hg log -r 'grep(foo)'
See also `hg help revsets`,
which are a very rich query system for revision history usable throughout
mercurial rather than only in log.
What is the flag for case-insensitive grep()? For git log -Gregex?
All revsets function matching string can have specific behavior. For
exanple it can be turned into matching regex using "re:" prefix etc.
This is global and unified.
As I stopped using Mercurial I do not understand what phases are.
they are phases of commit according to what? To the origin (let me
borrow the word from git terminology)?
Commits seen in the main public repository are marked as public, and
Mercurial refuses to edit them. Most history rewriting woes happen when
people rewrite widely shared history and force push the new version.
Disallowing non-fast-forward push on the server prevents the rewriting from
propagating unintentionally. Phases proactively prevent users from shooting
themselves in the foot.
More details here https://www.logilab.org/blogentry/88203
Thanks. I think upstream remote-tracking branches in git are rather
similar. If one's afraid of rewriting published history she should never
rebase before @{u}. Just always using ``git rebase -i @{u}`` should be
good enough.
The biggest difference here is that git doesn't stop one to rebase
beyond @{upstream}.
I've to stop you right there. Mercurial is not forbidding you to do
anything. You can trivially move phase backward and rewrite these
changesets anyway.
Hg is not the inflexible corporate tool that limit what use can do while
git would be the awesome free range developer tool.
Mercurial is just asserting that new users have probably a partial
understanding of what they are doing and target to be safe by default,
while still giving access to advance feature and work-flow to advanced
users. My daily work-flow with mercurial would probably make most
advance git user head hurts (And yet is nice a smooth down there ☺).
--
Pierre-Yves David
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
