Am 2/9/2011 18:26, schrieb Thiago Macieira:
> On Wednesday, 9 de February de 2011 14:35:34 Johannes Sixt wrote:
>> Take your example above. Name the '*' in the upper line between A and B z1
>> to z9, and in the lower line y1 to y5. When you know A is good and B is
>> bad, you only have to list the
Ian Monroe wrote:
> I've only done a basic look over on each repo (looked at branches,
> made sure each only had one parentless commit), plan on doing more
> tonight. But really it helps to know the history of the code to know
> if everything looks right. Also if folks could do build tests that
>
On Wednesday, February 09, 2011 18:28:16 John Tapsell wrote:
> 2011/2/9 Michael Pyne :
> > On Wednesday, February 09, 2011 02:16:44 John Tapsell wrote:
> >> Why does that require you to have a separate branch locally? Just
> >> don't push upstream until you're ready. Or only push to your clone.
>
2011/2/9 Michael Pyne :
> On Wednesday, February 09, 2011 02:16:44 John Tapsell wrote:
>> Why does that require you to have a separate branch locally? Just
>> don't push upstream until you're ready. Or only push to your clone.
>
> Having other people use the software greatly helps testing (just a
On Wednesday, February 09, 2011 02:16:44 John Tapsell wrote:
> Why does that require you to have a separate branch locally? Just
> don't push upstream until you're ready. Or only push to your clone.
Just because I think it's ready doesn't mean it's ready.
In this case I've been fairly successfu
In <201102091131.p19bvic4023...@mgw-da01.nokia.com>, Thiago Macieira wrote:
>> If I author a branch, then contributor X puts two commits on it to fix
>> compilation errors on m68k, contributor Y puts a commit on it adding the
>> doxygen documentation I forgot, and contributor Z provides a new test
Thiago Macieira wrote:
> If I choose one of the z commits to the left of X (let's say, Z), they'll
> test Good, which means I can exclude the A-Z commits from my list. If I
> choose one of the z commits to the right of X, they'll test bad and I
> should exclude from there to B. If I choose a commi
On Wednesday, 9 de February de 2011 14:35:34 Johannes Sixt wrote:
> Take your example above. Name the '*' in the upper line between A and B z1
> to z9, and in the lower line y1 to y5. When you know A is good and B is
> bad, you only have to list the commits in any linearized order, for example,
>
Am 2/9/2011 12:47, schrieb Thiago Macieira:
> good--*--A--*--*--*--*--Z--X--*--*--*--*--*---B--bad
> \ /
> *-*Y-*-*-*
>
> Suppose X marks the spot and Y and Z are innocent. In order to bisect this
> and
> find X,
Em quarta-feira, 9 de fevereiro de 2011, às 04:29:28, Boyd Stephen Smith Jr.
escreveu:
> A-*---*-B
> \ /
> *-*-*
> A = Good
> B = Bad
>
> Yes, no middle point, and if the commits were linear, then there would be
> exactly one to choose. However, there are other cases where a non-linear
> hi
Em quarta-feira, 9 de fevereiro de 2011, às 04:21:03, Boyd Stephen Smith Jr.
escreveu:
> In <20110209100027.be9157...@nargothrond.macieira.info>, Thiago Macieira
>
> wrote:
> >You don't rebase someone else's commits. You only to do that to your own.
> >
> >But that doesn't mean that the final push
merge>On 9 February 2011 07:50, Johannes Sixt wrote:
> The second drawback has to do with efficient testing, and it is much more
> serious, IMO. When you make a series of changes, you are expected to
> ensure that each individual change is self-contained and passes tests.
> I.e., after N commits,
In <20110209100027.be9157...@nargothrond.macieira.info>, Thiago Macieira
wrote:
>On Wednesday, 9 de February de 2011 03:41:32 Boyd Stephen Smith Jr. wrote:
>> Having the correct branch points, even for branches that are one or two
>> commits long, can be useful both for automated tools like git bi
In <20110209100027.be9157...@nargothrond.macieira.info>, Thiago Macieira
wrote:
>You don't rebase someone else's commits. You only to do that to your own.
>
>But that doesn't mean that the final push to the server, when the code that
>the collaboration produced is done needs to be a history mess.
On Wednesday, 9 de February de 2011 03:41:32 Boyd Stephen Smith Jr. wrote:
> Having the correct branch points, even for branches that are one or two
> commits long, can be useful both for automated tools like git bisect and for
> users that may want to use "just enough development code" for a criti
In <20110209085437.GA28152@ugly.local>, Oswald Buddenhagen wrote:
>On Wed, Feb 09, 2011 at 02:27:31AM -0600, Boyd Stephen Smith Jr. wrote:
>> I agree with your definition of a good history, but git does no favors by
>> automatically committing merges. The merge is another state and needs to
>> be
On Wed, Feb 09, 2011 at 02:27:31AM -0600, Boyd Stephen Smith Jr. wrote:
> I agree with your definition of a good history, but git does no favors by
> automatically committing merges. The merge is another state and needs to be
> tested before it is actually committed.
>
you can amend a merge like
In <4d524734.30...@viscovery.net>, Johannes Sixt wrote:
>In my book, a "nice" history is not when it is a linear string of changes,
>but rather when each commit represents a good (well tested) project state.
>If, after a rebase, you test only the tip commit, but not the N-1 other
>rebased commits,
18 matches
Mail list logo
