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