On Feb 1, 2013, at 9:38 PM, John Ralls wrote:
>
> On Feb 1, 2013, at 8:57 PM, Mike Alexander wrote:
>
>> If not I get a bunch of unresolvable references on this step after which
>> none of the transfer/xxx branches exist.
> Really? That's interesting. I'm testing that avenue now.
Nope, I ge
On Feb 1, 2013, at 8:57 PM, Mike Alexander wrote:
> --On February 1, 2013 2:35:36 PM -0800 John Ralls wrote:
>
>>
>> On Feb 1, 2013, at 2:14 PM, John Ralls wrote:
>>
>>> Just a heads-up to everyone: Derek and I are migrating the Github
>>> repositories now. The old ones have been renamed to
--On February 1, 2013 2:35:36 PM -0800 John Ralls
wrote:
On Feb 1, 2013, at 2:14 PM, John Ralls wrote:
Just a heads-up to everyone: Derek and I are migrating the Github
repositories now. The old ones have been renamed to e.g.
gnucash-old, so if you want to keep using them while we work, ju
On Feb 1, 2013, at 2:14 PM, John Ralls wrote:
> Just a heads-up to everyone: Derek and I are migrating the Github
> repositories now. The old ones have been renamed to e.g. gnucash-old, so if
> you want to keep using them while we work, just go to your local repo and say
> git remote set-url
Just a heads-up to everyone: Derek and I are migrating the Github repositories
now. The old ones have been renamed to e.g. gnucash-old, so if you want to keep
using them while we work, just go to your local repo and say
git remote set-url origin git://github.com/Gnucash/gnucash-old
or gnucash-d
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:
> Our current process (using the BP and AUDIT markers) has the same
> weaknesses IMO. There is no clear indication in the commit history of
> which commits were backported. We have BP/AUDIT as a visual reminder
> that backports should happen, but no easy way to check in ret
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
Geert Janssens writes:
>>> I'll note that if John changes his server origin to the renamed github
>>> repos then we don't need to disable the push to John's server. But I
>>> agree that that list looks correct.
>> Right.
>>
>> Should we pick a date/time and announce it via "news" (on the webpage
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
13 matches
Mail list logo
