On 01-02-13 16:45, Derek Atkins wrote:
Geert Janssens writes:
One more note on that: E may very well end up looking nothing like D
because B-C may have been enough of a change that a different
approach is required, but it's still necessary for it to be a
multi-parent commit.
Absolutely. The
On Feb 1, 2013, at 8:20 AM, Geert Janssens wrote:
> On 01-02-13 15:54, John Ralls wrote:
> (Keeping the branch image for reference)
>> A - B - C - E - F - G - I - (trunk)
>> \ //
>> --- D --- H - (stable)
>>
>> E and I are merge branches; E has both C and D
On 01-02-13 15:54, John Ralls wrote:
(Keeping the branch image for reference)
A - B - C - E - F - G - I - (trunk)
\ //
--- D --- H - (stable)
E and I are merge branches; E has both C and D as parents and able to generate
diffs to each of them, and I has bot
Geert Janssens writes:
>> One more note on that: E may very well end up looking nothing like D
>> because B-C may have been enough of a change that a different
>> approach is required, but it's still necessary for it to be a
>> multi-parent commit.
>>
> Absolutely. The extreme case being if commi
On Feb 1, 2013, at 3:59 AM, Geert Janssens wrote:
> On 31-01-13 22:52, John Ralls wrote:
>> On Jan 31, 2013, at 1:46 PM, John Ralls wrote:
>>
>>> On Jan 31, 2013, at 1:08 PM, Buddha Buck wrote:
>>>
I believe Geert's assumption is right -- git sees D as in the history
of both F and
On 31-01-13 22:52, John Ralls wrote:
On Jan 31, 2013, at 1:46 PM, John Ralls wrote:
On Jan 31, 2013, at 1:08 PM, Buddha Buck wrote:
I believe Geert's assumption is right -- git sees D as in the history
of both F and G, and won't try to remerge the A->D changes back into
G'. This should be
On Jan 31, 2013, at 1:46 PM, John Ralls wrote:
>
> On Jan 31, 2013, at 1:08 PM, Buddha Buck wrote:
>
>> I believe Geert's assumption is right -- git sees D as in the history
>> of both F and G, and won't try to remerge the A->D changes back into
>> G'. This should be easy enough to test, jus
On Jan 31, 2013, at 1:22 PM, Yawar Amin wrote:
> Hi John,
>
> On 2013-01-31, at 14:40, John Ralls wrote:
>
>> [...]
>> This breaks down when B and C affect the same code that D does. Obviously
>> you resolve those conflicts in favor of the development branch when you
>> merge D. No problem,
On Jan 31, 2013, at 1:08 PM, Buddha Buck wrote:
> I believe Geert's assumption is right -- git sees D as in the history
> of both F and G, and won't try to remerge the A->D changes back into
> G'. This should be easy enough to test, just create a new git
> repository, and make the appropriate s
Hi John,
On 2013-01-31, at 14:40, John Ralls wrote:
> [...]
> This breaks down when B and C affect the same code that D does. Obviously you
> resolve those conflicts in favor of the development branch when you merge D.
> No problem, right? Well, you have to resolve them again for every subsequ
I believe Geert's assumption is right -- git sees D as in the history
of both F and G, and won't try to remerge the A->D changes back into
G'. This should be easy enough to test, just create a new git
repository, and make the appropriate set of edits to see if that's the
case.
The problem I can s
On 31-01-13 20:40, John Ralls wrote:
On Jan 31, 2013, at 10:22 AM, Geert Janssens wrote:
On 31-01-13 18:26, John Ralls wrote:
On Jan 31, 2013, at 8:52 AM, Yawar Amin wrote:
Hi John,
On 2013-01-31, at 11:15, John Ralls wrote:
[...]
I think that you guys have a misunderstanding about h
On Jan 31, 2013, at 10:22 AM, Geert Janssens wrote:
> On 31-01-13 18:26, John Ralls wrote:
>> On Jan 31, 2013, at 8:52 AM, Yawar Amin wrote:
>>
>>> Hi John,
>>>
>>> On 2013-01-31, at 11:15, John Ralls wrote:
>>>
> [...]
>
I think that you guys have a misunderstanding about how
We have quite a debate going on here on the development process. We have
a working process that is in my opinion influenced by svn's limitations
and I'm currently interested in what process improvements we could make
if we are no longer bound by those limitations.
At some point our development
On 31-01-13 19:04, John Ralls wrote:
On Jan 31, 2013, at 9:06 AM, Geert Janssens wrote:
On 31-01-13 17:15, John Ralls wrote:
On Jan 31, 2013, at 7:04 AM, Derek Atkins wrote:
Geert Janssens writes:
[snip]
Daggy fixing is probably not the only useful scheme though. I could
also imagine so
On 31-01-13 18:26, John Ralls wrote:
On Jan 31, 2013, at 8:52 AM, Yawar Amin wrote:
Hi John,
On 2013-01-31, at 11:15, John Ralls wrote:
[...]
I think that you guys have a misunderstanding about how merging works. Try
merging 2.4 back into trunk.
When I did just now, 4 files merged succe
16 matches
Mail list logo
