Oleg Broytman <phd <at> phdru.name> writes: > > Hi! > > On Tue, Sep 15, 2015 at 07:44:28PM +0000, Augie Fackler <raf <at> 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.
I've honestly never found this a problem. Heck, I don't even know *how* I'd go about configuring additional ignores in Google's enormous repository[0] and it's never been a pain point to my knowledge. YMMV. 0: https://youtu.be/W71BTkUbdqE?t=193 for hard numbers that just got released. > > > > 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. No, actually, they don't. Signed tags let you have a slightly stronger assertion that the currently-tagged thing is what should be tagged, but it does *not* provide any way of validating that the thing tagged 1.2 last week is still the thing tagged 1.2. In Mercurial, you'd have the audit log of .hgtags being edited in history, or else some hashes changing. In git, a ref moves (even in the signed tag case!) and that's all. I think tags even move automatically on fetch, so if you don't notice when you fetch you just lost the evidence of tampering. (This is admittedly quite paranoid, but keep in mind that for some projects "motivated nation-state" is their attacker model, so detecting tampering on this level might be of value.) > > > > ``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. For you. I find the staging area to merely get in my way. It's really a matter of taste. > > > > ``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] $ hg help -k grep Topics: filesets Specifying File Sets revsets Specifying Revision Sets Commands: diff diff repository (or selected files) files list tracked files grep search for a pattern in specified files and revisions You want revsets. help -k is your friend. > > > 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? > > > > I don't > > > know what are the equivalent commands for ``git commit -c HEAD~`` > > > > hg commit --amend, or use hg histedit (which is like rebase -i) > > No, they are not the same. AFAIK there are no equivalent options for > ``git commit -Cc``. > > > > Git has a lot of good documentation. > > > > Honestly so does Mercurial. > > It is harder to find. Mine installation has bash completion that > doesn't know "revsets" and "templates" though the help pages are there. Good point. http://bz.selenic.com/show_bug.cgi?id=4828 filed. > Actually it doesn't know much at all: > > $ hg help [TAB][TAB] > add cat graft log record summary > addremove clone grep manifest recover tag > annotate commit heads merge remove tags > archive config help outgoing rename tip > backout copy identify parents resolve transplant > bisect diff import paths revert unbundle > bookmarks export incoming phase rollback update > branch fetch init pull root verify > branches forget l5 push serve version > bundle glog locate qrecord status > > $ git help [TAB][TAB] > Display all 180 possibilities? (y or n) > > Another sign of git complexity. Sigh. > > > > 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 <at> {u}. Just always using ``git rebase -i <at> {u}`` should be > good enough. But you've now added another set of concepts that must be understood in order to always use the tool safely - rather than opting in to danger with Git, you have to opt in to safety. Mercurial tries to bias for defaulting safe for the normal user, and making power available with a config knob for those that want it. > The biggest difference here is that git doesn't stop one to rebase > beyond <at> {upstream}. It's possible to rewrite this kind of history in Mercurial, but Mercurial prevents you from performing an operation which will hurt collaboration with others. This is an ideological difference. > > Oleg. BTW, if you can, I'd appreciate remaining on the CC list so I can respond from my MUA instead of using gmane - I don't subscribe to python-devel, so I only see responses in the web interface if I'm not cc'ed. _______________________________________________ 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
