Deprecate mootools-core-specs repo (and mootools-runner repo) #2134

Closed
ibolmo opened this Issue Nov 24, 2011 · 6 comments

Comments

Projects
None yet
4 participants
@ibolmo
Member

ibolmo commented Nov 24, 2011

I think we should go ahead and remove the submodule and add the files directly. Optionally include tree (history) of information from the specs repo.

We could keep the runner as its own submodule, but we should also consider removing it as well.

What say you?

@subtleGradient

This comment has been minimized.

Show comment
Hide comment
@subtleGradient

subtleGradient Nov 24, 2011

Member

Checkout the git-subtree.sh git plugin. It makes working with sub-projects like this really easy without having to use submodules.

— Thomas Aylott - SubtleGradient - MooTools - Sencha (from iPhone)

On Nov 23, 2011, at 4:14 PM, Olmo Maldonadoreply@reply.github.com wrote:

I think we should go ahead and remove the submodule and add the files directly. Optionally include tree (history) of information from the specs repo.

We could keep the runner as its own submodule, but we should also consider removing it as well.

What say you?


Reply to this email directly or view it on GitHub:
#2134

Member

subtleGradient commented Nov 24, 2011

Checkout the git-subtree.sh git plugin. It makes working with sub-projects like this really easy without having to use submodules.

— Thomas Aylott - SubtleGradient - MooTools - Sencha (from iPhone)

On Nov 23, 2011, at 4:14 PM, Olmo Maldonadoreply@reply.github.com wrote:

I think we should go ahead and remove the submodule and add the files directly. Optionally include tree (history) of information from the specs repo.

We could keep the runner as its own submodule, but we should also consider removing it as well.

What say you?


Reply to this email directly or view it on GitHub:
#2134

@ibolmo

This comment has been minimized.

Show comment
Hide comment
@ibolmo

ibolmo Nov 24, 2011

Member

Ah nice find!

So you support flattening the folders for ease of development?

On Wed, Nov 23, 2011 at 7:14 PM, Thomas Aylott <
reply@reply.github.com

wrote:

Checkout the git-subtree.sh git plugin. It makes working with sub-projects
like this really easy without having to use submodules.

— Thomas Aylott - SubtleGradient - MooTools - Sencha (from iPhone)

On Nov 23, 2011, at 4:14 PM, Olmo Maldonadoreply@reply.github.com wrote:

I think we should go ahead and remove the submodule and add the files
directly. Optionally include tree (history) of information from the specs
repo.

We could keep the runner as its own submodule, but we should also
consider removing it as well.

What say you?


Reply to this email directly or view it on GitHub:
#2134


Reply to this email directly or view it on GitHub:
#2134 (comment)

Member

ibolmo commented Nov 24, 2011

Ah nice find!

So you support flattening the folders for ease of development?

On Wed, Nov 23, 2011 at 7:14 PM, Thomas Aylott <
reply@reply.github.com

wrote:

Checkout the git-subtree.sh git plugin. It makes working with sub-projects
like this really easy without having to use submodules.

— Thomas Aylott - SubtleGradient - MooTools - Sencha (from iPhone)

On Nov 23, 2011, at 4:14 PM, Olmo Maldonadoreply@reply.github.com wrote:

I think we should go ahead and remove the submodule and add the files
directly. Optionally include tree (history) of information from the specs
repo.

We could keep the runner as its own submodule, but we should also
consider removing it as well.

What say you?


Reply to this email directly or view it on GitHub:
#2134


Reply to this email directly or view it on GitHub:
#2134 (comment)

@fabiomcosta

This comment has been minimized.

Show comment
Hide comment
@fabiomcosta

fabiomcosta Nov 24, 2011

Member

I prefer removing the submodule and adding the specs directly to the -core repo.

Member

fabiomcosta commented Nov 24, 2011

I prefer removing the submodule and adding the specs directly to the -core repo.

@ibolmo

This comment has been minimized.

Show comment
Hide comment
@ibolmo

ibolmo Nov 24, 2011

Member

I haven't mastered git-subtree, but I think that it'll seem as if the files
are just in the repo, but for those with subtree will be able to maintain a
separate repository for others to contribute without having to work through
the mootools-core repo.

So I propose the following.

mootools-core-specs deprecated (README updated with such information), and
not a subtree.
mootools-runner should be kept as a submodule for the time being, but
now at least it'll be a submodule of the core project and not of core-specs.

2011/11/24 Fábio M. Costa <
reply@reply.github.com

I prefer removing the submodule and adding the specs directly to the -core
repo.


Reply to this email directly or view it on GitHub:
#2134 (comment)

Member

ibolmo commented Nov 24, 2011

I haven't mastered git-subtree, but I think that it'll seem as if the files
are just in the repo, but for those with subtree will be able to maintain a
separate repository for others to contribute without having to work through
the mootools-core repo.

So I propose the following.

mootools-core-specs deprecated (README updated with such information), and
not a subtree.
mootools-runner should be kept as a submodule for the time being, but
now at least it'll be a submodule of the core project and not of core-specs.

2011/11/24 Fábio M. Costa <
reply@reply.github.com

I prefer removing the submodule and adding the specs directly to the -core
repo.


Reply to this email directly or view it on GitHub:
#2134 (comment)

@ibolmo

This comment has been minimized.

Show comment
Hide comment
@ibolmo

ibolmo Nov 24, 2011

Member

Correction. git-subtree.sh is not that it'll seem as files in the repo,
but they actually are files in the repo. Except that subtree helps us
separate the history (and push that history) to and from a separate
repo.

Basically it reduces the git submodule update --init and other headaches
for those that don't understand (or care to understand git submodules).

I still think, though, that we shouldn't bother picking up a new technology
until we really need it. We will unlikely update the runner as often as we
update the specs. Therefore, we should leave the Runner as a submodule and
review the submodule situation a month or two in the future.

2011/11/24 Olmo Maldonado olmo.maldonado@gmail.com

I haven't mastered git-subtree, but I think that it'll seem as if the
files are just in the repo, but for those with subtree will be able to
maintain a separate repository for others to contribute without having to
work through the mootools-core repo.

So I propose the following.

mootools-core-specs deprecated (README updated with such information), and
not a subtree.
mootools-runner should be kept as a submodule for the time being, but
now at least it'll be a submodule of the core project and not of core-specs.

2011/11/24 Fábio M. Costa <
reply@reply.github.com

I prefer removing the submodule and adding the specs directly to the -core

repo.


Reply to this email directly or view it on GitHub:
#2134 (comment)

Member

ibolmo commented Nov 24, 2011

Correction. git-subtree.sh is not that it'll seem as files in the repo,
but they actually are files in the repo. Except that subtree helps us
separate the history (and push that history) to and from a separate
repo.

Basically it reduces the git submodule update --init and other headaches
for those that don't understand (or care to understand git submodules).

I still think, though, that we shouldn't bother picking up a new technology
until we really need it. We will unlikely update the runner as often as we
update the specs. Therefore, we should leave the Runner as a submodule and
review the submodule situation a month or two in the future.

2011/11/24 Olmo Maldonado olmo.maldonado@gmail.com

I haven't mastered git-subtree, but I think that it'll seem as if the
files are just in the repo, but for those with subtree will be able to
maintain a separate repository for others to contribute without having to
work through the mootools-core repo.

So I propose the following.

mootools-core-specs deprecated (README updated with such information), and
not a subtree.
mootools-runner should be kept as a submodule for the time being, but
now at least it'll be a submodule of the core project and not of core-specs.

2011/11/24 Fábio M. Costa <
reply@reply.github.com

I prefer removing the submodule and adding the specs directly to the -core

repo.


Reply to this email directly or view it on GitHub:
#2134 (comment)

@fabiomcosta

This comment has been minimized.

Show comment
Hide comment
@fabiomcosta

fabiomcosta Nov 24, 2011

Member

Looks good to me!

Fbio Miranda Costa
Solucione Sistemas
Engenheiro de interfaces
Twitter: fabiomiranda
http://solucione.info

2011/11/24 Olmo Maldonado <
reply@reply.github.com

Correction. git-subtree.sh is not that it'll seem as files in the repo,
but they actually are files in the repo. Except that subtree helps us
separate the history (and push that history) to and from a separate
repo.

Basically it reduces the git submodule update --init and other headaches
for those that don't understand (or care to understand git submodules).

I still think, though, that we shouldn't bother picking up a new technology
until we really need it. We will unlikely update the runner as often as we
update the specs. Therefore, we should leave the Runner as a submodule and
review the submodule situation a month or two in the future.

2011/11/24 Olmo Maldonado olmo.maldonado@gmail.com

I haven't mastered git-subtree, but I think that it'll seem as if the
files are just in the repo, but for those with subtree will be able to
maintain a separate repository for others to contribute without having to
work through the mootools-core repo.

So I propose the following.

mootools-core-specs deprecated (README updated with such information),
and
not a subtree.
mootools-runner should be kept as a submodule for the time being, but
now at least it'll be a submodule of the core project and not of
core-specs.

2011/11/24 Fbio M. Costa <
reply@reply.github.com

I prefer removing the submodule and adding the specs directly to the
-core

repo.


Reply to this email directly or view it on GitHub:

#2134 (comment)


Reply to this email directly or view it on GitHub:
#2134 (comment)

Member

fabiomcosta commented Nov 24, 2011

Looks good to me!

Fbio Miranda Costa
Solucione Sistemas
Engenheiro de interfaces
Twitter: fabiomiranda
http://solucione.info

2011/11/24 Olmo Maldonado <
reply@reply.github.com

Correction. git-subtree.sh is not that it'll seem as files in the repo,
but they actually are files in the repo. Except that subtree helps us
separate the history (and push that history) to and from a separate
repo.

Basically it reduces the git submodule update --init and other headaches
for those that don't understand (or care to understand git submodules).

I still think, though, that we shouldn't bother picking up a new technology
until we really need it. We will unlikely update the runner as often as we
update the specs. Therefore, we should leave the Runner as a submodule and
review the submodule situation a month or two in the future.

2011/11/24 Olmo Maldonado olmo.maldonado@gmail.com

I haven't mastered git-subtree, but I think that it'll seem as if the
files are just in the repo, but for those with subtree will be able to
maintain a separate repository for others to contribute without having to
work through the mootools-core repo.

So I propose the following.

mootools-core-specs deprecated (README updated with such information),
and
not a subtree.
mootools-runner should be kept as a submodule for the time being, but
now at least it'll be a submodule of the core project and not of
core-specs.

2011/11/24 Fbio M. Costa <
reply@reply.github.com

I prefer removing the submodule and adding the specs directly to the
-core

repo.


Reply to this email directly or view it on GitHub:

#2134 (comment)


Reply to this email directly or view it on GitHub:
#2134 (comment)

@arian arian closed this in f80ca20 Nov 29, 2011

@ibolmo ibolmo closed this in 27a2d5d Nov 29, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment