From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Re: Git transition checklist Date: Wed, 8 Jan 2014 11:48:55 -0500 Organization: Eric Conspiracy Secret Labs Message-ID: <20140108164855.GD3877@thyrsus.com> References: <20140108135200.8ECF9380834@snark.thyrsus.com> Reply-To: esr@thyrsus.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1389199742 6977 80.91.229.3 (8 Jan 2014 16:49:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Jan 2014 16:49:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 08 17:49:09 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 1W0wJY-0003ad-Ug for ged-emacs-devel@m.gmane.org; Wed, 08 Jan 2014 17:49:09 +0100 Original-Received: from localhost ([::1]:47769 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0wJY-00075L-K4 for ged-emacs-devel@m.gmane.org; Wed, 08 Jan 2014 11:49:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0wJQ-000752-SO for emacs-devel@gnu.org; Wed, 08 Jan 2014 11:49:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0wJM-0005aF-Ov for emacs-devel@gnu.org; Wed, 08 Jan 2014 11:49:00 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:59287 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0wJM-0005a9-IH for emacs-devel@gnu.org; Wed, 08 Jan 2014 11:48:56 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 06B4A380834; Wed, 8 Jan 2014 11:48:55 -0500 (EST) Content-Disposition: inline In-Reply-To: X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 71.162.243.5 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:167749 Archived-At: Stefan Monnier : > > That's easy. Make a patch sequence from your bzr branch using sendto > > - the format is compatible with GNU patch. git checkout the branch > > name at the equivalent point in the git repo. Use GNU patch to apply. > > Fill in change comments as required. > > Sounds like a lot of manual work and it doesn't seem to preserve history > (e.g. merges that might have taken place). For a branch with a couple > commits that's probably OK, but with my 5 year-old branch it's > a non-starter, unless I misunderstand something. I don't know what to tell you. *I* may misunderstand; I don't know bzr well enough to suggest an alternative or write a procedure, and on top of everything else I need to do it is highly unlikely that I will be able to learn bzr well enough to change that. If branch transplant is to be to be automated, I think it's going to fall on you or Eli to do it. > >> 7. What about the mail messages to emacs-diffs mailing list? That > >> should be working as well, and support pushes to non-trunk > >> branches. > > That is trivial in git. Andreas can set it up in minutes. I could too, > > but I don't have write access to the repo hook files. > > Savannah has support for Git commit mails (we use them for the `elpa' > branch), but they kind of suck: > - it's "one mail per push" instead of "one mail per commit" > (I can live with that, but it has annoying consequences). > - the email's "Subject:" is useless (part of the problem is that > since there are several commits in it, you can't just take the first > line of *the* commit message, since there are several commit messages). > See http://git.savannah.gnu.org/r/emacs/elpa.git/config for the config > we currently use. So from the point of view of our transition this is a solved problem (enail notifications won't be interrupted) but there's a separate issue with that Savannah hooks needing some work. OK, so noted. > > Stefan Monnier added these: > > > > - Improve vc-git.el so that it can automatically enable smerge-mode when > > opening a conflicted file and (probably conditional on a config var) > > mark the file as "not conflicted any more" when saving with no > > remaining diff3 markers. > > This currently works in vc-bzr.el (and vc-svn.el as well, IIRC). > > > > - Improve vc-git.el with vc-git-conflicted-files so that > > vc-find-conflicted-files works for Git as well. > > > > Thierry Volpiatto pointed out that these issues are addressed now: > > No, they're not. > > > Better cross-VCS integration of smerge mode would be nice but is not a > > git-vs-bzr issue > > It is. I want my workflow to work about as well as before. I can live > with the lack of true lightweight checkouts, but manual conflict > resolution is something I do every day, so it needs to work well. I'm going to need a very detailed soecification of what you want, then. You can't assume I know what the bzr behvior looks like, either. > > 0. Before changeover, we prepare a shellscript that creates annotated > > cryptosigned tags for the historical versions. (This will require > > Stefan to create an "Emacs maintainer" GPG identity if none exists.) > [...] > > 6. Stefan applies the script to make cryptosigned historical release tags. > > I'd rather delegate those. I could do this - that is, create a maintainer identity and do all the cryptosigning. Then I could hand you the private key. You'd have to trust me not to keep a copy and use it for nefarious ends. :-) -- Eric S. Raymond