From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: vc.el support for staging hunks/files Date: Thu, 09 Jan 2014 12:49:18 -0500 Message-ID: References: <20140102211452.GA28685@c3po> <83d2k9xx1f.fsf@gnu.org> <87bnztgxyl.fsf_-_@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1389289759 30418 80.91.229.3 (9 Jan 2014 17:49:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jan 2014 17:49:19 +0000 (UTC) Cc: Emacs developers , Yuri Khan To: joaotavora@gmail.com (=?utf-8?B?Sm/Do28gVMOhdm9yYQ==?=) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 09 18:49:26 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 1W1JjR-0004h8-C6 for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 18:49:25 +0100 Original-Received: from localhost ([::1]:53358 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1JjQ-0006gn-UP for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 12:49:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45382) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1JjN-0006fH-3r for emacs-devel@gnu.org; Thu, 09 Jan 2014 12:49:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1JjL-0004Yt-DA for emacs-devel@gnu.org; Thu, 09 Jan 2014 12:49:21 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38840) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1JjL-0004Yp-A9 for emacs-devel@gnu.org; Thu, 09 Jan 2014 12:49:19 -0500 Original-Received: from dann by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1W1JjL-0008B2-2X; Thu, 09 Jan 2014 12:49:19 -0500 In-Reply-To: <87bnztgxyl.fsf_-_@gmail.com> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1?= =?utf-8?Q?vora=22's?= message of "Fri, 03 Jan 2014 10:29:38 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:167954 Archived-At: joaotavora@gmail.com (Jo=C3=A3o T=C3=A1vora) writes: >> On Fri, Jan 3, 2014 at 3:57 PM, Eli Zaretskii wrote: >>> I've managed to grasp all that, I've made an alias for "commit -a", >>> because that's what I almost always want. (And why isn't that the >>> default, dammit?) > > Yuri Khan writes: >> Because staging is a key concept in git and it enables a whole lot of >> useful workflows. E.g. you can work all day and half the next day on a >> feature, making small formatting changes and fix coding style >> violations on your way as you spot them, then fire up a commit tool >> and make three commits, one for trivial formatting changes, another >> for coding style fixes, and a third one with the feature you actually >> worked on. >> >> Without staging, you would have to look at the diff, back up and >> revert some changes so that the working directory looks the way you >> want for one commit, then the other, then the next one. Or you would >> hold off fixing small things until you have committed the feature, and >> risk forgetting to do them. > > +1 for git and +1 for this technique in particular. This has to be the > most useful thing that git brought to the table for me. > > I also thought git commit -a would be always what I wanted, but I was > obviously wrong. Now my favourite workflow is to prototype a change with > some initial commits, semantically independent, sometimes even > empty. Then hack away at everything at once like in pre-VCS days. Then > use git add -p (or git gui) to make many "fixup" commits that can be > squashed onto the initial ones first set using `git rebase > --interactive`. Finally, when the stage is set, `git push`. > > I admit I also had trouble with the git docs at first, but the "stage"" > metaphor couldn't be cleverer. > > My question is, since we're on emacs-devel: could vc.el support this > workflow? > > * git-add --edit seems to indicate so; > > * diff-mode apparently has diff-marker calculation logic built in; > > * magit supports it apparently and its git-rebase-mode.el could be used > independently. > IMHO there would be quite a bit of interest if such a feature was properly integrated in vc. You might want to first post the design here before doing any implementation work.. =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20