[Python-Dev] PEP: Collecting information about git

[Pierre-Yves David]

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