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: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message, Date: Tue, 14 Apr 2015 08:08:12 +0900 Message-ID: <878udv8w4j.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83oan2l4pk.fsf@gnu.org> <5521B811.8070603@yandex.ru> <83d23hlmia.fsf@gnu.org> <20150407165131.GA2600@acm.fritz.box> <552486A4.2020803@yandex.ru> <5525D65C.8090303@yandex.ru> <83fv89g3dl.fsf@gnu.org> <87mw2he0d7.fsf@uwakimon.sk.tsukuba.ac.jp> <20150413210654.GB6324@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1428966530 13936 80.91.229.3 (13 Apr 2015 23:08:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Apr 2015 23:08:50 +0000 (UTC) Cc: Eli Zaretskii , Dmitry Gutov , rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 14 01:08:38 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 1YhnT3-0000od-Fh for ged-emacs-devel@m.gmane.org; Tue, 14 Apr 2015 01:08:37 +0200 Original-Received: from localhost ([::1]:53691 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhnT2-0001il-P4 for ged-emacs-devel@m.gmane.org; Mon, 13 Apr 2015 19:08:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhnSz-0001ic-04 for emacs-devel@gnu.org; Mon, 13 Apr 2015 19:08:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YhnSx-0002EH-Lf for emacs-devel@gnu.org; Mon, 13 Apr 2015 19:08:32 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:53789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhnSo-00027W-1m; Mon, 13 Apr 2015 19:08:22 -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 D68F71C3870; Tue, 14 Apr 2015 08:08:12 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id AF2C6120EBE; Tue, 14 Apr 2015 08:08:12 +0900 (JST) In-Reply-To: <20150413210654.GB6324@acm.fritz.box> 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:185393 Archived-At: Alan Mackenzie writes: > Since that time, whenever I have files in the staging area ready to > commit, and do a git pull, those files end up no longer being in the > staging area. I don't understand. I did cd /tmp git clone ~/src/Twitter cd Twitter git reset --hard HEAD^ echo foo > foo git add foo I expect that if I now pull I will get an up-to-date git repo with foo ready for commit. Try it: Twitter 18:19$ git pull Updating 64cb97f..f079094 Fast-forward stream.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Twitter 18:19$ git status On branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) new file: foo Twitter 18:19$ How do I reproduce your experience? > > ...., but the problems Richard and Alan are encountering are > > soon solved by those who study a little bit, and establish some > > discipline in performing what they've learned. > > Excuse me, but that is disparagingly patronising. Nonsense. I don't know what you and Richard are doing differently, but it is a fact that millions of people have learned to use git, reasonably quickly, at the level needed to contribute to some project. I don't know why you and Richard encounter the issues you do. That doesn't mean I think you're somehow less of a developer for that. I would like to know why; if I did, I might be able to see a way to do things your way. But all I hear from you and Richard is that git requires tens of hours to learn to the level required for contributing to Emacs, which is manifestly false from my own experience and that of many many others, and that it is a "screw", which is purely pejorative. Neither contains content useful to developing an "unscrewed" workflow. > Again you're muddying the waters, insinuating that we're both stuck > in the antediluvian CVS past. You want workflows that (for Richard) involves avoiding branches and (for both) leaving some changes uncommitted for long periods while updating your workspace with new code from upstream. Those are typical of workflows developed for and adapted to CVS. "Antediluvian" is your word, not mine. Feel free to retract it, I won't mind. > > There's nothing wrong with wanting your tools to be adapted to > > you, of course, but if you want to cooperate with others, > > sometimes you need to compromise with the shared tools. > > More insinuations. Only if you make the effort to read them that way. That was not my intent, and it's in not the words you quoted. > Although I have criticised git's many shortcomings, I have never > requested or suggested that other people adapt it to my liking. In fact, Richard has done so, in particular suggesting to seek out somebody who "resents" git sufficiently to do it for him. But I did not say that in the text you quoted. > And nobody could fairly accuse me of not compromising with git. "Fair" is a matter of opinion, of course. But what anyone can observe is that you complain about the need to compromise with git, and disparage the tool itself. I think that's hardly helpful in developing a workflow.