[Python-Dev] PEP: Collecting information about git (original) (raw)

Pierre-Yves David pierre-yves.david at ens-lyon.org
Wed Sep 16 20:58:23 CEST 2015

On 09/16/2015 02:20 AM, Oleg Broytman wrote:

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 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

More information about the Python-Dev mailing list