Re: [Python-Dev] PEP: Collecting information about git
Oleg Broytman phdru.name> writes: > > Hi! 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. There are a lot of reasons to prefer one tool over another. Common ones are familiarity, simplicity, and power. Version control debates often touch all three of those points, and there’s often a _lot_ of misinformation thrown around during the debate. It’s very clear to me based on this thread that Oleg is not familiar with Mercurial -- everything listed as impossible is not only doable in Mercurial, but not infrequently the command or flag is *identically named*. I’m sending this mail not in an attempt to combat what may be a healthy move for the your development community, but instead to ensure that the right capability tradeoffs are seen during this process. If the Python community wants to move to Git (or, as is more often the case with such migrations, GitHub specifically - the choice of Git is often totally unrelated to the popularity of the one particular host), it should do so for good, clear reasons. That might be everyone thinking Git is a better tool (to my own personal dismay, I’ll admit), or it might be that the perceived network effects of being hosted on GitHub outweigh the switching costs or difficulty of using a more complex tool. > > On Sun, Sep 13, 2015 at 09:14:58AM +1000, Tim Delaney gmail.com> wrote: > > On 13 September 2015 at 04:42, Oleg Broytman phdru.name> wrote: > > > > >There are too many things that I personally can do with git but can't > > > do with hg. Because of that I switched all my development from hg to git > > > and I am willing to help those who want to follow. > > > > Slightly off-topic, but personally I'd love to know what those are. I've > > yet to find anything in Git that I haven't been able to do at least as well > > with Mercurial (or an extension), and there are things Mercurial > > supports that I use extensively (in particular named branches and phases) > > where the concept doesn't even exist in Git. > [elided much that is strictly personal preference, plus some personal history] >Git fixed all the problems I had with hg. Its branching model suits > my understanding of branches much better. So use bookmarks. They're almost identical. > With git we can have > per-directory .gitignore and .gitattributes. Lightweight and annotated > 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. > Ability to pull and push between unrelated repos. In my opinion, this is honestly a misfeature, but Mercurial absolutely can do it: `hg pull --force` will do what you want. >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. :) > Later Mercurial learned commit editing, > unwillingly perhaps, Not at all unwillingly, we're just trying to be deliberate about it. We wanted to make sure that we *both* enabled editing by default, *and* make it impossible for a user to lose data. Getting that right took time, but we think the wait has been worth it. If you want a preview of where we’re headed, take a look at https://mercurial.selenic.com/wiki/ChangesetEvolution. Parts of it have shipped, and the whole concept is making steady progress. > but git is still better at it: ``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. We also now ship (at least as of 3.5) a curses UI for record, which is quite nice. >Git is powerful. Even now, at version 3.1 ``hg help log`` lists about > a dozen of options; ``git help log`` gives me about 60 pages of > documentation. Counting number of command line flags is a horrible way to compare power of the tool. It reflects complexity, not power. Mercurial has two major concepts--revsets and templates--that repeat over and over, and which eliminate the need for many command-line flags that Git has to include. I’ll give some examples below, but I’d also like to point out that if you'd read recent Mercurial (3.5 is current - you looked at a version that’s over a year old by now) output for 'hg help log', you'd find many options are quite powerful. See below. > I do not use all of them but I very much like > ``git log --decorate`` This can be done with our templating system - I even have it in m
Re: [Python-Dev] PEP: Collecting information about git
Chris Angelico gmail.com> writes: > > On Wed, Sep 16, 2015 at 5:44 AM, Augie Fackler durin42.com> wrote: > >> but git is still better at it: ``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. We also now ship (at least as of 3.5) a curses UI for > > record, which is quite nice. > > Looks like it's time I spun up my own hg, rather than using the 3.1.2 > that ships with Debian. Clone https://selenic.com/hg and run `make deb` - it's not quite done (doesn't include system configs for using the ca-certificates files for ssl trust), but it should give you usable debs on your system. Please let me know if it doesn't work for you! (Note that I'm not subbed to python-devel, so you'll get faster service by leaving me cc'ed on the thread.) > A better UI for interactive (partial) commits > would go a long way toward filling the hole left by not having a > staging area; though I'll still miss it, some, in the most complicated > cases (where I use 'git gui' to stage and unstage bits, then check in > 'gitk' that it looks right, continue until happy). Fortunately the > complicated cases are rare, but when my non-technical mother or my > technical-but-decades-out-of-date father needs help fixing up a > repository problem, I make good use of git's staging power. > > Mentioning in the PEP that some of these things are available as of > version X might help bridge the gap between one author's knowledge and > a core dev's skills. > > ChrisA > ___ 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
Re: [Python-Dev] PEP: Collecting information about git
Oleg Broytman phdru.name> writes: > > Hi! > > On Tue, Sep 15, 2015 at 07:44:28PM +, Augie Fackler 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 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 grepmanifestrecover tag > annotatecommit heads merge remove tags > archive config helpoutgoingrename tip > ba
Re: [Python-Dev] PEP: Collecting information about git
Nikolaus Rath rath.org> writes:
>
> On Sep 16 2015, Chris Angelico gmail.com> wrote:
> > With git, there are infinite workflows possible - you aren't forced to
> > have a concept of "central server" and "clients" the way you would
> > with SVN. Mercurial's called a DVCS too, so presumably it's possible
> > to operate on a pure-peering model with no central server at all; how
> > does that tie in with the inability to alter some commits?
>
> There is no inability to do so in hg either, you just need some --force
> flags ("hg phase -f -d " should be enough in almost all cases).
Actually, part of the value of phases is that it makes a truly decentralized
workflow easier to manage without errors. In Mercurial pre-phases and git,
you have to take some amount of care to avoid rebasing changes that you
pulled from an authoritative server - if you don't, you can end up with
weird history divergence that can be tricky to resolve. The addition of
phases helps the tool prevent accidental history editing.
As a concrete example, I pull from mpm's repo for Mercurial, but I push to a
repo of my own when I've reviewed patches or otherwise have work for him to
push to the authoritative one. More than once phases have prevented me from
rebasing his work onto my own, because I had a brain fart.
Does that help explain how it's a benefit in the decentralized case?
>
> Best,
> -Nikolaus
>
___
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
Re: [Python-Dev] PEP: Collecting information about git
Nikolaus Rath rath.org> writes: > > On Sep 16 2015, Paul Moore gmail.com> wrote: > > On 16 September 2015 at 06:10, Stephen J. Turnbull xemacs.org> wrote: > > In general you can do that by configuring the repository with > > [phases] > publish = False > > However, I believe BitBucket doesn't allow you to do that. But that's > not hg's fault. Actually, BitBucket *does* support marking a repo as non-publishing. They don't yet support exchanging the bit of metadata that lets obsolete draft changes disappear, but I believe they have someone working on that now. (I don't work for them, so I'm potentially working off of outdated rumors.) ___ 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
[Python-Dev] PEP460 thoughts from a Mercurial dev
(sorry for not piling on any existing threads - I don't subscribe to
python-dev due to lack of time)
Brett Cannon asked me to chime in - I haven't actually read the very long
thread at this point, I'm just providing responses to things Brett
mentioned:
1) What do we need in terms of functionality
Best guess, %s, %d, and %f. I've not done a full audit of the code, but
some limited looking over the grep hits for % in .py files suggests I'm
right, and we could even do without %f (we only use that for 'hg --time'
output, which we could do in unicode).
We also need some way to emit raw bytes (in potentially mixed encodings,
yes I know this is "doing it wrong") to stdout/stderr (example: someone
changes a file from latin1 to utf8, and then wants to see the resulting
diff).
2) Would having it as an external library that worked with Python 2 help?
Probably, IF it came with 2.4 support (RHEL support, basically), and we
could bundle it in our source tree. It's been extremely valuable to have
the install only depend on a working C compiler and Python.
3) If this does go in, how long would it take us to port Mercurial to py3?
Would it being in 3.5 hold us up?
I'm honestly not sure. I'm still in the outermost layers of this yak shave:
fixing cyclic imports. I'll know more when I can at least get 'hg version'
to print its own version, because at that point the testsuite failures
might be informative. I'd honestly _rather_ this went into 3.5 *and* got
lots of validation by both us and twisted (the other folks that care?)
before becoming set in stone by a release. Does that make sense?
4) Do we care if it's .format()/%, or could it be in the stdlib?
It'd be really nice to not have to boil the oceans as far as editing
everyplace in the codebase that does % today. If we do have to do that,
it's not going to be much more helpful than something like:
def maybestr(a):
if isinstance(a, bytes):
return a.decode('latin1)
return a
def sprintf(fmt, *args):
(fmt.decode('latin1') % [maybestr(a) for a in args]).encode('latin1)
or similar. That was (roughly) what I was figuring I'd do today without any
formal bytes-string-formatting support.
He also mentioned that some are calling for a shortened 3.5 release cycle -
I'd rather not see that happen, for the aforementioned reason of wanting
time to make sure this is Right - it'd be a shame to do the work and rush
it out only to find something missing in an important way.
Feel free to ask further questions - I'll try to respond promptly.
AF
(For those curious: my hg-on-py3 repo isn't published at the moment because
I rebuilt the server it lived on and I forgot to publish it. I'll rectify
that sometime this week, I hope, but it's really totally nonfunctional due
to cyclic imports.)
___
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
Re: [Python-Dev] PEP460 thoughts from a Mercurial dev
On Mon, Jan 13, 2014 at 12:34 PM, Guido van Rossum wrote: > On Mon, Jan 13, 2014 at 8:51 AM, Nick Coghlan wrote: > > On 13 January 2014 23:57, Augie Fackler wrote: > >> 1) What do we need in terms of functionality > >> > >> Best guess, %s, %d, and %f. I've not done a full audit of the code, but > some > >> limited looking over the grep hits for % in .py files suggests I'm > right, > >> and we could even do without %f (we only use that for 'hg --time' > output, > >> which we could do in unicode). > > > > I think PEP 460 will have you covered there, or hopefully asciistr on > 3.3+ > > I'm confused on how PEP 460 would help -- Augie mentioned %d, which it > excludes. Yes - not having %d makes this much much less useful to me. For my part, it'd probably be fine if we could do %s (which would handle an RHS that was bytes, and only bytes, no handing of str or __bytes__-type stuff at all) and %d (with all the usual format modifiers, and would result in an ascii-compatible sequence of bytes all the time). ___ 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
Re: [Python-Dev] PEP460 thoughts from a Mercurial dev
On Mon, Jan 13, 2014 at 12:39 PM, Guido van Rossum wrote: > On Mon, Jan 13, 2014 at 9:37 AM, Augie Fackler wrote: > > > > On Mon, Jan 13, 2014 at 12:34 PM, Guido van Rossum > wrote: > >> > >> On Mon, Jan 13, 2014 at 8:51 AM, Nick Coghlan > wrote: > >> > On 13 January 2014 23:57, Augie Fackler wrote: > >> >> 1) What do we need in terms of functionality > >> >> > >> >> Best guess, %s, %d, and %f. I've not done a full audit of the code, > but > >> >> some > >> >> limited looking over the grep hits for % in .py files suggests I'm > >> >> right, > >> >> and we could even do without %f (we only use that for 'hg --time' > >> >> output, > >> >> which we could do in unicode). > >> > > >> > I think PEP 460 will have you covered there, or hopefully asciistr on > >> > 3.3+ > >> > >> I'm confused on how PEP 460 would help -- Augie mentioned %d, which it > >> excludes. > > > > > > > > Yes - not having %d makes this much much less useful to me. > > > > For my part, it'd probably be fine if we could do %s (which would handle > an > > RHS that was bytes, and only bytes, no handing of str or __bytes__-type > > stuff at all) and %d (with all the usual format modifiers, and would > result > > in an ascii-compatible sequence of bytes all the time). > > Would it be okay of instead of %s you had to use %b for those > semantics? (%d would still exist) Probably, but it'd be quite painful, since we'd have to to some kind of .sub() call all over the place to remain compatible with 2.4 and 2.6. Dropping 2.4 might be possible in the 3.5 timeframe - 2.6 almost certainly not. ___ 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
Re: [Python-Dev] PEP460 thoughts from a Mercurial dev
Antoine Pitrou pitrou.net> writes: > > On Mon, 13 Jan 2014 09:34:39 -0800 > Guido van Rossum python.org> wrote: > > On Mon, Jan 13, 2014 at 8:51 AM, Nick Coghlan gmail.com> wrote: > > > On 13 January 2014 23:57, Augie Fackler durin42.com> wrote: > > >> 1) What do we need in terms of functionality > > >> > > >> Best guess, %s, %d, and %f. I've not done a full audit of the code, but some > > >> limited looking over the grep hits for % in .py files suggests I'm right, > > >> and we could even do without %f (we only use that for 'hg --time' output, > > >> which we could do in unicode). > > > > > > I think PEP 460 will have you covered there, or hopefully asciistr on 3.3+ > > > > I'm confused on how PEP 460 would help -- Augie mentioned %d, which it excludes. > > Serhiy did a survey of formatting codes in the Mercurial sources: > https://mail.python.org/pipermail/python-dev/2014-January/130969.html Note that a lot of those are in debug code (eg the only %f I've spotted is), or are time format specifiers (which can be unicode just fine). A few others (eg %ln) are for our internal revset format-string language, so this overstates what we'd need in bytes by a little. %f would probably be good too, as I look a little more. (Please don't remove me from the CC list - I could only respond via gmane because I'm not subscribed to python-dev.) > > Regards > > Antoine. > > ___ 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
Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3
On Mar 29, 2014, at 2:53 PM, Gregory P. Smith wrote: > > On Thu, Mar 27, 2014 at 3:05 PM, Antoine Pitrou wrote: > On Thu, 27 Mar 2014 18:47:59 + > Brett Cannon wrote: > > On Thu Mar 27 2014 at 2:42:40 PM, Guido van Rossum wrote: > > > > > Much better, but I'm still not happy with including %s at all. Otherwise > > > it's accept-worthy. (How's that for pressure. :-) > > > > > > > But if we only add %b and leave out %s then how is this going to lead to > > Python 2/3 compatible code since %b is not in Python 2? Or am I > > misunderstanding you? > > I think we have reached a point where adding porting-related facilities > in 3.5 may actually slow down the pace of porting, rather than > accelerate it (because people will then wait for 3.5 to start porting > stuff). > > I understand that sentiment but that is an unjustified fear. It is not a good > reason not to do it. Projects are already trying to port stuff today and > running into roadblocks when it comes to ascii-compatible bytes formatting > for real world data formats in code needing to be 2.x compatible. I'm pulling > out my practicality beats purity card here. > > Mercurial is one of the large Python 2.4-2.7 code bases that needs this > feature in order to support Python 3 in a sane manner. (+Augie Fackler to > look at the latest http://legacy.python.org/dev/peps/pep-0461/ to confirm > usefulness) That looks sufficient to me - the biggest thing is being able to do "abort: %s is broken" % some_filename_that_is_bytes and have that work sanely, as well as the numerics. This looks like exactly what we need, but I'd love to test it soon (I'm happy to build a 3.5 from tip for testing) so that if it's not Right[0] changes can be made before it's permanent. Feel encouraged to CC me on patches or something for testing (or mail me directly when it lands). Thanks! AF > > -gps signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
