Make a "general" Emacs configuration

Make a "general" Emacs configuration

[Andrea Crotti]

I feel that I have to change something in my emacs configuration, what I
would like to have is something similar to the linux kernel, where you
can disable enable things and they keep track of the dependencies.

Using many autoloads and hooks it should not be a problem of course but
I would like to make more modular.

But the first thing to do is to move out everything I don't develop.
For example all the packages that I pull from git, should not be in my
own git repository, but if I move them out then I need to download them
every time, and the version could be different.

I think that git submodule could be the way to go, BUT I would like to
keep the same version also, so I upgrade only once and I keep
consistency everywhere.

Reading now again the doc looks like it could work exactly like that
anyway, but I still have some troubles understanding the submodules...

Any example or idea is welcome...

Re: Make a "general" Emacs configuration

[Pascal J. Bourguignon]

Andrea Crotti <andrea.crotti.0@gmail.com> writes:

> I feel that I have to change something in my emacs configuration, what I
> would like to have is something similar to the linux kernel, where you
> can disable enable things and they keep track of the dependencies.
>
> Using many autoloads and hooks it should not be a problem of course but
> I would like to make more modular.
>
> But the first thing to do is to move out everything I don't develop.
> For example all the packages that I pull from git, should not be in my
> own git repository, but if I move them out then I need to download them
> every time, and the version could be different.
>
> I think that git submodule could be the way to go, BUT I would like to
> keep the same version also, so I upgrade only once and I keep
> consistency everywhere.
>
> Reading now again the doc looks like it could work exactly like that
> anyway, but I still have some troubles understanding the submodules...
>
> Any example or idea is welcome...

You could just rely on the work done by your linux distribution.  For
example, gentoo automatically updates the site-start.el file (actually
site-gentoo.el, loaded from site-start.el), when you install, update
or remove packages from the app-emacs category.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Re: Make a "general" Emacs configuration

[Joel James Adamson]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

Andrea Crotti <andrea.crotti.0@gmail.com> writes:

> Reading now again the doc looks like it could work exactly like that
> anyway, but I still have some troubles understanding the submodules...

So...what's your question?

Joel
-- 
Joel J. Adamson
Servedio Lab
University of North Carolina at Chapel Hill

FSF Member #8164
http://www.unc.edu/~adamsonj

[-- Attachment #2: Type: application/pgp-signature, Size: 229 bytes --]

Re: Make a "general" Emacs configuration

[rustom]

On Aug 10, 9:11 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Andrea Crotti <andrea.crott...@gmail.com> writes:
> > I feel that I have to change something in my emacs configuration, what I
> > would like to have is something similar to the linux kernel, where you
> > can disable enable things and they keep track of the dependencies.
>
> > Using many autoloads and hooks it should not be a problem of course but
> > I would like to make more modular.
>
> > But the first thing to do is to move out everything I don't develop.
> > For example all the packages that I pull from git, should not be in my
> > own git repository, but if I move them out then I need to download them
> > every time, and the version could be different.
>
> > I think that git submodule could be the way to go, BUT I would like to
> > keep the same version also, so I upgrade only once and I keep
> > consistency everywhere.
>
> > Reading now again the doc looks like it could work exactly like that
> > anyway, but I still have some troubles understanding the submodules...
>
> > Any example or idea is welcome...
>
> You could just rely on the work done by your linux distribution.  For
> example, gentoo automatically updates the site-start.el file (actually
> site-gentoo.el, loaded from site-start.el), when you install, update
> or remove packages from the app-emacs category.
>
> --
> __Pascal Bourguignon__                    http://www.informatimago.com/

Just wondering how much other linux-emacs-ers share this view?
My general impression (from hanging about this list) is that linux
distros nowadays screw up emacs so bad it turns out simpler and less
work to compile it from source.

But maybe its just ubuntu/debian that are screwing up...

Personally Ive been using a my-compiled linux for some time but this
causes its own issues because apt thinks I dont have emacs...

Re: Make a "general" Emacs configuration

[Pascal J. Bourguignon]

rustom <rustompmody@gmail.com> writes:

> On Aug 10, 9:11 pm, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> You could just rely on the work done by your linux distribution.  For
>> example, gentoo automatically updates the site-start.el file (actually
>> site-gentoo.el, loaded from site-start.el), when you install, update
>> or remove packages from the app-emacs category.
>
> Just wondering how much other linux-emacs-ers share this view?
> My general impression (from hanging about this list) is that linux
> distros nowadays screw up emacs so bad it turns out simpler and less
> work to compile it from source.
>
> But maybe its just ubuntu/debian that are screwing up...
>
> Personally Ive been using a my-compiled linux for some time but this
> causes its own issues because apt thinks I dont have emacs...

I'm happy with gentoo's treatment of emacs (and even of most of Common
Lisp stuff, if you don't install clc, the Common Lisp Controller).

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Re: Make a "general" Emacs configuration

[Andrea Crotti]

Joel James Adamson <adamsonj@email.unc.edu> writes:

> Andrea Crotti <andrea.crotti.0@gmail.com> writes:
>
>> Reading now again the doc looks like it could work exactly like that
>> anyway, but I still have some troubles understanding the submodules...
>
> So...what's your question?
>
> Joel

Yes sorry there were no real questions, I was just wondering if you had
some good advices in maintaing external packages using different OS.

I practiced finally with the git submodule and it looks exactly what I
wanted.
So it's very easy to upgrade packages that are already using git, and
they keep the same version that is on the server.

For the others that don't use git maybe I could
- mirror them on github updating from time to time (there are already
  many of these mirrors on github)
- add the mirrors as submodule

But like this I risk to end up having too many project, but I don't see
any other clean way to accomplish this...

Re: Make a "general" Emacs configuration

[Gabriele Lanaro]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

I haven't understood very well your question, anyway there's already a
package manager for emacs, called ELPA, http://tromey.com/elpa/install.html

A part from this I've found the best configuration/modularization work done
in the emacs-starter-kit packages
http://github.com/technomancy/emacs-starter-kit (it uses ELPA extensively).

Hope it can help a bit...


2010/8/10 Andrea Crotti <andrea.crotti.0@gmail.com>

> Joel James Adamson <adamsonj@email.unc.edu> writes:
>
> > Andrea Crotti <andrea.crotti.0@gmail.com> writes:
> >
> >> Reading now again the doc looks like it could work exactly like that
> >> anyway, but I still have some troubles understanding the submodules...
> >
> > So...what's your question?
> >
> > Joel
>
> Yes sorry there were no real questions, I was just wondering if you had
> some good advices in maintaing external packages using different OS.
>
> I practiced finally with the git submodule and it looks exactly what I
> wanted.
> So it's very easy to upgrade packages that are already using git, and
> they keep the same version that is on the server.
>
> For the others that don't use git maybe I could
> - mirror them on github updating from time to time (there are already
>  many of these mirrors on github)
> - add the mirrors as submodule
>
> But like this I risk to end up having too many project, but I don't see
> any other clean way to accomplish this...
>
>
>

[-- Attachment #2: Type: text/html, Size: 2070 bytes --]

Re: Make a "general" Emacs configuration

[Andrea Crotti]

Gabriele Lanaro <gabriele.lanaro@gmail.com> writes:

> I haven't understood very well your question, anyway there's already a
> package manager for emacs, called ELPA,
> http://tromey.com/elpa/install.html
>
> A part from this I've found the best configuration/modularization work
> done in the emacs-starter-kit packages
> http://github.com/technomancy/emacs-starter-kit (it uses ELPA
> extensively).
>
> Hope it can help a bit...
>

Sure thanks, ELPA looks very interesting, but what happens if I want to
keep the same version everywhere?
Looks like it's downloading the last one..
And how often are the packages updated?

Actually the idea of forking/mirroring what I need (also cvs for example
as seen here)
http://issaris.blogspot.com/2005/11/cvs-to-git-and-back.html

and using submodules is more intriguing and flexible.
The only pain is automatic compilation and also not keeping around all
the .git directories configure and Makefiles.

It would be also automatic to propose some changes to those modules if I
can enhance them somehow.

Moreover I think that elisp is not so good for configuration, I think
something like yaml would be more suited.

(just for a nonsense example)
--8<---------------cut here---------------start------------->8---
haskell: true
python: true
yasnippet: [haskell, python]
--8<---------------cut here---------------end--------------->8---

Re: Make a "general" Emacs configuration

[Bernardo]

Andrea Crotti said the following on 11/08/10 05:13:
> Gabriele Lanaro <gabriele.lanaro@gmail.com> writes:
> 
>> I haven't understood very well your question, anyway there's already a
>> package manager for emacs, called ELPA,
>> http://tromey.com/elpa/install.html
>>
>> A part from this I've found the best configuration/modularization work
>> done in the emacs-starter-kit packages
>> http://github.com/technomancy/emacs-starter-kit (it uses ELPA
>> extensively).
>>
>> Hope it can help a bit...
>>
> 
> Sure thanks, 

have a look at this
http://catb.org/~esr/faqs/smart-questions.html

Re: Make a "general" Emacs configuration

[Andrea Crotti]

Bernardo <bernardo.bacic@pobox.com> writes:

>
> have a look at this
> http://catb.org/~esr/faqs/smart-questions.html
Yes I knew that, but this time I didn't really have a question.

But I would like to share my thoughts with the mailing list about
something that I think is a common problem.

So I think the options are
- try to use packages.el as much as possible like the starter-kit
- fork/mirror all the needed packages and then add them as submodules

Is this all right?

Re: Make a "general" Emacs configuration

[Tim Visher]

FWIW, my config file makes extensive use of git submodules and solves
the consistent version across deploys of the configuration.  I also
use a slightly modified version of emacs-version to detect OS
settings.  However, I'm still a complete n00b when it comes to elisp
and emacs in general so my configuration is probably riddled with
awful antipatterns.

http://github.com/timvisher/.emacs/tree/master/site-lisp/

On Wed, Aug 11, 2010 at 4:52 AM, Andrea Crotti
<andrea.crotti.0@gmail.com> wrote:
> Bernardo <bernardo.bacic@pobox.com> writes:
>
>>
>> have a look at this
>> http://catb.org/~esr/faqs/smart-questions.html
> Yes I knew that, but this time I didn't really have a question.
>
> But I would like to share my thoughts with the mailing list about
> something that I think is a common problem.
>
> So I think the options are
> - try to use packages.el as much as possible like the starter-kit
> - fork/mirror all the needed packages and then add them as submodules
>
> Is this all right?
>
>
>



-- 

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ - Spend less time on e-mail

Re: Make a "general" Emacs configuration

[Andrea Crotti]

Tim Visher <tim.visher@gmail.com> writes:

> FWIW, my config file makes extensive use of git submodules and solves
> the consistent version across deploys of the configuration.  I also
> use a slightly modified version of emacs-version to detect OS
> settings.  However, I'm still a complete n00b when it comes to elisp
> and emacs in general so my configuration is probably riddled with
> awful antipatterns.
>
> http://github.com/timvisher/.emacs/tree/master/site-lisp/
>

Well I think is not too bad at all.
I didn't know about label macro btw, why not flet?

If I can suggest something I like to add directories in the first level
automatically to the load path, because normally if I put something
there I want to use it.

--8<---------------cut here---------------start------------->8---
  (defun gen-path-dirs ()
    "Add to load path all the subdirectories of first level"
    (interactive)
    (message "adding all directories in the first level to the load-path")
    (dolist (dir (directory-files conf t))
      (if (and 
           (file-directory-p dir)
           (not (file-symlink-p dir)))
          (add-to-list 'load-path dir))))
  
  (gen-path-dirs)
--8<---------------cut here---------------end--------------->8---

Re: Make a "general" Emacs configuration

[Glauber Alex Dias Prado]

also keep submodules here but i do only use emacs on linux so i can
share it with many machines and have a backup, no problems about versioning only use
latest stuff.

Andrea Crotti <andrea.crotti.0@gmail.com> writes:

> Tim Visher <tim.visher@gmail.com> writes:
>
>> FWIW, my config file makes extensive use of git submodules and solves
>> the consistent version across deploys of the configuration.  I also
>> use a slightly modified version of emacs-version to detect OS
>> settings.  However, I'm still a complete n00b when it comes to elisp
>> and emacs in general so my configuration is probably riddled with
>> awful antipatterns.
>>
>> http://github.com/timvisher/.emacs/tree/master/site-lisp/
>>
>
> Well I think is not too bad at all.
> I didn't know about label macro btw, why not flet?
>
> If I can suggest something I like to add directories in the first level
> automatically to the load path, because normally if I put something
> there I want to use it.
>
>   (defun gen-path-dirs ()
>     "Add to load path all the subdirectories of first level"
>     (interactive)
>     (message "adding all directories in the first level to the load-path")
>     (dolist (dir (directory-files conf t))
>       (if (and 
>            (file-directory-p dir)
>            (not (file-symlink-p dir)))
>           (add-to-list 'load-path dir))))
>   
>   (gen-path-dirs)

Re: Make a "general" Emacs configuration

[Andrea Crotti]

Glauber Alex Dias Prado <smade4@gmail.com> writes:

> also keep submodules here but i do only use emacs on linux so i can
> share it with many machines and have a backup, no problems about versioning only use
> latest stuff.
>

Well with git submodules is not a problem anyway, since it keeps track
of the version so everyone cloning the repo will have the same version
of submodules.

Re: Make a "general" Emacs configuration

[Andrea Crotti]

Andrea Crotti <andrea.crotti.0@gmail.com> writes:
>
> Well with git submodules is not a problem anyway, since it keeps track
> of the version so everyone cloning the repo will have the same version
> of submodules.

But I have another problem now, whenever I do something (even just
byte-compilation) inside a submodule I get this

--8<---------------cut here---------------start------------->8---
Submodule doxymacs contains untracked content
--8<---------------cut here---------------end--------------->8---

which is a bit annoying.
Then the changes are not automatically staged and you would have to
commit explicitly, but still that "dirty" flag is not nice.

Maybe is worth to mirror everything myself, so even if I want to modify
something I can also push the changes, and the maybe send the patch to
the original author.

Re: Make a "general" Emacs configuration

[Tim Visher]

On Thu, Aug 12, 2010 at 9:57 AM, Andrea Crotti
<andrea.crotti.0@gmail.com> wrote:
> Andrea Crotti <andrea.crotti.0@gmail.com> writes:
>>
>> Well with git submodules is not a problem anyway, since it keeps track
>> of the version so everyone cloning the repo will have the same version
>> of submodules.
>
> But I have another problem now, whenever I do something (even just
> byte-compilation) inside a submodule I get this
>
> --8<---------------cut here---------------start------------->8---
> Submodule doxymacs contains untracked content
> --8<---------------cut here---------------end--------------->8---
>
> which is a bit annoying.
> Then the changes are not automatically staged and you would have to
> commit explicitly, but still that "dirty" flag is not nice.

    $ cd path/to/submodule/root
    $ cat > .gitignore
    *.elc
    C-d

That should get rid of the untracked content in your submodule in the
case of byte compilation.

> Maybe is worth to mirror everything myself, so even if I want to modify
> something I can also push the changes, and the maybe send the patch to
> the original author.

If you're planning on modifying anything about the project, then the
accepted way to do this in git would be to set up your own fork of the
project to enable you to share patches and to update your own copy of
it.  Also, you'll need a commit at which to point your submodule and
if you're going to change the submodule there's no guarantee that the
original author will accept them so you'll need a central place to
keep those commits.

-- 

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ - Spend less time on e-mail

Re: Make a "general" Emacs configuration

[Glauber Alex Dias Prado]

Tim Visher <tim.visher@gmail.com> writes:

> On Thu, Aug 12, 2010 at 9:57 AM, Andrea Crotti
> <andrea.crotti.0@gmail.com> wrote:
>> Andrea Crotti <andrea.crotti.0@gmail.com> writes:
>>>
>>> Well with git submodules is not a problem anyway, since it keeps track
>>> of the version so everyone cloning the repo will have the same version
>>> of submodules.
>>
>> But I have another problem now, whenever I do something (even just
>> byte-compilation) inside a submodule I get this
>>
>> --8<---------------cut here---------------start------------->8---
>> Submodule doxymacs contains untracked content
>> --8<---------------cut here---------------end--------------->8---
>>
>> which is a bit annoying.
>> Then the changes are not automatically staged and you would have to
>> commit explicitly, but still that "dirty" flag is not nice.
>
>     $ cd path/to/submodule/root
>     $ cat > .gitignore
>     *.elc
>     C-d
>
> That should get rid of the untracked content in your submodule in the
> case of byte compilation.
>
>> Maybe is worth to mirror everything myself, so even if I want to modify
>> something I can also push the changes, and the maybe send the patch to
>> the original author.
>
> If you're planning on modifying anything about the project, then the
> accepted way to do this in git would be to set up your own fork of the
> project to enable you to share patches and to update your own copy of
> it.  Also, you'll need a commit at which to point your submodule and
> if you're going to change the submodule there's no guarantee that the
> original author will accept them so you'll need a central place to
> keep those commits.

Maybe im doing it wrong but i am branching my submodules to change
them. Would it be better to have a consumer submodule and a producer
separate repo in case i want to send a pull request? but then any change
i made will have to be accepted before i can consume it and the workflow will kind
of become anti-productive.

Re: Make a "general" Emacs configuration

[Andrea Crotti]

Tim Visher <tim.visher@gmail.com> writes:
>
>     $ cd path/to/submodule/root
>     $ cat > .gitignore
>     *.elc
>     C-d
>
> That should get rid of the untracked content in your submodule in the
> case of byte compilation.

Now I don't see them but still the submodules are marked as dirty.
Not a big deal anyway...
>
> If you're planning on modifying anything about the project, then the
> accepted way to do this in git would be to set up your own fork of the
> project to enable you to share patches and to update your own copy of
> it.  Also, you'll need a commit at which to point your submodule and
> if you're going to change the submodule there's no guarantee that the
> original author will accept them so you'll need a central place to
> keep those commits.

Yes that's the point, if I
- commit something
- can't merge because of some conflicts
- the patch not accepted

Then I'm done...
I didn't want to fork all those project but they're not so many in the
end maybe I can live with it...

It's really a pity that some projects still use CVS, why do they hate
themselves so much :D?

Re: Make a "general" Emacs configuration

[Tim Visher]

Glauber,

On Thu, Aug 12, 2010 at 2:08 PM, Glauber Alex Dias Prado
<smade4@gmail.com> wrote:
>
> Tim Visher <tim.visher@gmail.com> writes:
>
>> On Thu, Aug 12, 2010 at 9:57 AM, Andrea Crotti
>> <andrea.crotti.0@gmail.com> wrote:
>>> Andrea Crotti <andrea.crotti.0@gmail.com> writes:
>>>>
>>>> Well with git submodules is not a problem anyway, since it keeps track
>>>> of the version so everyone cloning the repo will have the same version
>>>> of submodules.
>>>
>>> But I have another problem now, whenever I do something (even just
>>> byte-compilation) inside a submodule I get this
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> Submodule doxymacs contains untracked content
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> which is a bit annoying.
>>> Then the changes are not automatically staged and you would have to
>>> commit explicitly, but still that "dirty" flag is not nice.
>>
>>     $ cd path/to/submodule/root
>>     $ cat > .gitignore
>>     *.elc
>>     C-d
>>
>> That should get rid of the untracked content in your submodule in the
>> case of byte compilation.
>>
>>> Maybe is worth to mirror everything myself, so even if I want to modify
>>> something I can also push the changes, and the maybe send the patch to
>>> the original author.
>>
>> If you're planning on modifying anything about the project, then the
>> accepted way to do this in git would be to set up your own fork of the
>> project to enable you to share patches and to update your own copy of
>> it.  Also, you'll need a commit at which to point your submodule and
>> if you're going to change the submodule there's no guarantee that the
>> original author will accept them so you'll need a central place to
>> keep those commits.
>
> Maybe im doing it wrong but i am branching my submodules to change
> them. Would it be better to have a consumer submodule and a producer
> separate repo in case i want to send a pull request? but then any change
> i made will have to be accepted before i can consume it and the workflow will kind
> of become anti-productive.

I'm not sure if I quite follow you.

1. There's no 'wrong' way to do things with git, usually.

2. If you're changing your submodules rather than simply consuming
upstream changes, then you almost certainly want your own public
repository so that you can push those changes to a central location
that you can both generate pull requests for as well as reference from
any deploys of your configuration.

That workflow would look like

a) Bare clone from the truth repo to a public location that you control.

b) `git submodule add -- public-repo-location path/to/submodule`

c) hack on the submodule

d) if you've done something worthy of being published, push it to your
public repo and send a pull request

e) head out to the superproject where `git status` will report that
your submodule is dirty. `git add path/to/submodule`, `git commit`

f) hack on...

Because your submodule is pointed at your public repo, any and
everywhere you deploy you'll be able to reference that commit. If it
happened to get adopted into the original project, great. It doesn't
affect you.

Now, all of that is quite a lot if you don't plan on hacking on the
project.  If you're just a consumer (if only, perhaps, temporarily)
then simply setting the submodule to point towards the truth repo
should be enough and every once in a while you can interogate the
truth repo to see if anything interesting has changed.  You can always
update the submodule later to point to your own public repo instead if
you start hacking on it.

Hope that helps.

-- 

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ - Spend less time on e-mail

Re: Make a "general" Emacs configuration

[Glauber Alex Dias Prado]

Tim Visher <tim.visher@gmail.com> writes:

> Glauber,
>
> On Thu, Aug 12, 2010 at 2:08 PM, Glauber Alex Dias Prado
> <smade4@gmail.com> wrote:
>>
>> Tim Visher <tim.visher@gmail.com> writes:
>>
>>> On Thu, Aug 12, 2010 at 9:57 AM, Andrea Crotti
>>> <andrea.crotti.0@gmail.com> wrote:
>>>> Andrea Crotti <andrea.crotti.0@gmail.com> writes:
>>>>>
>>>>> Well with git submodules is not a problem anyway, since it keeps track
>>>>> of the version so everyone cloning the repo will have the same version
>>>>> of submodules.
>>>>
>>>> But I have another problem now, whenever I do something (even just
>>>> byte-compilation) inside a submodule I get this
>>>>
>>>> --8<---------------cut here---------------start------------->8---
>>>> Submodule doxymacs contains untracked content
>>>> --8<---------------cut here---------------end--------------->8---
>>>>
>>>> which is a bit annoying.
>>>> Then the changes are not automatically staged and you would have to
>>>> commit explicitly, but still that "dirty" flag is not nice.
>>>
>>>     $ cd path/to/submodule/root
>>>     $ cat > .gitignore
>>>     *.elc
>>>     C-d
>>>
>>> That should get rid of the untracked content in your submodule in the
>>> case of byte compilation.
>>>
>>>> Maybe is worth to mirror everything myself, so even if I want to modify
>>>> something I can also push the changes, and the maybe send the patch to
>>>> the original author.
>>>
>>> If you're planning on modifying anything about the project, then the
>>> accepted way to do this in git would be to set up your own fork of the
>>> project to enable you to share patches and to update your own copy of
>>> it.  Also, you'll need a commit at which to point your submodule and
>>> if you're going to change the submodule there's no guarantee that the
>>> original author will accept them so you'll need a central place to
>>> keep those commits.
>>
>> Maybe im doing it wrong but i am branching my submodules to change
>> them. Would it be better to have a consumer submodule and a producer
>> separate repo in case i want to send a pull request? but then any change
>> i made will have to be accepted before i can consume it and the workflow will kind
>> of become anti-productive.
>
> I'm not sure if I quite follow you.

Its easy, i branch to change the submodules so when i update it i keep
the master clean. Most if not all my changes are minor things that are
specific to my setup, or patches sent by others that i found usefull and
upstream didnt merged it yet mostly cause its not mature. 

>
> 1. There's no 'wrong' way to do things with git, usually.
>
> 2. If you're changing your submodules rather than simply consuming
> upstream changes, then you almost certainly want your own public
> repository so that you can push those changes to a central location
> that you can both generate pull requests for as well as reference from
> any deploys of your configuration.
>

I see, this is more feasible in the case you think your hacks are worthily

>
> That workflow would look like
>
> a) Bare clone from the truth repo to a public location that you control.
>
> b) `git submodule add -- public-repo-location path/to/submodule`
>
> c) hack on the submodule
>
> d) if you've done something worthy of being published, push it to your
> public repo and send a pull request
>
> e) head out to the superproject where `git status` will report that
> your submodule is dirty. `git add path/to/submodule`, `git commit`
>
> f) hack on...
>
> Because your submodule is pointed at your public repo, any and
> everywhere you deploy you'll be able to reference that commit. If it
> happened to get adopted into the original project, great. It doesn't
> affect you.
>
> Now, all of that is quite a lot if you don't plan on hacking on the
> project.  If you're just a consumer (if only, perhaps, temporarily)
> then simply setting the submodule to point towards the truth repo
> should be enough and every once in a while you can interogate the
> truth repo to see if anything interesting has changed.  You can always
> update the submodule later to point to your own public repo instead if
> you start hacking on it.
>

this is very nice and flexible, thank you for taking the time to
explain, understanding the 'better' workflow is always nice.

> Hope that helps.

cheers,
glauber