From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: VC mode and git Date: Tue, 24 Mar 2015 23:18:01 +0200 Message-ID: <5511D489.9010007@yandex.ru> References: <86egoeusg2.fsf@example.com> <83pp7yp5po.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1427231910 18465 80.91.229.3 (24 Mar 2015 21:18:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Mar 2015 21:18:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii , Sebastien Vauban Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 24 22:18:25 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 1YaWDQ-0002mv-4p for ged-emacs-devel@m.gmane.org; Tue, 24 Mar 2015 22:18:24 +0100 Original-Received: from localhost ([::1]:34591 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaWDO-00060s-TL for ged-emacs-devel@m.gmane.org; Tue, 24 Mar 2015 17:18:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46353) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaWDA-00060k-Ka for emacs-devel@gnu.org; Tue, 24 Mar 2015 17:18:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YaWD7-0003bp-EQ for emacs-devel@gnu.org; Tue, 24 Mar 2015 17:18:08 -0400 Original-Received: from mail-wg0-x232.google.com ([2a00:1450:400c:c00::232]:36294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaWD7-0003bS-7X; Tue, 24 Mar 2015 17:18:05 -0400 Original-Received: by wgra20 with SMTP id a20so4607443wgr.3; Tue, 24 Mar 2015 14:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=I1qWsFKwSdE6Zjo+0U3/qd8Gf+8+d/WaKxyJO63m5UU=; b=rqR/y7/4d3qQJgMyWqacNAIzkLpLCuyYNyZq6CUt9/xxzxVjnRuVCZezwdQnd2ZW2r dXnluhLFp54I/e+MTSfNDWE9eQBEGPagz7jda/0iu8Je0t5NPU2dICPgQ8hGiRH9fJg2 WJ8ld6CRmof+hvF60K86o7E7OUXxRpmkDNTw7/ilL+FD0zjnYqlg18tWZ6JxIv4lFc5k hepI5/P5o/EDPcE5JP0UWkUInyN2tIUGwJpFyWrnoBWtUCe05TfjWIlDJdkztIUxFVA6 NHDgAVSWrYqKVBTPwQkDl1bFq30KS+NT3xpmQoMYcCF7NdWEbgL6DjTr/YN/t2BluODl 3DbA== X-Received: by 10.180.208.107 with SMTP id md11mr32533281wic.10.1427231884477; Tue, 24 Mar 2015 14:18:04 -0700 (PDT) Original-Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id nb4sm636562wjc.20.2015.03.24.14.18.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2015 14:18:03 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 In-Reply-To: <83pp7yp5po.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::232 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:184183 Archived-At: On 03/24/2015 09:15 PM, Eli Zaretskii wrote: > A related question is: does "C-x v v" at all make sense with Git and > other dVCSes? If it does, what would be the DWIM cycle there? It's only slightly difference from what we have. For VCSes with a staging area (which would have to be displayed separately), the cycle would be unstaged -> staged -> commit. The details would need working out, though. Like, whether "C-x v v" would do something in a file buffer other than displaying the vc-dir buffer. > E.g., > would it make sense for "C-x v v" to push when the previous action was > commit and there are not uncommitted changes? After a prompt, maybe, like Chad suggested. But I don't know if we want to make this too easy: after all, when ChangeLogs are auto-generated, it might be better to somehow force the user to review the changes and messages before pushing. However, if the "push now?" action would support that, maybe it'll be a good combination.