On 26 Oct 2016, at 17:54 , Michael wrote:
> Interesting that you mention "Quilt". There is another tool -- Stacked Git --
> that is modeled after Quilt.
I don’t see the point of these additional tools on top of git?
If git provides branches, why do I need extra magic to
On 2016-10-26, at 12:25 AM, Joshua Root wrote:
> On 2016-10-25 10:03 , Michael wrote:
>>
>> On 2016-10-24, at 2:57 PM, Marko Käning wrote:
>>
>>> Hi folks,
>>>
>>> when I read only the first two paragraphs of this thread...
>>>
>>> On 24 Oct 2016,
On 2016-10-25 10:03 , Michael wrote:
On 2016-10-24, at 2:57 PM, Marko Käning wrote:
Hi folks,
when I read only the first two paragraphs of this thread...
On 24 Oct 2016, at 18:37 , Michael wrote:
So since MacPorts is moving to git, and from
> On Oct 24, 2016, at 7:03 PM, Michael wrote:
>
>> On 2016-10-24, at 2:57 PM, Marko Käning wrote:
>>
>> Well, but I think what you, Michael, are describing, is only needed
>> if you work with many patches which aren’t really committed to any
>>
On 2016-10-24, at 2:57 PM, Marko Käning wrote:
> Hi folks,
>
> when I read only the first two paragraphs of this thread...
>
> On 24 Oct 2016, at 18:37 , Michael wrote:
>> So since MacPorts is moving to git, and from what I saw in the "how to use
On Mon, Oct 24, 2016 at 11:57:51PM +0200, Marko Käning wrote:
> The only question mark I have there is:
>
> Will we ask the committers to squash their changesets or prefer to
> clutter the main repo with potentially many tiny iterations for the
> changed ports??
I think
> On Oct 24, 2016, at 5:57 PM, Marko Käning wrote:
>
> The only question mark I have there is:
>
> Will we ask the committers to squash their changesets or prefer
> to clutter the main repo with potentially many tiny iterations
> for the changed ports??
Hi folks,
when I read only the first two paragraphs of this thread...
On 24 Oct 2016, at 18:37 , Michael wrote:
> So since MacPorts is moving to git, and from what I saw in the "how to use
> git" docs you mentioned, you apparently want people to work with patchsets
>
> I think Michael is thinking:
>
> I have port 'foo' in macports and it requires a (rather large/complicated)
> patch that currently sits in files/ and has to be re-generated every time
> upstream releases a new version of 'foo'
>
> And essentially we're saying "we haven't done anything to
On Oct 24, 2016, at 1:39 PM, Clemens Lang wrote:
> On Mon, Oct 24, 2016 at 10:29:19AM -0700, Michael wrote:
>> My understanding -- and maybe this is my error here -- is that your
>> patches have to be constantly rebased onto the current version every
>> time the upstream
Hi,
On Mon, Oct 24, 2016 at 10:29:19AM -0700, Michael wrote:
> My understanding -- and maybe this is my error here -- is that your
> patches have to be constantly rebased onto the current version every
> time the upstream releases a new version.
I think our understanding of what "upstream" is in
On Oct 24, 2016, at 12:29, Michael wrote:
>
>
>> On 2016-10-24, at 10:25 AM, Clemens Lang wrote:
>>
>> Hi,
>>
>>> On Mon, Oct 24, 2016 at 09:37:37AM -0700, Michael wrote:
>>> So since MacPorts is moving to git, and from what I saw in the "how to
>>>
On 2016-10-24, at 10:25 AM, Clemens Lang wrote:
> Hi,
>
> On Mon, Oct 24, 2016 at 09:37:37AM -0700, Michael wrote:
>> So since MacPorts is moving to git, and from what I saw in the "how to
>> use git" docs you mentioned, you apparently want people to work with
>> patchsets
Hi,
On Mon, Oct 24, 2016 at 09:37:37AM -0700, Michael wrote:
> So since MacPorts is moving to git, and from what I saw in the "how to
> use git" docs you mentioned, you apparently want people to work with
> patchsets rebased onto the current head from upstream.
>
> As I was thinking about that,
So since MacPorts is moving to git, and from what I saw in the "how to use git"
docs you mentioned, you apparently want people to work with patchsets rebased
onto the current head from upstream.
As I was thinking about that, I realized that you lose your history of the
patchset in the process.
15 matches
Mail list logo