Re: [Python-Dev] Hg: inter-branch workflow

Michael Foord writes: > On 28/03/2011 11:35, Nick Coghlan wrote: > > I'm seeing if I can get the best of both worlds by having a public > > sandbox repo where I work on things (which has the full messy > > history of development on its feature branches), and then just drop > > them into the main

Re: [Python-Dev] Hg: inter-branch workflow

On 28 March 2011 22:29, Terry Reedy wrote: > From what you write, it seems that mq is actually an unordered patch set, > not a queue (in the FIFO) sense. (Or do you have to commit and remove in > FIFO order?) Why the confusing mislabel, if indeed I understood correctly? It's a queue (FIFO). Sorry

Re: [Python-Dev] Hg: inter-branch workflow

On 3/28/2011 6:13 AM, Paul Moore wrote: This philosophy is essentially what the "mq" extension to Mercurial tries to capture. In mq, you maintain a series of patches "on top of" your repository, amending, refining and rebasing them as you wish until they are ready to commit, at which time you ta

Re: [Python-Dev] Hg: inter-branch workflow

On Mar 27, 2011, at 01:39 PM, Neil Schemenauer wrote: >Barry Warsaw wrote: >> I'm asking because I don't know hg and git well enough to answer the >> question. In my own use of Bazaar over the last 4+ years, I've almost never >> rebased or even been asked to. > >Maybe it depends on what kind of

Re: [Python-Dev] Hg: inter-branch workflow

On Mon, Mar 28, 2011 at 10:48 PM, Michael Foord wrote: > On 28/03/2011 11:35, Nick Coghlan wrote: >> Mercurial makes merging easy enough that I'm happy with the way that >> approach is working so far. > > For any non-trivial work I think this is the best approach. You still get > all the advantage

Re: [Python-Dev] Hg: inter-branch workflow

On 28/03/2011 11:35, Nick Coghlan wrote: On Mon, Mar 28, 2011 at 8:13 PM, Paul Moore wrote: For people in the "clean history" school, I'd recommend looking at mq for your personal use. But it's definitely an advanced feature of Mercurial, so it may be better to understand core Mercurial (and at

Re: [Python-Dev] Hg: inter-branch workflow

On 28 March 2011 11:35, Nick Coghlan wrote: > On Mon, Mar 28, 2011 at 8:13 PM, Paul Moore wrote: >> For people in the "clean history" school, I'd recommend looking at mq >> for your personal use. But it's definitely an advanced feature of >> Mercurial, so it may be better to understand core Mercu

Re: [Python-Dev] Hg: inter-branch workflow

On Mon, Mar 28, 2011 at 8:13 PM, Paul Moore wrote: > For people in the "clean history" school, I'd recommend looking at mq > for your personal use. But it's definitely an advanced feature of > Mercurial, so it may be better to understand core Mercurial (and at > least temporarily accept that Mercu

Re: [Python-Dev] Hg: inter-branch workflow

On 27 March 2011 20:15, Neil Schemenauer wrote: > Guido van Rossum wrote: >> What is "rebase"? Why does everyone want it and hate it at the same time? [...] > The other school, which I am a member of, considers a logical > development sequence more important than actual development history. > I l

Re: [Python-Dev] Hg: inter-branch workflow

Neil Schemenauer writes: > Regarding collapsing multiple comments (and rewriting history in > general), I feel there are two main schools of thought. One school > considers the development history of a change important and that it > should be preserved: every step and misstep of development shoul

Re: [Python-Dev] Hg: inter-branch workflow

Barry Warsaw wrote: > I'm asking because I don't know hg and git well enough to answer the > question. In my own use of Bazaar over the last 4+ years, I've almost never > rebased or even been asked to. Maybe it depends on what kind of changes you commit. I consider future maintainers the most i

Re: [Python-Dev] Hg: inter-branch workflow

Guido van Rossum wrote: > What is "rebase"? Why does everyone want it and hate it at the same time? It's the same thing that happens when you do a "svn up" with local changes in your checkout. Logically, your patch gets modified so that it applies on a different (newer) version of the code. If

Re: [Python-Dev] Hg: inter-branch workflow

On 03/21/2011 11:35 PM, "Martin v. Löwis" wrote: If people then complain about too much fine-grainedness, we could tighten it again. Hi to all for the first time, I'm new to this list. First of all I would like to thank all you for the great software and ideas you produce. I found this

Re: [Python-Dev] Hg: inter-branch workflow

On Tue, 22 Mar 2011 15:42:27 -0700, Glenn Linderman wrote: > I don't recall 5-12 step sequences in the DVCS PEP when I read it once, > for any of the tools, but things progressed from the time I read it, so > maybe they would all have longer sequences. > > Back when I used non-distributed VCS

Re: [Python-Dev] Hg: inter-branch workflow

Daniel> On Mon, Mar 21, 2011 at 8:02 PM, Stephen J. Turnbull wrote: >> ... because I commit with *every* save ... Effectively, I use git as >> an extension to XEmacs's undo/redo mechanism. Daniel> I, too, commit using git with every save (which I do early and Daniel> often).

Re: [Python-Dev] Hg: inter-branch workflow

>>> I'm curious: what are the benefits of the Mercurial model? >> Simplicity. > > That's an amusing response, after reading hundreds of emails on this > list I think the great number of messages is caused by incomplete learning, confusion caused by familiarity with other tools, FUD and anxiety.

Re: [Python-Dev] Hg: inter-branch workflow

> FWIW, Mercurial's "mainline" is the branch with the name 'default'. This > branch name is reserved, and it implies that the head with the highest > revision number from that branch will be checked out on 'hg clone'. This does not fully maps to Bazaar’s concept of mainline, though. An aside for

Re: [Python-Dev] Hg: inter-branch workflow

On Tue, Mar 22, 2011 at 03:42:27PM -0700, Glenn Linderman wrote: > and didn't figure I had time to learn both. I haven't read the new devguide > yet, but from the activity on the list, it would seem that either no one else I think, it is a good idea to read that. You might find that many discussio

Re: [Python-Dev] Hg: inter-branch workflow

On 3/22/2011 2:43 PM, Éric Araujo wrote: Bazaar apparently has a notion of mainline whereas Mercurial believes that all changesets are created equal. The tools are different. I'm curious: what are the benefits of the Mercurial model? Simplicity. That's an amusing response, after reading hund

Re: [Python-Dev] Hg: inter-branch workflow

>> Bazaar apparently has a notion of mainline whereas Mercurial believes >> that all changesets are created equal. The tools are different. > I'm curious: what are the benefits of the Mercurial model? Simplicity. ___ Python-Dev mailing list Python-Dev@p

Re: [Python-Dev] Hg: inter-branch workflow

On Wed, Mar 23, 2011 at 12:28 AM, Barry Warsaw wrote: >>Ah. We don't support this kind of development - no new named branches >>are allowed in the central repository. > > It does sound like that restriction is a source of friction for us. I'd like to hold off on abandoning it, though. All the iss

Re: [Python-Dev] Hg: inter-branch workflow

On Wed, Mar 23, 2011 at 12:22 AM, Barry Warsaw wrote: > I think that's different than what John was describing, or perhaps Python's > use of it has the effect of being different.  IIUC, in Mercurial, within the > default branch there's no clear "main line" of development assigned to a path > withi

Re: [Python-Dev] Hg: inter-branch workflow

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22/03/11 11:19, John Arbash Meinel wrote: > And suddenly the revision which was an "important" C change is now gone > on the mainline, and your personal "and I did D" is now a primary > revision. It doesn't matter much for a single revision D and C,

Re: [Python-Dev] Hg: inter-branch workflow

On Mon, Mar 21, 2011 at 8:02 PM, Stephen J. Turnbull wrote: > Speaking for myself, I rewrite my git history because it is *not* > useful to me as is. Almost all of my git commits have a informational > half-life measured in hours once they're off tip, because I commit > with *every* save (I have

Re: [Python-Dev] Hg: inter-branch workflow

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/22/2011 3:25 PM, Barry Warsaw wrote: > On Mar 22, 2011, at 12:52 AM, Éric Araujo wrote: > >> Bazaar apparently has a notion of mainline whereas Mercurial believes >> that all changesets are created equal. The tools are different. > > I'm curiou

Re: [Python-Dev] Hg: inter-branch workflow

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/22/2011 3:22 PM, Barry Warsaw wrote: > On Mar 22, 2011, at 12:07 PM, Adrian Buehlmann wrote: > >> FWIW, Mercurial's "mainline" is the branch with the name 'default'. This >> branch name is reserved, and it implies that the head with the highest >

Re: [Python-Dev] Hg: inter-branch workflow

On Tue, Mar 22, 2011 at 10:25 AM, Barry Warsaw wrote: > I'm curious: what are the benefits of the Mercurial model? If we're all left confused and unable to use the tools to change the software, we won't break things. This is good. :-)   -Fred -- Fred L. Drake, Jr.    "A storm broke loose in

Re: [Python-Dev] Hg: inter-branch workflow

On Mar 22, 2011, at 07:51 AM, Martin v. Löwis wrote: >Am 22.03.2011 02:02, schrieb Eugene Toder: >>> Not if the changes you want to suppress are actually also on the same >>> branch as the one whose mainline you are trying to see (which they >>> typically are, with the branch typically being "defa

Re: [Python-Dev] Hg: inter-branch workflow

On Mar 22, 2011, at 12:52 AM, Éric Araujo wrote: >Bazaar apparently has a notion of mainline whereas Mercurial believes >that all changesets are created equal. The tools are different. I'm curious: what are the benefits of the Mercurial model? -Barry signature.asc Description: PGP signature _

Re: [Python-Dev] Hg: inter-branch workflow

On Mar 22, 2011, at 12:07 PM, Adrian Buehlmann wrote: >FWIW, Mercurial's "mainline" is the branch with the name 'default'. This >branch name is reserved, and it implies that the head with the highest >revision number from that branch will be checked out on 'hg clone'. I think that's different tha

Re: [Python-Dev] Hg: inter-branch workflow

On Mar 21, 2011, at 11:09 PM, Martin v. Löwis wrote: >However, what some of us requesting is that the "SHOULD collapse" >in the devguide is changed to a "MAY collapse", making it strictly >an option of the committer. +1 -Barry signature.asc Description: PGP signature __

Re: [Python-Dev] Hg: inter-branch workflow

On 2011-03-22 11:19, John Arbash Meinel wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 3/21/2011 9:19 PM, Barry Warsaw wrote: >> On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote: >> >>> Keeping the repository clean makes it easier to use a bisection search to >>> hunt down the

Re: [Python-Dev] Hg: inter-branch workflow

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/21/2011 9:19 PM, Barry Warsaw wrote: > On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote: > >> Keeping the repository clean makes it easier to use a bisection search to >> hunt down the introduction of a bug. If every developer's intermediat

Re: [Python-Dev] Hg: inter-branch workflow

On Tue, Mar 22, 2011 at 8:35 AM, "Martin v. Löwis" wrote: >> Well, it's "should", not "must" ;) >> When writing this, I had in mind that other projects have different >> workflows, where indeed people never collapse and many tiny changesets >> (which are only significant as part of a bigger work)

Re: [Python-Dev] Hg: inter-branch workflow

"Martin v. Löwis" writes: > Am 22.03.2011 02:02, schrieb Eugene Toder: > >> Not if the changes you want to suppress are actually also on the same > >> branch as the one whose mainline you are trying to see (which they > >> typically are, with the branch typically being "default"). > > > > Rig

Re: [Python-Dev] Hg: inter-branch workflow

Am 22.03.2011 03:43, schrieb Stephen J. Turnbull: > "Martin v. Löwis" writes: > > > Not if the changes you want to suppress are actually also on the same > > branch as the one whose mainline you are trying to see (which they > > typically are, with the branch typically being "default"). > > Th

Re: [Python-Dev] Hg: inter-branch workflow

Am 22.03.2011 02:02, schrieb Eugene Toder: >> Not if the changes you want to suppress are actually also on the same >> branch as the one whose mainline you are trying to see (which they >> typically are, with the branch typically being "default"). > > Right, that would amount to not using named bra

Re: [Python-Dev] Hg: inter-branch workflow

Greg Ewing writes: > There should be a hierarchy of changesets, so you can look at the top > level and get the big picture, while being able to drill down into the > details when you need to. Yes, that's exactly what Bazaar does. Perhaps the Python team can make a big request to Mercurial to imp

Re: [Python-Dev] Hg: inter-branch workflow

On 2011-03-22, Steven D'Aprano wrote: > Tim Delaney wrote: > >> You'd end up using more horizontal space, but we all seem to have >> widescreen monitors these days. > > Not even close to "we all". Fair enough - that was a fairly stupid statement on my part. Blame it on being on dial-up (26kbps!)

Re: [Python-Dev] Hg: inter-branch workflow

Ben Finney writes: > As a user of Bazaar primarily, that's addressing the problem in the > wrong place: why rewrite *my* history, which is useful to me as is, when > the other person is using Bazaar and so doesn't see revisions they don't > care about? Speaking for myself, I rewrite my git hi

Re: [Python-Dev] Hg: inter-branch workflow

"Martin v. Löwis" writes: > Not if the changes you want to suppress are actually also on the same > branch as the one whose mainline you are trying to see (which they > typically are, with the branch typically being "default"). There is no "also on" with Mercurial named branches. Every commit

Re: [Python-Dev] Hg: inter-branch workflow

> Not if the changes you want to suppress are actually also on the same > branch as the one whose mainline you are trying to see (which they > typically are, with the branch typically being "default"). Right, that would amount to not using named branches. But if you develop on a named feature-bran

Re: [Python-Dev] Hg: inter-branch workflow

Am 22.03.2011 01:08, schrieb Eugene Toder: >> Bazaar apparently has a notion of mainline whereas Mercurial believes >> that all changesets are created equal. The tools are different. > > Mercurial has named branches. When viewing history you can restrict it > to just one named branch, which, I th

Re: [Python-Dev] Hg: inter-branch workflow

Eugene Toder wrote: Mercurial has named branches. When viewing history you can restrict it to just one named branch, which, I think, will have an effect similar to "mainline". So with Hg, could you get the same effect by pushing your local changes into a temporary named branch, and then mergin

Re: [Python-Dev] Hg: inter-branch workflow

> Bazaar apparently has a notion of mainline whereas Mercurial believes > that all changesets are created equal.  The tools are different. Mercurial has named branches. When viewing history you can restrict it to just one named branch, which, I think, will have an effect similar to "mainline". Eu

Re: [Python-Dev] Hg: inter-branch workflow

Le 22/03/2011 00:46, Greg Ewing a écrit : > Ben Finney wrote: >> That seems to me the ideal: preserve all revision history for those >> cases when some user will care about it, but *present* history cleanly >> by default. > > Seems to me the basic problem here is the way Mercurial > presents you w

Re: [Python-Dev] Hg: inter-branch workflow

Ben Finney wrote: That seems to me the ideal: preserve all revision history for those cases when some user will care about it, but *present* history cleanly by default. Seems to me the basic problem here is the way Mercurial presents you with a big pile of changesets and not much way of imposi

Re: [Python-Dev] Hg: inter-branch workflow

On Mon, 21 Mar 2011 23:35:30 +0100 "Martin v. Löwis" wrote: > > Having to be nitpicking here "not how you (Antoine) want us to work". > "We" aren't using mercurial long enough to make such a statement. Well, being directive and giving strong workflow indications seems to be what many people are

Re: [Python-Dev] Hg: inter-branch workflow

> Well, it's "should", not "must" ;) > When writing this, I had in mind that other projects have different > workflows, where indeed people never collapse and many tiny changesets > (which are only significant as part of a bigger work) end up in the main > history. The point is to signal that it's

Re: [Python-Dev] Hg: inter-branch workflow

Tim Delaney wrote: You'd end up using more horizontal space, but we all seem to have widescreen monitors these days. Not even close to "we all". -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/pyt

Re: [Python-Dev] Hg: inter-branch workflow

> One of the key elements here is the way we use python-checkins for > after-the-fact review. I think this can be achieved with a better email hook. I would propose that there will be one email message per push per branch (rather than one per changeset). For each branch, it should report what chan

Re: [Python-Dev] Hg: inter-branch workflow

> However, what some of us requesting is that the "SHOULD collapse" > in the devguide is changed to a "MAY collapse", making it strictly > an option of the committer. If there is one substantial change, > a typo change, and three merges, asking for a collapse of the typo > change is IMO complicati

Re: [Python-Dev] Hg: inter-branch workflow

> I know I would be sorely tempted to use hg export + hg import (and > extensive testing after the latter of course) so that the approved > changes can land with a single thud in the core repo. But maybe I'm a > dinosaur? I certainly agree that there are cases where collapsing changes is desirable

Re: [Python-Dev] Hg: inter-branch workflow

On Mon, Mar 21, 2011 at 3:00 PM, Nick Coghlan wrote: > On Tue, Mar 22, 2011 at 7:51 AM, Guido van Rossum wrote: >> Let's say I'm working on a fairly substantial feature that may take >> weeks to complete. My way of working is to explore different >> approaches until I'm happy. I like to make chec

Re: [Python-Dev] Hg: inter-branch workflow

On Tue, Mar 22, 2011 at 7:51 AM, Guido van Rossum wrote: > Let's say I'm working on a fairly substantial feature that may take > weeks to complete. My way of working is to explore different > approaches until I'm happy. I like to make checkpoints while I'm > exploring so that I can easily backtrac

Re: [Python-Dev] Hg: inter-branch workflow

On Mon, 21 Mar 2011 22:47:19 +0100 "Martin v. Löwis" wrote: > > ISTM, there has been substantial mission creep from > > the workflow described in the PEP. If the current workflow > > had been described there, I don't think it would have been > > readily accepted. > > I don't think PEP 385 actua

Re: [Python-Dev] Hg: inter-branch workflow

On Tue, Mar 22, 2011 at 7:25 AM, Barry Warsaw wrote: > On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote: > >>I'd rather take a look at the final aggregate patch to see if it looks >>correct, actually. It's easy to have incremental changes which look >>good but lead to a questionable patch in the

Re: [Python-Dev] Hg: inter-branch workflow

On Mon, Mar 21, 2011 at 2:31 PM, Antoine Pitrou wrote: > On Mon, 21 Mar 2011 17:25:05 -0400 > Barry Warsaw wrote: >> On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote: >> >> >I'd rather take a look at the final aggregate patch to see if it looks >> >correct, actually. It's easy to have increment

Re: [Python-Dev] Hg: inter-branch workflow

> ISTM, there has been substantial mission creep from > the workflow described in the PEP. If the current workflow > had been described there, I don't think it would have been > readily accepted. I don't think PEP 385 actually *was* accepted at all (PEP 374 was, selecting Mercurial). I had meant

Re: [Python-Dev] Hg: inter-branch workflow

On Mon, 21 Mar 2011 17:25:05 -0400 Barry Warsaw wrote: > On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote: > > >I'd rather take a look at the final aggregate patch to see if it looks > >correct, actually. It's easy to have incremental changes which look > >good but lead to a questionable patch

Re: [Python-Dev] Hg: inter-branch workflow

On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote: >I'd rather take a look at the final aggregate patch to see if it looks >correct, actually. It's easy to have incremental changes which look >good but lead to a questionable patch in the end. Better to review it >in aggregate, IMO. I think it wo

Re: [Python-Dev] Hg: inter-branch workflow

On 2011-03-22, Ben Finney wrote: > That seems to me the ideal: preserve all revision history for those > cases when some user will care about it, but *present* history cleanly > by default. > > Whether adding support in Mercurial or Git for similar > clean-presentation-by-default would obviate th

Re: [Python-Dev] Hg: inter-branch workflow

2011/3/21 Raymond Hettinger : > > On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote: > > People love it because it's a very powerful tool.  People hate it because it > allows you to shoot yourself in the foot. > > There's a certain irony in this.   The original motivation for version > control >

Re: [Python-Dev] Hg: inter-branch workflow

On Mon, 21 Mar 2011 16:33:31 -0400 Barry Warsaw wrote: > Each of those would be > represented by a changeset in my local line of development, and by a side > branch in the mainline DAG once my merge is completed. You might want to dig > into that sideline to see if indeed I addressed the issues i

Re: [Python-Dev] Hg: inter-branch workflow

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/21/2011 04:33 PM, Barry Warsaw wrote: > On Mar 21, 2011, at 07:38 PM, Antoine Pitrou wrote: > >> On Mon, 21 Mar 2011 14:29:54 -0400 >> Barry Warsaw wrote: I don't think many hg users advocate rebase, really. AFAICT the Mercurial

Re: [Python-Dev] Hg: inter-branch workflow

On Mar 21, 2011, at 07:38 PM, Antoine Pitrou wrote: >On Mon, 21 Mar 2011 14:29:54 -0400 >Barry Warsaw wrote: >> > >> >I don't think many hg users advocate rebase, really. AFAICT the >> >Mercurial developers themselves don't seem to use it (they do use mq, >> >OTOH). >> >> I guess that begs the q

Re: [Python-Dev] Hg: inter-branch workflow

On Mar 22, 2011, at 06:57 AM, Ben Finney wrote: >Barry Warsaw writes: > >> There's something I don't understand about rebase. It seems like most >> git and hg users I hear from advocate rebase, while (ISTM) few Bazaar >> users do. >> >> I'd like to understand whether that's a cultural thing or wh

Re: [Python-Dev] Hg: inter-branch workflow

On Mar 21, 2011, at 08:58 PM, Georg Brandl wrote: >On 21.03.2011 20:09, s...@pobox.com wrote: >> >> Daniel> If every developer's intermediate commits make it into the main >> Daniel> repository, it's hard to go back to an older revision to test >> Daniel> something, because many of th

Re: [Python-Dev] Hg: inter-branch workflow

On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote: >Keeping the repository clean makes it easier to use a bisection search to >hunt down the introduction of a bug. If every developer's intermediate >commits make it into the main repository, it's hard to go back to an older >revision to test s

Re: [Python-Dev] Hg: inter-branch workflow

On 21.03.2011 20:09, s...@pobox.com wrote: > > Daniel> If every developer's intermediate commits make it into the main > Daniel> repository, it's hard to go back to an older revision to test > Daniel> something, because many of the older revisions will be broken in > Daniel> some w

Re: [Python-Dev] Hg: inter-branch workflow

Barry Warsaw writes: > There's something I don't understand about rebase. It seems like most > git and hg users I hear from advocate rebase, while (ISTM) few Bazaar > users do. > > I'd like to understand whether that's a cultural thing or whether it's > a byproduct of some aspect of the respectiv

Re: [Python-Dev] Hg: inter-branch workflow

On 21.03.2011 20:40, Raymond Hettinger wrote: > > On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote: >> >> >> People love it because it's a very powerful tool. People hate it because it >> allows you to shoot yourself in the foot. > > There's a certain irony in this. The original motivation

Re: [Python-Dev] Hg: inter-branch workflow

On Mon, 21 Mar 2011 12:40:08 -0700 Raymond Hettinger wrote: > > Now we seem to be advocating a complex, fragile workflow that > is hard to learn, hard to get right, that let's you shoot yourself in > the foot, and that has rebasing/collapsing steps that destroy and > rewrite history (an possibl

Re: [Python-Dev] Hg: inter-branch workflow

On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote: > > People love it because it's a very powerful tool. People hate it because it > allows you to shoot yourself in the foot. There's a certain irony in this. The original motivation for version control was to be a safety rope, to serve as

Re: [Python-Dev] Hg: inter-branch workflow

Daniel> If every developer's intermediate commits make it into the main Daniel> repository, it's hard to go back to an older revision to test Daniel> something, because many of the older revisions will be broken in Daniel> some way. This is what I discovered with my trivial doc pa

Re: [Python-Dev] Hg: inter-branch workflow

On Sun, Mar 20, 2011 at 9:39 AM, Georg Brandl wrote: > Now, "hg pull --rebase" prevents that by "re-basing" the A-B history > line onto the latest remote head. After rebasing, the history looks > like this: > > ... --- X --- C --- D --- E --- A' --- B' > Rebasing also allows you to collapse the

Re: [Python-Dev] Hg: inter-branch workflow

On Mon, 21 Mar 2011 14:29:54 -0400 Barry Warsaw wrote: > > > >I don't think many hg users advocate rebase, really. AFAICT the > >Mercurial developers themselves don't seem to use it (they do use mq, > >OTOH). > > I guess that begs the question then. ;) > > What harm would there be in relaxing

Re: [Python-Dev] Hg: inter-branch workflow

On Mar 21, 2011, at 06:07 PM, Antoine Pitrou wrote: >On Mon, 21 Mar 2011 12:20:15 -0400 >Barry Warsaw wrote: >> On Mar 20, 2011, at 04:39 PM, Georg Brandl wrote: >> >> >On 20.03.2011 16:21, Guido van Rossum wrote: >> >> What is "rebase"? Why does everyone want it and hate it at the same time? >>

Re: [Python-Dev] Hg: inter-branch workflow

On Mon, 21 Mar 2011 12:20:15 -0400 Barry Warsaw wrote: > On Mar 20, 2011, at 04:39 PM, Georg Brandl wrote: > > >On 20.03.2011 16:21, Guido van Rossum wrote: > >> What is "rebase"? Why does everyone want it and hate it at the same time? > > > >Basically, rebase is a way to avoid having pointless m

Re: [Python-Dev] Hg: inter-branch workflow

On 21 March 2011 16:20, Barry Warsaw wrote: > It could be that some aspect of the tools causes A and B to not be hidden as > well as they should, so that when looking at the history for example, the fact > that A and B exist is a jarring or annoying artifact that would be better if > they didn't e

Re: [Python-Dev] Hg: inter-branch workflow

On Tue, Mar 22, 2011 at 1:20 AM, Barry Warsaw wrote: > On Mar 20, 2011, at 04:39 PM, Georg Brandl wrote: > >>On 20.03.2011 16:21, Guido van Rossum wrote: >>> What is "rebase"? Why does everyone want it and hate it at the same time? >> >>Basically, rebase is a way to avoid having pointless merge co

Re: [Python-Dev] Hg: inter-branch workflow

On Mar 20, 2011, at 04:39 PM, Georg Brandl wrote: >On 20.03.2011 16:21, Guido van Rossum wrote: >> What is "rebase"? Why does everyone want it and hate it at the same time? > >Basically, rebase is a way to avoid having pointless merge commits on the >same branch. There's something I don't underst

Re: [Python-Dev] Hg: inter-branch workflow

In article <4d871440.2000...@timgolden.me.uk>, Tim Golden wrote: > A further tip in case it helps anyone: hg import (and its mq > counterpart hg qimport) can patch directly from a URL. This > is handy when I want to try out someone's patch directly from > the issue page on bugs.python.org. [Maybe

Re: [Python-Dev] Hg: inter-branch workflow

> A further tip in case it helps anyone: hg import (and its mq > counterpart hg qimport) can patch directly from a URL. This > is handy when I want to try out someone's patch directly from > the issue page on bugs.python.org. [Maybe everyone else knew > this, but I found it out by accident!] Thank

Re: [Python-Dev] Hg: inter-branch workflow

On 21/03/2011 02:49, Éric Araujo wrote: I have been avoiding hg import because my understanding is that it defaults to commit, and I don't see that it has any advantage over patch itself. “hg import” understands the extended diff format, which patch does not. (That format has been described a

Re: [Python-Dev] Hg: inter-branch workflow

> I have been avoiding hg import because my understanding is that it > defaults to commit, and I don't see that it has any advantage over patch > itself. “hg import” understands the extended diff format, which patch does not. (That format has been described a number of times already, see http://me

Re: [Python-Dev] Hg: inter-branch workflow

On 21 March 2011 08:16, Tim Delaney wrote: > > For the second and later merges: > > hg update 1234_merged_with_3.2 > hg merge 3.2 > hg commit -m "Merged 3.2 to 1234_merged_with_3.2" > hg merge 1234 > hg commit -m "Merged 1234 to 1234_merged_with_3.2" > Of course, you should probably do the "hg m

Re: [Python-Dev] Hg: inter-branch workflow

On 20.03.2011 18:32, Thomas Wouters wrote: > > > On Sun, Mar 20, 2011 at 17:59, Georg Brandl > wrote: > > On 20.03.2011 16:50, Thomas Wouters wrote: > > > > > > On Sun, Mar 20, 2011 at 17:39, Georg Brandl > >

Re: [Python-Dev] Hg: inter-branch workflow

On Mon, Mar 21, 2011 at 2:59 AM, Georg Brandl wrote: > Well, YMMV.  But instead of spreading FUD you might want to state *why*. David isn't the only one this kind of thing blew up on during the sprints (although in my case, it may have been "hg rollback" rather than rebasing). Essentially, if us

Re: [Python-Dev] Hg: inter-branch workflow

Thomas Wouters writes: > On Sun, Mar 20, 2011 at 17:59, Georg Brandl wrote: > > On 20.03.2011 16:50, Thomas Wouters wrote: > > > On Sun, Mar 20, 2011 at 17:39, Georg Brandl > > > wrote: > > > > > > The reason why rebasing is not universally applied is that the >

Re: [Python-Dev] Hg: inter-branch workflow

On 21 March 2011 04:32, Thomas Wouters wrote: > > Merging and merge changesets are a fact of DVCSes, and while I (as a grumpy > luddite misanthrope) greatly prefer the automatic (and mostly silent) merge > as BitKeeper does it, in the long run the actual merging and the merge > changesets are una

Re: [Python-Dev] Hg: inter-branch workflow

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/20/2011 5:06 AM, R. David Murray wrote: > On Thu, 17 Mar 2011 14:33:00 +0100, wrote: >> On Thu, 17 Mar 2011 09:24:26 -0400 >> "R. David Murray" wrote: >>> >>> It would be great if rebase did work with share, that would make a >>> push race basic

Re: [Python-Dev] Hg: inter-branch workflow

On Sun, Mar 20, 2011 at 17:59, Georg Brandl wrote: > On 20.03.2011 16:50, Thomas Wouters wrote: > > > > > > On Sun, Mar 20, 2011 at 17:39, Georg Brandl > > wrote: > > > > The reason why rebasing is not universally applied is that the > > rebased changesets are di

Re: [Python-Dev] Hg: inter-branch workflow

On 20.03.2011 16:50, Thomas Wouters wrote: > > > On Sun, Mar 20, 2011 at 17:39, Georg Brandl > wrote: > > The reason why rebasing is not universally applied is that the > rebased changesets are different from the original ones (therefore > I wrote A' and B')

Re: [Python-Dev] Hg: inter-branch workflow

On Sun, Mar 20, 2011 at 17:39, Georg Brandl wrote: > The reason why rebasing is not universally applied is that the > rebased changesets are different from the original ones (therefore > I wrote A' and B') -- even if the diff is the same, the parents > are not, and therefore the changeset id (has

Re: [Python-Dev] Hg: inter-branch workflow

On Sun, 20 Mar 2011 16:39:50 -, Georg Brandl wrote: > The reason why rebasing is not universally applied is that the > rebased changesets are different from the original ones (therefore > I wrote A' and B') -- even if the diff is the same, the parents > are not, and therefore the changeset id

Re: [Python-Dev] Hg: inter-branch workflow

On 20.03.2011 16:39, Georg Brandl wrote: > The reason why rebasing is not universally applied is that the > rebased changesets are different from the original ones (therefore > I wrote A' and B') -- even if the diff is the same, the parents > are not, and therefore the changeset id (hash) changes.

Re: [Python-Dev] Hg: inter-branch workflow

On 20.03.2011 16:21, Guido van Rossum wrote: > What is "rebase"? Why does everyone want it and hate it at the same time? Basically, rebase is a way to avoid having pointless merge commits on the same branch. Let's say you have the following history in your local repository: ... --- X --- A --- B

Re: [Python-Dev] Hg: inter-branch workflow

What is "rebase"? Why does everyone want it and hate it at the same time? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.or

Re: [Python-Dev] Hg: inter-branch workflow

Le dimanche 20 mars 2011 à 11:52 -0400, R. David Murray a écrit : > On Sun, 20 Mar 2011 00:06:01 -0400, "R. David Murray" > wrote: > > It would have been nice if rebase had refused to run given that > > there were merges, since it clearly doesn't work in that case. > > To clarify, that should ha

  1   2   >