[Python-Dev] PEP: Collecting information about git

Augie Fackler raf at durin42.com
Wed Sep 16 16:24:30 CEST 2015


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.






More information about the Python-Dev mailing list