Re: [Emacs-diffs] master 2b316c0: ; * CONTRIBUTE: Add section about the bug tracker

Re: [Emacs-diffs] master 2b316c0: ; * CONTRIBUTE: Add section about the bug tracker

[Juanma Barranquero]

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

On Fri, Nov 6, 2015 at 9:57 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> -See all the files in admin/notes/* .  In particular, see
> -admin/notes/newfile, see admin/notes/repo.

Speaking of admin/notes/repo... It has a few obsolete references to Bazaar,
and a comment "[The section on git merge procedure has not yet been
written.]"

And I miss some discussion about policies on pushing branches to the repo.
old-branches/* and other-branches/* are ancient, but what about the others?
Some are prefixed with scratch/ or fix/ (one case), while others are not
(like nsm, stream or shr-fontified). Is there any rhyme or reason? Also,
perhaps some of the non-prefixed branches are really ancient, like pending,
and should be renamed?

    J

[-- Attachment #2: Type: text/html, Size: 901 bytes --]

Re: [Emacs-diffs] master 2b316c0: ; * CONTRIBUTE: Add section about the bug tracker

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 6 Nov 2015 10:33:48 +0100
> 
> Speaking of admin/notes/repo... It has a few obsolete references to Bazaar, and
> a comment "[The section on git merge procedure has not yet been written.]"

Clean up is welcome.

> And I miss some discussion about policies on pushing branches to the repo.
> old-branches/* and other-branches/* are ancient, but what about the others?
> Some are prefixed with scratch/ or fix/ (one case), while others are not (like
> nsm, stream or shr-fontified). Is there any rhyme or reason?

The convention was to use scratch/ for experimental branches and fix/
for public feature branches that fix some issue.  Suggestions to
codify this are welcome.

> Also, perhaps some of the non-prefixed branches are really ancient,
> like pending, and should be renamed?

No idea, but I think this was already examined at some point, and what
you see is the result.

Thanks.

Re: [Emacs-diffs] master 2b316c0: ; * CONTRIBUTE: Add section about the bug tracker

[Juanma Barranquero]

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

On Fri, Nov 6, 2015 at 10:49 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Clean up is welcome.

Yes to cleanup, but as for the merge section, I'm not yet so comfortable
with git to be offering advice to others...

> The convention was to use scratch/ for experimental branches and fix/
> for public feature branches that fix some issue.  Suggestions to
> codify this are welcome.

Was this convention discussed on emacs-devel? I tried to search, but got so
many hits related to git that it was a bit hopeless.

> No idea, but I think this was already examined at some point, and what
> you see is the result.

OK, but pending never got much use and has not had a commit for three years
and half.

Thanks,

   J

[-- Attachment #2: Type: text/html, Size: 969 bytes --]

Re: [Emacs-diffs] master 2b316c0: ; * CONTRIBUTE: Add section about the bug tracker

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 6 Nov 2015 10:56:32 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > Clean up is welcome.
> 
> Yes to cleanup, but as for the merge section, I'm not yet so comfortable with
> git to be offering advice to others...

The idea of that passage is that merge is not to be afraid of.  That
is correct with any modern dVCS.

> > The convention was to use scratch/ for experimental branches and fix/
> > for public feature branches that fix some issue. Suggestions to
> > codify this are welcome.
> 
> Was this convention discussed on emacs-devel?

I don't think so.

Use of git branches (was: [Emacs-diffs] master 2b316c0: ; * CONTRIBUTE: Add section about the bug tracker)

[Nicolas Richard]

Juanma Barranquero <lekktu@gmail.com> writes:
> On Fri, Nov 6, 2015 at 10:49 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> The convention was to use scratch/ for experimental branches and fix/
>> for public feature branches that fix some issue. Suggestions to
>> codify this are welcome.
>
> Was this convention discussed on emacs-devel?

ISTR there was some kind of decision that scratch/ branches didn't have
to follow the gitlog-is-ChangeLog convention, i.e. they would never be
merged as is, but always rebased or squashed onto master.

-- 
Nico

Re: [Emacs-diffs] master 2b316c0: ; * CONTRIBUTE: Add section about the bug tracker

[Juanma Barranquero]

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

On Fri, Nov 6, 2015 at 11:10 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> The idea of that passage is that merge is not to be afraid of.  That
> is correct with any modern dVCS.

This is inside a section about merging changes from the release branch to
the trunk. I wouldn't expect there a general discussion of merge, but of
merge policies in Emacs, and about gitmerge.el.

> I don't think so.

In this case, before codifying these policies we should agree on them,
shouldn't we?

In general (this is *not* a complain, just an impression), having been out
for a year, so I missed the switch to git, I think that for a newcomer, the
information about using git with Emacs is a bit scattered. We have sections
in CONTRIBUTE, we have admin/notes/repo, admin/notes/git-workflow, which
starts with the not-very-reassuring "(This is a draft.  The method here
won't actually work yet, because neither git-new-workdir nor
merge-changelog are in the Emacs distribution yet.)". And then we have two
different documents on EmacsWiki.

A trivial change for the obsolete references to Bazaar.

diff --git a/admin/notes/repo b/admin/notes/repo
index b27a3f4..d28955c 100644
--- a/admin/notes/repo
+++ b/admin/notes/repo
@@ -41,8 +41,8 @@ preferable not to merge from master until you are done
with the
 feature.  Unless you really need some change that was done on the
 master while you were developing on the branch, you don't really need
 those merges; just merge once, when you are done with the feature, and
-Bazaar will take care of the rest.  Bazaar is much better in this than
-CVS, so interim merges are unnecessary.
+Git will take care of the rest.  Git is much better in this than CVS
+or Bazaar, so interim merges are unnecessary.

 Or use shelves; or rebase; or do something else.  See the thread for
 yet another fun excursion into the exciting world of version control.
warning: LF will be replaced by CRLF in admin/notes/repo.
The file will have its original line endings in your working directory.

[-- Attachment #2: Type: text/html, Size: 2460 bytes --]

Re: [Emacs-diffs] master 2b316c0: ; * CONTRIBUTE: Add section about the bug tracker

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 6 Nov 2015 11:18:46 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > The idea of that passage is that merge is not to be afraid of. That
> > is correct with any modern dVCS.
> 
> This is inside a section about merging changes from the release branch to the
> trunk.

That's the section, yes.  But the specific paragraph that refers to
Bazaar is more general:

  In general, when working on some feature in a separate branch, it is
  ^^^^^^^^^^                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  preferable not to merge from master until you are done with the
  feature. [...]

> I wouldn't expect there a general discussion of merge, but of merge
> policies in Emacs, and about gitmerge.el.

Once again, cleanups are welcome.

This file was originally written in Bazaar era, but then it was edited
in transition to Git.  It obviously needs some loving attention it
never got back then.  TIA.

> > I don't think so.
> 
> In this case, before codifying these policies we should agree on them,
> shouldn't we?

Preferably, yes.

> In general (this is *not* a complain, just an impression), having been out for
> a year, so I missed the switch to git, I think that for a newcomer, the
> information about using git with Emacs is a bit scattered. We have sections in
> CONTRIBUTE, we have admin/notes/repo, admin/notes/git-workflow, which starts
> with the not-very-reassuring "(This is a draft. The method here won't actually
> work yet, because neither git-new-workdir nor merge-changelog are in the Emacs
> distribution yet.)". And then we have two different documents on EmacsWiki.

Everything of interest to contributors should be in CONTRIBUTE, IMO.
Marginal technicalities and extended discussions not appropriate for
CONTRIBUTE could be in admin/notes/repo.  FWIW, my past attempts to
kill admin/notes/git-workflow failed.

> A trivial change for the obsolete references to Bazaar.
> 
> diff --git a/admin/notes/repo b/admin/notes/repo
> index b27a3f4..d28955c 100644
> --- a/admin/notes/repo
> +++ b/admin/notes/repo
> @@ -41,8 +41,8 @@ preferable not to merge from master until you are done with
> the
> feature. Unless you really need some change that was done on the
> master while you were developing on the branch, you don't really need
> those merges; just merge once, when you are done with the feature, and
> -Bazaar will take care of the rest. Bazaar is much better in this than
> -CVS, so interim merges are unnecessary.
> +Git will take care of the rest. Git is much better in this than CVS
> +or Bazaar, so interim merges are unnecessary.

Just "better than CVS" is good enough (and is also more correct,
IMO).  Thanks.

Re: Use of git branches (was: [Emacs-diffs] master 2b316c0: ; * CONTRIBUTE: Add section about the bug tracker)

[Eli Zaretskii]

> From: Nicolas Richard <youngfrog@members.fsf.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Emacs developers <emacs-devel@gnu.org>
> Date: Fri, 06 Nov 2015 11:16:17 +0100
> 
> ISTR there was some kind of decision that scratch/ branches didn't have
> to follow the gitlog-is-ChangeLog convention, i.e. they would never be
> merged as is, but always rebased or squashed onto master.

IMNSHO, this should be true for any branch which is not used to
_release_ Emacs.  The conventions are only for master and the release
branch.

Re: Use of git branches (was: [Emacs-diffs] master 2b316c0: ; * CONTRIBUTE: Add section about the bug tracker)

[Juanma Barranquero]

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

Ok, we have a new thread (thanks, Nicolas).

Could we use it to clarify what's the policy on public branches on the repo
(or, in general, our nettiquete wrt the emacs repo)? (So we can document
it.)

One thing that I dislike is having 66 branches in git branch -r, of which
41 are definitely obsolete (other-branches/* and old-branches/* are, except
for cairo, between 3 and 18 years old)

Among the non-(old|other) branches there are also a few (the last four in
this list) that seem too less than active:

origin/master                                            28 minutes ago
origin/concurrency                                        3 days ago
origin/fix/no-undo-boundary-on-secondary-buffer-change    8 days ago
origin/scratch/isearch-show-toggles                       8 days ago
origin/xwidget_mvp                                        2 weeks ago
origin/scratch/dbusbind-type-tests                        9 weeks ago
origin/scratch/dbusbind-type                             10 weeks ago
origin/emacs-24                                           3 months ago
origin/stream                                             3 months ago
origin/scratch/project                                    4 months ago
origin/scratch/quote-escaping                             4 months ago
origin/scratch/dynamic-modules-2                          5 months ago
origin/scratch/remove-internal-field                      6 months ago
origin/scratch/highlight-n-windows                        7 months ago
origin/scratch/fix-info-dups                              7 months ago
origin/shr-fontified                                      9 months ago
origin/xwidget                                            9 months ago
origin/scratch/xref                                      10 months ago
origin/dynamic-modules-rc2                               11 months ago
origin/nsm                                               12 months ago
origin/emacs-23                                           2 years, 9 months
ago
origin/pending                                            3 years, 7 months
ago
origin/gtk-tabs                                           5 years ago
origin/x-tabs                                             5 years ago


I know that some old branches (though not all) are perhaps of historical
interest. But, isn't there any way to remove them and yet keep their
content from being pruned? Tags or something?

[-- Attachment #2: Type: text/html, Size: 5227 bytes --]

Re: [Emacs-diffs] master 2b316c0: ; * CONTRIBUTE: Add section about the bug tracker

[Juanma Barranquero]

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

On Fri, Nov 6, 2015 at 11:44 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> FWIW, my past attempts to
> kill admin/notes/git-workflow failed.

Did it fight back?

> Just "better than CVS" is good enough (and is also more correct,
> IMO).  Thanks.

Installed.

[-- Attachment #2: Type: text/html, Size: 424 bytes --]

Re: [Emacs-diffs] master 2b316c0: ; * CONTRIBUTE: Add section about the bug tracker

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 6 Nov 2015 14:59:09 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > FWIW, my past attempts to
> > kill admin/notes/git-workflow failed.
> 
> Did it fight back?

Yes, it came after me with a vengeance.

Re: Use of git branches

[David Kastrup]

Juanma Barranquero <lekktu@gmail.com> writes:

> Ok, we have a new thread (thanks, Nicolas).
>
> Could we use it to clarify what's the policy on public branches on the repo
> (or, in general, our nettiquete wrt the emacs repo)? (So we can document
> it.)
>
> One thing that I dislike is having 66 branches in git branch -r, of which
> 41 are definitely obsolete (other-branches/* and old-branches/* are, except
> for cairo, between 3 and 18 years old)

git branch --contains master~100

does a pretty good job of weeding out inactive branches.

-- 
David Kastrup

Re: Use of git branches

[John Wiegley]

>>>>> Juanma Barranquero <lekktu@gmail.com> writes:

> I know that some old branches (though not all) are perhaps of historical
> interest. But, isn't there any way to remove them and yet keep their content
> from being pruned? Tags or something?

You can move branches into a different "ref space" on the server (this is not
tested yet, but should give the idea):

    git push origin refs/remotes/origin/old-branches/foo:refs/history/branches/foo
    git push origin :refs/old-branches/foo

Historical branches are not fetched until you add the corresponding refspec to
your .git/config file:

    [remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	fetch = +refs/history/*:refs/remotes/origin/history/*

Now you can write:

    git log origin/history/branches/Boehm-GC

John

p.s. This same trick works for GitHub PRs, btw, by using:

       fetch = +refs/pull/*:refs/remotes/origin/pr/*

     Now allowing you to: git checkout -b pr/1233 origin/pr/1233

Re: Use of git branches

[Juanma Barranquero]

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

On Fri, Nov 6, 2015 at 3:56 PM, David Kastrup <dak@gnu.org> wrote:

> git branch --contains master~100
>
> does a pretty good job of weeding out inactive branches.

As a way of listing the branches and excluding old ones, you mean?

I don't know if that's brilliant or gross ;-)

    J

[-- Attachment #2: Type: text/html, Size: 454 bytes --]

Re: Use of git branches

[Juanma Barranquero]

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

On Fri, Nov 6, 2015 at 5:05 PM, John Wiegley <jwiegley@gmail.com> wrote:

> You can move branches into a different "ref space" on the server (this is
not
> tested yet, but should give the idea):
[...]
> Now you can write:
>
>     git log origin/history/branches/Boehm-GC

This is great. We should do that with all those old branches.

[-- Attachment #2: Type: text/html, Size: 485 bytes --]

Re: Use of git branches

[David Kastrup]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Nov 6, 2015 at 3:56 PM, David Kastrup <dak@gnu.org> wrote:
>
>> git branch --contains master~100
>>
>> does a pretty good job of weeding out inactive branches.
>
> As a way of listing the branches and excluding old ones, you mean?
>
> I don't know if that's brilliant or gross ;-)

Isn't that the motto on Git's coat of arms?

-- 
David Kastrup

Re: Use of git branches

[Juanma Barranquero]

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

> Isn't that the motto on Git's coat of arms?

Yeah, but in Google's Latin: "Nescio si id vel crassa egregie"

[-- Attachment #2: Type: text/html, Size: 188 bytes --]