From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master c6f03ed: Fix a problem in url.el without GnuTLS Date: Thu, 18 Dec 2014 17:39:22 +0200 Message-ID: <83fvcdufv9.fsf@gnu.org> References: <20141211155740.11916.1584@vcs.savannah.gnu.org> <87ppbquo97.fsf@gmail.com> <83zjaurreb.fsf@gnu.org> <874mt14wrc.fsf@lifelogs.com> <83egs5rzlr.fsf@gnu.org> <877fxx2e6t.fsf@lifelogs.com> <83a92trlgs.fsf@gnu.org> <87oar81jlp.fsf@lifelogs.com> <87bnn7rkcq.fsf@engster.org> <877fxvri96.fsf@engster.org> <87zjarznzs.fsf@lifelogs.com> <87sigjpri2.fsf@engster.org> <838uib60jv.fsf@gnu.org> <87mw6rpc6l.fsf@engster.org> <83sigj48z5.fsf@gnu.org> <874mszp2i7.fsf@engster.org> <83iohe43hu.fsf@gnu.org> <87vbldoqp2.fsf@engster.org> <83a92py3p3.fsf@gnu.org> <87mw6oodep.fsf@engster.org> <83lhm7wfd4.fsf@gnu.org> <87egrynhcd.fsf@engster.org> <87wq5pd0ap.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1418917196 16608 80.91.229.3 (18 Dec 2014 15:39:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Dec 2014 15:39:56 +0000 (UTC) Cc: deng@randomsample.de, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 18 16:39:49 2014 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 1Y1dB3-00079c-Ax for ged-emacs-devel@m.gmane.org; Thu, 18 Dec 2014 16:39:45 +0100 Original-Received: from localhost ([::1]:54471 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1dB2-0008FF-Lu for ged-emacs-devel@m.gmane.org; Thu, 18 Dec 2014 10:39:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1dAt-000885-6C for emacs-devel@gnu.org; Thu, 18 Dec 2014 10:39:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1dAm-0005gT-0k for emacs-devel@gnu.org; Thu, 18 Dec 2014 10:39:35 -0500 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:46225) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1dAl-0005fy-L5 for emacs-devel@gnu.org; Thu, 18 Dec 2014 10:39:27 -0500 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NGS00800B1XXR00@mtaout29.012.net.il> for emacs-devel@gnu.org; Thu, 18 Dec 2014 17:36:53 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NGS0040GBDHSZ60@mtaout29.012.net.il>; Thu, 18 Dec 2014 17:36:53 +0200 (IST) In-reply-to: <87wq5pd0ap.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.185 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:180279 Archived-At: > From: "Stephen J. Turnbull" > Cc: Eli Zaretskii , > emacs-devel@gnu.org > Date: Thu, 18 Dec 2014 13:55:26 +0900 > > > > That'd lose too much information, so I'd like to avoid that if > > > possible. > > > > What kind of information do you mean here? I'm guessing you want to see > > the merges from master and how you reacted to them? You're right that > > this will be lost. > > I think this is the crucial question. git documents are very good at > explaining implementations, but people have a habit of deciding what > they think a command does based on its name. That matters a little > for Eli, and a lot for GitForEmacsDevs. > > We really need to see what DAG Eli wants to construct. The one that would be there if the push from master following a merge from a feature branch succeeded. I hope this is clear enough; if not, please ask more specific questions. > (where "reasonable" is defined "Eli feels comfortable with it > for the purposes he has in mind" -- we have to ask Eli :-). I don't think I've invented something unnatural here. What I'd like is to have a merge-based workflow where the DAG reflects all the merges between 2 branches as they happened in real time. Race conditions interfere with that, but I'd like to resolve that issue in a way that only affects the last merge before the final successful push from the local master to upstream. > > . You want to keep a clear history of 'mainline', meaning you want to > > achieve a similar log view to that from Bazaar, using 'git log > > --first-parent'. > > > > This conflicts with how Git orders the parents of a merge. The first > > parent is always the tip of the branch you're currently on. And since > > you do 'git pull' while being on your local master, that will be the > > first parent. > I don't see a conflict here. What I do see is an ambiguity in the > discription of entry conditions. If you bzr-think, on a feature > branch the "local master" is likely to be the feature branch.[1] That > is, the workflow is > git clone git:emacs ./feature-1 > cd feature-1 > emacs file1 ... > git commit > git pull git:emacs # we've just swapped master and > # origin/master, ie, the public mainline, > # when we push mainline is nonlinear > > without actually defining a branch. This is not how work on a branch happens (and not how it happened with bzr). There's an actual named branch, and changes are merged from there to master, before pushing them. > git clone git:emacs ./feature-1 > cd feature-1 > git checkout -b feature-1 > emacs file1 ... > git commit > git pull git:emacs # origin/master contains public mainline > # feature-1 contains local mainline > To push to public: > git checkout master > git push # public mainline is preserved > git checkout feature-1 # #### these three commands are error-prone > AFAICS this is what you need to do for emacs-24, too. What I do for emacs-24 is similar, but not identical: git clone git:emacs ./emacs-24 cd emacs-24 git checkout emacs-24 git commit git push cd ../trunk # another clone git checkout master git pull git merge origin/emacs-24 git push > The problems are (1) a convenient discipline for those last three > commands What is error-prone about them? > I think that one way to provide convenience and discipline would be > to (a) require that the feature branch workspace be located in a > directory with the same name as the feature branch, and (b) provide > git-pull-emacs and git-push-emacs scripts that check for $(basename > $cwd) == feature-name as a precondition. Sounds complicated, and I'm not sure it's really needed. Local feature branches (unlike emacs-24) don't need to be in a separate directory, because they usually don't diverge from master enough to justify that. What remains is the requirement to be aware of the currently checked-out branch, something that is quite easy both at the shell prompt (where Git instructs Bash to show the branch) and in Emacs. A significant disadvantage of this proposal, at least for me, is that it defines a set of commands and some details of the workflow that are specific to Emacs and not available and/or unneeded in any other project that uses Git. So it gets in the way of a more efficient learning to use Git by combining the experience from other projects. > > One could implement a git hook that checks for a linear git history > > of mainline and that rejects pushes otherwise, but I guess Stefan > > isn't very inclined to agree to that. > > My impression is that Stefan is not inclined to encourage work on this > problem; he thinks it's a waste of time. I think he'd come around > quickly if presented with either another problem that would be solved > by the same workflow that preserves linear mainline, or a > "sufficiently convenient" workflow that preserves linear mainline. But there doesn't appear to be such a sufficiently convenient workflow, not with Git. > [1] I think Eli means that in his feature branch workspace he uses a > branch named for the feature rather than master Of course!