From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: VC mode and git Date: Thu, 26 Mar 2015 18:27:25 +0200 Message-ID: <83a8yzohaq.fsf@gnu.org> References: <86egoeusg2.fsf@example.com> <83pp7yp5po.fsf@gnu.org> <5511BB2A.2070909@dancol.org> <83oanip42b.fsf@gnu.org> <874mp9nc2k.fsf@uwakimon.sk.tsukuba.ac.jp> <83h9t9pwos.fsf@gnu.org> <877fu5o838.fsf@zigzag.favinet> <83d23xouls.fsf@gnu.org> <87y4mkn1zd.fsf@zigzag.favinet> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1427387286 30802 80.91.229.3 (26 Mar 2015 16:28:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Mar 2015 16:28:06 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 26 17:27:56 2015 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 1YbAdB-0002z5-EP for ged-emacs-devel@m.gmane.org; Thu, 26 Mar 2015 17:27:41 +0100 Original-Received: from localhost ([::1]:45461 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbAdA-0007zJ-Mz for ged-emacs-devel@m.gmane.org; Thu, 26 Mar 2015 12:27:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39456) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbAd6-0007z8-Ve for emacs-devel@gnu.org; Thu, 26 Mar 2015 12:27:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YbAd1-000531-T5 for emacs-devel@gnu.org; Thu, 26 Mar 2015 12:27:36 -0400 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:58806) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbAd1-00052H-Fw for emacs-devel@gnu.org; Thu, 26 Mar 2015 12:27:31 -0400 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NLT00N00V16C600@mtaout26.012.net.il> for emacs-devel@gnu.org; Thu, 26 Mar 2015 18:28:29 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NLT00M85V3HCJ10@mtaout26.012.net.il> for emacs-devel@gnu.org; Thu, 26 Mar 2015 18:28:29 +0200 (IST) In-reply-to: <87y4mkn1zd.fsf@zigzag.favinet> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.182 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:184334 Archived-At: > From: Thien-Thi Nguyen > Date: Wed, 25 Mar 2015 23:31:18 +0100 > > The relevant question is: would this be useful in enough use > cases to justify the feature, at least as an option? > > I think the time when people would respect VC imposing its > unified model on the underlying VCS is past. I'm not talking about imposing some model, I'm talking about recognizing useful and frequent patterns, and then codifying those in "C-x v v". See below for the patterns I can easily identify. Besides, if someone feels "C-x v v" is not for them, they can just refrain from using it. That command certainly isn't imposing itself on users, does it? > When they were all centralized, such an imposition lifted the burden > of having to remember fiddly details such as command-line options. That's not my understanding of the "C-x v v" usefulness. IMO, it has very little to do with "centralized". It had much more to do with the fact that there is a particular order/pattern of VC commands one needs to perform while working on changes. Look at the doc string of vc-next-action, and you will see that pattern clearly identified for RCS. A dVCS, IMO, makes this single-pattern approach too limited, because a dVCS enables many more workflows that were unavailable with RCS and its ilk. But that doesn't mean there are no patterns at all, or that the patterns are limited to what vc-next-action currently supports for a dVCS. Again, if you read the doc string for "merging-based version control systems", whatever that means, you will, I think, agree that vc-next-action is next to useless for a modern dVCS, because it basically always commits and does nothing else. > But the schism between centralized and distributed is here, and here > to stay, and so a unified model spanning these models now is an > impediment to fully exploiting the tools. The lack of a _single_ pattern doesn't mean there are no patterns at all. Here's what I do all the time in Emacs maintenance, when I need to make a change that is a single one-off job I expect to take an hour or so: . git pull # make changes, build, fix errors, test, fix bugs, write logs . git pull . if new files added: . git add NEW-FILES... . git status -s . git commit -a . git show . if I found some deficiency in the commit, looking at "git show" display: . git reset HEAD^ # fix whatever needs fixing . git commit -a . git show # verify all is OK now . git push . if push rejected: . git pull . if conflicts found: . fix conflicts . git commit -a . git show . git push I see a clear, non-trivial pattern here that is useful enough to have vc-next-action remember it for me. I also am quite sure I'm not the only one who uses this pattern, perhaps with minor deviations. There are other useful patterns, e.g., when I work on a larger feature on a separate branch. As long as I just make changes and commit them, the pattern is # make changes, build, fix errors, test . if new files added: . git add NEW-FILES... . git status -s . git commit -a Once I want to land the feature on a public branch, there's another pattern, something like . git checkout master . git pull . git merge FEATURE . if there are conflicts: # resolve conflicts . git add FILES-THAT-CHANGED . git status -s . git commit . git show . git push Etc. etc. -- the only difference is that there are several widely used patterns instead of just one. Why can't vc-next-action support these patterns? If it needs to be told which pattern to use, that can be solved by a simple command that is unlikely to be needed too frequently, and so is not an annoyance. > It's a lose/lose situation when DWIM must straddle disparate M based > on disparate models. I don't see where this could lose, and so I don't share your pessimism. Having such patterns is certainly a win for people who don't commit/push changes frequently enough to have the patterns burnt into their finger memory, because even the simplest patterns are much more complex with a dVCS than they were with RCS, see above. And I didn't even start talking about a plight of someone who needs to use more than one VCS. Contemporary projects use Git, SVN, and Mercurial, so remembering the subtly different semantics of their commands is a burden, especially if you use some of them rarely. That's where vc-next-action could shine. > That said, within any particular camp (cent or dist), some > unification is still possible (and desirable). But the thrust > should be away from DWIM and towards clean primitives exposed > directly to the user. Centralized camp is already happy. > Distributed is only one lacuna away from happiness (IMHO). I see no "centralized vs distributed" schism here. What I see is the need to generalize DWIM in a useful way for the modern VCSes. Having several DWIM patterns switchable by user commands seems to be one such useful generalization. Maybe we could even do better by having VC intuit the pertinent pattern(s) for at least some cases and suggest them, or default to them unless told otherwise. IOW, vc-next-action, IMO, is about making complex, but routine tasks easier on users, by serving as a substitute for their (absent) finger memory. I think having this would be a Good Thing, and is certainly not impossible. Patches are welcome, as always.