unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Richard Stallman <rms@gnu.org>
To: "Stephen J. Turnbull" <stephen@xemacs.org>
Cc: sb@dod.no, emacs-devel@gnu.org
Subject: Re: Stash
Date: Thu, 09 Apr 2015 09:16:03 -0400	[thread overview]
Message-ID: <E1YgCJP-00089N-Pc@fencepost.gnu.org> (raw)
In-Reply-To: <877ftng0jz.fsf@uwakimon.sk.tsukuba.ac.jp> (stephen@xemacs.org)

[[[ 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.




  reply	other threads:[~2015-04-09 13:16 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-05 17:42 Stash Richard Stallman
2015-04-05 18:31 ` Stash Steinar Bang
2015-04-05 18:38   ` Stash Eli Zaretskii
2015-04-06  5:50   ` Stash Richard Stallman
2015-04-06  6:37     ` Stash Steinar Bang
2015-04-06  7:35     ` Stash Eli Zaretskii
2015-04-06  7:57       ` Stash Eli Zaretskii
2015-04-07 19:31       ` Stash Stephen J. Turnbull
2015-04-08  5:28         ` Stash Eli Zaretskii
2015-04-06  5:50   ` Stash Richard Stallman
2015-04-06  6:50     ` Stash Steinar Bang
2015-04-06  6:55       ` Stash Eli Zaretskii
2015-04-06 11:25         ` Stash Mathias Megyei
2015-04-06 11:30           ` Stash Eli Zaretskii
2015-04-06 11:56             ` Stash Yuri Khan
2015-04-06 12:06               ` Stash João Távora
2015-04-06 12:25                 ` Stash Eli Zaretskii
2015-04-06 12:19               ` Stash Eli Zaretskii
2015-04-06 11:59             ` Stash João Távora
2015-04-06 12:21               ` Stash Eli Zaretskii
2015-04-06 13:06                 ` Stash João Távora
2015-04-06  6:55       ` Stash Eli Zaretskii
2015-04-06 14:53       ` Stash Steinar Bang
2015-04-06 15:07         ` Stash Harald Hanche-Olsen
2015-04-06 18:48           ` Stash Steinar Bang
2015-04-06  5:51   ` Stash Richard Stallman
2015-04-06  7:29     ` Stash Eli Zaretskii
2015-04-06  7:55       ` Stash Harald Hanche-Olsen
2015-04-07 16:13       ` Stash Richard Stallman
2015-04-07 16:48         ` Stash Eli Zaretskii
2015-04-07 19:51           ` Stash Stephen J. Turnbull
2015-04-08 18:20             ` Stash Richard Stallman
2015-04-08 18:21           ` Stash Richard Stallman
2015-04-08 18:33             ` Stash Eli Zaretskii
2015-04-09 13:16               ` Stash Richard Stallman
2015-04-09 13:45                 ` Stash Eli Zaretskii
2015-04-10 10:57                   ` Stash Richard Stallman
2015-04-08 18:21           ` Stash Richard Stallman
2015-04-07 16:58         ` Stash Andreas Schwab
2015-04-08 18:21           ` Stash Richard Stallman
2015-04-09 17:07             ` Stash Andreas Schwab
2015-04-10 10:58               ` Stash Richard Stallman
2015-04-07 20:12     ` Stash Stephen J. Turnbull
2015-04-09 13:16       ` Richard Stallman [this message]
2015-04-09 16:53         ` Stash Stephen J. Turnbull
2015-04-10 10:58           ` Stash Richard Stallman
2015-04-10 11:18             ` Stash Eli Zaretskii
2015-04-10 13:52             ` Stash Stephen J. Turnbull
2015-04-05 18:40 ` Stash Paul Eggert
2015-04-05 19:25   ` Stash Harald Hanche-Olsen
2015-04-05 19:59     ` Stash Paul Eggert
2015-04-05 19:26   ` Stash Steinar Bang
2015-04-05 20:18     ` Stash Stephen J. Turnbull
2015-04-05 19:41 ` Stash Harald Hanche-Olsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1YgCJP-00089N-Pc@fencepost.gnu.org \
    --to=rms@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=sb@dod.no \
    --cc=stephen@xemacs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).