From: Glauber Alex Dias Prado <smade4@gmail.com>
To: Tim Visher <tim.visher@gmail.com>
Cc: help-gnu-emacs@gnu.org, Andrea Crotti <andrea.crotti.0@gmail.com>
Subject: Re: Make a "general" Emacs configuration
Date: Fri, 13 Aug 2010 15:39:18 -0300 [thread overview]
Message-ID: <878w4aqrvt.fsf@gmail.com> (raw)
In-Reply-To: <AANLkTi=kQ0shMcA5qfXBWci9j=3G_Qr3p8wusnpqAB5o@mail.gmail.com> (Tim Visher's message of "Fri, 13 Aug 2010 09:34:22 -0400")
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
next prev parent reply other threads:[~2010-08-13 18:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-10 14:31 Make a "general" Emacs configuration Andrea Crotti
2010-08-10 16:53 ` Joel James Adamson
2010-08-10 17:26 ` Andrea Crotti
2010-08-10 18:50 ` Gabriele Lanaro
2010-08-10 19:13 ` Andrea Crotti
2010-08-10 23:00 ` Bernardo
2010-08-11 8:52 ` Andrea Crotti
2010-08-11 14:45 ` Tim Visher
2010-08-11 15:09 ` Andrea Crotti
2010-08-11 19:10 ` Glauber Alex Dias Prado
2010-08-12 8:39 ` Andrea Crotti
2010-08-12 13:57 ` Andrea Crotti
2010-08-12 16:33 ` Tim Visher
2010-08-12 18:08 ` Glauber Alex Dias Prado
2010-08-13 13:34 ` Tim Visher
2010-08-13 18:39 ` Glauber Alex Dias Prado [this message]
2010-08-13 8:55 ` Andrea Crotti
[not found] <mailman.1.1281450695.30969.help-gnu-emacs@gnu.org>
2010-08-10 16:11 ` Pascal J. Bourguignon
2010-08-10 16:53 ` rustom
2010-08-10 17:23 ` Pascal J. Bourguignon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878w4aqrvt.fsf@gmail.com \
--to=smade4@gmail.com \
--cc=andrea.crotti.0@gmail.com \
--cc=help-gnu-emacs@gnu.org \
--cc=tim.visher@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.