From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie 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 17:16:35 +0000 Message-ID: <20150414171635.GB4612@acm.fritz.box> References: <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> <878udv8w4j.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1429032698 32723 80.91.229.3 (14 Apr 2015 17:31:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Apr 2015 17:31:38 +0000 (UTC) Cc: Eli Zaretskii , Dmitry Gutov , rms@gnu.org, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 14 19:31:22 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 1Yi4gD-0002qk-9S for ged-emacs-devel@m.gmane.org; Tue, 14 Apr 2015 19:31:21 +0200 Original-Received: from localhost ([::1]:57277 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yi4gC-0001di-K8 for ged-emacs-devel@m.gmane.org; Tue, 14 Apr 2015 13:31:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yi4S3-0001TP-6B for emacs-devel@gnu.org; Tue, 14 Apr 2015 13:16:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yi4Rz-0006SV-Ts for emacs-devel@gnu.org; Tue, 14 Apr 2015 13:16:43 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:51373 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yi4Rz-0006Rz-K4 for emacs-devel@gnu.org; Tue, 14 Apr 2015 13:16:39 -0400 Original-Received: (qmail 5208 invoked by uid 3782); 14 Apr 2015 17:16:36 -0000 Original-Received: from acm.muc.de (p579E829F.dip0.t-ipconnect.de [87.158.130.159]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 14 Apr 2015 19:16:34 +0200 Original-Received: (qmail 5353 invoked by uid 1000); 14 Apr 2015 17:16:35 -0000 Content-Disposition: inline In-Reply-To: <878udv8w4j.fsf@uwakimon.sk.tsukuba.ac.jp> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.1 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:185419 Archived-At: Hello, Stephen. #On Tue, Apr 14, 2015 at 08:08:12AM +0900, Stephen J. Turnbull wrote: > 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? I don't know. But when it has happened to me, it has always been with existing files in a repository directly cloned from a remote repository. (I have no experience of other scenarios.) I can't even say whether the loss of staging of files is a bug or an intended feature. > > > ...., 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 can't speak for Richard, but for me, it might be how I learn new tools: I first flick through tutorials to get the general gist of a tool, then hit the reference documentation and build an internal mental map of it, then start using the tool, using the reference doc to sort out the problems which occur. This usually works well, but hasn't done for git. How do other people, such as yourself, learn these things? > 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. OK. To take an example, I was stuck a couple of months back having made changes in my working directory and needing to revert them (from the repository). In many (?most) VCSs this operation is called "revert". Not in git. In git, you have to use "git checkout" in a particular fashion. Supposing one doesn't know that the command is called "checkout", how does one find out? How would you find this out? In the end, I gave up and bothered people on emacs-devel instead. But if you can answer this question, it would help me a great deal next time I have a similar puzzlement. > 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, How, then, did you learn git? > and that it is a "screw", which is purely pejorative. I agree with you here. The term is offensive, probably deliberately so. > 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. Yes. I think it more likely that CVS was developed for those workflows. But why does git cope so badly with these workflows? It's supposed to be a modern flexible tool. How do you personally deal with commits that you make not because your development is at a suitable stage for a commit, but that you make because git encourages/enforces it (for example, when you want to pull)? I don't see any need for me personally to use branches. If I was constantly active in the development of several different things in Emacs I might. But then I would probably want to use several parallel repositories rather than branches within a single one. git's scheme of constant branching and branch swapping doesn't scale to built objects (such as files.o and files.elc). I actually keep two Emacs git repositories, one for master, the other for the Emacs-24 branch. I foresee that both "frivolous" commits and "frivolous" branching would create extra administrative work for me. Somehow, they would have to be dealt with, and effort would need to be made to prevent them accidentally leaking to the savannah repository. > "Antediluvian" is your word, not mine. Feel free to retract it, I > won't mind. OK, I retract it. There hasn't been a flood since the CVS times which has affected me, so it's inaccurate. [ ... ] > > 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. Well, maybe not. But remaining silent about problems isn't helpful either. -- Alan Mackenzie (Nuremberg, Germany).