From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Glauber Alex Dias Prado Newsgroups: gmane.emacs.help Subject: Re: Make a "general" Emacs configuration Date: Fri, 13 Aug 2010 15:39:18 -0300 Message-ID: <878w4aqrvt.fsf@gmail.com> References: <4C61DA12.5080403@pobox.com> <87ocd9c6dp.fsf@gmail.com> <87y6cbya98.fsf@gmail.com> Reply-To: smade4@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 1281724272 20192 80.91.229.12 (13 Aug 2010 18:31:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 13 Aug 2010 18:31:12 +0000 (UTC) Cc: help-gnu-emacs@gnu.org, Andrea Crotti To: Tim Visher Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Aug 13 20:31:10 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 1Ojz24-0004H0-Uk for geh-help-gnu-emacs@m.gmane.org; Fri, 13 Aug 2010 20:31:09 +0200 Original-Received: from localhost ([127.0.0.1]:37773 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ojz24-0002Pu-Cn for geh-help-gnu-emacs@m.gmane.org; Fri, 13 Aug 2010 14:31:08 -0400 Original-Received: from [140.186.70.92] (port=38954 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ojz1d-0002Oc-NK for help-gnu-emacs@gnu.org; Fri, 13 Aug 2010 14:30:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ojz1c-0007TE-M3 for help-gnu-emacs@gnu.org; Fri, 13 Aug 2010 14:30:41 -0400 Original-Received: from mail-gx0-f169.google.com ([209.85.161.169]:63802) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ojz1c-0007T9-Hp for help-gnu-emacs@gnu.org; Fri, 13 Aug 2010 14:30:40 -0400 Original-Received: by gxk4 with SMTP id 4so1426464gxk.0 for ; Fri, 13 Aug 2010 11:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :face:reply-to:date:in-reply-to:message-id:user-agent:mime-version :content-type:content-transfer-encoding; bh=SMk33KmVp99qfPuweaFpJ5sJUASWxALIJ9+JSsdq2TA=; b=IYpu3Rfp5p4acZmM5qC6cuE2t8QJlaBpZM5upfI26qxjk37s4YRDdKDZmnghsnJlY1 TzGuVFC875qTKwKxTfbxn1iTp4m0e97g89GBqEYYk/arKI+V4+DX4gcbnKAjfQ5HXkbj ykrsDlsPwemfXSrP0eCDu6EEJPQMEOSJkDSIo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:face:reply-to:date:in-reply-to :message-id:user-agent:mime-version:content-type :content-transfer-encoding; b=e8btToYS6Z6b0oElTdTJ4IuIc4RhOOCoUwv0ew7DRMqIDv2Y5xpznU/5RefHM/4C8U tsd01soAjxcBflz4pcAjfxhxVeAgB4P1hx/b6HocM8uZ1NxFqOp56XUTt1xn6BQEIRqg u0UCr7XSMONWHdfsksLw0LMpNWS+sFrkd3ReI= Original-Received: by 10.100.33.14 with SMTP id g14mr2285312ang.180.1281724239865; Fri, 13 Aug 2010 11:30:39 -0700 (PDT) Original-Received: from localhost ([187.2.130.170]) by mx.google.com with ESMTPS id r7sm4640385anb.15.2010.08.13.11.30.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Aug 2010 11:30:38 -0700 (PDT) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAACVBMVEX9/Py9sZ6FcE5gCec3 AAAACXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAwAAAAMADO7oxXAAABGklEQVQoz02RPW6E MBCFx6uQwlWKJQUHSJFTUKUmUowiVylWSOtT7BEoshRUKQCt3ykz4x+wKfCnGea9eRDxUX8UjzIX qpYMDlsPE6EC0ANjBL5NwBqg7j36Fb4LAIPZAGHGG8PG4AXeeQBmfsYdvA2gBbBaLGcWtQEc/FPL tU8hx9IC1AhZTEFK8U3gFjd4BQYgtKmf2Nmm3ZQIB6+aF3VsPUAzipEIA3gMNsiLDbWk5jSgeVD3 bDMsvOEVse1FDP2ecijUoyNMKcoTJ+AyEH+r55yrmLoXQKaE+lFAU1b0tYSyTfsCqq8S0u87h9EJ hpB6Gq0vopOMKtlyF3XdUSH9TZW90d5XuzaLuOl+GNDYDtMqJpXOBzv7B2mugjLxx2cLAAAAQnRF WHRjb21tZW50AENSRUFUT1I6IGdkLWpwZWcgdjEuMCAodXNpbmcgSUpHIEpQRUcgdjYyKSwgcXVh bGl0eSA9IDEwMAowBf9PAAAAJXRFWHRjcmVhdGUtZGF0ZQAyMDA5LTA1LTI2VDA3OjM2OjUwLTAz OjAw8P7KDgAAABF0RVh0anBlZzpjb2xvcnNwYWNlADIsdVWfAAAAIHRFWHRqcGVnOnNhbXBsaW5n LWZhY3RvcgAyeDIsMXgxLDF4MUn6prQAAAAldEVYdG1vZGlmeS1kYXRlADIwMDktMDUtMjZUMDc6 MzY6NTAtMDM6MDCvT7w6AAAAAElFTkSuQmCC In-Reply-To: (Tim Visher's message of "Fri, 13 Aug 2010 09:34:22 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) 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:74622 Archived-At: Tim Visher writes: > 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 a= nd >>> 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.=20 > > 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