From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Stash Date: Thu, 09 Apr 2015 09:16:03 -0400 Message-ID: References: <86sice77h0.fsf@dod.no> <877ftng0jz.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: rms@gnu.org NNTP-Posting-Host: plane.gmane.org Content-Type: text/plain; charset=Utf-8 X-Trace: ger.gmane.org 1428585393 16592 80.91.229.3 (9 Apr 2015 13:16:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Apr 2015 13:16:33 +0000 (UTC) Cc: sb@dod.no, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 09 15:16:26 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 1YgCJk-0008Ex-Ui for ged-emacs-devel@m.gmane.org; Thu, 09 Apr 2015 15:16:25 +0200 Original-Received: from localhost ([::1]:34551 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgCJk-000880-8T for ged-emacs-devel@m.gmane.org; Thu, 09 Apr 2015 09:16:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgCJg-000873-BU for emacs-devel@gnu.org; Thu, 09 Apr 2015 09:16:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgCJZ-0001Lm-JZ for emacs-devel@gnu.org; Thu, 09 Apr 2015 09:16:20 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42936) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgCJZ-0001Li-GD for emacs-devel@gnu.org; Thu, 09 Apr 2015 09:16:13 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1YgCJP-00089N-Pc; Thu, 09 Apr 2015 09:16:03 -0400 In-reply-to: <877ftng0jz.fsf@uwakimon.sk.tsukuba.ac.jp> (stephen@xemacs.org) 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:185201 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Lack of a facility that only merges into the workspace and pays no > attention to the revision history is a deliberate design choice. One > reason that git developers do not add such a mode is that it can and > does create future conflicts. I prefer future conflicts. Conflicts are normal, and no problem. > What can (and did) happen in CVS is > that developers who preferred to keep pending changes in their > workspaces would repeatedly cvs up and repeatedly resolve different > conflicts, I've done this. It is not a great problem. which would end up all jammed together in a single commit. The commit I ultimately make contains only my own change. All the changes from the repository, that conflicted with my change, I will have merged in. > However, the resolutions would not be recorded individually in the > history. As long as I resolve the conflicts myself, which is like unofficial rebasing, why should that be recorded anywhere? No one needs to know it. Imagine if I had written all my changes just a minute before installing them. That would not bother anyone. This sort of updating would produce the same results, so it should not bother anyone either. In git, this causes headaches for third parties who were > cherrypicking or rebasing because they had only *some* of the > conflicting changes, and had to decide for themselves how to resolve > those conflicts that had resolutions but not conflicting changes. I can't understand that, because it involves things about Git that I don't know and probably never will know. However, I am skeptical of the claim that installing a simple localized change, all at once, could cause complexities like that. If I push just one commit that changes a file, Savannah will contain zero changes from me before I push it, and one change from me after I push it. > You could keep track of whether previous pulls had required conflict > resolution, and refuse to update if there would be conflicts again. I could, but I wouldn't. I'd make it work in all cases, as CVS does. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! See stallman.org/skype.html.