From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.devel Subject: Re: need help adjusting workflow to git (or vice versa) Date: Thu, 13 Nov 2014 23:18:40 -0600 Message-ID: <87h9y22wcv.fsf@trouble.defaultvalue.org> References: <87zjbvt8o3.fsf@rosalinde.fritz.box> <5464DC5F.8070607@gmx.at> <87oasaubfc.fsf@rosalinde.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1415942353 5275 80.91.229.3 (14 Nov 2014 05:19:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Nov 2014 05:19:13 +0000 (UTC) Cc: martin rudalics , emacs-devel@gnu.org To: Stephen Berman , Andreas Schwab Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 14 06:19:06 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xp9Hl-0008BV-OP for ged-emacs-devel@m.gmane.org; Fri, 14 Nov 2014 06:19:05 +0100 Original-Received: from localhost ([::1]:34943 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xp9Hl-0004hS-8P for ged-emacs-devel@m.gmane.org; Fri, 14 Nov 2014 00:19:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49369) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xp9HT-0004eS-NC for emacs-devel@gnu.org; Fri, 14 Nov 2014 00:18:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xp9HO-0002yM-84 for emacs-devel@gnu.org; Fri, 14 Nov 2014 00:18:47 -0500 Original-Received: from defaultvalue.org ([70.85.129.156]:51037) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xp9HN-0002yG-Vt for emacs-devel@gnu.org; Fri, 14 Nov 2014 00:18:42 -0500 Original-Received: from trouble.defaultvalue.org (localhost [127.0.0.1]) (Authenticated sender: rlb@defaultvalue.org) by defaultvalue.org (Postfix) with ESMTPSA id 1BCEE20072; Thu, 13 Nov 2014 23:18:41 -0600 (CST) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id B795614E18D; Thu, 13 Nov 2014 23:18:40 -0600 (CST) In-Reply-To: <87oasaubfc.fsf@rosalinde.fritz.box> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 70.85.129.156 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:177031 Archived-At: Stephen Berman writes: > I would be very surprised if either of these approaches is used by most > developers using git, because if so, I'd have expected them to be part > of the standard toolkit and well documented. So I think my workflow is > suboptimal for git. What do people who have several branches of a > single project repository and want to build from one of them without > including changes from another in the build usually do? Isn't that a > common scenario, especially for Emacs developers? What do you people do? I don't know if this will help, but personally -- with git, in most cases I only have one (or very few) clones, and I just switch branches (a *lot*). For example, if I were on say tmp/fix-foo, and I wanted to switch to work on master, but I still had local changes that I wanted to come back to later, I'd probably either use stash, or a trivial commit. For example (via stash): $ git stash 'stuff I want to deal with later' $ git checkout master ... do whatever... $ git checkout tmp/fix-foo $ git stash pop And now I'm exactly where I was (plus or minus any build detritus that differs between the two branches.). Though often it's more convenient to use an actual dummy commit since git's stash is somewhat "one dimensional". Here's the same thing via a temporary commit: $ git commit -am 'stuff I want to deal with later' $ git checkout master ... do whatever... $ git checkout tmp/fix-foo $ git reset HEAD^ # "Undoes" the top commit, putting the changes back on disk. And I'm again back where I was. Some caveats: * If you have any new files, you'll need to "git add ..." them before the "commit -am" or stash above, otherwise they'll be left out (and also be left alone in the current working directory). * If the build process isn't really solid (and even if it is), it may sometimes be helpful to run a "make clean" before you switch branches. Alternately, you can use this command if you want to *completely* clean your tree -- likely more thoroughly, and possibly more quickly than via make: $ git clean -fdx But that deletes *everything* git doesn't know about, including ignored files, so be sure that's what you want. You can see what it's going to do beforehand with the "-n" (--dry-run) option. Note too that no working directory (copy) is more special than any other, so if you have the disk space, you can always "cp -a" or rsync your working dir before you do something you're uncertain about, and move it back if things go horribly wrong (no one need ever know...unless it's a push). (Technically, if your working directory is clean, all you need is the .git subdir, but it's less complicated to save/restore the whole tree -- otherwise you may need a "get reset --hard HEAD" or similar afterward.) Some other comments that might or might not be useful... For what it's worth, I almost always work on a temporary branch. It's trivial to migrate the changes back to master (or wherever), via merge, rebase, or cherry-pick, once I decide I'm ready to push. I find gitk (--all) to be tremendously helpful as a tool to see what's going on, and to see whether or not I did what I think I did, especially when stumbling around unfamiliar bits of git. Or, if you can't (or don't want to) fire up a GUI, this may be useful: $ git log --decorate --oneline --graph And as compared to "git status", if you want briefer status output, perhaps $ git status -s $ git status -s -uno Another item in the category of "knowing what's going on" -- the fancy git prompt component that Debian (at least) provides by default, i.e.: GIT_SHOW_DIRTYSTATE=true GIT_SHOW_STASHSTATE=true PS1='...$(__git_ps1)...' Finally, I'd definitely recommend eventually learning "git rebase --interactive ..." *for local use*. I find it extremely useful. (Note: I didn't talk about magit because I'm not using it heavily yet, but it's probably useful to understand some of the command line operations regardless.) Hope this helps -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4