From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Stash Date: Wed, 08 Apr 2015 05:12:32 +0900 Message-ID: <877ftng0jz.fsf@uwakimon.sk.tsukuba.ac.jp> References: <86sice77h0.fsf@dod.no> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1428437948 14769 80.91.229.3 (7 Apr 2015 20:19:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Apr 2015 20:19:08 +0000 (UTC) Cc: Steinar Bang , emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 07 22:18:59 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 1YfZxb-0004DN-E9 for ged-emacs-devel@m.gmane.org; Tue, 07 Apr 2015 22:18:59 +0200 Original-Received: from localhost ([::1]:48739 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfZxa-0005vK-JR for ged-emacs-devel@m.gmane.org; Tue, 07 Apr 2015 16:18:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfZrU-0004Sz-9o for emacs-devel@gnu.org; Tue, 07 Apr 2015 16:12:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YfZrP-0000Z0-7g for emacs-devel@gnu.org; Tue, 07 Apr 2015 16:12:40 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:39606) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfZrO-0000YP-Tp; Tue, 07 Apr 2015 16:12:35 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id CD6601C3875; Wed, 8 Apr 2015 05:12:32 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id AD1FD120EC9; Wed, 8 Apr 2015 05:12:32 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:185110 Archived-At: Richard Stallman writes: > I think Git ought to have an 'update' facility, for simple usage > scenarios, that would be just as easy to use as cvs update. In > more complex scenarios, it could refuse to operate. 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. 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, which would end up all jammed together in a single commit. In CVS, everybody worked on the mainline, and there was very little branching or cherrypicking, so very little annoyance, since essentially all workspaces were based on tip of trunk. However, the resolutions would not be recorded individually in the history. 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. Often they would decide differently, not knowing the history, and thus end up reverting the original resolution. So with git, the annoyance to other developers became the dominant factor because of the prevalence of multiple-branch development workflows. I think it is likely that a request for such a feature to the Git project would be immediately closed WONTFIX, but you could try. You could keep track of whether previous pulls had required conflict resolution, and refuse to update if there would be conflicts again. I suspect that this would be a horrible workflow, requiring a pile of git knowledge to reconstruct an appropriate state to commit.