Neil Schemenauer n...@python.ca 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
On 27 March 2011 20:15, Neil Schemenauer n...@python.ca wrote:
Guido van Rossum gu...@python.org 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
On Mon, Mar 28, 2011 at 8:13 PM, Paul Moore p.f.mo...@gmail.com 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
On 28 March 2011 11:35, Nick Coghlan ncogh...@gmail.com wrote:
On Mon, Mar 28, 2011 at 8:13 PM, Paul Moore p.f.mo...@gmail.com 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
On 28/03/2011 11:35, Nick Coghlan wrote:
On Mon, Mar 28, 2011 at 8:13 PM, Paul Moorep.f.mo...@gmail.com 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
On Mon, Mar 28, 2011 at 10:48 PM, Michael Foord
fuzzy...@voidspace.org.uk 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
On Mar 27, 2011, at 01:39 PM, Neil Schemenauer wrote:
Barry Warsaw ba...@python.org 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
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 take
On 28 March 2011 22:29, Terry Reedy tjre...@udel.edu 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
Michael Foord fuzzy...@voidspace.org.uk 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
Guido van Rossum gu...@python.org 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
Barry Warsaw ba...@python.org 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
On Tue, 22 Mar 2011 15:42:27 -0700, Glenn Linderman v+pyt...@g.nevcal.com
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
Daniel On Mon, Mar 21, 2011 at 8:02 PM, Stephen J. Turnbull
step...@xemacs.orgwrote:
... 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
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
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!]
Thanks -
In article 4d871440.2000...@timgolden.me.uk,
Tim Golden m...@timgolden.me.uk 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
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 understand
On Tue, Mar 22, 2011 at 1:20 AM, Barry Warsaw ba...@python.org 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
On 21 March 2011 16:20, Barry Warsaw ba...@python.org 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
On Mon, 21 Mar 2011 12:20:15 -0400
Barry Warsaw ba...@python.org 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
On Mar 21, 2011, at 06:07 PM, Antoine Pitrou wrote:
On Mon, 21 Mar 2011 12:20:15 -0400
Barry Warsaw ba...@python.org 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?
On Mon, 21 Mar 2011 14:29:54 -0400
Barry Warsaw ba...@python.org 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
On Sun, Mar 20, 2011 at 9:39 AM, Georg Brandl g.bra...@gmx.net 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
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 patch
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 a
On Mon, 21 Mar 2011 12:40:08 -0700
Raymond Hettinger raymond.hettin...@gmail.com 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
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 for
Barry Warsaw ba...@python.org 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
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 way.
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
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 the older
On Mar 22, 2011, at 06:57 AM, Ben Finney wrote:
Barry Warsaw ba...@python.org 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
On Mar 21, 2011, at 07:38 PM, Antoine Pitrou wrote:
On Mon, 21 Mar 2011 14:29:54 -0400
Barry Warsaw ba...@python.org 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
-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 ba...@python.org wrote:
I don't think many hg users advocate rebase, really. AFAICT the
Mercurial
On Mon, 21 Mar 2011 16:33:31 -0400
Barry Warsaw ba...@python.org 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
2011/3/21 Raymond Hettinger raymond.hettin...@gmail.com:
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
On 2011-03-22, Ben Finney ben+pyt...@benfinney.id.au 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
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 would
On Mon, 21 Mar 2011 17:25:05 -0400
Barry Warsaw ba...@python.org 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
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 to
On Mon, Mar 21, 2011 at 2:31 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 21 Mar 2011 17:25:05 -0400
Barry Warsaw ba...@python.org 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.
On Tue, Mar 22, 2011 at 7:25 AM, Barry Warsaw ba...@python.org 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
On Mon, 21 Mar 2011 22:47:19 +0100
Martin v. Löwis mar...@v.loewis.de 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
On Tue, Mar 22, 2011 at 7:51 AM, Guido van Rossum gu...@python.org 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
On Mon, Mar 21, 2011 at 3:00 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Mar 22, 2011 at 7:51 AM, Guido van Rossum gu...@python.org 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 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 -
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 complicating
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
Le dimanche 20 mars 2011 à 00:06 -0400, R. David Murray a écrit :
On Thu, 17 Mar 2011 14:33:00 +0100, wrote:
On Thu, 17 Mar 2011 09:24:26 -0400
R. David Murray rdmurray at bitdance.com wrote:
It would be great if rebase did work with share, that would make a
push race basically a
On Sun, 20 Mar 2011 12:17:25 +0100, Antoine Pitrou solip...@pitrou.net wrote:
Le dimanche 20 mars 2011 à 00:06 -0400, R. David Murray a écrit :
On Thu, 17 Mar 2011 14:33:00 +0100, wrote:
On Thu, 17 Mar 2011 09:24:26 -0400
R. David Murray rdmurray at bitdance.com wrote:
It would
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 rdmur...@bitdance.com
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,
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:
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
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.
On Sun, 20 Mar 2011 16:39:50 -, Georg Brandl g.bra...@gmx.net 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
On Sun, Mar 20, 2011 at 17:39, Georg Brandl g.bra...@gmx.net 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
On 20.03.2011 16:50, Thomas Wouters wrote:
On Sun, Mar 20, 2011 at 17:39, Georg Brandl g.bra...@gmx.net
mailto:g.bra...@gmx.net wrote:
The reason why rebasing is not universally applied is that the
rebased changesets are different from the original ones (therefore
I wrote A'
On Sun, Mar 20, 2011 at 17:59, Georg Brandl g.bra...@gmx.net wrote:
On 20.03.2011 16:50, Thomas Wouters wrote:
On Sun, Mar 20, 2011 at 17:39, Georg Brandl g.bra...@gmx.net
mailto:g.bra...@gmx.net wrote:
The reason why rebasing is not universally applied is that the
rebased
-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 rdmurray at bitdance.com wrote:
It would be great if rebase did work with share, that would make a
push
On 21 March 2011 04:32, Thomas Wouters tho...@python.org 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
Thomas Wouters writes:
On Sun, Mar 20, 2011 at 17:59, Georg Brandl g.bra...@gmx.net wrote:
On 20.03.2011 16:50, Thomas Wouters wrote:
On Sun, Mar 20, 2011 at 17:39, Georg Brandl g.bra...@gmx.net
mailto:g.bra...@gmx.net wrote:
The reason why rebasing is not universally
On Mon, Mar 21, 2011 at 2:59 AM, Georg Brandl g.bra...@gmx.net 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).
On 20.03.2011 18:32, Thomas Wouters wrote:
On Sun, Mar 20, 2011 at 17:59, Georg Brandl g.bra...@gmx.net
mailto:g.bra...@gmx.net wrote:
On 20.03.2011 16:50, Thomas Wouters wrote:
On Sun, Mar 20, 2011 at 17:39, Georg Brandl g.bra...@gmx.net
mailto:g.bra...@gmx.net
On 21 March 2011 08:16, Tim Delaney timothy.c.dela...@gmail.com 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
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
On Sat, Mar 19, 2011 at 12:22 PM, Jesus Cea j...@jcea.es wrote:
On 19/03/11 03:14, Nick Coghlan wrote:
(i.e. start moving towards more of a style of development where code
doesn't land in the main repository until it has been vetted by the
buildbots *first*).
Unfortunately, this is *not*
On Sat, Mar 19, 2011 at 9:46 PM, Stephen J. Turnbull step...@xemacs.org wrote:
To the extent the buildbots are not overloaded, this strategy will
indeed save developer time, as most changes are more or less
independent of each other (that's why automated merging works at all
well), and most of
On Thu, 17 Mar 2011 14:33:00 +0100, wrote:
On Thu, 17 Mar 2011 09:24:26 -0400
R. David Murray rdmurray at bitdance.com wrote:
It would be great if rebase did work with share, that would make a
push race basically a non-issue for me.
rebase as well as strip destroy some history,
On Thu, 17 Mar 2011 20:00:29 +0100, Jesus Cea j...@jcea.es wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/03/11 14:45, R. David Murray wrote:
Not if the cpython repo is in a fully merged stated. And if it
isn't, I will wait until it is. (The update notifications on the
IRC
On Fri, Mar 18, 2011 at 5:00 AM, Jesus Cea j...@jcea.es wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/03/11 14:45, R. David Murray wrote:
Not if the cpython repo is in a fully merged stated. And if it
isn't, I will wait until it is. (The update notifications on the
IRC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/03/11 03:14, Nick Coghlan wrote:
What may actually be better for buildbot experimentation purposes is
to allow us to request running a build-and-test cycle from branches in
*any* of the repositories hosted on hg.python.org, rather than having
On Sat, Mar 19, 2011 at 1:22 PM, Jesus Cea j...@jcea.es wrote:
This is a good suggestion. I kind of remember that when working in SVN
you could request a particular build from a particular branch. If that
was true, we should consider something similar with mercurial. I am
offline and can't
I did just poke around on the buildbot pages, but couldn't find
anything resembling the old buiild a branch form.
MvL/Antoine/Georg, any ideas?
Kelsey Hightower is already working on it. There is the buildbot 'try'
feature, but there may be other options as well.
Regards,
Martin
On Wed, Mar 16, 2011 at 10:14 PM, R. David Murray rdmur...@bitdance.comwrote:
On Thu, 17 Mar 2011 05:11:23 +0100, Jesus Cea j...@jcea.es wrote:
On 17/03/11 04:41, R. David Murray wrote:
Dealing with a null merge when someone else has committed between the
time I started the merge dance
On 3/16/2011 11:58 PM, Jesus Cea wrote:
I agree that half the changesets are merges now.
Which has basically stopped me from reviewing changes. I can't quickly
tell the real changes from the noise of merges.
___
Python-Dev mailing list
Am 17.03.2011 06:14, schrieb R. David Murray:
On Thu, 17 Mar 2011 05:11:23 +0100, Jesus Cea j...@jcea.es wrote:
On 17/03/11 04:41, R. David Murray wrote:
Dealing with a null merge when someone else has committed between the
time I started the merge dance (I always pull just before I start
Am 17.03.2011 09:57, schrieb Eric Smith:
On 3/16/2011 11:58 PM, Jesus Cea wrote:
I agree that half the changesets are merges now.
Which has basically stopped me from reviewing changes. I can't quickly
tell the real changes from the noise of merges.
Even though every merge changeset mail
On 3/17/2011 6:28 AM, Georg Brandl wrote:
Am 17.03.2011 09:57, schrieb Eric Smith:
On 3/16/2011 11:58 PM, Jesus Cea wrote:
I agree that half the changesets are merges now.
Which has basically stopped me from reviewing changes. I can't quickly
tell the real changes from the noise of merges.
On Thu, Mar 17, 2011 at 6:28 AM, Georg Brandl g.bra...@gmx.net wrote:
Am 17.03.2011 09:57, schrieb Eric Smith:
On 3/16/2011 11:58 PM, Jesus Cea wrote:
I agree that half the changesets are merges now.
Which has basically stopped me from reviewing changes. I can't quickly
tell the real changes
On Thu, Mar 17, 2011 at 6:26 AM, Georg Brandl g.bra...@gmx.net wrote:
Uh... wouldn't using the rebase extension make this much easier?
Perhaps, but I/we haven't figured out how to get rebasing to do anything useful.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/03/11 06:14, R. David Murray wrote:
The fun part comes if there are changesets. At this point there
are two options: go through each of the branches doing an up/merge/ci,
and then pull/push. Or, what I actually do:
hg log
hg strip the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/03/11 13:35, Jesus Cea wrote:
Tonight I was thinking about doing a merge inside the branch, to solve
the +1 branch. Something like transforming:
Another thing I was thinking about tonight was... dropping the +1 head
banning. Embrace it.
On Thu, Mar 17, 2011 at 07:41, Jesus Cea j...@jcea.es wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/03/11 13:35, Jesus Cea wrote:
Tonight I was thinking about doing a merge inside the branch, to solve
the +1 branch. Something like transforming:
Another thing I was thinking
On Thu, 17 Mar 2011 11:26:13 +0100, Georg Brandl g.bra...@gmx.net wrote:
Am 17.03.2011 06:14, schrieb R. David Murray:
The fun part comes if there are changesets. At this point there
are two options: go through each of the branches doing an up/merge/ci,
and then pull/push. Or, what I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/03/11 14:10, Brian Curtin wrote:
On Thu, Mar 17, 2011 at 07:41, Jesus Cea j...@jcea.es
mailto:j...@jcea.es wrote:
[..]
Each developer is responsible of merging HIS heads. If somebody
forgets, nothing wrong will happens. And no patch
On Wed, 16 Mar 2011 23:21:37 -0700, Gregory P. Smith g...@krypto.org wrote:
why do you use hg diff and patch above rather than hg export and hg import?
(not implying one is better than the other, learning here...)
We're all learning, even the ones who have used Mercurial before (which
isn't
On Thu, 17 Mar 2011 09:24:26 -0400
R. David Murray rdmur...@bitdance.com wrote:
It would be great if rebase did work with share, that would make a
push race basically a non-issue for me.
rebase as well as strip destroy some history, meaning some of your
shared clones may end up having their
On Thu, 17 Mar 2011 13:35:50 +0100, Jesus Cea j...@jcea.es wrote:
On 17/03/11 06:14, R. David Murray wrote:
Clearly, this procedure is not for everyone
Clearly not :).
So you do a hg strip and start over again.
The problem with this is that your patch will be applied on top of the
On Thu, Mar 17, 2011 at 9:33 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 17 Mar 2011 09:24:26 -0400
R. David Murray rdmur...@bitdance.com wrote:
It would be great if rebase did work with share, that would make a
push race basically a non-issue for me.
rebase as well as strip
On Thu, Mar 17, 2011 at 10:03 AM, Reid Kleckner reid.kleck...@gmail.com wrote:
98% of the time, if you don't actually have merge conflicts, applying
your change over someone else's without testing will work, so I feel
like rebasing a single commit without testing is no big deal. On the
off
On Thu, 17 Mar 2011 14:33:00 +0100, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 17 Mar 2011 09:24:26 -0400
R. David Murray rdmur...@bitdance.com wrote:
It would be great if rebase did work with share, that would make a
push race basically a non-issue for me.
rebase as well as
On Thu, 17 Mar 2011 10:03:36 -0400, Reid Kleckner reid.kleck...@gmail.com
wrote:
I don't think anyone has laid out why destroying history is considered
bad by some, so I thought I'd plug this post:
http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html
Essentially, lets
On Thu, 17 Mar 2011 10:50:24 -0400
R. David Murray rdmur...@bitdance.com wrote:
On Thu, 17 Mar 2011 14:33:00 +0100, Antoine Pitrou solip...@pitrou.net
wrote:
On Thu, 17 Mar 2011 09:24:26 -0400
R. David Murray rdmur...@bitdance.com wrote:
It would be great if rebase did work with
On Thu, 17 Mar 2011 16:00:50 +0100, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 17 Mar 2011 10:50:24 -0400
R. David Murray rdmur...@bitdance.com wrote:
On Thu, 17 Mar 2011 14:33:00 +0100, Antoine Pitrou solip...@pitrou.net
wrote:
On Thu, 17 Mar 2011 09:24:26 -0400
R. David
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/03/11 14:45, R. David Murray wrote:
Not if the cpython repo is in a fully merged stated. And if it
isn't, I will wait until it is. (The update notifications on the
IRC channel help with monitoring this.)
That is repository serialization.
I think devguide's suggested interbranch workflow introduces too much
complexity for too little payoff.
If I need to make a fix to 3.2, I can't just fix it. I would need to also
merge the changeset into 3.3 and then revert it, and then commit both. There
is not much payoff to this style. It
On Wed, Mar 16, 2011 at 7:00 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
I don't think the more complex workflow if worth it. Mercurial is very user
friendly right out of the box will simple commands. But as soon as you
require the branches to be inter-linked, you've made it
On Wed, Mar 16, 2011 at 7:00 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
I think devguide's suggested interbranch workflow introduces too much
complexity for too little payoff.
Raymond,
We had this discussion many, many times before the transition. This
*is* the way every single
On Wed, Mar 16, 2011 at 7:15 PM, Nick Coghlan ncogh...@gmail.com wrote:
be handled. We're already deviating from common Hg practices in many
errors, please at least *try* this one for a few months before
throwing up your hands in disgust.
s/errors/areas/
Cheers,
Nick.
--
Nick Coghlan |
1 - 100 of 106 matches
Mail list logo
