Git transition checklist

Git transition checklist

[Eric S. Raymond]

This post rounds up all the issues I know about with the bzr to git
changeover and their current state.  A revised transition checklist
is included at the end.

Eli Zaretski recommended, and Stefan Monnier endorsed, the following
preparatory steps for the transition to git:

> 5. Have the procedures and the recommended workflows described on the
>    wiki, similar to what was done with bzr migration.

That is now done.  I have created two new pages on EmacsWiki,
GitForEmacsDevs and GitQuickStartForEmacsDevs. These are adapted from
the corresponding *Bzr* pages but describe git commands to perform
equivalent operations.

The only omission is that I left out the git equivalent of bzr bundle.
There is such a feature in git, but it is one of the historical
fossils in the system and rarely enough used that I wouldn't want to
rely on it not bitrotting.  Git practice has moved decisively to (a)
mailing around patch sets produced by git format-patch, and (b)
github/gitorious-style merge requests.

An interesting side effect of doing this translation, by the way, is
that I now know the exact git-command equivalents for the recommended
workflow in Bazaar.  Rather to my surprise, the git procedures are
simpler!

I'm surprised at this because Bazaar, whatever its other failings, had
a reputation as being simpler to use than git which I believed was
deserved. But, at least for the workflows described, git avoids so
much complexity and ceremony by not having the branch-vs.-repo
distinction that the gain from this swamps git's other UI
shortcomings.

> 6. Describe (and test if needed) the procedure for migrating local
>    bzr branches into git without losing history (yes, I have a
>    couple in the works), and describe that on the wiki as well.

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.

I don't think this really belongs on the wiki, as it's a one-shot
transition issue probably affecting only a few people and possibly
only you. But if you think it needs describing there, go to 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.

> 8. There's the emacs-bzr-version whose value gets copied into the bug
>    reports.  This should be replaced by the suitable git equivalent,
>    or else the bug reports (of which we have quite a few each day)
>    will not identify the version correctly.

Proof of concept (tested):

(defun emacs-repository-get-version (&optional dir)
  "Try to return as a string the version-control revision of the Emacs sources.
Value is nil if the sources do not seem to be under version
control, or if we could not determine the revision.  Note that
this reports on the current state of the sources, which may not
correspond to the running Emacs.

Optional argument DIR is a directory to use instead of `source-directory'."
  ;; This is the only function that knows what VCS the Emacs sources are under.
  (let ((here default-directory))
    (cd (or dir (setq dir source-directory))) 
    (message "Waiting for git...")
    (with-temp-buffer
      (if (zerop
           (call-process "git" nil '(t nil) nil "describe" "--tags"))
         (buffer-string)))
    (cd here)))

Replacing the function emacs-bzr-get-version with this will rectify a
design error; it callers knew the string "bzr", which they should not have -
they didn't care what the VCS was as long as they could back some 
version cookie to embed in bug reports.

This code is simpler than emacs-bzr-get-version because "git describe" is
very fast - there's no need to avoid calling it for better performance.

The change to integrate this and fix its callers is easy, five minutes'
work which I will cheerfully do immediately after the repo switchover.
No need to do it before as it really only becomes crucial to have this
working for the next point release.

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:
"You can use git-mergetool with ediff-merge for this" he said, 
and gave a recipe.

Better cross-VCS integration of smerge mode would be nice but is not a
git-vs.bzr issue - rather it's a feature request against VC which,
as VC's maintainer, I take note of and will address after the switchover.

- Release 24.4 (i.e. I'd rather not deal with the move before we
  release 24.4).

That seems completely reasonable to me.

Nobody else explicitly suggested any additional preconditions. Andreas
Schwab did, however, observe this:

>A good way to identify a git branch is to use git describe.  However it
>prefers to have an annotated (release) tag available to base on, which
>we currently don't have (bzr doesn't have the concept of annotated
>tags).

This should be fixed.  Each Emacs release should be marked with an 
annotated tag, and annotations should be retconned onto the historical
releases.  This is basic good Git practice; it helps guard against attacks
by trojaned versions of the public releases.

So, here is the revised operation sequence for the changeover.

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

1. Wait on 24.4 release and Stefan's go signal.

2. Andreas announces on the dev list that the changeover is beginning.

3. Andreas turns off bzr commit mirroring (and disables the bzr repo).

4. Andreas enters a small documentation commit recording the changeover.

5. Andreas installs a commit hook that mails notifications to the emacs-diffs
   mailing list

6. Stefan applies the script to make cryptosigned historical release tags.

7. Andreas announces on the dev list that the git repo is live for
   developer pushes.

8. I replace emacs-bzr-version with emacs-repository-get-version.

9. I mark the wiki pages on Bzr obsolete and update the Git ones.

10. I will do the work required to update /etc and /admin to reflect
    git use over the following few days.

11. (Later, lower priority.) I arrange better cross-VCS integration of smerge
    in vc.el.

That's it, I think.  Currently I see only two blockers on the process:
(a) 24.4 needs to ship, and (b) somebody needs to write the script to 
map the existing lightweight release tags to cryptosigned annotated tags. 
I'll work on that.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Our society won't be truly free until "None of the Above" is always an option.

Re: Git transition checklist

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

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

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

There's plenty of time to address this before the 24.4 release and hence
before the switch over.

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


        Stefan

Re: Git transition checklist

[Rüdiger Sonderfeld]

On Wednesday 08 January 2014 09:59:53 Stefan Monnier wrote:
> >> 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.

Git now comes with an improved post-receive-mail hook called multimail

* https://github.com/git/git/tree/master/contrib/hooks/multimail
* https://github.com/mhagger/git-multimail

It seems to create one mail per commit.

Regards
Rüdiger

Re: Git transition checklist

[Stefan Monnier]

> Git now comes with an improved post-receive-mail hook called multimail
> * https://github.com/git/git/tree/master/contrib/hooks/multimail
> * https://github.com/mhagger/git-multimail
> It seems to create one mail per commit.

Could you open a Savannah ticket to have this new scheme used for the
`elpa' branch?


        Stefan

Re: Git transition checklist

[Rüdiger Sonderfeld]

On Wednesday 08 January 2014 12:12:59 Stefan Monnier wrote:
> > Git now comes with an improved post-receive-mail hook called multimail
> > * https://github.com/git/git/tree/master/contrib/hooks/multimail
> > * https://github.com/mhagger/git-multimail
> > It seems to create one mail per commit.
> 
> Could you open a Savannah ticket to have this new scheme used for the
> `elpa' branch?

Done https://savannah.gnu.org/support/index.php?108467 (added you as CC)

Regards
Rüdiger

Improved git commit emails [was Re: Git transition checklist]

[Glenn Morris]

These are the changes I would like to see in the commit emails
(decreasing order of importance):

1) get the first line of the commit message in the subject
2) remove the guff "This is an automated email...in full, below"
3) add a list of modified files somewhere near the top
4) Mail-Followup-To: committer, emacs-devel

Even just 1) would be a big help. As it stands I have to read the entire
mail to see which files got changed. Before I just had to look at the
start of the mail.

I spent some time getting the Savannah bzr setup working (obviously
wasted effort now). I won't repeat that for Git, I hope someone else will.

Re: Improved git commit emails [was Re: Git transition checklist]

[Ted Zlatanov]

On Wed, 08 Jan 2014 13:21:04 -0500 Glenn Morris <rgm@gnu.org> wrote: 

GM> These are the changes I would like to see in the commit emails
GM> (decreasing order of importance):

GM> 1) get the first line of the commit message in the subject
GM> 2) remove the guff "This is an automated email...in full, below"
GM> 3) add a list of modified files somewhere near the top
GM> 4) Mail-Followup-To: committer, emacs-devel

GM> Even just 1) would be a big help. As it stands I have to read the entire
GM> mail to see which files got changed. Before I just had to look at the
GM> start of the mail.

GM> I spent some time getting the Savannah bzr setup working (obviously
GM> wasted effort now). I won't repeat that for Git, I hope someone else will.

I did something like this for Gnus commit e-mails (starting with an
existing Git post-receive script).  See
http://git.gnus.org/cgit/gnus.git/tree/etc/post-receive and the e-mails
themselves are at http://news.gmane.org/gmane.emacs.gnus.commits for
example.

There may be pre-canned solutions that do what you need, but I'd be
happy to assist if the Gnus post-receive script is close to what you
need.

Ted

Re: Improved git commit emails

[Glenn Morris]

Ted Zlatanov wrote:

> I did something like this for Gnus commit e-mails (starting with an
> existing Git post-receive script).  See
> http://git.gnus.org/cgit/gnus.git/tree/etc/post-receive and the e-mails
> themselves are at http://news.gmane.org/gmane.emacs.gnus.commits for
> example.

At first glance, the results look pretty good to me. Certainly much
better than the current elpa setup.

I have no idea how it would integrate with the other solution that just
appeared out of thin air and is already the subject of a Savannah
support request (maybe someone should have tested that before bothering
Savannah?).

Anyway, I'm going to invest zero effort in this, just bitch and
complain, like a bunch of people did about bzr. :)

Re: Improved git commit emails

[Ted Zlatanov]

On Wed, 08 Jan 2014 13:37:49 -0500 Glenn Morris <rgm@gnu.org> wrote: 

GM> Ted Zlatanov wrote:
>> I did something like this for Gnus commit e-mails (starting with an
>> existing Git post-receive script).  See
>> http://git.gnus.org/cgit/gnus.git/tree/etc/post-receive and the e-mails
>> themselves are at http://news.gmane.org/gmane.emacs.gnus.commits for
>> example.

GM> At first glance, the results look pretty good to me. Certainly much
GM> better than the current elpa setup.

Yup.  It's basically what the Gnus developers wanted so it's probably
close to what you'd like :)

GM> I have no idea how it would integrate with the other solution that just
GM> appeared out of thin air and is already the subject of a Savannah
GM> support request (maybe someone should have tested that before bothering
GM> Savannah?).

*shrug*

GM> Anyway, I'm going to invest zero effort in this, just bitch and
GM> complain, like a bunch of people did about bzr. :)

OK.  If you or Stefan decide to use the Gnus post-receive hook for the
GNU ELPA or whatever, just let me know and we can move it out to its own
repo or otherwise make it a standalone tool you can depend on.  For now
it's a Gnus-only thing.

Specifically for the GNU ELPA it could be better integrated with the
underlying repo structure, customized specifically for commits against
an ELPA repo.

Ted

Re: Improved git commit emails

[Bob Proulx]

Glenn Morris wrote:
> ... support request (maybe someone should have tested that before
> bothering Savannah?).

But we are a friendly bunch and happy to help out.  It isn't much
bother.  :-)

I use emacs.  I am supporting the mailing lists.  I have been hacking
on Savannah.  I am one of the few savannah hackers that uses and
supports git.  Seems like a perfect match!  (And it is unlikely that
anyone else would take the task.)  I assigned the support request to
me and came over here to read the mailing list to understand what
needs to be done.  Oh my!  Is it too late to get out of the way?  :-)

Rüdiger Sonderfeld wrote:
> The new git-multimail hook seems to fix these problems. 
>   https://github.com/git/git/tree/master/contrib/hooks/multimail
>   https://github.com/mhagger/git-multimail
> Could you please switch the post-receive hook for GNU ELPA to
> git-multimail?

Glenn Morris wrote:
> These are the changes I would like to see in the commit emails
> (decreasing order of importance):
> 
> 1) get the first line of the commit message in the subject
> 2) remove the guff "This is an automated email...in full, below"
> 3) add a list of modified files somewhere near the top
> 4) Mail-Followup-To: committer, emacs-devel

Ted Zlatanov wrote:
> I did something like this for Gnus commit e-mails (starting with an
> existing Git post-receive script).  See
> http://git.gnus.org/cgit/gnus.git/tree/etc/post-receive and the
> e-mails themselves are at
> http://news.gmane.org/gmane.emacs.gnus.commits for example.

I am happy to help improve the commit emails.  I am happy if this
needs some iterations to develop a good solution.  For at least one
project there are multiple commit emails of different types sent to
different mailing lists.  Also there are currently at least three
different email commit hook scripts in use.  So there is a lot of
flexibility possible.  But I fear that this will quickly start to
bike-shed.

I have changed the post-receive hook for elpa over to the the new
git-multimail hook as requested.  See if that is more to your liking.
If not and you have a different preference let me know what you would
like to try next.

Bob

Re: Improved git commit emails

[Glenn Morris]

Thanks very much Bob.
Waiting for the next elpa commit to see how it looks...

Re: Improved git commit emails

[Bob Proulx]

Glenn Morris wrote:
> Waiting for the next elpa commit to see how it looks...

There are two different commits now.  Except I set the From: address
to emacs-devel thinking that would be good.  Afterward I didn't think
that was as good as having it from the committer.  So I removed it.
The next commit will be From: the committer the same as previously.
But I am not sure that generates a valid reply address.

Bob

Re: Improved git commit emails

[Glenn Morris]

Thanks. It seems like an improvement.

Is it possible to add a "Mail-Followup-To: committer, emacs-devel"
header?

(Trivia) Is it possible to remove the "This is an automated email...in
repository elpa." header (it just repeats the subject/from info), and
the "To stop receiving notification... of this repository" footer?

Re: Improved git commit emails

[Bob Proulx]

Glenn Morris wrote:
> Thanks. It seems like an improvement.
> 
> Is it possible to add a "Mail-Followup-To: committer, emacs-devel"
> header?

I see no support for doing so.  I see only this section.

  https://github.com/mhagger/git-multimail

  multimailhook.replyTo
  multimailhook.replyToCommit
  multimailhook.replyToRefchange

      Addresses to use in the Reply-To: field for commit emails
      (replyToCommit) and refchange emails (replyToRefchange).
      multimailhook.replyTo is used as default when replyToCommit or
      replyToRefchange is not set.  The value for these variables can be
      either:

      - An email address, which will be used directly.

      - The value "pusher", in which case the pusher's address (if
        available) will be used.  This is the default for refchange
        emails.

      - The value "author" (meaningful only for replyToCommit), in which
        case the commit author's address will be used.  This is the
        default for commit emails.

      - The value "none", in which case the Reply-To: field will be
        omitted.

That is the extent in this area that I see.  Although it is all python
and so a python hacker could make modifications to it to add this
capability.  If someone wanted to add that capability that would be
great.

> (Trivia) Is it possible to remove the "This is an automated email...in
> repository elpa." header (it just repeats the subject/from info), and
> the "To stop receiving notification... of this repository" footer?

Deleting lines is easy.  :-)  Done.

Bob

Re: Improved git commit emails

[Stephen J. Turnbull]

Bob Proulx writes:

 > > (Trivia) Is it possible to remove the "This is an automated email...in
 > > repository elpa." header (it just repeats the subject/from info), and
 > > the "To stop receiving notification... of this repository" footer?
 > 
 > Deleting lines is easy.  :-)  Done.

Removing the "To stop receiving notification" footer may put you in
violation of anti-spam laws, especially in Europe.  IANAL TINLA, so
ask a real one.

Re: Improved git commit emails

[Bob Proulx]

Stephen J. Turnbull wrote:
> Bob Proulx writes:
>  > > (Trivia) Is it possible to remove the "This is an automated email...in
>  > > repository elpa." header (it just repeats the subject/from info), and
>  > > the "To stop receiving notification... of this repository" footer?
>  > 
>  > Deleting lines is easy.  :-)  Done.
> 
> Removing the "To stop receiving notification" footer may put you in
> violation of anti-spam laws, especially in Europe.  IANAL TINLA, so
> ask a real one.

It isn't a problem.  Fortunately we are talking about just another
mailing list.  A mailing list just like this one.  The same rules
apply.

Bob

Re: Improved git commit emails

[Glenn Morris]

Bob Proulx wrote:

> Although it is all python and so a python hacker could make
> modifications to it to add this capability.

Been there, done it for bzr, not doing it again.

Re: Improved git commit emails

[Rüdiger Sonderfeld]

On Sunday 19 January 2014 18:09:18 Bob Proulx wrote:
> Glenn Morris wrote:
> > Thanks. It seems like an improvement.
> > 
> > Is it possible to add a "Mail-Followup-To: committer, emacs-devel"
> > header?
> 
> I see no support for doing so.  I see only this section.

It supports changing it by including git_multimail.py and changing the 
template variable values.

E.g., using the following as post-receive hook (requires git_multimail.py to 
be in the hooks directory) might work

-- 8< --------------------------------------------------------------- >8 --

#! /usr/bin/env python2

import sys
import os

import git_multimail

#git_multimail.DEBUG = True

git_multimail.FOOTER_TEMPLATE = ""
git_multimail.REFCHANGE_HEADER_TEMPLATE = """\
To: %(recipients)s
Subject: %(subject)s
MIME-Version: 1.0
Content-Type: text/plain; charset=%(charset)s
Content-Transfer-Encoding: 8bit
Message-ID: %(msgid)s
From: %(fromaddr)s
Reply-To: %(reply_to)s
Mail-Followup-To: %(fromaddr)s, emacs-devel@gnu.org
X-Git-Repo: %(repo_shortname)s
X-Git-Refname: %(refname)s
X-Git-Reftype: %(refname_type)s
X-Git-Oldrev: %(oldrev)s
X-Git-Newrev: %(newrev)s
Auto-Submitted: auto-generated
"""
git_multimail.REFCHANGE_INTRO_TEMPLATE = """\
%(pusher)s pushed a change to %(refname_type)s %(short_refname)s
in repository %(repo_shortname)s.

"""
git_multimail.REVISION_HEADER_TEMPLATE = """\
To: %(recipients)s
Subject: %(emailprefix)s%(num)02d/%(tot)02d: %(oneline)s
MIME-Version: 1.0
Content-Type: text/plain; charset=%(charset)s
Content-Transfer-Encoding: 8bit
From: %(fromaddr)s
Reply-To: %(reply_to)s
Mail-Followup-To: %(fromaddr)s, emacs-devel@gnu.org
In-Reply-To: %(reply_to_msgid)s
References: %(reply_to_msgid)s
X-Git-Repo: %(repo_shortname)s
X-Git-Refname: %(refname)s
X-Git-Reftype: %(refname_type)s
X-Git-Rev: %(rev)s
Auto-Submitted: auto-generated
"""
git_multimail.REVISION_INTRO_TEMPLATE = """\
%(pusher)s pushed a commit to %(refname_type)s %(short_refname)s
in repository %(repo_shortname)s.

"""
git_multimail.REVISION_FOOTER_TEMPLATE = git_multimail.FOOTER_TEMPLATE

# To debug use
# git_multimail.main(sys.argv[1:]+ ['--stdout'])

git_multimail.main(sys.argv[1:])

-- 8< --------------------------------------------------------------- >8 --

That way changing git_multimail.py is not necessary and therefore upgrading it 
should be less hassle.  But I'm not sure if the code encodes the Mail-
Followup-To header correctly.

See "Customizing email contents" and "Customizing git-multimail for your 
environment" in git_multimail's README.

Regards,
Rüdiger

Re: Improved git commit emails

[Bob Proulx]

Rüdiger Sonderfeld wrote:
> Bob Proulx wrote:
> > Glenn Morris wrote:
> > > Is it possible to add a "Mail-Followup-To: committer, emacs-devel"
> > > header?
> > 
> > I see no support for doing so.  I see only this section.
> 
> It supports changing it by including git_multimail.py and changing the 
> template variable values.
> 
> E.g., using the following as post-receive hook (requires git_multimail.py to 
> be in the hooks directory) might work

Thank you for doing this work.  I will put it into place and then we
can try it out.

> That way changing git_multimail.py is not necessary and therefore upgrading it 
> should be less hassle.

Yes.  That should be easier. 

> But I'm not sure if the code encodes the Mail-Followup-To header correctly.

I am not a python person so I can only rely upon your expertise here.

> See "Customizing email contents" and "Customizing git-multimail for your 
> environment" in git_multimail's README.

Thanks again for doing that work.

Bob

Re: Improved git commit emails

[Glenn Morris]

Please don't spend too much time and effort on what may well be only my
personal preference.

Re: Improved git commit emails

[Bob Proulx]

Glenn Morris wrote:
> Please don't spend too much time and effort on what may well be only my
> personal preference.

I personally haven't.  Thanks go to Rüdiger who did and wrapped it up
for us.  But this is a feature, and the other tweaks such as less
noisy headers and footers, that will be used by a lot of projects.
Potentially every project using git that wants notifications.  I
expect that I will probably implement all of the future git
notification requests using the wrapper and import strategy so that
there can be easy customizations.  And the ability to add
Mail-Followup-To is something that I wish were in the upstream since
it just makes things easier for consumers of the messages.

The only thing left that seems a little spurious is that the mailing
list adds a subject suffix and the notification adds a project suffix.
I think it would be quieter to reduce that to only one subject suffix
not two.

Bob

Re: Git transition checklist

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> > 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. :-)
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Git transition checklist

[Stefan Monnier]

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

I'd expect that if git-remote-bzr is used for the conversion of the Bzr
repository into a Git repository, git-remote-bzr will also correctly
convert any personal branch, but I don't know those bzr->git conversion
tools to know which tool people want to use to do the conversion nor
whether this tool does work on external branches.

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

It's in the text you quoted (and which I re-quoted above as well for
convenience).  It's got nothing to do with Bzr (except for the fact that
vc-bzr.el does implement those features).

> 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. :-)

Can't be much worse than the current status quo.


        Stefan

Re: Git transition checklist

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'd expect that if git-remote-bzr is used for the conversion of the Bzr
> repository into a Git repository, git-remote-bzr will also correctly
> convert any personal branch, but I don't know those bzr->git conversion
> tools to know which tool people want to use to do the conversion nor
> whether this tool does work on external branches.

Unfortunately the result of git-remote-bzr will be different from the
current git mirror on savannah (for some reason git-remote-bzr likes
adding an extra newline to the commit messages, and the author
conversion handles missing information differently).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Git transition checklist

[Glenn Morris]

PS. Another thing you could do in/after the conversion is remove the
useless tags that exist in the bzr version. (Maybe you did this
already.)

http://lists.gnu.org/archive/html/emacs-devel/2012-04/msg00042.html

Andreas Schwab wrote:

> They are inherited from the old times when the RCS files were shared
> between different projects.

Re: Git transition checklist

[Eric S. Raymond]

Glenn Morris <rgm@gnu.org>:
> PS. Another thing you could do in/after the conversion is remove the
> useless tags that exist in the bzr version. (Maybe you did this
> already.)

No. Added to the list.  Actually this is something I ciuld start doing now.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Git transition checklist

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> It's in the text you quoted (and which I re-quoted above as well for
> convenience).  It's got nothing to do with Bzr (except for the fact that
> vc-bzr.el does implement those features).

On my list.

> > 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. :-)
> 
> Can't be much worse than the current status quo.

I'll do that, then.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Git transition checklist

[Glenn Morris]

"Eric S. Raymond" wrote:

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

"Eric S. Raymond" wrote:

> as a topic expert in version-control systems and the surrounding tools

Hmmm.

Re: Git transition checklist

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 08 Jan 2014 09:59:53 -0500
> Cc: emacs-devel@gnu.org
> 
> > 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.

Indeed.  I want to preserve the history of that branch, because it is
work in progress that will land one day on the trunk.  I don't want to
see dozens of commits appear as a single jumbo commit after the
migration.  I'm quite sure I mentioned that in my original request.

Re: Git transition checklist

[David Engster]

Eli Zaretskii writes:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Wed, 08 Jan 2014 09:59:53 -0500
>> Cc: emacs-devel@gnu.org
>
>> 
>> > 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.
>
> Indeed.  I want to preserve the history of that branch, because it is
> work in progress that will land one day on the trunk.  I don't want to
> see dozens of commits appear as a single jumbo commit after the
> migration.  I'm quite sure I mentioned that in my original request.

If I understood Andreas correctly, all branches currently in the
Savannah repository are converted. So if you push this branch before the
switch, it should land in git as well?

-David

Re: Git transition checklist

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  esr@thyrsus.com,  emacs-devel@gnu.org
> Date: Wed, 08 Jan 2014 19:17:03 +0100
> 
> If I understood Andreas correctly, all branches currently in the
> Savannah repository are converted. So if you push this branch before the
> switch, it should land in git as well?

I don't want to push it, it's not ready to get public.  I don't think
it's right to pollute the savannah repository with every local branch
we all have.

I hope that the same (or similar) procedure that is used to convert
the bzr repository, with all its branches, to git, could be used for
migrating local branches.

Re: Git transition checklist

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't want to push it, it's not ready to get public.  I don't think
> it's right to pollute the savannah repository with every local branch
> we all have.

Note that it is possible for you to delete the branch again at any time,
so if you don't mind making it public temporally this would be the
easiest solution.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Git transition checklist

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <deng@randomsample.de>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, esr@thyrsus.com,
>> emacs-devel@gnu.org
>> Date: Wed, 08 Jan 2014 19:17:03 +0100
>> 
>> If I understood Andreas correctly, all branches currently in the
>> Savannah repository are converted. So if you push this branch before the
>> switch, it should land in git as well?
>
> I don't want to push it, it's not ready to get public.

I understand. You could make it a clandestine operation, though. Just
push the branch shortly before Andreas' script runs (I guess it runs at
least daily at some fixed time), then pull the git repo and immediately
delete your remote branch afterwards. Of course, anyone who does a fetch
or push with '--all' in that window will have the branch (and could push
it again), but maybe you could live with that possibility.

>  I don't think it's right to pollute the savannah repository with
> every local branch we all have.

I see no problem with that. Branches are cheap and can be deleted when
no longer needed. And AFAIK, git won't fetch or even show remote
branches unless you explicitly ask for it.

> I hope that the same (or similar) procedure that is used to convert
> the bzr repository, with all its branches, to git, could be used for
> migrating local branches.

Well, to be absolutely sure that you can later merge it to the master
branch on Savannah, it should run through Andreas' script.

-David

Re: Git transition checklist

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Indeed.  I want to preserve the history of that branch, because it is
> work in progress that will land one day on the trunk.  I don't want to
> see dozens of commits appear as a single jumbo commit after the
> migration.  I'm quite sure I mentioned that in my original request.

One way to solve that is to publish your branch in the emacs bzr repo,
so that it will automatically be mirrored to the git repo.  If that
cannot be done for some reason, it is possible that you do the
conversion yourself with bzr fast-export / git fast-import, though it
requires some care to get correct results.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Git transition checklist

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  esr@thyrsus.com,  emacs-devel@gnu.org
> Date: Wed, 08 Jan 2014 19:41:25 +0100
> 
> One way to solve that is to publish your branch in the emacs bzr repo,
> so that it will automatically be mirrored to the git repo.  If that
> cannot be done for some reason, it is possible that you do the
> conversion yourself with bzr fast-export / git fast-import, though it
> requires some care to get correct results.

I'd appreciate some instructions for the latter, especially in the
"some care" department.

Thanks in advance.

Re: Git transition checklist

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> I'd appreciate some instructions for the latter, especially in the
> "some care" department.

Noted.  I will try to put some instructions together.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Git transition checklist

[Stephen Berman]

On Wed,  8 Jan 2014 08:52:00 -0500 (EST) esr@thyrsus.com (Eric S. Raymond) wrote:

> This post rounds up all the issues I know about with the bzr to git
> changeover and their current state.
[...]
> Nobody else explicitly suggested any additional preconditions.

I suggested one
(http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00594.html):

   On Tue, 07 Jan 2014 15:57:05 +0100 Andreas Schwab <schwab@suse.de> wrote:
   
   > Stephen Berman <stephen.berman@gmx.net> writes:
   >
   >> Why is the git repository so much larger than the bzr repository?
   >
   > The git repositories on savannah appear to be packed rather badly.  A
   > reasonably well packed emacs repository should have around 350MB.
   
   Ok.  If the packing can be improved, I think it would be good for that
   to happen before finalizing the move to git.

Steve Berman

Re: Git transition checklist

[Eric S. Raymond]

Stephen Berman <stephen.berman@gmx.net>:
> > Nobody else explicitly suggested any additional preconditions.
> 
> I suggested one
> (http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00594.html):
> 
>    On Tue, 07 Jan 2014 15:57:05 +0100 Andreas Schwab <schwab@suse.de> wrote:
>    
>    > Stephen Berman <stephen.berman@gmx.net> writes:
>    >
>    >> Why is the git repository so much larger than the bzr repository?
>    >
>    > The git repositories on savannah appear to be packed rather badly.  A
>    > reasonably well packed emacs repository should have around 350MB.
>    
>    Ok.  If the packing can be improved, I think it would be good for that
>    to happen before finalizing the move to git.

I have added this to the list.  But:

1. Given the restrictions Savannah has on shell access to repository
   directories, I'm not sure it's possible at all. I have not been able
   to find any way to force a repack remotely.

2. Really this could be done at any time relative to the switchover.
   If Andreas can figure out a way to do it, "immediately" would be
   the best time.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Git repack on Savannah [was: Re: Git transition checklist]

[James Cloos]

>>>>> "ESR" == Eric S Raymond <esr@thyrsus.com> writes:

ESR> 1. Given the restrictions Savannah has on shell access to repository
ESR>    directories, I'm not sure it's possible at all. I have not been able
ESR>    to find any way to force a repack remotely.

ESR> 2. Really this could be done at any time relative to the switchover.
ESR>    If Andreas can figure out a way to do it, "immediately" would be
ESR>    the best time.

AIUI, the public method is to open a request for a repack at:

  https://savannah.gnu.org/support/?group=administration

-JimC
--
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Git repack on Savannah [was: Re: Git transition checklist]

[Bob Proulx]

James Cloos wrote:
> >>>>> "ESR" == Eric S Raymond writes:
> ESR> 1. Given the restrictions Savannah has on shell access to repository
> ESR>    directories, I'm not sure it's possible at all. I have not been able
> ESR>    to find any way to force a repack remotely.
> 
> AIUI, the public method is to open a request for a repack at:
> 
>   https://savannah.gnu.org/support/?group=administration

There is no need.  There is a cron task that periodically repacks all
of the repositories once a month.  It is a rather heavy task to do for
all of the repositories and therefore it runs at a low priority
periodically but not every day.  Here is the emacs related output from
the last run.

  ./emacs-epackage.git...
  ./emacs-epackage.git 740 KiB->740 (saved 0% in 1s)
  ./emacs-i18n.git...
  ./emacs-i18n.git     116 KiB->116 (saved 0% in 0s)
  ./emacs-tiny-tools.git...
  ./emacs-tiny-tools.git 7096 KiB->7096 (saved 0% in 1s)
  ./emacs.git...
  ./emacs.git          1218808 KiB->1074624 (saved 11.82% in 233s)
  ./emacs/elpa.git...
  ./emacs/elpa.git     28248 KiB->26772 (saved 5.22% in 5s)

Bob

Re: Git repack on Savannah [was: Re: Git transition checklist]

[Eli Zaretskii]

> Date: Sat, 11 Jan 2014 23:11:19 -0700
> From: Bob Proulx <bob@proulx.com>
> 
>   ./emacs.git          1218808 KiB->1074624 (saved 11.82% in 233s)

As you see, it barely changes anything, in terms of storage.

Re: Git transition checklist

[Bastien]

esr@thyrsus.com (Eric S. Raymond) writes:

>> 5. Have the procedures and the recommended workflows described on the
>>    wiki, similar to what was done with bzr migration.
>
> That is now done.  I have created two new pages on EmacsWiki,
> GitForEmacsDevs and GitQuickStartForEmacsDevs.

Both pages list this instruction on how to clone as a dev:

~$ git clone <username>@git://git.sv.gnu.org/emacs

This does not work.  I think it should be

~$ git clone <membername>@git.sv.gnu.org:/srv/git/emacs.git

(Unless the writable repository will be hosted at a different address
than this one.)

-- 
 Bastien

Re: Git transition checklist

[Eric S. Raymond]

Bastien <bzg@gnu.org>:
> Both pages list this instruction on how to clone as a dev:
> 
> ~$ git clone <username>@git://git.sv.gnu.org/emacs
> 
> This does not work.  I think it should be
> 
> ~$ git clone <membername>@git.sv.gnu.org:/srv/git/emacs.git

You are correct.  Fixed.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Git transition checklist

[Bastien]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Bastien <bzg@gnu.org>:
>> Both pages list this instruction on how to clone as a dev:
>> 
>> ~$ git clone <username>@git://git.sv.gnu.org/emacs
>> 
>> This does not work.  I think it should be
>> 
>> ~$ git clone <membername>@git.sv.gnu.org:/srv/git/emacs.git
>
> You are correct.  Fixed.

Thanks!

-- 
 Bastien

Re: Git transition checklist

[Glenn Morris]

"Eric S. Raymond" wrote:

>> This does not work.  I think it should be
>> 
>> ~$ git clone <membername>@git.sv.gnu.org:/srv/git/emacs.git
>
> You are correct.  Fixed.

I hope that the end result of a move to Git would be one repo in which
elpa is a branch, rather than than two repos that exist at present
(git.savannah.gnu.org/emacs.git and git.savannah.gnu.org/emacs).

Re: Git transition checklist

[Dani Moncayo]

> I hope that the end result of a move to Git would be one repo in which
> elpa is a branch, rather than than two repos that exist at present
> (git.savannah.gnu.org/emacs.git and git.savannah.gnu.org/emacs).

AFAIK, elpa contains stuff that is not in the "core" repository (and
vice-versa).  If I'm right, I don't see the benefit of making elpa a
branch in a repository where there is no common history to share.

-- 
Dani Moncayo

Re: Git transition checklist

[Glenn Morris]

Dani Moncayo wrote:

> AFAIK, elpa contains stuff that is not in the "core" repository (and
> vice-versa).  If I'm right, I don't see the benefit of making elpa a
> branch in a repository where there is no common history to share.

That's how it started with bzr, before elpa changed to git.

What if I move a file from elpa to core or vice versa?

Re: Git transition checklist

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> I hope that the end result of a move to Git would be one repo in which
> elpa is a branch, rather than than two repos that exist at present
> (git.savannah.gnu.org/emacs.git and git.savannah.gnu.org/emacs).

The emacs branches and elpa don't share any history (they are branches
with separate roots) so there isn't really any reason to share their
repositories.

(There's still old-branches/elpa in git that was used as the base for
the elpa git repo, but the latter has been subject to filter-branch to
plug in the converted subtrees.)

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Git transition checklist

[Glenn Morris]

Andreas Schwab wrote:

> The emacs branches and elpa don't share any history (they are branches
> with separate roots) so there isn't really any reason to share their
> repositories.

There's simplicity, and the issue that one day a file/package may move
from one to the other.

What's the reason _not_ to share them?

Re: Git transition checklist

[Stefan Monnier]

> There's simplicity, and the issue that one day a file/package may move
> from one to the other.

I think it'll be simpler to keep the two repository separate.
Moving file from elpa to emacs can be done without any
particular trouble.  You can also make a "shared" repository containing
both `emacs' and `elpa' branches, if you want.


        Stefan

Re: Git transition checklist

[Glenn Morris]

Stefan Monnier wrote:

> You can also make a "shared" repository containing both `emacs' and
> `elpa' branches, if you want.

If I can be bothered to learn how. It doesn't work exactly like my
existing bzr setup!1!!!! Stamps feet! I might have to read some
documentation!

(I'm enjoying seeing how the other half lives...)

Re: Git transition checklist

[Stefan Monnier]

>> You can also make a "shared" repository containing both `emacs' and
>> `elpa' branches, if you want.
> If I can be bothered to learn how. It doesn't work exactly like my
> existing bzr setup!1!!!! Stamps feet! I might have to read some
> documentation!

Start by adding the `elpa' repository as an additional remote
(git remote add elpa git://...).
Of course "make externals" will probably require some adjustments.


        Stefan

Re: Git transition checklist

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> There's simplicity, and the issue that one day a file/package may move
> from one to the other.

You can just add another remote to your clone that points to the elpa
repository.  Git doesn't really care where the commits originate from,
once they are in your repository all are alike.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Git transition checklist

[Glenn Morris]

Andreas Schwab wrote:

> You can just add another remote to your clone that points to the elpa
> repository.  Git doesn't really care where the commits originate from,
> once they are in your repository all are alike.

The instructions for committing to / fetching from Emacs will be made
more complicated by the existence of two separate repos, with weirdly
different but confusingly similar names.

(You did not answer the question "What's the reason _not_ to share them?".)

Re: Git transition checklist

[Stefan Monnier]

> (You did not answer the question "What's the reason _not_ to share them?".)

It was shared in Bzr because I did not know how to make a separate
repository for it in bzr.sv.gnu.org.

It is not shared in Git because sharing does not bring any significant
benefit, given the fact that the 2 repositories have no common history.

`elpa' is not a "version" of Emacs, contrary to pretty much
every other branch in the `emacs' repository.

In any case, these decisions aren't terribly important: it's easy enough
to change them later if we want.


        Stefan

Re: Git transition checklist

[Dani Moncayo]

On Wed, Jan 8, 2014 at 8:16 PM, Glenn Morris <rgm@gnu.org> wrote:
> Andreas Schwab wrote:
>
>> You can just add another remote to your clone that points to the elpa
>> repository.  Git doesn't really care where the commits originate from,
>> once they are in your repository all are alike.
>
> The instructions for committing to / fetching from Emacs will be made
> more complicated by the existence of two separate repos, with weirdly
> different but confusingly similar names.
>
> (You did not answer the question "What's the reason _not_ to share them?".)

Because then, switching between the elpa branch and any "core" branch
would be a much heavyweight (slower) operation.  By contrast,
switching between "core" branches should be almost instantaneous.

-- 
Dani Moncayo

Re: Git transition checklist

[Bob Proulx]

Eric S. Raymond wrote:
> Bastien wrote:
> > ~$ git clone <username>@git://git.sv.gnu.org/emacs
> > This does not work.  I think it should be
> > 
> > ~$ git clone <membername>@git.sv.gnu.org:/srv/git/emacs.git
> 
> You are correct.  Fixed.

I would like to note that the final ".git" suffix at the end is
optional.  For some reason by the time I have typed in the *fourth*
set of characters "git" on a line I tend to think it is just too many
strings of "git" on a line.  :-) So personally I tend to leave off the
final .git on the end.  It will be added if it is not specified.  And
stripped to create the local target name if added and the target
directory is not specified.

This is fine for anonymous public access since that is already rooted at
/srv/git on the server side:

  git clone git://git.sv.gnu.org/emacs

This is fine for logged in with ssh read-write access:

  git clone username@git.sv.gnu.org:/srv/git/emacs

Or with .git on the end is fine too if you prefer.

  git clone git://git.sv.gnu.org/emacs.git
  git clone username@git.sv.gnu.org:/srv/git/emacs.git

Yet another alternative ssh read-write access path would be to use the
URL syntax for ssh.

  git clone ssh://username@git.sv.gnu.org/srv/git/emacs

The ssh URL syntax tends to be used less than the scp-like syntax.

Bob

Re: Git transition checklist

[Bastien]

Bob Proulx <bob@proulx.com> writes:

> Eric S. Raymond wrote:
>> Bastien wrote:
>> > ~$ git clone <username>@git://git.sv.gnu.org/emacs
>> > This does not work.  I think it should be
>> > 
>> > ~$ git clone <membername>@git.sv.gnu.org:/srv/git/emacs.git
>> 
>> You are correct.  Fixed.
>
> I would like to note that the final ".git" suffix at the end is
> optional.

Good to know, thanks for the clear explanations.

-- 
 Bastien

Re: Git transition checklist

[Bastien]

esr@thyrsus.com (Eric S. Raymond) writes:

> 7. Andreas announces on the dev list that the git repo is live for
>    developer pushes.

7.5. Someone updates http://savannah.gnu.org/projects/emacs/ to
reflect the change.

> 8. I replace emacs-bzr-version with emacs-repository-get-version.
>
> 9. I mark the wiki pages on Bzr obsolete and update the Git ones.

-- 
 Bastien

Re: Git transition checklist

[Eric S. Raymond]

Bastien <bzg@gnu.org>:
> 7.5. Someone updates http://savannah.gnu.org/projects/emacs/ to
> reflect the change.

Added to the list.

Someone with administrator access should either volunteer to do this
(and tell me so I can add that to the transition recipe) or give me
administrator access so I can do it.  I don't care which.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Git transition checklist

[Glenn Morris]

Eric S. Raymond wrote:

> The only omission is that I left out the git equivalent of bzr bundle.

Bundles are useless anyway IMO.

Questions I would ask:
How do I make a shared repository?
How do I make a bound branch?
What is the equivalent of bzr commit --fixes?
Is there a changelog_merge equivalent?

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

But not trivial to make them as useful as the bzr ones were.
This is an issue right now with elpa, see separate emails.

> Replacing the function emacs-bzr-get-version with this will rectify a
> design error; it callers knew the string "bzr", which they should not have -

Yes alright, fair enough. Though I think "emacs-vcs-version" or
"emacs-dev-version" is less of a mouthful. Ditto with INSTALL.BZR ->
INSTALL.DEV or somesuch.

> This code is simpler than emacs-bzr-get-version because "git describe" is
> very fast - there's no need to avoid calling it for better performance.

The current version deliberately avoids calling an external executable
during dumping of Emacs, because that seemed safer to me (one less point
of failure). I think a git version should do the same (but I expect to
hear it's impossible).

BTW, people have previously posted git versions, eg
http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00430.html

> The change to integrate this and fix its callers is easy, five minutes'
> work which I will cheerfully do immediately after the repo switchover.
> No need to do it before as it really only becomes crucial to have this
> working for the next point release.

Err, no. It is completely useless for releases. It is very useful for
the time inbetween releases, and will start being needed right away.

> Thierry Volpiatto pointed out that these issues are addressed now:
> "You can use git-mergetool with ediff-merge for this" he said, 
> and gave a recipe.

That is in no way a solution.

> as VC's maintainer,

I was not aware you were VC's maintainer, except perhaps of
vc-dispatcher.el. (A maintainer who does nothing for 5+ years is not a
maintainer IMO.)

> 10. I will do the work required to update /etc and /admin to reflect
>     git use over the following few days.

I don't see why these things cannot be done in advance, since there is
no rush for this switch.
Why, you could even publish your work on a bzr branch so others can
help...
Eg I would like admin/update_autogen to be working right away.

Other things:

Work with hydra-users mailing list to update hydra build config.
Again, this is something that should work right away.

Makefile.in refers to a bzr file.

Re: Git transition checklist

[Eric S. Raymond]

Glenn Morris <rgm@gnu.org>:
> Questions I would ask:
> How do I make a shared repository?

There isn't any such thing. But when you clone the repo you get all
the branches, and every time you pull (normally) all are updated, so
in a sense all repositories are automatically shared.

> How do I make a bound branch?

There is no such thing.  All branches require "git push" to publish the
changes to the upstream.

> What is the equivalent of bzr commit --fixes?

There isn't one.  If you want to associate a bug with a commit you'll
have to do it manually in the commit comment.

> Is there a changelog_merge equivalent?

Not directly in git as far as I know.  Various Emacs front ends
probably implement something like 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.
> 
> But not trivial to make them as useful as the bzr ones were.
> This is an issue right now with elpa, see separate emails.

Yes, looks like multimail will handle it.
 
> > Replacing the function emacs-bzr-get-version with this will rectify a
> > design error; it callers knew the string "bzr", which they should not have -
> 
> Yes alright, fair enough. Though I think "emacs-vcs-version" or
> "emacs-dev-version" is less of a mouthful. Ditto with INSTALL.BZR ->
> INSTALL.DEV or somesuch.

Yes, indeed.

> > This code is simpler than emacs-bzr-get-version because "git describe" is
> > very fast - there's no need to avoid calling it for better performance.
> 
> The current version deliberately avoids calling an external executable
> during dumping of Emacs, because that seemed safer to me (one less point
> of failure). I think a git version should do the same (but I expect to
> hear it's impossible).

I don't know of a way to do it.

> BTW, people have previously posted git versions, eg
> http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00430.html

Noted. I'll use that as a model.

> > The change to integrate this and fix its callers is easy, five minutes'
> > work which I will cheerfully do immediately after the repo switchover.
> > No need to do it before as it really only becomes crucial to have this
> > working for the next point release.
> 
> Err, no. It is completely useless for releases. It is very useful for
> the time inbetween releases, and will start being needed right away.

I can see the sense in that. I'll do it right away then.
 
> I was not aware you were VC's maintainer, except perhaps of
> vc-dispatcher.el. (A maintainer who does nothing for 5+ years is not a
> maintainer IMO.)

I wrote the code, and I don't see anyone else taking responsibility for it.
Who else do you have in mind to do so?  I'm busy enough to *like* the
idea of handing it off.

> > 10. I will do the work required to update /etc and /admin to reflect
> >     git use over the following few days.
> 
> I don't see why these things cannot be done in advance, since there is
> no rush for this switch.

I don't want to do these things in advance because the less time I
spend typing bzr commands the better.  Keeping track of the branch/repo
distinction and when I have to utter which kind of invocation makes
my head hurt.

I tried the bzr way shortly after that switch and...there's a *reason*
I went silent for several years.

> Why, you could even publish your work on a bzr branch so others can
> help...
> Eg I would like admin/update_autogen to be working right away.

Nobody's stopping you from working on that.

I did volunteer for the technical lead on this.  That doesn't mean you
can expect me to do work that would be more efficiently done by
others, nor that I will always exactly share your beliefs about what
is urgent when.

> Work with hydra-users mailing list to update hydra build config.
> Again, this is something that should work right away.

See above. I know nothing about hydra.  You should probably find someone
who does for that part.

> Makefile.in refers to a bzr file.

That I expect I can fix.  I've added it to my list.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Git transition checklist

[Eli Zaretskii]

> Date: Wed, 8 Jan 2014 15:02:16 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: emacs-devel@gnu.org
> 
> > What is the equivalent of bzr commit --fixes?
> 
> There isn't one.  If you want to associate a bug with a commit you'll
> have to do it manually in the commit comment.

It would be nice to have something similar to --fixes, so that the bug
report is mentioned in the commit's metadata in some canonical format,
which will then make it easy to look for that.

> > Is there a changelog_merge equivalent?
> 
> Not directly in git as far as I know.

Yes, there is: in gnulib.  It's called git-merge-changelog.  The
problem that (AFAIK) there's no distribution of it you can download;
one needs to produce a gnulib module for it, and then configure and
build it.

> > The current version deliberately avoids calling an external executable
> > during dumping of Emacs, because that seemed safer to me (one less point
> > of failure). I think a git version should do the same (but I expect to
> > hear it's impossible).
> 
> I don't know of a way to do it.

How about looking in .git/logs/HEAD?

> I don't want to do these things in advance because the less time I
> spend typing bzr commands the better.  Keeping track of the branch/repo
> distinction and when I have to utter which kind of invocation makes
> my head hurt.

Latest bzr versions support colocated branches, if you cannot live
without that.  (Frankly, in Emacs this makes little sense.)

Re: Git transition checklist

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, there is: in gnulib.  It's called git-merge-changelog.  The
> problem that (AFAIK) there's no distribution of it you can download;
> one needs to produce a gnulib module for it, and then configure and
> build it.

For those who use openSUSE, it's available as the git-merge-changelog
package.  I don't know about other distributions.

>> > The current version deliberately avoids calling an external executable
>> > during dumping of Emacs, because that seemed safer to me (one less point
>> > of failure). I think a git version should do the same (but I expect to
>> > hear it's impossible).
>> 
>> I don't know of a way to do it.
>
> How about looking in .git/logs/HEAD?

While the repository format is fully documented, there are a few
indirections to be done before you wind up with the ultimate git
revision.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Git transition checklist

[James Cloos]

>>>>> "AS" == Andreas Schwab <schwab@linux-m68k.org> writes:

AS> For those who use openSUSE, it's available as the git-merge-changelog
AS> package.  I don't know about other distributions.

It was just added to Gentoo in the last week or so.

I don't see it in debian sid or ubuntu trusty.

-JimC
--
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Git transition checklist

[Rüdiger Sonderfeld]

On Wednesday 08 January 2014 19:54:11 James Cloos wrote:
> >>>>> "AS" == Andreas Schwab <schwab@linux-m68k.org> writes:
> AS> For those who use openSUSE, it's available as the git-merge-changelog
> AS> package.  I don't know about other distributions.
> 
> It was just added to Gentoo in the last week or so.
> 
> I don't see it in debian sid or ubuntu trusty.

I've created a bug report about adding it to git-extras on Debian (and 
consequently Ubuntu).  I haven't heard anything back so far.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734527

But I think it would make more sense to move those scripts (git-merge-
changelog and gitlog-to-changelog) into git's contrib.  That way they would be 
more easy to discover, included in many distributions, and developed alongside 
git.

Regards
Rüdiger

Re: Git transition checklist

[Eli Zaretskii]

> From: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
> Cc: James Cloos <cloos@jhcloos.com>, esr@thyrsus.com, Eli Zaretskii <eliz@gnu.org>, Andreas Schwab <schwab@linux-m68k.org>
> Date: Thu, 09 Jan 2014 02:23:34 +0100
> 
> But I think it would make more sense to move those scripts (git-merge-
> changelog and gitlog-to-changelog) into git's contrib.  That way they would be 
> more easy to discover, included in many distributions, and developed alongside 
> git.

For better discovery, they should be documented somewhere, and that
docs preferably accessible from "git help".

Re: Git transition checklist

[James Cloos]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

EZ> It would be nice to have something similar to --fixes, so that the bug
EZ> report is mentioned in the commit's metadata in some canonical format,
EZ> which will then make it easy to look for that.

I think I've seen a hook which does that.  Perhaps a web search might find it.

It would have to be a prepare-commit-msg hook.

-JimC
--
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Git transition checklist

[Rüdiger Sonderfeld]

On Wednesday 08 January 2014 22:19:52 Eli Zaretskii wrote:
> > Date: Wed, 8 Jan 2014 15:02:16 -0500
> > From: "Eric S. Raymond" <esr@thyrsus.com>
> > Cc: emacs-devel@gnu.org
> > 
> > > What is the equivalent of bzr commit --fixes?
> > 
> > There isn't one.  If you want to associate a bug with a commit you'll
> > have to do it manually in the commit comment.
> 
> It would be nice to have something similar to --fixes, so that the bug
> report is mentioned in the commit's metadata in some canonical format,
> which will then make it easy to look for that.

This could be handled by git-notes(1).

E.g.,

  git commit ...
  git notes add -m 'Fixes: #16389'

Would add a note (metadata) to the last commit.  It is shown in `git log' or 
the current note can be displayed using `git notes show'.

Regards,
Rüdiger

Re: Git transition checklist

[Rüdiger Sonderfeld]

On Thursday 09 January 2014 02:36:33 Rüdiger Sonderfeld wrote:
>   git commit ...
>   git notes add -m 'Fixes: #16389'

Or maybe better

  git notes --ref=fixes add -m '#1234'

That way the bug metadata would be stored in its own note.  Which can be 
handled and displayed separately (E.g., `git log --show-notes=fixes' or by 
setting `notes.displayRef').

Regards,
Rüdiger

Re: Git transition checklist

[Eli Zaretskii]

> From: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
> Date: Thu, 09 Jan 2014 02:48:55 +0100
> Cc: esr@thyrsus.com, Eli Zaretskii <eliz@gnu.org>
> 
> On Thursday 09 January 2014 02:36:33 Rüdiger Sonderfeld wrote:
> >   git commit ...
> >   git notes add -m 'Fixes: #16389'
> 
> Or maybe better
> 
>   git notes --ref=fixes add -m '#1234'
> 
> That way the bug metadata would be stored in its own note.  Which can be 
> handled and displayed separately (E.g., `git log --show-notes=fixes' or by 
> setting `notes.displayRef').

If you suggest doing the above by hand, then that won't do the job:
people will forget and/or use different formats for the text.  We need
something better, if it's possible.

Re: Git transition checklist

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> If you suggest doing the above by hand, then that won't do the job:
> people will forget and/or use different formats for the text.  We need
> something better, if it's possible.

Notes can be added, removed and modified independently from the commits
they are attached to, so anybody can fix it up.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Git transition checklist

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Rüdiger Sonderfeld <ruediger@c-plusplus.de>,
>   esr@thyrsus.com,  emacs-devel@gnu.org
> Date: Thu, 09 Jan 2014 12:10:27 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If you suggest doing the above by hand, then that won't do the job:
> > people will forget and/or use different formats for the text.  We need
> > something better, if it's possible.
> 
> Notes can be added, removed and modified independently from the commits
> they are attached to, so anybody can fix it up.

Yes, but only after the problem is discovered and/or reported.  Until
then, it could lay dormant for a long time.  Again, this happened in
the past.

Re: Git transition checklist

[Rüdiger Sonderfeld]

On Thursday 09 January 2014 18:17:52 Eli Zaretskii wrote:
> > From: Andreas Schwab <schwab@linux-m68k.org>
> > Cc: Rüdiger Sonderfeld <ruediger@c-plusplus.de>,
> > 
> >   esr@thyrsus.com,  emacs-devel@gnu.org
> > 
> > Date: Thu, 09 Jan 2014 12:10:27 +0100
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > > If you suggest doing the above by hand, then that won't do the job:
> > > people will forget and/or use different formats for the text.  We need
> > > something better, if it's possible.
> > 
> > Notes can be added, removed and modified independently from the commits
> > they are attached to, so anybody can fix it up.
> 
> Yes, but only after the problem is discovered and/or reported.  Until
> then, it could lay dormant for a long time.  Again, this happened in
> the past.

What does --fixes in bzr exactly do?  Does it close the corresponding bug on 
the tracker?  Does that happen when you commit or when you push?

This could be handled automatically in a pre-receive hook.  It depends on what 
exactly we need to do.  Is it enough to check the format?  That would be 
simple.  Checking if it matches an existing bug and closing the bug would be a 
bit more complicated because it requires interaction with the bug tracker.

But I'm currently more concerned with the fact that notes aren't automatically 
pushed.  So maybe git-notes aren't useful in our case.

Regards,
Rüdiger

Re: Git transition checklist

[Eli Zaretskii]

> From: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
> Cc: Andreas Schwab <schwab@linux-m68k.org>, esr@thyrsus.com, emacs-devel@gnu.org
> Date: Thu, 09 Jan 2014 17:45:28 +0100
> 
> What does --fixes in bzr exactly do?  Does it close the corresponding bug on 
> the tracker?

No, it does not.  It just adds a canonical reference to the bug on
debbugs into the commit meta-date:

  bzr log -c 115888
  ------------------------------------------------------------
  revno: 115888
  fixes bug: http://debbugs.gnu.org/16129  <<<<<<<<<<<<<<<<<<<<<<<<<
  committer: Eli Zaretskii <eliz@gnu.org>
  branch nick: trunk
  timestamp: Mon 2014-01-06 16:28:26 +0000
  message:
    Fix bug #16129 with slow and incorrect redisplay in follow-mode.

     src/xdisp.c (redisplay_window): Don't skip window redisplay if the
     last value of point is not equal to buffer's point.

> Does that happen when you commit or when you push?

When you commit, because it is inserted into the commit data (but with
a bound branch, commit also pushes).

Re: Git transition checklist

[Rüdiger Sonderfeld]

On Thursday 09 January 2014 08:41:17 Eli Zaretskii wrote:
> > From: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
> > Date: Thu, 09 Jan 2014 02:48:55 +0100
> > Cc: esr@thyrsus.com, Eli Zaretskii <eliz@gnu.org>
> > 
> > On Thursday 09 January 2014 02:36:33 Rüdiger Sonderfeld wrote:
> > >   git commit ...
> > >   git notes add -m 'Fixes: #16389'
> > 
> > Or maybe better
> > 
> >   git notes --ref=fixes add -m '#1234'
> > 
> > That way the bug metadata would be stored in its own note.  Which can be
> > handled and displayed separately (E.g., `git log --show-notes=fixes' or by
> > setting `notes.displayRef').
> 
> If you suggest doing the above by hand, then that won't do the job:
> people will forget and/or use different formats for the text.  We need
> something better, if it's possible.

That's why I like the second form, using a `fixes' ref.  That way the format 
is simple enough that it's harder to screw up.  But as Andreas said, the Notes 
can be edited without changing the commit message or history.

However I just learned that sharing those notes is a bit of a pain.  They are 
apparently not automatically pushed or fetched.  This might need some work or 
some wrapper script.

Regards,
Rüdiger

Re: Git transition checklist

[Glenn Morris]

Eli Zaretskii wrote:

> It would be nice to have something similar to --fixes, so that the bug
> report is mentioned in the commit's metadata in some canonical format,
> which will then make it easy to look for that.

All it really does for Bzr (in non-Launchpad use) is add:

fixes bug: http://debbugs.gnu.org/123

to the log output; and eg loggerhead formats this nicely as a hyperlink,
see eg http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/115903 .

Re: Git transition checklist

[Glenn Morris]

PS Someone should also search for Emacs bugs related to vc-git support
and fix the relevant ones. Some possibilities at a very quick glance:

http://debbugs.gnu.org/8288
http://debbugs.gnu.org/8756
http://debbugs.gnu.org/15696
http://debbugs.gnu.org/10378

Re: Git transition checklist

[Eric S. Raymond]

Glenn Morris <rgm@gnu.org>:
> 
> PS Someone should also search for Emacs bugs related to vc-git support
> and fix the relevant ones. Some possibilities at a very quick glance:
> 
> http://debbugs.gnu.org/8288
> http://debbugs.gnu.org/8756
> http://debbugs.gnu.org/15696
> http://debbugs.gnu.org/10378

I can fix some of these.

What is the form of the magic argument to --fixes?  "--fixes emacs:8756" and
"--fixes=emacs:8756" don't seem to work.  This isn't documented anywhere.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Git transition checklist

[Paul Eggert]

Eric S. Raymond wrote:
> What is the form of the magic argument to --fixes?  "--fixes emacs:8756" and
> "--fixes=emacs:8756" don't seem to work.  This isn't documented anywhere.

It's documented in admin/notes/bugtracker, presumably another file that
will need to be changed during the transition to git.

Re: Git transition checklist

[Eric S. Raymond]

Paul Eggert <eggert@cs.ucla.edu>:
> Eric S. Raymond wrote:
> >What is the form of the magic argument to --fixes?  "--fixes emacs:8756" and
> >"--fixes=emacs:8756" don't seem to work.  This isn't documented anywhere.
> 
> It's documented in admin/notes/bugtracker, presumably another file that
> will need to be changed during the transition to git.

I don't get it.  Glen Morris passes along this bug URL:

http://debbugs.gnu.org/8756

I fix the bug and attempt to commit with 

bzr commit --fixes debbugs:8756

I get back

bzr: ERROR: Unrecognized bug debbugs:8756. Commit refused.

What am I doing wrong here?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Git transition checklist

[Juanma Barranquero]

On Thu, Jan 9, 2014 at 4:15 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> bzr: ERROR: Unrecognized bug debbugs:8756. Commit refused.
>
> What am I doing wrong here?

Did you add

bugtracker_debbugs_url = http://debbugs.gnu.org/{id}

to the [DEFAULT] section of your bazaar.conf?

   J

Re: Git transition checklist

[Eric S. Raymond]

Juanma Barranquero <lekktu@gmail.com>:
> Did you add
> 
> bugtracker_debbugs_url = http://debbugs.gnu.org/{id}
> 
> to the [DEFAULT] section of your bazaar.conf?

Thanks, that fixed it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Git transition checklist

[Glenn Morris]

"Eric S. Raymond" wrote:

>> How do I make a shared repository?
>
> There isn't any such thing. But when you clone the repo you get all
> the branches, and every time you pull (normally) all are updated, so
> in a sense all repositories are automatically shared.

Let me explain a bit more:

What I have now is an emacs-bzr/ directory, which is a shared repository.
Within that directory I have multiple trunk/ directories, also
directories for emacs-24, emacs-23 (etc) branches. These are all
independent. The .bzr directory within each branch directory is
very small, only the top-level .bzr directory is not. I can simply
copy trunk/ to trunk-test/ at any time using standard Unix tools to
have a new directory that tracks the upstream repository independently
of trunk/, and does not waste space with a duplicate copy of a large
.bzr directory. If I fetch new revisions from upstream in trunk/,
those are available locally when I want to update trunk-test/, and do
not have to be refetched from the remote server.

Can I replicate such a setup?

>> How do I make a bound branch?
>
> There is no such thing. [...]
>
>> What is the equivalent of bzr commit --fixes?
>
> There isn't one. [...]
>
>> Is there a changelog_merge equivalent?
>
> Not directly in git as far as I know. [...]

I'm sure I will "enjoy the greater simplicity that results from the
absence of many" VCS features I've been using.

> Yes, looks like multimail will handle it.

AFAIK, no-one has actually tested this to see if the output fixes the
issues. Also Ted suggested an alternative. Someone should see which is
best.

> I wrote the code, and I don't see anyone else taking responsibility for it.

The people who've been fixing it and developing it over the past decade
have been taking responsibility for it. You'll find their names in the
ChangeLog.

> Who else do you have in mind to do so?  I'm busy enough to *like* the
> idea of handing it off.

Good ol' Maintainer: FSF sounds right.
It's only vc-dispatcher.el you'll have to change.
(Though Andre Spiegel has been AWOL for many years too.)

> Nobody's stopping you from working on that.

I did not ask for this change of VCS, and don't expect to benefit from it.

> See above. I know nothing about hydra.  You should probably find someone
> who does for that part.

I know about it, but I am not going to work on a VCS switch, since I
prefer to work on the 24.4 release.

http://lists.gnu.org/archive/html/hydra-users/

Probably all that needs to be done is to email the hydra-users list and
ask them to switch the emacs input from bzr to git at the right time.

http://hydra.nixos.org/jobset/gnu/emacs-trunk#tabs-configuration

Re: Git transition checklist

[Stephen J. Turnbull]

Glenn Morris writes:

 > Can I replicate such a [bzr shared repo] setup?
 > How do I make a bound branch?

Replicate, no -- there are minor semantic differences.  Get space
savings and avoid network traffic when the object is available
locally, yes.  Bound branch, see Option 2 below.

DO NOT read the footnotes unless you are a git fan, if you're a bzr
kinda hacker your brain will explode.

Two ways to do it.  Both start by cloning the upstream repo

    cd $PARENT_DIRECTORY_FOR_EMACS_REPOS
    git clone $URL_TO_SAVANNAH_GIT_EMACS_TRUNK trunk

Option 1:

    # In same CWD as above:

    git clone --shared trunk ws1

Option 2:

    # In same CWD as above; [branch2] is an optional argument to
    # choose the named branch from trunk to check out.  It may be
    # irrelevant to the Emacs repo setup, I don't know.
    # The git-new-workdir script is in the git contrib directory, it's
    # not enabled by default.

    git new-workdir trunk ws2 [branch2]

CAVEAT for both options: DO NOT BLOW AWAY TRUNK!!  It is the
equivalent of the shared-repo's .bzr.

Difference between the options:

Option 1 is like a regular bzr branch: branch1's history is identical
to trunk up to the point of cloning, after that independent of trunk.

It is possible to switch the workspace to a different branch using
git-checkout, but that branch's history may not be complete unless you
pull it again from trunk.[1]

Option 2 has many similarities to a *local* bound branch.  *All*
history and branch configuration is shared.[2]  This has some glitches.

The obvious one is that it only works locally, so unlike a bzr bound
branch it's useless as an "automatically synced staging area for
pushes."  Almost as obvious, since HEAD is usually a pointer to a
branch ref (not to a commit), a commit in ws1 will advance HEAD in all
workspaces that have checked out the same branch.  This is usually not
what is wanted in a development workspace.

For more glitches, ask Stefan.  It's against my religion to believe in
glitches in git, so surely there aren't any more.

Now, you can make an informed choice.  Pick your poison!

I hereby license this text to all under the MIT/X license.  For a
signed paper copy, send me an SASE (110 yen).

Footnotes: 
[1]  Technically the history DAG is complete because the objects
directory is hardlinked in both GIT_DIRs, but the branch ref in ws1
does not advance with the branch ref of the same name in trunk.

[2]  Technically, the refs and .git/config as well as the DAG are shared.

Re: Git transition checklist

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Thu, 09 Jan 2014 13:27:44 +0900
> Cc: esr@thyrsus.com, emacs-devel@gnu.org
> 
> Two ways to do it.  Both start by cloning the upstream repo

Thanks.

I think we should decide whether we want to recommend one of these
methods (or some 3rd one), and describe the related workflow in the
Wiki.

Re: Git transition checklist

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > I think we should decide whether we want to recommend one of these
 > methods (or some 3rd one), and describe the related workflow in the
 > Wiki.

Been there, done that, and the alligators ate my T-shirt so I have
nothing to show.  I recommend avoiding recommendations here.  I think
it's better to post various possibilities, describe their use cases,
and limit recommendation to something implicit like reordering them in
the wiki page.

In the case of "git clone --shared" vs "git new-workdir", however,
"git new-workdir" does something equivalent to "git clone --shared",
and then does some other stuff too.  I don't really see any reason not
to do "clone --shared".

Also, you can do both at the same time in different workspaces.  Since
their use cases are different, you might want to.

Re: Git transition checklist

[Andreas Schwab]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> In the case of "git clone --shared" vs "git new-workdir", however,
> "git new-workdir" does something equivalent to "git clone --shared",
> and then does some other stuff too.  I don't really see any reason not
> to do "clone --shared".

clone --shared should only be used if know what you do, especially avoid
it if the origin is continued to be used for development.  It works best
if the origin is just a mirror of the upstream repo, and never modified
except by pulling from upstream.  A clone without --shared gives almost
the same space saving without the caveats.  Copying commits between
clones is straight forward with git fetch.

There is work in progress to fully integrate git new-workdir into the
git core, to remove its shortcomings.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Git transition checklist

[Stephen J. Turnbull]

Andreas Schwab writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > 
 > > In the case of "git clone --shared" vs "git new-workdir", however,
 > > "git new-workdir" does something equivalent to "git clone --shared",
 > > and then does some other stuff too.  I don't really see any reason not
 > > to do "clone --shared".
 > 
 > clone --shared should only be used if know what you do, especially avoid
 > it if the origin is continued to be used for development.

True, it's best used as a staging area.  However, the most dangerous
operations (rebasing and deleting branches in the origin repo (what I
called "trunk")) are unlikely to be done by bzr fans.

 > It works best if the origin is just a mirror of the upstream repo,
 > and never modified except by pulling from upstream.  A clone
 > without --shared gives almost the same space saving without the
 > caveats.

That depends on how actively the developer uses separate workspaces.
I guess for Emacs with about 100,000 commits and 275,000 objects,
you'd have to be pretty frenetic to make a noticable difference.

On balance, I guess it is better to avoid the --shared option.

Except: what about Windows filesystems?  I have no idea if they
implement hardlinks properly (I gather the semantics of symlinks are
somewhat different).

 > Copying commits between clones is straight forward with git fetch.

True but I doubt Glenn and Eli are worried about that.

Re: Git transition checklist

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Andreas Schwab writes:
>  > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>  > 
>  > > In the case of "git clone --shared" vs "git new-workdir", however,
>  > > "git new-workdir" does something equivalent to "git clone --shared",
>  > > and then does some other stuff too.  I don't really see any reason not
>  > > to do "clone --shared".
>  > 
>  > clone --shared should only be used if know what you do, especially avoid
>  > it if the origin is continued to be used for development.
>
> True, it's best used as a staging area.  However, the most dangerous
> operations (rebasing and deleting branches in the origin repo (what I
> called "trunk")) are unlikely to be done by bzr fans.

Branches are rebased and deleted also when upstream developers rebase
and delete in the central repository from which the material is fetched.

> On balance, I guess it is better to avoid the --shared option.

Yup.

-- 
David Kastrup

Re: Git transition checklist

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: esr@thyrsus.com,
>     Eli Zaretskii <eliz@gnu.org>,
>     emacs-devel@gnu.org
> Date: Thu, 09 Jan 2014 23:30:35 +0900
> 
> On balance, I guess it is better to avoid the --shared option.

I guess we have a consensus, then.  I think Stefan also suggested
separate repositories.

So would someone "in the know" please update the Wiki with the
instructions how to set this up and what the workflow would look like
for working on the trunk and a release branch  in this way?  The main
jobs to be covered are, I think, (a) updating each branch from
upstream and (b) merging and/or cherry-picking commits between the two
branches each one of which is in a separate repository.  TIA.

> Except: what about Windows filesystems?  I have no idea if they
> implement hardlinks properly

Hard links are supported on NTFS.  I didn't yet try cloning locally
though, so I don't know whether there are Windows-specific problems
here.

> (I gather the semantics of symlinks are somewhat different).

The semantics of symlinks are almost identical, but creating a symlink
is a privileged operation on Windows, so use of symlinks is not a good
idea.

Btw, I think git can use something called "alternates" instead of hard
links?  Is this relevant?

>  > Copying commits between clones is straight forward with git fetch.
> 
> True but I doubt Glenn and Eli are worried about that.

??? Merges and cherry-picks between the release branch and the trunk
happen all the time, as long as the release branch is active.

Btw, one other task that should be accomplished before the switch is
how and what will we merge between the two branches.  We use
admin/bzrmerge.el with bzr, and the way that works allows to make a
release branch from the trunk by merging.  The corresponding
gitmerge.el, if it is needed, or procedures that will replace it if
not, should probably allow similar capabilities.

Re: Git transition checklist

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > I guess we have a consensus, then.  I think Stefan also suggested
 > separate repositories.

 > So would someone "in the know" please update the Wiki with the
 > instructions how to set this up and what the workflow would look like
 > for working on the trunk and a release branch  in this way?  The main
 > jobs to be covered are, I think, (a) updating each branch from
 > upstream and (b) merging and/or cherry-picking commits between the two
 > branches each one of which is in a separate repository.  TIA.

No, both branches must be in the same repository to perform those
operations.  The only thing git can do between repositories is fetch
objects that are reachable from a reference.  Merging branches
requires that both be present in one repository; the resulting DAG
structure can then be fetched and merged into other repositories.
Similarly with cherry-picking.

What this implies for Emacs release workflows I can't say because I
don't know how the Emacs release workflow works, specifically who
commits the merges and cherry-picks.

The issue about multiple repositories is about whether a single
developer's feature branches should share an object database (at least
that's what I've been talking about, and I believe Andreas too).  The
conclusion is that they shouldn't, but this will result in a certain
number of objects duplicated in several local repos.  However,
reducing that duplication by --share'ing is not worth the risk of gc
in the origin repo corrupting the feature branches (because the origin
repo doesn't know about those branches).

 > Btw, I think git can use something called "alternates" instead of hard
 > links?  Is this relevant?

Yes, that's precisely what --shared does.

 > >  > Copying commits between clones is straight forward with git fetch.
 > > 
 > > True but I doubt Glenn and Eli are worried about that.
 > 
 > ??? Merges and cherry-picks between the release branch and the trunk
 > happen all the time, as long as the release branch is active.

Sure, but you won't be using git fetch directly to do that.  You'll
use git pull or git push, which do any necessary fetching implicitly.
What Andreas is talking about is reorganizing the object databases in
a way that won't affect the branch structure visible in the origin or
in the clone.  (At least, that's what I think he's talking about.)

Re: Git transition checklist

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: esr@thyrsus.com,
>     schwab@linux-m68k.org,
>     emacs-devel@gnu.org
> Date: Fri, 10 Jan 2014 03:46:45 +0900
> 
>  > jobs to be covered are, I think, (a) updating each branch from
>  > upstream and (b) merging and/or cherry-picking commits between the two
>  > branches each one of which is in a separate repository.  TIA.
> 
> No, both branches must be in the same repository to perform those
> operations.

I somehow understood that if one does "git remote add" to track the
other repository, one can then fetch from there and merge or
cherry-pick from the fetched commits.  Is that wrong?

> What this implies for Emacs release workflows I can't say because I
> don't know how the Emacs release workflow works, specifically who
> commits the merges and cherry-picks.

Merges from the release branch to the trunk can be currently done by
anyone with write access.  The only requirement is to follow the
protocol encoded in admin/bzrmerge.el, which in a nutshell merges all
the revisions from the last merge point "till now", and then
selectively reverts the changes we don't want on the trunk (e.g.,
because a different fix for the same problem was committed to the
trunk).

> The issue about multiple repositories is about whether a single
> developer's feature branches should share an object database (at least
> that's what I've been talking about, and I believe Andreas too).  The
> conclusion is that they shouldn't, but this will result in a certain
> number of objects duplicated in several local repos.  However,
> reducing that duplication by --share'ing is not worth the risk of gc
> in the origin repo corrupting the feature branches (because the origin
> repo doesn't know about those branches).

Feature branches worry me much less than the need to work with at
least two (in the future maybe more) public and long-living branches:
the development trunk and the release branch.  As previously
explained, frequent merging between them is a matter of routine, and
since they diverge very quickly after the branching, having them
colocated in the same directory will be a nuisance, because the build
after switching to another branch will be annoyingly long, generally a
full configure+bootstrap will be required.

Re: Git transition checklist

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Feature branches worry me much less than the need to work with at
> least two (in the future maybe more) public and long-living branches:
> the development trunk and the release branch.  As previously
> explained, frequent merging between them is a matter of routine, and
> since they diverge very quickly after the branching, having them
> colocated in the same directory will be a nuisance, because the build
> after switching to another branch will be annoyingly long, generally a
> full configure+bootstrap will be required.

I have a defadvice for the magit function that switches branches. It
saves the file timestamps of the current branch, switches to the other
branch and restores the file timestamps for that branch.

Then, each branch has its own build directory.

For Emacs, this approach has the problem of having the .elc files shared
on the source directory. A configure option for putting the .elc files
on the build directory would fix that.

Re: Git transition checklist

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 09 Jan 2014 20:40:13 +0100
> 
> I have a defadvice for the magit function that switches branches. It
> saves the file timestamps of the current branch, switches to the other
> branch and restores the file timestamps for that branch.
> 
> Then, each branch has its own build directory.
> 
> For Emacs, this approach has the problem of having the .elc files shared
> on the source directory. A configure option for putting the .elc files
> on the build directory would fix that.

Thanks, but I don't think a VCS should dictate how I configure my
builds to such a great extent.  I'm quite sure a less invasive
solution can be found.

Re: Git transition checklist

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> I have a defadvice for the magit function that switches branches. It
>> saves the file timestamps of the current branch, switches to the other
>> branch and restores the file timestamps for that branch.
>> 
>> Then, each branch has its own build directory.
>> 
>> For Emacs, this approach has the problem of having the .elc files shared
>> on the source directory. A configure option for putting the .elc files
>> on the build directory would fix that.
>
> Thanks, but I don't think a VCS should dictate how I configure my
> builds to such a great extent. I'm quite sure a less invasive solution
> can be found.

Where is the "great extent" and how is it "invasive"? Because you need
to remove hacks from the build system and Emacs itself?

Placing build products in the source directory while doing an
out-of-source build is terrible, so the feature shouldn't exist to begin
with. If the hacker wishes to save the time of producing the .elc files,
just cp -R them to the new build directory.

Re: Git transition checklist

[Glenn Morris]

Óscar Fuentes wrote:

> Placing build products in the source directory while doing an
> out-of-source build is terrible, so the feature shouldn't exist to begin
> with. 

Then you need to provide a patch to allow the .el and .elc versions of
the same file to live in different directories, which is not something
that Emacs currently expects to happen.

Re: Git transition checklist

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 09 Jan 2014 21:12:47 +0100
> 
> > Thanks, but I don't think a VCS should dictate how I configure my
> > builds to such a great extent. I'm quite sure a less invasive solution
> > can be found.
> 
> Where is the "great extent" and how is it "invasive"? Because you need
> to remove hacks from the build system and Emacs itself?

No, because a package should support building both from its source
directory and outside it.  Every other project does.

> Placing build products in the source directory while doing an
> out-of-source build is terrible, so the feature shouldn't exist to begin
> with.

But I like it.  And it's not up to you or the VCS to educate me about
that, not at my age.

Re: Git transition checklist

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Where is the "great extent" and how is it "invasive"? Because you need
>> to remove hacks from the build system and Emacs itself?
>
> No, because a package should support building both from its source
> directory and outside it.  Every other project does.

Emacs does not really support out-of-source builds.

>> Placing build products in the source directory while doing an
>> out-of-source build is terrible, so the feature shouldn't exist to begin
>> with.
>
> But I like it.  And it's not up to you or the VCS to educate me about
> that,

Then it is unfair to blame the tool when it does not match your
personal, against-the-standard views.

> not at my age.

Age-related learning disability? Sorry to hear that.

Seriously, even if you find an acceptable workflow, supporting a true
out-of-source build (and making it the default) is something missing
from Emacs. (It looks like something I could do. Loading the .elc files
from the build directory is no problem. Adapting the build system...
<shudder>)

Re: Git transition checklist

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 09 Jan 2014 22:49:50 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Where is the "great extent" and how is it "invasive"? Because you need
> >> to remove hacks from the build system and Emacs itself?
> >
> > No, because a package should support building both from its source
> > directory and outside it.  Every other project does.
> 
> Emacs does not really support out-of-source builds.

Only when building from bzr.  Release tarballs can be built out of the
source tree.

> >> Placing build products in the source directory while doing an
> >> out-of-source build is terrible, so the feature shouldn't exist to begin
> >> with.
> >
> > But I like it.  And it's not up to you or the VCS to educate me about
> > that,
> 
> Then it is unfair to blame the tool when it does not match your
> personal, against-the-standard views.

Who blamed the tool?  I didn't.  And the "standard" does support
in-tree builds.

> Seriously, even if you find an acceptable workflow, supporting a true
> out-of-source build (and making it the default) is something missing
> from Emacs.

As Glenn already said: patches are welcome.

Re: Git transition checklist

[Eli Zaretskii]

> Date: Thu, 09 Jan 2014 18:58:46 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: esr@thyrsus.com, schwab@linux-m68k.org, emacs-devel@gnu.org
> 
> > Except: what about Windows filesystems?  I have no idea if they
> > implement hardlinks properly
> 
> Hard links are supported on NTFS.  I didn't yet try cloning locally
> though, so I don't know whether there are Windows-specific problems
> here.

Tried that now: it seems to work as expected.

Re: Git transition checklist

[Glenn Morris]

Oh look, what great timing:

https://lists.ubuntu.com/archives/bazaar/2014q1/075790.html

   I've forked Bazaar, as bzr3, in order to move the codebase to Python 3.x
   and remove things no longer required to make that effort easier.

Not dead, only sleeping?

(I know this makes no difference to anything.)

Re: Git transition checklist

[David Kastrup]

Glenn Morris <rgm@gnu.org> writes:

> Oh look, what great timing:
>
> https://lists.ubuntu.com/archives/bazaar/2014q1/075790.html
>
>    I've forked Bazaar, as bzr3, in order to move the codebase to Python 3.x
>    and remove things no longer required to make that effort easier.
>
> Not dead, only sleeping?

How is it not dead if a _fork_ appears appropriate for supporting the
current Python version?

While I don't know the circumstances involved, for a live project
porting to the current version of its language would happen in a
_branch_ of the upstream repository.

A _fork_ will take a lot of effort before it can gather the kind of
support an original project once had.

-- 
David Kastrup

Re: Git transition checklist

[Jorgen Schaefer]

On Sat, 11 Jan 2014 21:32:31 +0100
David Kastrup <dak@gnu.org> wrote:

> Glenn Morris <rgm@gnu.org> writes:
> 
> > Oh look, what great timing:
> >
> > https://lists.ubuntu.com/archives/bazaar/2014q1/075790.html
> >
> >    I've forked Bazaar, as bzr3, in order to move the codebase to
> > Python 3.x and remove things no longer required to make that effort
> > easier.
> >
> > Not dead, only sleeping?
> 
> How is it not dead if a _fork_ appears appropriate for supporting the
> current Python version?

And the fork is happening because it is easier to port bzr to py3 than
to port launchpad to git. To quote the author of that fork in the
Google Plus discussion linked from that post:

| If launchpad start to support git bzr will be either totally obsolete
| or totally replaced by bzr-with-native-git support. In either case,
| now the problem is python2 is getting deprecated and I still rely on
| bzr at work.

Regards,
Jorgen

Re: Git transition checklist

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

On Jan 12, 2014, at 11:30 AM, Jorgen Schaefer wrote:

>And the fork is happening because it is easier to port bzr to py3 than
>to port launchpad to git.

Well, I don't know that to be necessarily true, and I don't think the two
efforts are at all related.

I think it is true that there are no Canonical resources currently available
to add git support to Launchpad.  However, Launchpad is free software so
perhaps some folks in the community would be willing and able to help out with
that.  If you're interested I can point you to the right forums to get
involved.

The above referenced Python 3 port of Bazaar is certainly interesting, and it
would be a fun project to work on if I wasn't already overwhelmed with fun
projects to work on. ;)  Whether that port ends up being a fork or eventually
gets folded back into bzr mainline is something that may come up some day if
the work becomes viable.

OTOH, Bazaar is *also* free software, so like all free software, anybody with
an interest and time is welcome to fork it on their own initiative, and see
where it leads.

Cheers,
-Barry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Git transition checklist

[Glenn Morris]

Glenn Morris wrote:

> https://lists.ubuntu.com/archives/bazaar/2014q1/075790.html

And apparently GNU Bazaar has a new maintainer as well:

https://lists.ubuntu.com/archives/bazaar/2014q1/075797.html

Re: Git transition checklist

[David Kastrup]

Glenn Morris <rgm@gnu.org> writes:

> Glenn Morris wrote:
>
>> https://lists.ubuntu.com/archives/bazaar/2014q1/075790.html
>
> And apparently GNU Bazaar has a new maintainer as well:
>
> https://lists.ubuntu.com/archives/bazaar/2014q1/075797.html

    I am interested in keeping the bzr project maintained and willing to
    spend time and effort towards that goal.  I enjoy using the libré
    software bzr tool for distributed version control.

According to that mailing list thread, Richard Wilbur has been appointed
on Jan 6 by RMS as GNU Bazaar maintainer.

He announces this on Jan 13, and there is a reply by Aaron Bentley on
the same day with the text

    I'm glad you're so passionate about keeping bzr going that you're
    willing to take over as a maintainer.  Did you discuss this with the
    existing community first?

In the same thread, Aaron Bentley announces the release of BzrTools
2.6.0 on Jan 13, and Zygmunt Krynicki is announcing on Jan 11 that he is
forking Bazaar in order to make it support Python 3.0.

I don't think it is an overstatement to say that the general situation
surrounding Bazaar as well as its relations to the GNU project appear to
be rather unclear currently.

-- 
David Kastrup

Re: Git transition checklist

[Richard Stallman]

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

Bazaar was unusual as a GNU package in the past because of its close
relationship with Canonical.  Now Bazaar is like most GNU packages.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Git transition checklist

[Stefan Monnier]

> Option 1 is like a regular bzr branch: branch1's history is identical
> to trunk up to the point of cloning, after that independent of trunk.

W.r.t to Bzr's shared repository, this is different in that the sharing
is asymmetric: what you pull into "trunk" will also be available
(without re-fetching) in ws1 but not vice-versa.

Also, this comes with a big "NOTE: this is a possibly dangerous operation"
in the manpage, because "trunk" doesn't know about "ws1", so a "git gc"
in trunk (explicit or implicit) may remove revisions that are still
needed by ws1.
Bzr avoided the problem by not providing "gc".

> For more glitches, ask Stefan.

I think that covers it up.  Basically, IIUC, the rule for
git-new-workdir is "at most one workdir for a given branch".
So if you want a "second workdir" of trunk, make a new branch off of
"trunk" and then do a "new-workdir" for that new branch.


        Stefan

Re: Git transition checklist

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think that covers it up.  Basically, IIUC, the rule for
> git-new-workdir is "at most one workdir for a given branch".
> So if you want a "second workdir" of trunk, make a new branch off of
> "trunk" and then do a "new-workdir" for that new branch.

git generally favors workflows with separate (local) development
branches.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Git transition checklist

[Eli Zaretskii]

> From: esr@thyrsus.com (Eric S. Raymond)
> Date: Wed,  8 Jan 2014 08:52:00 -0500 (EST)
> 
> > 8. There's the emacs-bzr-version whose value gets copied into the bug
> >    reports.  This should be replaced by the suitable git equivalent,
> >    or else the bug reports (of which we have quite a few each day)
> >    will not identify the version correctly.
> 
> Proof of concept (tested):
> 
> (defun emacs-repository-get-version (&optional dir)
>   "Try to return as a string the version-control revision of the Emacs sources.
> Value is nil if the sources do not seem to be under version
> control, or if we could not determine the revision.  Note that
> this reports on the current state of the sources, which may not
> correspond to the running Emacs.
> 
> Optional argument DIR is a directory to use instead of `source-directory'."
>   ;; This is the only function that knows what VCS the Emacs sources are under.
>   (let ((here default-directory))
>     (cd (or dir (setq dir source-directory))) 
>     (message "Waiting for git...")
>     (with-temp-buffer
>       (if (zerop
>            (call-process "git" nil '(t nil) nil "describe" "--tags"))
>          (buffer-string)))
>     (cd here)))

If I run the above git command in the Emacs git repo, I get this:

  $ git describe --tags
  mh-e-8.5-4522-gaa5ae3b

I doubt that we want this.  We want the git sha1 value of the last
commit instead, I think.

> This code is simpler than emacs-bzr-get-version because "git describe" is
> very fast - there's no need to avoid calling it for better performance.

At least here (on MS-Windows), "git describe" is not very fast: with a
warm cache it takes 0.265 sec, with a cold cache it takes several
seconds.

But a command that prints the sha1 value should be much faster (about
30 to 45 msec here).

> The change to integrate this and fix its callers is easy, five minutes'
> work which I will cheerfully do immediately after the repo switchover.
> No need to do it before as it really only becomes crucial to have this
> working for the next point release.

No, I think it needs to be done before the first user checks out the
git repo after the switch, because that signature is important in bug
reports.  We don't want to have builds of Emacs that don't identify
the git commit they are based on, because that makes it harder to
decide whether a bug was already fixed.

So either the above function should be added to Emacs before the
switch, wrapped with some code that would activate it when git starts
to be used, or the repo should be locked for pulls for a few moments
after the switch, until the function is committed.

> Nobody else explicitly suggested any additional preconditions.

I think we have identified another one today: repack the savannah
repository, to avoid both slow initial clone and, what's more, local
repacking that is problematic on slow or low-memory machines.

Thanks.

Re: Git transition checklist

[Glenn Morris]

Eli Zaretskii wrote:

> I doubt that we want this.  We want the git sha1 value of the last
> commit instead, I think.

Which is less useful than the current bzr version, because it is
impossible to tell at a glance if one sha1 represents a later commit
than another.

Re: Git transition checklist

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 08 Jan 2014 13:29:51 -0500
> 
> Eli Zaretskii wrote:
> 
> > I doubt that we want this.  We want the git sha1 value of the last
> > commit instead, I think.
> 
> Which is less useful than the current bzr version, because it is
> impossible to tell at a glance if one sha1 represents a later commit
> than another.

Yes, I want bzr as well ;-)

Seriously, someone will surely come up with a command to show the date
of a given commit specified by its SHA1.  Not "at a glance", but
close.

Re: Git transition checklist

[Eli Zaretskii]

> Date: Wed, 08 Jan 2014 20:39:34 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Seriously, someone will surely come up with a command to show the date
> of a given commit specified by its SHA1.  Not "at a glance", but
> close.

Here, how about this, for a given SHA1-VALUE:

  git log --pretty=format:%cd $(SHA1-VALUE)^!

For the last commit:

  git log --pretty=format:%cd `git rev-parse --verify HEAD`^!

Re: Git transition checklist

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 08 Jan 2014 20:39:34 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>> 
>> Seriously, someone will surely come up with a command to show the date
>> of a given commit specified by its SHA1.  Not "at a glance", but
>> close.
>
> Here, how about this, for a given SHA1-VALUE:
>
>   git log --pretty=format:%cd $(SHA1-VALUE)^!

git log -1 seems easier...

-- 
David Kastrup

Re: Git transition checklist

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> Eli Zaretskii wrote:
>
>> I doubt that we want this.  We want the git sha1 value of the last
>> commit instead, I think.
>
> Which is less useful than the current bzr version, because it is
> impossible to tell at a glance if one sha1 represents a later commit
> than another.

git describe gives you that (the middle number is the number of commits
since the tags).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Git transition checklist

[Achim Gratz]

Eli Zaretskii writes:
> If I run the above git command in the Emacs git repo, I get this:
>
>   $ git describe --tags
>   mh-e-8.5-4522-gaa5ae3b
>
> I doubt that we want this.  We want the git sha1 value of the last
> commit instead, I think.

With annotated release tags, you should drop the --tags option and only
the annotated tags are considered:

.../emacs> git tag --annotate emacs-24.3-ann emacs-24.3
.../emacs> git describe
emacs-24.3-ann-5712-g478ff9c


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: Git transition checklist

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Wed, 08 Jan 2014 19:45:20 +0100
> 
> Eli Zaretskii writes:
> > If I run the above git command in the Emacs git repo, I get this:
> >
> >   $ git describe --tags
> >   mh-e-8.5-4522-gaa5ae3b
> >
> > I doubt that we want this.  We want the git sha1 value of the last
> > commit instead, I think.
> 
> With annotated release tags, you should drop the --tags option and only
> the annotated tags are considered:
> 
> .../emacs> git tag --annotate emacs-24.3-ann emacs-24.3
> .../emacs> git describe
> emacs-24.3-ann-5712-g478ff9c

I still don't see why not use 'git log' for this purpose.  We don't
want a description of the branch, we want the ID of the last commit on
which the build is based.  Using that, one can easily identify what
was in the tree.

Re: Git transition checklist

[Achim Gratz]

Eli Zaretskii writes:
>> .../emacs> git tag --annotate emacs-24.3-ann emacs-24.3
>> .../emacs> git describe
>> emacs-24.3-ann-5712-g478ff9c
>
> I still don't see why not use 'git log' for this purpose.

Didn't you say you wanted to see at a glance which commit comes later?
The above gives you that information: we are 5712 commits past release
emacs-24.3-ann and the SHA1 of the commit starts with 478ff9c (where to
truncate the SHA1 can be controlled by the --abbrev option).

> We don't want a description of the branch, we want the ID of the last
> commit on which the build is based.  Using that, one can easily
> identify what was in the tree.

You have that information, plus some more.  If you really just want the
(abbreviated) SHA1, then:

git show --format=format:%h --no-patch

does that without much fuzz (if you want a trailing newline, then the
format should be "%h%n".


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Git transition checklist

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> If I run the above git command in the Emacs git repo, I get this:
>
>   $ git describe --tags
>   mh-e-8.5-4522-gaa5ae3b
>
> I doubt that we want this.  We want the git sha1 value of the last
> commit instead, I think.

That's the g.... part (strip off the leading g).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Git transition checklist

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> If I run the above git command in the Emacs git repo, I get this:
> 
>   $ git describe --tags
>   mh-e-8.5-4522-gaa5ae3b
> 
> I doubt that we want this.  We want the git sha1 value of the last
> commit instead, I think.

Why?  If the repo has proper release tags (which it will - I'm going to
do that), knowing the offset from the last release conveys more information
than a lump of SHA1.

> At least here (on MS-Windows), "git describe" is not very fast: with a
> warm cache it takes 0.265 sec, with a cold cache it takes several
> seconds.
> 
> But a command that prints the sha1 value should be much faster (about
> 30 to 45 msec here).

Performance may be an overriding factor her, but I'd prefer we think
about the use cases for the information and decide what we'd *like*
it to do first.

> > The change to integrate this and fix its callers is easy, five minutes'
> > work which I will cheerfully do immediately after the repo switchover.
> > No need to do it before as it really only becomes crucial to have this
> > working for the next point release.
> 
> No, I think it needs to be done before the first user checks out the
> git repo after the switch, because that signature is important in bug
> reports.  We don't want to have builds of Emacs that don't identify
> the git commit they are based on, because that makes it harder to
> decide whether a bug was already fixed.
> 
> So either the above function should be added to Emacs before the
> switch, wrapped with some code that would activate it when git starts
> to be used, or the repo should be locked for pulls for a few moments
> after the switch, until the function is committed.

Very well. One of these things can be made to happen; I'll ensure
the transition plan spells this out.

> > Nobody else explicitly suggested any additional preconditions.
> 
> I think we have identified another one today: repack the savannah
> repository, to avoid both slow initial clone and, what's more, local
> repacking that is problematic on slow or low-memory machines.

Right, and I saw the mail about where to post that request, too.  I
expect one of the people having performance problems will do that.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Git transition checklist

[Eli Zaretskii]

> Date: Wed, 8 Jan 2014 15:11:04 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org>:
> > If I run the above git command in the Emacs git repo, I get this:
> > 
> >   $ git describe --tags
> >   mh-e-8.5-4522-gaa5ae3b
> > 
> > I doubt that we want this.  We want the git sha1 value of the last
> > commit instead, I think.
> 
> Why?  If the repo has proper release tags (which it will - I'm going to
> do that), knowing the offset from the last release conveys more information
> than a lump of SHA1.

"Proper release tags" are something for humans to remember doing, and
so is unreliable.

If we want more information, we can make "git log" command that will
provide that, e.g., the commit date and time.

And of course what you call "the lump of SHA1" is the most beautiful
thing in the whole world, so why should we be shy of that?

Re: Git transition checklist

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> "Proper release tags" are something for humans to remember doing, and
> so is unreliable.

Huh? Emacs release don't happen so often, or with so little ceremony,
that we can expect that step to get skipped once it becomes policy.

> And of course what you call "the lump of SHA1" is the most beautiful
> thing in the whole world, so why should we be shy of that?

Your sense of humor is too dry for me.  I think I'll go slug down
some limeade.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Git transition checklist

[Eli Zaretskii]

> Date: Wed, 8 Jan 2014 15:28:24 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org>:
> > "Proper release tags" are something for humans to remember doing, and
> > so is unreliable.
> 
> Huh? Emacs release don't happen so often, or with so little ceremony,
> that we can expect that step to get skipped once it becomes policy.

Policy or not, we had this kind of mistakes in the past (releases and
branches that did not get proper tags).  I see no reason why these
will not be repeated.

> Your sense of humor is too dry for me.

Sorry about that.

Re: Git transition checklist

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> > Huh? Emacs release don't happen so often, or with so little ceremony,
> > that we can expect that step to get skipped once it becomes policy.
> 
> Policy or not, we had this kind of mistakes in the past (releases and
> branches that did not get proper tags).  I see no reason why these
> will not be repeated.

Maybe not, but mussing a tag is also very easy to cirrect retroactively.

> > Your sense of humor is too dry for me.
> 
> Sorry about that.

Um.  That was a joke.  Partly. :-)
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Git transition checklist

[Eli Zaretskii]

> Date: Wed, 8 Jan 2014 16:26:00 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org>:
> > > Huh? Emacs release don't happen so often, or with so little ceremony,
> > > that we can expect that step to get skipped once it becomes policy.
> > 
> > Policy or not, we had this kind of mistakes in the past (releases and
> > branches that did not get proper tags).  I see no reason why these
> > will not be repeated.
> 
> Maybe not, but mussing a tag is also very easy to cirrect retroactively.

But until it is corrected, the revision descriptions based on tags lie
about where they are, unless you count the commits by hand to compare
them with.

Re: Git transition checklist

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> And of course what you call "the lump of SHA1" is the most beautiful
> thing in the whole world, so why should we be shy of that?

It's ugly but that's irrelevant since you never type them off.  It's
copy&paste material and reliable when used like that.

-- 
David Kastrup

Re: Git transition checklist

[Eli Zaretskii]

> From: esr@thyrsus.com (Eric S. Raymond)
> Date: Wed,  8 Jan 2014 08:52:00 -0500 (EST)
> 
> > 5. Have the procedures and the recommended workflows described on the
> >    wiki, similar to what was done with bzr migration.
> 
> That is now done.  I have created two new pages on EmacsWiki,
> GitForEmacsDevs and GitQuickStartForEmacsDevs. These are adapted from
> the corresponding *Bzr* pages but describe git commands to perform
> equivalent operations.

Thanks.  I have some comments/questions on that:

 . The section about merging to the upstream master seems to omit "git
   push" after merging the task onto the master branch.  It ends with
   the "git commit" command, which AFAIK is not the end of the story.

 . The few places that describe a merge from another branch seem to
   say that one needs to issue 2 commands: "git merge" and "git commit".
   Perhaps I'm confused, but isn't it true that "git merge"
   automatically commits if there are no conflicts?  If I'm right, an
   explicit commit is needed after merge only when there are conflicts
   to be resolved.

   For the same reason, is "git revert" TRT when a push upstream fails
   after a merge from the local task branch, because someone else
   pushed meanwhile?  The merge is already committed locally, so what
   will revert do?  I think one will need "git reset" in this case.

 . I would suggest describing the setup of git-merge-changelog,
   because as long as we keep ChangeLog files in the repository,
   people might bump into conflicts in the logs, and it would be nice
   to avoid that.

 . I think we should discuss some more how to work with the
   development trunk and the release branch in parallel, and reflect
   the results of the discussion in the Wiki.

   The issue here is that the release branch and the trunk diverge
   very quickly after the branch point, and the result is that after
   you checkout the other branch, you generally need a very long
   build, many times a full bootstrap.  While on a modern system, a
   full bootstrap should take a few minutes, it is still annoyingly
   long, and makes higher the risk of losing the race against other
   committers.  In addition, you only have a single executable at any
   given time, so comparison of behavior between the two branches is
   difficult.

   So perhaps we should find a way of having two separate branches,
   such that switching between them does not require a build if
   nothing changed.

> The only omission is that I left out the git equivalent of bzr bundle.

I think the section about publishing a task was also omitted.  Was
that on purpose?

> An interesting side effect of doing this translation, by the way, is
> that I now know the exact git-command equivalents for the recommended
> workflow in Bazaar.  Rather to my surprise, the git procedures are
> simpler!
> 
> I'm surprised at this because Bazaar, whatever its other failings, had
> a reputation as being simpler to use than git which I believed was
> deserved. But, at least for the workflows described, git avoids so
> much complexity and ceremony by not having the branch-vs.-repo
> distinction that the gain from this swamps git's other UI
> shortcomings.

Can we please stop the apology and concentrate on the task at hand?
This kind of comments can only annoy those who are still in mourning
of the need to switch.  (And no, I don't see how the git procedures
are simpler, except due to some omissions and non-existent features,
they are roughly the same.)

Re: Git transition checklist

[Stefan Monnier]

>  . I think we should discuss some more how to work with the
>    development trunk and the release branch in parallel, and reflect
>    the results of the discussion in the Wiki.

Right, there's also the bzrmerge.el thingy that needs to be ported to Git.

>    So perhaps we should find a way of having two separate branches,
>    such that switching between them does not require a build if
>    nothing changed.

Currently, you'll be better off not using "colocated branches" but two
separate Git trees.  To the extent that most .el files will change
between the two branches, a "git checkout" will be followed by a the
equivalent of a full bootstrap (and will probably always require "make
bootstrap" when switching from the release branch to the trunk).


        Stefan

Re: Git transition checklist

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: esr@thyrsus.com (Eric S. Raymond),  emacs-devel@gnu.org
> Date: Wed, 08 Jan 2014 16:07:46 -0500
> 
> Currently, you'll be better off not using "colocated branches" but two
> separate Git trees.

OK, but then we should say something about "git remote" commands that
are needed to work with such two repositories, I think, and a few
others (perhaps "git fetch"?).

Re: Git transition checklist

[Angelo Graziosi]

Dear Emacs maintainers, out of curiosity..

Richard Stallman wrote:
> Bazaar was unusual as a GNU package in the past because of its close
> relationship with Canonical.  Now Bazaar is like most GNU packages.


Hmm... What does this mean? Git transition has been stopped? All the 
discussions about BZR --> GIT decay ended with a stalemate?


Ciao,
  Angelo.

Re: Git transition checklist

[Richard Stallman]

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

    Hmm... What does this mean? Git transition has been stopped?

Please don't make guesses based on big leaps.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.