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