remove "design folder" and "repo index" functionality from main repo

[vise890]

The design directory problem seems orthogonal to the git shortcuts that are the main functionality. There are also other (perhaps better?) solution to handle binary files in git (e.g. git-annex).

[vise890]

it also requires the ~/.scmbrc file in the home dir, which for non users is just clutter.

Is this just a feature that we could remove, or are people depending on it? Could we just split out the git shortcuts stuff into its own repo / project and re-import it here?

[jeffbyrnes]

@vise890 I’d be in favor of just dropping the feature.

[vise890]

@jeffbyrnes I'd love to do that as well. But how do we do about doing these sort of things. Do we need to maintain backwards compatibility? Is there a way to figure out how many people are actually using the feature?

[jeffbyrnes]

@vise890 no way to determine who’s using the feature, short of just removing it & seeing who complains, AFAIK.

I think it’s safe to put a big notice at the top of the README, and go ahead & rip it out. Folks can either make some noise for its return, or fork this repo, if they wish to keep it.

[ghthor]

I vote rip it out. We can tag the last version that includes it and link to that from the readme.

[vise890]

OK then. Is there any other stuff se want to deprecate? Ive never used the project index stuff...

[jeffbyrnes]

I used to use it, but nowadays, just use Bash’s built-in $CDPATH, and give it all the paths that have my projects.

[vise890]

so rip it all out ? what about just ripping out the git and numbering stuff into its own thing and adding it here as a sub-module? that way we don't need to worry about angering anyone and we can just bump the submodule version from time to time here

[ghthor]

Yeah, that could work. Calling the git+numbering repo scmgust or something?

On Mon, Feb 6, 2017 at 12:46 PM, Martino Visintin notifications@github.com wrote:

so rip it all out ? what about just ripping out the git and numbering stuff into its own thing and adding it here as a sub-module? that way we don't need to worry about angering anyone and we can just bump the submodule version from time to time here

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/scmbreeze/scm_breeze/issues/220#issuecomment-277757578, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJyKo9IlTs5jZ0SduHn8yzp985yQ6Xtks5rZ1yEgaJpZM4LqHhd .

[jeffbyrnes]

Ehh, I’d argue that the git + numbering stuff are the main feature here. If somebody is automatically upgrading their clone of SCM Breeze, they’ll come here & complain, it’s true. But I’d rather that, and we politely encourage them to fork an older commit to keep it, than confuse things with another repo/project.

[vise890]

right. so i think the 3 of us agree; git+numbering is the main thing we use. The two options are:

1. strip scm_breeze down to it
2. split it out into other project

@ghthor should we ask the original author for their input?

[ndbroadbent]

Hi, i'm happy to just remove it, I don't use it any more either :)

[vise890]

ok so to recap, we're happy to remove the "design folder" and "repo index" stuff from the main repo, yes?

[jeffbyrnes]

In case it was unclear from my reaction, I’m all-in on removing the design folder & repo index features.