From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim Visher Newsgroups: gmane.emacs.help Subject: Re: Make a "general" Emacs configuration Date: Fri, 13 Aug 2010 09:34:22 -0400 Message-ID: References: <4C61DA12.5080403@pobox.com> <87ocd9c6dp.fsf@gmail.com> <87y6cbya98.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1281706532 22520 80.91.229.12 (13 Aug 2010 13:35:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 13 Aug 2010 13:35:32 +0000 (UTC) Cc: help-gnu-emacs@gnu.org, Andrea Crotti To: smade4@gmail.com Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Aug 13 15:35:30 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OjuPu-0000Pj-10 for geh-help-gnu-emacs@m.gmane.org; Fri, 13 Aug 2010 15:35:26 +0200 Original-Received: from localhost ([127.0.0.1]:39629 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OjuPs-0004d6-If for geh-help-gnu-emacs@m.gmane.org; Fri, 13 Aug 2010 09:35:24 -0400 Original-Received: from [140.186.70.92] (port=32819 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OjuPF-0004bl-Qf for help-gnu-emacs@gnu.org; Fri, 13 Aug 2010 09:34:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OjuPE-0001la-8q for help-gnu-emacs@gnu.org; Fri, 13 Aug 2010 09:34:45 -0400 Original-Received: from mail-vw0-f41.google.com ([209.85.212.41]:42977) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OjuPE-0001lS-3W for help-gnu-emacs@gnu.org; Fri, 13 Aug 2010 09:34:44 -0400 Original-Received: by vws16 with SMTP id 16so1366134vws.0 for ; Fri, 13 Aug 2010 06:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=2qYbXcXm9avIXJ2U2rwDrNTqlgw6p08eHhWLHeI6oW8=; b=XkuRfdGHoRqESS0SAyKRExszEQMn57GJx/IoIxyxsGMbqHsHnhMamu4/fIcVkZqqp9 7ZIcKA6mVBfNExPdexKR9ZSCwAKAzkR4CDBR2Z07YRJ1b2pnXqi7ZSTM0MPt2T3m97cM y64WAL77TUdMyrwHMpygJBkc/A0MwGEHujTV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=NvpYBPzfI1uf9zpCerJ4yfYQdoXj8LVVIVVzbIEMSctoa9GGY85zIY6aKeprEdX4t7 iSWLqiLTq7Ibx1APzMHVXp2YWCQdArJGAhxJdkDip6jsUBe/a1wFQAb3XnIPO3TlYlIO hT3xEjoVL5z4JF4exAX9vMFQ1CjGQ+mNFTlvY= Original-Received: by 10.220.96.4 with SMTP id f4mr788143vcn.267.1281706483300; Fri, 13 Aug 2010 06:34:43 -0700 (PDT) Original-Received: by 10.220.109.6 with HTTP; Fri, 13 Aug 2010 06:34:22 -0700 (PDT) In-Reply-To: <87y6cbya98.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:74604 Archived-At: Glauber, On Thu, Aug 12, 2010 at 2:08 PM, Glauber Alex Dias Prado wrote: > > Tim Visher writes: > >> On Thu, Aug 12, 2010 at 9:57 AM, Andrea Crotti >> wrote: >>> Andrea Crotti 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. >> >> =C2=A0 =C2=A0 $ cd path/to/submodule/root >> =C2=A0 =C2=A0 $ cat > .gitignore >> =C2=A0 =C2=A0 *.elc >> =C2=A0 =C2=A0 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. =C2=A0Also, you'll need a commit at which to point your submodule an= d >> 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. --=20 In Christ, Timmy V. http://blog.twonegatives.com/ http://five.sentenc.es/ - Spend less time on e-mail