[Python-Dev] PEP: Collecting information about git

Oleg Broytman phd at phdru.name
Wed Sep 16 11:20:25 CEST 2015


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.

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

> 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.
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 @{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}.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.


More information about the Python-Dev mailing list