On Dec 13, 2012, at 7:00 PM, Chris Jerdonek chris.jerdo...@gmail.com wrote:
On Thu, Dec 13, 2012 at 6:48 PM, R. David Murray rdmur...@bitdance.com
wrote:
On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson tr...@snakebite.org wrote:
- Use a completely separate clone to house all the
Apologies the top-posting (damned Gmail ...).
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Possibly. A collapsed changeset is more likely to have larger hunks of
changes e.g. two changesets that each modified adjacent pieces of code get
collapsed down to a single change hunk - which would make the merge
machinery have to work harder to detect moved hunks, etc.
In practice, so long as
Raymond Hettinger writes:
Does hg's ability to make merges easier than svn depend on having
all the intermediate commits? I thought the theory was that the smaller
changesets provided extra information that made it possible to merge
two expansive groups of changes.
Tim Delaney's
Le Thu, 13 Dec 2012 21:48:23 -0500,
R. David Murray rdmur...@bitdance.com a écrit :
On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson
tr...@snakebite.org wrote:
- Use a completely separate clone to house all the
intermediate commits, then generate a diff once the final commit is
Scenario: I'm working on a change that I want to actively test on a
bunch of Snakebite hosts. Getting the change working is going to be
an iterative process -- lots of small commits trying to attack the
problem one little bit at a time.
Eventually I'll get to a point where
On 12/13/2012 05:21 PM, Trent Nelson wrote:
Thoughts?
% hg help rebase
//arry/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Fri, Dec 14, 2012 at 12:02 PM, Larry Hastings la...@hastings.org wrote:
On 12/13/2012 05:21 PM, Trent Nelson wrote:
Thoughts?
% hg help rebase
And also the histedit extension (analagous to git rebase -i).
Both Git and Hg recognise there is a difference between interim commits and
On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson tr...@snakebite.org wrote:
- Use a completely separate clone to house all the intermediate
commits, then generate a diff once the final commit is ready,
then apply that diff to the main cpython repo, then push that.
On Thu, Dec 13, 2012 at 6:48 PM, R. David Murray rdmur...@bitdance.com wrote:
On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson tr...@snakebite.org wrote:
- Use a completely separate clone to house all the intermediate
commits, then generate a diff once the final commit is
On Dec 14, 2012, at 12:36 PM, Nick Coghlan wrote:
Both Git and Hg recognise there is a difference between interim commits and
ones you want to publish and provide tools to revise a series of commits
into a simpler set for publication to an official repo.
One of the things I love about Bazaar is
In article 20121214024824.3bccc250...@webabinitio.net,
R. David Murray rdmur...@bitdance.com wrote:
On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson tr...@snakebite.org wrote:
- Use a completely separate clone to house all the intermediate
commits, then generate a diff once
R. David Murray writes:
those commits...if you don't want those intermediate commits in the
official repo, then why is a diff/patch a bad way to achieve that?
Because a decent VCS provides TOOWTDI. And sometimes there are
different degrees of intermediate, or pehaps you even want to slice,
13 matches
Mail list logo
