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 ex
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 ea
On Dec 13, 2012, at 7:00 PM, Chris Jerdonek wrote:
> On Thu, Dec 13, 2012 at 6:48 PM, R. David Murray
> wrote:
>> On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson wrote:
>>>- Use a completely separate clone to house all the intermediate
>>> commits, then generate a diff once
Le Thu, 13 Dec 2012 21:48:23 -0500,
"R. David Murray" a écrit :
> On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson
> 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
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 slic
In article <20121214024824.3bccc250...@webabinitio.net>,
"R. David Murray" wrote:
> On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson wrote:
> > - Use a completely separate clone to house all the intermediate
> > commits, then generate a diff once the final commit is ready,
> >
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 i
On Thu, Dec 13, 2012 at 6:48 PM, R. David Murray wrote:
> On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson 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
On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson 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.
> This ap
On Fri, Dec 14, 2012 at 12:02 PM, Larry Hastings 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
ones you
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:
http://mail.python.org/mailman/options/python-dev/
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 I'm
13 matches
Mail list logo
