* Re: Git transition checklist
2014-01-08 13:52 Git transition checklist Eric S. Raymond
@ 2014-01-08 14:59 ` Stefan Monnier
2014-01-08 16:35 ` Rüdiger Sonderfeld
` (2 more replies)
2014-01-08 15:02 ` Stephen Berman
` (5 subsequent siblings)
6 siblings, 3 replies; 130+ messages in thread
From: Stefan Monnier @ 2014-01-08 14:59 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 14:59 ` Stefan Monnier
@ 2014-01-08 16:35 ` Rüdiger Sonderfeld
2014-01-08 17:12 ` Stefan Monnier
2014-01-08 16:48 ` Git transition checklist Eric S. Raymond
2014-01-08 18:02 ` Eli Zaretskii
2 siblings, 1 reply; 130+ messages in thread
From: Rüdiger Sonderfeld @ 2014-01-08 16:35 UTC (permalink / raw)
To: emacs-devel; +Cc: Eric S. Raymond, Stefan Monnier
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 16:35 ` Rüdiger Sonderfeld
@ 2014-01-08 17:12 ` Stefan Monnier
2014-01-08 18:08 ` Rüdiger Sonderfeld
0 siblings, 1 reply; 130+ messages in thread
From: Stefan Monnier @ 2014-01-08 17:12 UTC (permalink / raw)
To: Rüdiger Sonderfeld; +Cc: Eric S. Raymond, emacs-devel
> 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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 17:12 ` Stefan Monnier
@ 2014-01-08 18:08 ` Rüdiger Sonderfeld
2014-01-08 18:21 ` Improved git commit emails [was Re: Git transition checklist] Glenn Morris
0 siblings, 1 reply; 130+ messages in thread
From: Rüdiger Sonderfeld @ 2014-01-08 18:08 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Eric S. Raymond, emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Improved git commit emails [was Re: Git transition checklist]
2014-01-08 18:08 ` Rüdiger Sonderfeld
@ 2014-01-08 18:21 ` Glenn Morris
2014-01-08 18:31 ` Ted Zlatanov
0 siblings, 1 reply; 130+ messages in thread
From: Glenn Morris @ 2014-01-08 18:21 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Improved git commit emails [was Re: Git transition checklist]
2014-01-08 18:21 ` Improved git commit emails [was Re: Git transition checklist] Glenn Morris
@ 2014-01-08 18:31 ` Ted Zlatanov
2014-01-08 18:37 ` Improved git commit emails Glenn Morris
0 siblings, 1 reply; 130+ messages in thread
From: Ted Zlatanov @ 2014-01-08 18:31 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Improved git commit emails
2014-01-08 18:31 ` Ted Zlatanov
@ 2014-01-08 18:37 ` Glenn Morris
2014-01-08 21:04 ` Ted Zlatanov
0 siblings, 1 reply; 130+ messages in thread
From: Glenn Morris @ 2014-01-08 18:37 UTC (permalink / raw)
To: 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.
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. :)
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Improved git commit emails
2014-01-08 18:37 ` Improved git commit emails Glenn Morris
@ 2014-01-08 21:04 ` Ted Zlatanov
2014-01-12 5:44 ` Bob Proulx
0 siblings, 1 reply; 130+ messages in thread
From: Ted Zlatanov @ 2014-01-08 21:04 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Improved git commit emails
2014-01-08 21:04 ` Ted Zlatanov
@ 2014-01-12 5:44 ` Bob Proulx
2014-01-13 2:22 ` Glenn Morris
0 siblings, 1 reply; 130+ messages in thread
From: Bob Proulx @ 2014-01-12 5:44 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Improved git commit emails
2014-01-12 5:44 ` Bob Proulx
@ 2014-01-13 2:22 ` Glenn Morris
2014-01-15 2:10 ` Bob Proulx
0 siblings, 1 reply; 130+ messages in thread
From: Glenn Morris @ 2014-01-13 2:22 UTC (permalink / raw)
To: Bob Proulx; +Cc: emacs-devel
Thanks very much Bob.
Waiting for the next elpa commit to see how it looks...
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Improved git commit emails
2014-01-13 2:22 ` Glenn Morris
@ 2014-01-15 2:10 ` Bob Proulx
2014-01-15 7:35 ` Glenn Morris
0 siblings, 1 reply; 130+ messages in thread
From: Bob Proulx @ 2014-01-15 2:10 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Improved git commit emails
2014-01-15 2:10 ` Bob Proulx
@ 2014-01-15 7:35 ` Glenn Morris
2014-01-20 1:09 ` Bob Proulx
0 siblings, 1 reply; 130+ messages in thread
From: Glenn Morris @ 2014-01-15 7:35 UTC (permalink / raw)
To: emacs-devel
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?
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Improved git commit emails
2014-01-15 7:35 ` Glenn Morris
@ 2014-01-20 1:09 ` Bob Proulx
2014-01-20 2:16 ` Stephen J. Turnbull
` (2 more replies)
0 siblings, 3 replies; 130+ messages in thread
From: Bob Proulx @ 2014-01-20 1:09 UTC (permalink / raw)
To: emacs-devel, Glenn Morris
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Improved git commit emails
2014-01-20 1:09 ` Bob Proulx
@ 2014-01-20 2:16 ` Stephen J. Turnbull
2014-01-20 4:27 ` Bob Proulx
2014-01-22 19:20 ` Glenn Morris
2014-01-23 18:42 ` Rüdiger Sonderfeld
2 siblings, 1 reply; 130+ messages in thread
From: Stephen J. Turnbull @ 2014-01-20 2:16 UTC (permalink / raw)
To: Bob Proulx; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Improved git commit emails
2014-01-20 2:16 ` Stephen J. Turnbull
@ 2014-01-20 4:27 ` Bob Proulx
0 siblings, 0 replies; 130+ messages in thread
From: Bob Proulx @ 2014-01-20 4:27 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Improved git commit emails
2014-01-20 1:09 ` Bob Proulx
2014-01-20 2:16 ` Stephen J. Turnbull
@ 2014-01-22 19:20 ` Glenn Morris
2014-01-23 18:42 ` Rüdiger Sonderfeld
2 siblings, 0 replies; 130+ messages in thread
From: Glenn Morris @ 2014-01-22 19:20 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Improved git commit emails
2014-01-20 1:09 ` Bob Proulx
2014-01-20 2:16 ` Stephen J. Turnbull
2014-01-22 19:20 ` Glenn Morris
@ 2014-01-23 18:42 ` Rüdiger Sonderfeld
2014-01-28 23:45 ` Bob Proulx
2 siblings, 1 reply; 130+ messages in thread
From: Rüdiger Sonderfeld @ 2014-01-23 18:42 UTC (permalink / raw)
To: emacs-devel; +Cc: Bob Proulx
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Improved git commit emails
2014-01-23 18:42 ` Rüdiger Sonderfeld
@ 2014-01-28 23:45 ` Bob Proulx
2014-01-29 0:57 ` Glenn Morris
0 siblings, 1 reply; 130+ messages in thread
From: Bob Proulx @ 2014-01-28 23:45 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Improved git commit emails
2014-01-28 23:45 ` Bob Proulx
@ 2014-01-29 0:57 ` Glenn Morris
2014-01-31 0:41 ` Bob Proulx
0 siblings, 1 reply; 130+ messages in thread
From: Glenn Morris @ 2014-01-29 0:57 UTC (permalink / raw)
To: emacs-devel
Please don't spend too much time and effort on what may well be only my
personal preference.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Improved git commit emails
2014-01-29 0:57 ` Glenn Morris
@ 2014-01-31 0:41 ` Bob Proulx
0 siblings, 0 replies; 130+ messages in thread
From: Bob Proulx @ 2014-01-31 0:41 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 14:59 ` Stefan Monnier
2014-01-08 16:35 ` Rüdiger Sonderfeld
@ 2014-01-08 16:48 ` Eric S. Raymond
2014-01-08 17:19 ` Stefan Monnier
2014-01-08 17:49 ` Glenn Morris
2014-01-08 18:02 ` Eli Zaretskii
2 siblings, 2 replies; 130+ messages in thread
From: Eric S. Raymond @ 2014-01-08 16:48 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
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>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 16:48 ` Git transition checklist Eric S. Raymond
@ 2014-01-08 17:19 ` Stefan Monnier
2014-01-08 18:43 ` Andreas Schwab
2014-01-08 19:17 ` Eric S. Raymond
2014-01-08 17:49 ` Glenn Morris
1 sibling, 2 replies; 130+ messages in thread
From: Stefan Monnier @ 2014-01-08 17:19 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 17:19 ` Stefan Monnier
@ 2014-01-08 18:43 ` Andreas Schwab
2014-01-08 19:02 ` Glenn Morris
2014-01-08 19:17 ` Eric S. Raymond
1 sibling, 1 reply; 130+ messages in thread
From: Andreas Schwab @ 2014-01-08 18:43 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Eric S. Raymond, emacs-devel
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."
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 17:19 ` Stefan Monnier
2014-01-08 18:43 ` Andreas Schwab
@ 2014-01-08 19:17 ` Eric S. Raymond
1 sibling, 0 replies; 130+ messages in thread
From: Eric S. Raymond @ 2014-01-08 19:17 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
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>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 16:48 ` Git transition checklist Eric S. Raymond
2014-01-08 17:19 ` Stefan Monnier
@ 2014-01-08 17:49 ` Glenn Morris
1 sibling, 0 replies; 130+ messages in thread
From: Glenn Morris @ 2014-01-08 17:49 UTC (permalink / raw)
To: emacs-devel
"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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 14:59 ` Stefan Monnier
2014-01-08 16:35 ` Rüdiger Sonderfeld
2014-01-08 16:48 ` Git transition checklist Eric S. Raymond
@ 2014-01-08 18:02 ` Eli Zaretskii
2014-01-08 18:17 ` David Engster
2014-01-08 18:41 ` Andreas Schwab
2 siblings, 2 replies; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-08 18:02 UTC (permalink / raw)
To: Stefan Monnier; +Cc: esr, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:02 ` Eli Zaretskii
@ 2014-01-08 18:17 ` David Engster
2014-01-08 18:36 ` Eli Zaretskii
2014-01-08 18:41 ` Andreas Schwab
1 sibling, 1 reply; 130+ messages in thread
From: David Engster @ 2014-01-08 18:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: esr, Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:17 ` David Engster
@ 2014-01-08 18:36 ` Eli Zaretskii
2014-01-08 19:07 ` Andreas Schwab
2014-01-08 19:16 ` David Engster
0 siblings, 2 replies; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-08 18:36 UTC (permalink / raw)
To: David Engster; +Cc: esr, monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:36 ` Eli Zaretskii
@ 2014-01-08 19:07 ` Andreas Schwab
2014-01-08 19:16 ` David Engster
1 sibling, 0 replies; 130+ messages in thread
From: Andreas Schwab @ 2014-01-08 19:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: esr, monnier, David Engster, emacs-devel
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."
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:36 ` Eli Zaretskii
2014-01-08 19:07 ` Andreas Schwab
@ 2014-01-08 19:16 ` David Engster
1 sibling, 0 replies; 130+ messages in thread
From: David Engster @ 2014-01-08 19:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: esr, monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:02 ` Eli Zaretskii
2014-01-08 18:17 ` David Engster
@ 2014-01-08 18:41 ` Andreas Schwab
2014-01-08 18:48 ` Eli Zaretskii
1 sibling, 1 reply; 130+ messages in thread
From: Andreas Schwab @ 2014-01-08 18:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: esr, Stefan Monnier, emacs-devel
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."
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:41 ` Andreas Schwab
@ 2014-01-08 18:48 ` Eli Zaretskii
2014-01-08 19:19 ` Andreas Schwab
0 siblings, 1 reply; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-08 18:48 UTC (permalink / raw)
To: Andreas Schwab; +Cc: esr, monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:48 ` Eli Zaretskii
@ 2014-01-08 19:19 ` Andreas Schwab
0 siblings, 0 replies; 130+ messages in thread
From: Andreas Schwab @ 2014-01-08 19:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: esr, monnier, emacs-devel
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."
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 13:52 Git transition checklist Eric S. Raymond
2014-01-08 14:59 ` Stefan Monnier
@ 2014-01-08 15:02 ` Stephen Berman
2014-01-08 16:26 ` Eric S. Raymond
2014-01-08 15:33 ` Git transition checklist Bastien
` (4 subsequent siblings)
6 siblings, 1 reply; 130+ messages in thread
From: Stephen Berman @ 2014-01-08 15:02 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 15:02 ` Stephen Berman
@ 2014-01-08 16:26 ` Eric S. Raymond
2014-01-08 16:37 ` Git repack on Savannah [was: Re: Git transition checklist] James Cloos
0 siblings, 1 reply; 130+ messages in thread
From: Eric S. Raymond @ 2014-01-08 16:26 UTC (permalink / raw)
To: Stephen Berman; +Cc: emacs-devel
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>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Git repack on Savannah [was: Re: Git transition checklist]
2014-01-08 16:26 ` Eric S. Raymond
@ 2014-01-08 16:37 ` James Cloos
2014-01-12 6:11 ` Bob Proulx
0 siblings, 1 reply; 130+ messages in thread
From: James Cloos @ 2014-01-08 16:37 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: Stephen Berman, emacs-devel
>>>>> "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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git repack on Savannah [was: Re: Git transition checklist]
2014-01-08 16:37 ` Git repack on Savannah [was: Re: Git transition checklist] James Cloos
@ 2014-01-12 6:11 ` Bob Proulx
2014-01-12 15:59 ` Eli Zaretskii
0 siblings, 1 reply; 130+ messages in thread
From: Bob Proulx @ 2014-01-12 6:11 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 13:52 Git transition checklist Eric S. Raymond
2014-01-08 14:59 ` Stefan Monnier
2014-01-08 15:02 ` Stephen Berman
@ 2014-01-08 15:33 ` Bastien
2014-01-08 16:19 ` Eric S. Raymond
2014-01-08 15:34 ` Bastien
` (3 subsequent siblings)
6 siblings, 1 reply; 130+ messages in thread
From: Bastien @ 2014-01-08 15:33 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 15:33 ` Git transition checklist Bastien
@ 2014-01-08 16:19 ` Eric S. Raymond
2014-01-08 16:20 ` Bastien
` (2 more replies)
0 siblings, 3 replies; 130+ messages in thread
From: Eric S. Raymond @ 2014-01-08 16:19 UTC (permalink / raw)
To: Bastien; +Cc: emacs-devel
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>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 16:19 ` Eric S. Raymond
@ 2014-01-08 16:20 ` Bastien
2014-01-08 17:48 ` Glenn Morris
2014-01-12 20:15 ` Bob Proulx
2 siblings, 0 replies; 130+ messages in thread
From: Bastien @ 2014-01-08 16:20 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: emacs-devel
"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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 16:19 ` Eric S. Raymond
2014-01-08 16:20 ` Bastien
@ 2014-01-08 17:48 ` Glenn Morris
2014-01-08 18:15 ` Dani Moncayo
2014-01-08 18:23 ` Andreas Schwab
2014-01-12 20:15 ` Bob Proulx
2 siblings, 2 replies; 130+ messages in thread
From: Glenn Morris @ 2014-01-08 17:48 UTC (permalink / raw)
To: esr; +Cc: Bastien, emacs-devel
"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).
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 17:48 ` Glenn Morris
@ 2014-01-08 18:15 ` Dani Moncayo
2014-01-08 18:22 ` Glenn Morris
2014-01-08 18:23 ` Andreas Schwab
1 sibling, 1 reply; 130+ messages in thread
From: Dani Moncayo @ 2014-01-08 18:15 UTC (permalink / raw)
To: Glenn Morris; +Cc: Emacs development discussions
> 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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 17:48 ` Glenn Morris
2014-01-08 18:15 ` Dani Moncayo
@ 2014-01-08 18:23 ` Andreas Schwab
2014-01-08 18:26 ` Glenn Morris
1 sibling, 1 reply; 130+ messages in thread
From: Andreas Schwab @ 2014-01-08 18:23 UTC (permalink / raw)
To: Glenn Morris; +Cc: esr, Bastien, emacs-devel
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."
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:23 ` Andreas Schwab
@ 2014-01-08 18:26 ` Glenn Morris
2014-01-08 18:50 ` Stefan Monnier
2014-01-08 19:11 ` Andreas Schwab
0 siblings, 2 replies; 130+ messages in thread
From: Glenn Morris @ 2014-01-08 18:26 UTC (permalink / raw)
To: emacs-devel
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?
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:26 ` Glenn Morris
@ 2014-01-08 18:50 ` Stefan Monnier
2014-01-08 19:00 ` Glenn Morris
2014-01-08 19:11 ` Andreas Schwab
1 sibling, 1 reply; 130+ messages in thread
From: Stefan Monnier @ 2014-01-08 18:50 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:26 ` Glenn Morris
2014-01-08 18:50 ` Stefan Monnier
@ 2014-01-08 19:11 ` Andreas Schwab
2014-01-08 19:16 ` Glenn Morris
1 sibling, 1 reply; 130+ messages in thread
From: Andreas Schwab @ 2014-01-08 19:11 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
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."
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 19:11 ` Andreas Schwab
@ 2014-01-08 19:16 ` Glenn Morris
2014-01-08 19:46 ` Stefan Monnier
2014-01-08 23:07 ` Dani Moncayo
0 siblings, 2 replies; 130+ messages in thread
From: Glenn Morris @ 2014-01-08 19:16 UTC (permalink / raw)
To: Andreas Schwab; +Cc: emacs-devel
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?".)
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 19:16 ` Glenn Morris
@ 2014-01-08 19:46 ` Stefan Monnier
2014-01-08 23:07 ` Dani Moncayo
1 sibling, 0 replies; 130+ messages in thread
From: Stefan Monnier @ 2014-01-08 19:46 UTC (permalink / raw)
To: Glenn Morris; +Cc: Andreas Schwab, emacs-devel
> (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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 19:16 ` Glenn Morris
2014-01-08 19:46 ` Stefan Monnier
@ 2014-01-08 23:07 ` Dani Moncayo
1 sibling, 0 replies; 130+ messages in thread
From: Dani Moncayo @ 2014-01-08 23:07 UTC (permalink / raw)
To: Glenn Morris; +Cc: Andreas Schwab, Emacs development discussions
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 16:19 ` Eric S. Raymond
2014-01-08 16:20 ` Bastien
2014-01-08 17:48 ` Glenn Morris
@ 2014-01-12 20:15 ` Bob Proulx
2014-01-13 10:50 ` Bastien
2 siblings, 1 reply; 130+ messages in thread
From: Bob Proulx @ 2014-01-12 20:15 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-12 20:15 ` Bob Proulx
@ 2014-01-13 10:50 ` Bastien
0 siblings, 0 replies; 130+ messages in thread
From: Bastien @ 2014-01-13 10:50 UTC (permalink / raw)
To: Bob Proulx; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 13:52 Git transition checklist Eric S. Raymond
` (2 preceding siblings ...)
2014-01-08 15:33 ` Git transition checklist Bastien
@ 2014-01-08 15:34 ` Bastien
2014-01-08 16:13 ` Eric S. Raymond
2014-01-08 17:47 ` Glenn Morris
` (2 subsequent siblings)
6 siblings, 1 reply; 130+ messages in thread
From: Bastien @ 2014-01-08 15:34 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 13:52 Git transition checklist Eric S. Raymond
` (3 preceding siblings ...)
2014-01-08 15:34 ` Bastien
@ 2014-01-08 17:47 ` Glenn Morris
2014-01-08 20:02 ` Eric S. Raymond
2014-01-08 18:14 ` Eli Zaretskii
2014-01-08 20:52 ` Eli Zaretskii
6 siblings, 1 reply; 130+ messages in thread
From: Glenn Morris @ 2014-01-08 17:47 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 17:47 ` Glenn Morris
@ 2014-01-08 20:02 ` Eric S. Raymond
2014-01-08 20:19 ` Eli Zaretskii
2014-01-09 2:12 ` Glenn Morris
0 siblings, 2 replies; 130+ messages in thread
From: Eric S. Raymond @ 2014-01-08 20:02 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
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>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 20:02 ` Eric S. Raymond
@ 2014-01-08 20:19 ` Eli Zaretskii
2014-01-08 21:10 ` Andreas Schwab
` (3 more replies)
2014-01-09 2:12 ` Glenn Morris
1 sibling, 4 replies; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-08 20:19 UTC (permalink / raw)
To: esr; +Cc: emacs-devel
> 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.)
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 20:19 ` Eli Zaretskii
@ 2014-01-08 21:10 ` Andreas Schwab
2014-01-09 0:54 ` James Cloos
2014-01-09 0:51 ` James Cloos
` (2 subsequent siblings)
3 siblings, 1 reply; 130+ messages in thread
From: Andreas Schwab @ 2014-01-08 21:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: esr, emacs-devel
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."
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 21:10 ` Andreas Schwab
@ 2014-01-09 0:54 ` James Cloos
2014-01-09 1:23 ` Rüdiger Sonderfeld
0 siblings, 1 reply; 130+ messages in thread
From: James Cloos @ 2014-01-09 0:54 UTC (permalink / raw)
To: emacs-devel; +Cc: esr, Eli Zaretskii, Andreas Schwab
>>>>> "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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 0:54 ` James Cloos
@ 2014-01-09 1:23 ` Rüdiger Sonderfeld
2014-01-09 6:38 ` Eli Zaretskii
0 siblings, 1 reply; 130+ messages in thread
From: Rüdiger Sonderfeld @ 2014-01-09 1:23 UTC (permalink / raw)
To: emacs-devel; +Cc: esr, Eli Zaretskii, Andreas Schwab, James Cloos
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 1:23 ` Rüdiger Sonderfeld
@ 2014-01-09 6:38 ` Eli Zaretskii
0 siblings, 0 replies; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-09 6:38 UTC (permalink / raw)
To: Rüdiger Sonderfeld; +Cc: esr, schwab, cloos, emacs-devel
> 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".
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 20:19 ` Eli Zaretskii
2014-01-08 21:10 ` Andreas Schwab
@ 2014-01-09 0:51 ` James Cloos
2014-01-09 1:36 ` Rüdiger Sonderfeld
2014-01-09 1:53 ` Glenn Morris
3 siblings, 0 replies; 130+ messages in thread
From: James Cloos @ 2014-01-09 0:51 UTC (permalink / raw)
To: emacs-devel; +Cc: esr, Eli Zaretskii
>>>>> "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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 20:19 ` Eli Zaretskii
2014-01-08 21:10 ` Andreas Schwab
2014-01-09 0:51 ` James Cloos
@ 2014-01-09 1:36 ` Rüdiger Sonderfeld
2014-01-09 1:48 ` Rüdiger Sonderfeld
2014-01-09 1:53 ` Glenn Morris
3 siblings, 1 reply; 130+ messages in thread
From: Rüdiger Sonderfeld @ 2014-01-09 1:36 UTC (permalink / raw)
To: emacs-devel, Eli Zaretskii; +Cc: esr
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 1:36 ` Rüdiger Sonderfeld
@ 2014-01-09 1:48 ` Rüdiger Sonderfeld
2014-01-09 6:41 ` Eli Zaretskii
0 siblings, 1 reply; 130+ messages in thread
From: Rüdiger Sonderfeld @ 2014-01-09 1:48 UTC (permalink / raw)
To: emacs-devel; +Cc: esr, Eli Zaretskii
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 1:48 ` Rüdiger Sonderfeld
@ 2014-01-09 6:41 ` Eli Zaretskii
2014-01-09 11:10 ` Andreas Schwab
2014-01-09 11:53 ` Rüdiger Sonderfeld
0 siblings, 2 replies; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-09 6:41 UTC (permalink / raw)
To: Rüdiger Sonderfeld; +Cc: esr, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 6:41 ` Eli Zaretskii
@ 2014-01-09 11:10 ` Andreas Schwab
2014-01-09 16:17 ` Eli Zaretskii
2014-01-09 11:53 ` Rüdiger Sonderfeld
1 sibling, 1 reply; 130+ messages in thread
From: Andreas Schwab @ 2014-01-09 11:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Rüdiger Sonderfeld, esr, emacs-devel
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."
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 11:10 ` Andreas Schwab
@ 2014-01-09 16:17 ` Eli Zaretskii
2014-01-09 16:45 ` Rüdiger Sonderfeld
0 siblings, 1 reply; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-09 16:17 UTC (permalink / raw)
To: Andreas Schwab; +Cc: ruediger, esr, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 16:17 ` Eli Zaretskii
@ 2014-01-09 16:45 ` Rüdiger Sonderfeld
2014-01-09 17:44 ` Eli Zaretskii
0 siblings, 1 reply; 130+ messages in thread
From: Rüdiger Sonderfeld @ 2014-01-09 16:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: esr, Andreas Schwab, emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 16:45 ` Rüdiger Sonderfeld
@ 2014-01-09 17:44 ` Eli Zaretskii
0 siblings, 0 replies; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-09 17:44 UTC (permalink / raw)
To: Rüdiger Sonderfeld; +Cc: esr, schwab, emacs-devel
> 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).
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 6:41 ` Eli Zaretskii
2014-01-09 11:10 ` Andreas Schwab
@ 2014-01-09 11:53 ` Rüdiger Sonderfeld
1 sibling, 0 replies; 130+ messages in thread
From: Rüdiger Sonderfeld @ 2014-01-09 11:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: esr, emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 20:19 ` Eli Zaretskii
` (2 preceding siblings ...)
2014-01-09 1:36 ` Rüdiger Sonderfeld
@ 2014-01-09 1:53 ` Glenn Morris
2014-01-09 2:13 ` Glenn Morris
3 siblings, 1 reply; 130+ messages in thread
From: Glenn Morris @ 2014-01-09 1:53 UTC (permalink / raw)
To: emacs-devel
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 .
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 20:02 ` Eric S. Raymond
2014-01-08 20:19 ` Eli Zaretskii
@ 2014-01-09 2:12 ` Glenn Morris
2014-01-09 4:27 ` Stephen J. Turnbull
1 sibling, 1 reply; 130+ messages in thread
From: Glenn Morris @ 2014-01-09 2:12 UTC (permalink / raw)
To: esr; +Cc: emacs-devel
"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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 2:12 ` Glenn Morris
@ 2014-01-09 4:27 ` Stephen J. Turnbull
2014-01-09 7:05 ` Eli Zaretskii
2014-01-09 15:12 ` Stefan Monnier
0 siblings, 2 replies; 130+ messages in thread
From: Stephen J. Turnbull @ 2014-01-09 4:27 UTC (permalink / raw)
To: Glenn Morris; +Cc: esr, emacs-devel
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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 4:27 ` Stephen J. Turnbull
@ 2014-01-09 7:05 ` Eli Zaretskii
2014-01-09 8:14 ` Stephen J. Turnbull
2014-01-09 15:12 ` Stefan Monnier
1 sibling, 1 reply; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-09 7:05 UTC (permalink / raw)
To: Stephen J. Turnbull; +Cc: esr, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 7:05 ` Eli Zaretskii
@ 2014-01-09 8:14 ` Stephen J. Turnbull
2014-01-09 11:22 ` Andreas Schwab
0 siblings, 1 reply; 130+ messages in thread
From: Stephen J. Turnbull @ 2014-01-09 8:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: esr, emacs-devel
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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 8:14 ` Stephen J. Turnbull
@ 2014-01-09 11:22 ` Andreas Schwab
2014-01-09 14:30 ` Stephen J. Turnbull
0 siblings, 1 reply; 130+ messages in thread
From: Andreas Schwab @ 2014-01-09 11:22 UTC (permalink / raw)
To: Stephen J. Turnbull; +Cc: esr, Eli Zaretskii, emacs-devel
"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."
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 11:22 ` Andreas Schwab
@ 2014-01-09 14:30 ` Stephen J. Turnbull
2014-01-09 14:58 ` David Kastrup
2014-01-09 16:58 ` Eli Zaretskii
0 siblings, 2 replies; 130+ messages in thread
From: Stephen J. Turnbull @ 2014-01-09 14:30 UTC (permalink / raw)
To: Andreas Schwab; +Cc: esr, Eli Zaretskii, emacs-devel
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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 14:30 ` Stephen J. Turnbull
@ 2014-01-09 14:58 ` David Kastrup
2014-01-09 16:58 ` Eli Zaretskii
1 sibling, 0 replies; 130+ messages in thread
From: David Kastrup @ 2014-01-09 14:58 UTC (permalink / raw)
To: emacs-devel
"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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 14:30 ` Stephen J. Turnbull
2014-01-09 14:58 ` David Kastrup
@ 2014-01-09 16:58 ` Eli Zaretskii
2014-01-09 18:46 ` Stephen J. Turnbull
2014-01-11 9:14 ` Eli Zaretskii
1 sibling, 2 replies; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-09 16:58 UTC (permalink / raw)
To: Stephen J. Turnbull; +Cc: esr, schwab, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 16:58 ` Eli Zaretskii
@ 2014-01-09 18:46 ` Stephen J. Turnbull
2014-01-09 19:03 ` Eli Zaretskii
2014-01-11 9:14 ` Eli Zaretskii
1 sibling, 1 reply; 130+ messages in thread
From: Stephen J. Turnbull @ 2014-01-09 18:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: esr, schwab, emacs-devel
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.)
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 18:46 ` Stephen J. Turnbull
@ 2014-01-09 19:03 ` Eli Zaretskii
2014-01-09 19:40 ` Óscar Fuentes
0 siblings, 1 reply; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-09 19:03 UTC (permalink / raw)
To: Stephen J. Turnbull; +Cc: esr, schwab, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 19:03 ` Eli Zaretskii
@ 2014-01-09 19:40 ` Óscar Fuentes
2014-01-09 19:47 ` Eli Zaretskii
0 siblings, 1 reply; 130+ messages in thread
From: Óscar Fuentes @ 2014-01-09 19:40 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 19:40 ` Óscar Fuentes
@ 2014-01-09 19:47 ` Eli Zaretskii
2014-01-09 20:12 ` Óscar Fuentes
0 siblings, 1 reply; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-09 19:47 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 19:47 ` Eli Zaretskii
@ 2014-01-09 20:12 ` Óscar Fuentes
2014-01-09 20:17 ` Glenn Morris
2014-01-09 20:29 ` Eli Zaretskii
0 siblings, 2 replies; 130+ messages in thread
From: Óscar Fuentes @ 2014-01-09 20:12 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 20:12 ` Óscar Fuentes
@ 2014-01-09 20:17 ` Glenn Morris
2014-01-09 20:29 ` Eli Zaretskii
1 sibling, 0 replies; 130+ messages in thread
From: Glenn Morris @ 2014-01-09 20:17 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: emacs-devel
Ó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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 20:12 ` Óscar Fuentes
2014-01-09 20:17 ` Glenn Morris
@ 2014-01-09 20:29 ` Eli Zaretskii
2014-01-09 21:49 ` Óscar Fuentes
1 sibling, 1 reply; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-09 20:29 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 20:29 ` Eli Zaretskii
@ 2014-01-09 21:49 ` Óscar Fuentes
2014-01-10 6:38 ` Eli Zaretskii
0 siblings, 1 reply; 130+ messages in thread
From: Óscar Fuentes @ 2014-01-09 21:49 UTC (permalink / raw)
To: emacs-devel
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>)
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 21:49 ` Óscar Fuentes
@ 2014-01-10 6:38 ` Eli Zaretskii
0 siblings, 0 replies; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-10 6:38 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 16:58 ` Eli Zaretskii
2014-01-09 18:46 ` Stephen J. Turnbull
@ 2014-01-11 9:14 ` Eli Zaretskii
2014-01-11 20:09 ` Glenn Morris
1 sibling, 1 reply; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-11 9:14 UTC (permalink / raw)
To: stephen; +Cc: esr, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-11 9:14 ` Eli Zaretskii
@ 2014-01-11 20:09 ` Glenn Morris
2014-01-11 20:32 ` David Kastrup
2014-01-13 17:06 ` Glenn Morris
0 siblings, 2 replies; 130+ messages in thread
From: Glenn Morris @ 2014-01-11 20:09 UTC (permalink / raw)
To: emacs-devel
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.)
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-11 20:09 ` Glenn Morris
@ 2014-01-11 20:32 ` David Kastrup
2014-01-12 10:30 ` Jorgen Schaefer
2014-01-13 17:06 ` Glenn Morris
1 sibling, 1 reply; 130+ messages in thread
From: David Kastrup @ 2014-01-11 20:32 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-11 20:32 ` David Kastrup
@ 2014-01-12 10:30 ` Jorgen Schaefer
2014-01-13 22:34 ` Barry Warsaw
0 siblings, 1 reply; 130+ messages in thread
From: Jorgen Schaefer @ 2014-01-12 10:30 UTC (permalink / raw)
To: David Kastrup; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-12 10:30 ` Jorgen Schaefer
@ 2014-01-13 22:34 ` Barry Warsaw
0 siblings, 0 replies; 130+ messages in thread
From: Barry Warsaw @ 2014-01-13 22:34 UTC (permalink / raw)
To: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-11 20:09 ` Glenn Morris
2014-01-11 20:32 ` David Kastrup
@ 2014-01-13 17:06 ` Glenn Morris
2014-01-13 17:50 ` David Kastrup
1 sibling, 1 reply; 130+ messages in thread
From: Glenn Morris @ 2014-01-13 17:06 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-13 17:06 ` Glenn Morris
@ 2014-01-13 17:50 ` David Kastrup
2014-01-14 17:05 ` Richard Stallman
0 siblings, 1 reply; 130+ messages in thread
From: David Kastrup @ 2014-01-13 17:50 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-13 17:50 ` David Kastrup
@ 2014-01-14 17:05 ` Richard Stallman
0 siblings, 0 replies; 130+ messages in thread
From: Richard Stallman @ 2014-01-14 17:05 UTC (permalink / raw)
To: David Kastrup; +Cc: emacs-devel
[[[ 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 4:27 ` Stephen J. Turnbull
2014-01-09 7:05 ` Eli Zaretskii
@ 2014-01-09 15:12 ` Stefan Monnier
2014-01-09 15:33 ` Andreas Schwab
1 sibling, 1 reply; 130+ messages in thread
From: Stefan Monnier @ 2014-01-09 15:12 UTC (permalink / raw)
To: Stephen J. Turnbull; +Cc: esr, emacs-devel
> 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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-09 15:12 ` Stefan Monnier
@ 2014-01-09 15:33 ` Andreas Schwab
0 siblings, 0 replies; 130+ messages in thread
From: Andreas Schwab @ 2014-01-09 15:33 UTC (permalink / raw)
To: Stefan Monnier; +Cc: esr, Stephen J. Turnbull, emacs-devel
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."
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 13:52 Git transition checklist Eric S. Raymond
` (4 preceding siblings ...)
2014-01-08 17:47 ` Glenn Morris
@ 2014-01-08 18:14 ` Eli Zaretskii
2014-01-08 18:29 ` Glenn Morris
` (3 more replies)
2014-01-08 20:52 ` Eli Zaretskii
6 siblings, 4 replies; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-08 18:14 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:14 ` Eli Zaretskii
@ 2014-01-08 18:29 ` Glenn Morris
2014-01-08 18:39 ` Eli Zaretskii
2014-01-08 19:03 ` Andreas Schwab
2014-01-08 18:45 ` Achim Gratz
` (2 subsequent siblings)
3 siblings, 2 replies; 130+ messages in thread
From: Glenn Morris @ 2014-01-08 18:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:29 ` Glenn Morris
@ 2014-01-08 18:39 ` Eli Zaretskii
2014-01-08 18:46 ` Eli Zaretskii
2014-01-08 19:03 ` Andreas Schwab
1 sibling, 1 reply; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-08 18:39 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:39 ` Eli Zaretskii
@ 2014-01-08 18:46 ` Eli Zaretskii
2014-01-08 20:17 ` David Kastrup
0 siblings, 1 reply; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-08 18:46 UTC (permalink / raw)
To: rgm; +Cc: emacs-devel
> 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`^!
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:46 ` Eli Zaretskii
@ 2014-01-08 20:17 ` David Kastrup
0 siblings, 0 replies; 130+ messages in thread
From: David Kastrup @ 2014-01-08 20:17 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:29 ` Glenn Morris
2014-01-08 18:39 ` Eli Zaretskii
@ 2014-01-08 19:03 ` Andreas Schwab
1 sibling, 0 replies; 130+ messages in thread
From: Andreas Schwab @ 2014-01-08 19:03 UTC (permalink / raw)
To: Glenn Morris; +Cc: Eli Zaretskii, emacs-devel
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."
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:14 ` Eli Zaretskii
2014-01-08 18:29 ` Glenn Morris
@ 2014-01-08 18:45 ` Achim Gratz
2014-01-08 18:52 ` Eli Zaretskii
2014-01-08 19:00 ` Andreas Schwab
2014-01-08 20:11 ` Eric S. Raymond
3 siblings, 1 reply; 130+ messages in thread
From: Achim Gratz @ 2014-01-08 18:45 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:45 ` Achim Gratz
@ 2014-01-08 18:52 ` Eli Zaretskii
2014-01-08 19:15 ` Achim Gratz
0 siblings, 1 reply; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-08 18:52 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:52 ` Eli Zaretskii
@ 2014-01-08 19:15 ` Achim Gratz
0 siblings, 0 replies; 130+ messages in thread
From: Achim Gratz @ 2014-01-08 19:15 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:14 ` Eli Zaretskii
2014-01-08 18:29 ` Glenn Morris
2014-01-08 18:45 ` Achim Gratz
@ 2014-01-08 19:00 ` Andreas Schwab
2014-01-08 20:11 ` Eric S. Raymond
3 siblings, 0 replies; 130+ messages in thread
From: Andreas Schwab @ 2014-01-08 19:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Eric S. Raymond, emacs-devel
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."
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 18:14 ` Eli Zaretskii
` (2 preceding siblings ...)
2014-01-08 19:00 ` Andreas Schwab
@ 2014-01-08 20:11 ` Eric S. Raymond
2014-01-08 20:22 ` Eli Zaretskii
3 siblings, 1 reply; 130+ messages in thread
From: Eric S. Raymond @ 2014-01-08 20:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 20:11 ` Eric S. Raymond
@ 2014-01-08 20:22 ` Eli Zaretskii
2014-01-08 20:28 ` Eric S. Raymond
2014-01-08 21:47 ` David Kastrup
0 siblings, 2 replies; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-08 20:22 UTC (permalink / raw)
To: esr; +Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 20:22 ` Eli Zaretskii
@ 2014-01-08 20:28 ` Eric S. Raymond
2014-01-08 21:04 ` Eli Zaretskii
2014-01-08 21:47 ` David Kastrup
1 sibling, 1 reply; 130+ messages in thread
From: Eric S. Raymond @ 2014-01-08 20:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 20:28 ` Eric S. Raymond
@ 2014-01-08 21:04 ` Eli Zaretskii
2014-01-08 21:26 ` Eric S. Raymond
0 siblings, 1 reply; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-08 21:04 UTC (permalink / raw)
To: esr; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 21:04 ` Eli Zaretskii
@ 2014-01-08 21:26 ` Eric S. Raymond
2014-01-09 6:25 ` Eli Zaretskii
0 siblings, 1 reply; 130+ messages in thread
From: Eric S. Raymond @ 2014-01-08 21:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 21:26 ` Eric S. Raymond
@ 2014-01-09 6:25 ` Eli Zaretskii
0 siblings, 0 replies; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-09 6:25 UTC (permalink / raw)
To: esr; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 20:22 ` Eli Zaretskii
2014-01-08 20:28 ` Eric S. Raymond
@ 2014-01-08 21:47 ` David Kastrup
1 sibling, 0 replies; 130+ messages in thread
From: David Kastrup @ 2014-01-08 21:47 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 13:52 Git transition checklist Eric S. Raymond
` (5 preceding siblings ...)
2014-01-08 18:14 ` Eli Zaretskii
@ 2014-01-08 20:52 ` Eli Zaretskii
2014-01-08 21:07 ` Stefan Monnier
6 siblings, 1 reply; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-08 20:52 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: emacs-devel
> 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.)
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 20:52 ` Eli Zaretskii
@ 2014-01-08 21:07 ` Stefan Monnier
2014-01-08 21:22 ` Eli Zaretskii
0 siblings, 1 reply; 130+ messages in thread
From: Stefan Monnier @ 2014-01-08 21:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Eric S. Raymond, emacs-devel
> . 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
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Git transition checklist
2014-01-08 21:07 ` Stefan Monnier
@ 2014-01-08 21:22 ` Eli Zaretskii
0 siblings, 0 replies; 130+ messages in thread
From: Eli Zaretskii @ 2014-01-08 21:22 UTC (permalink / raw)
To: Stefan Monnier; +Cc: esr, emacs-devel
> 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"?).
^ permalink raw reply [flat|nested] 130+ messages in thread