minor bzr->git changes missed

minor bzr->git changes missed

[Perry E. Metzger]

.dir-locals.el at the top level still has a reference to one's
"bazaar.conf" file.

etc/CONTRIBUTE still refers to the repo as being bazaar based.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: minor bzr->git changes missed

[Eli Zaretskii]

> Date: Thu, 13 Nov 2014 11:00:17 -0500
> From: "Perry E. Metzger" <perry@piermont.com>
> 
> .dir-locals.el at the top level still has a reference to one's
> "bazaar.conf" file.
> 
> etc/CONTRIBUTE still refers to the repo as being bazaar based.

Switching to git does not magically make any such changes.  Humans
(who care) should do that instead of complaining.

Re: minor bzr->git changes missed

[Perry E. Metzger]

On Thu, 13 Nov 2014 18:21:53 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Thu, 13 Nov 2014 11:00:17 -0500
> > From: "Perry E. Metzger" <perry@piermont.com>
> > 
> > .dir-locals.el at the top level still has a reference to one's
> > "bazaar.conf" file.
> > 
> > etc/CONTRIBUTE still refers to the repo as being bazaar based.
> 
> Switching to git does not magically make any such changes.  Humans
> (who care) should do that instead of complaining.
> 

I'm afraid I don't have commit access. I'm thus not really in a
position to make changes on my own.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: minor bzr->git changes missed

[Eli Zaretskii]

> Date: Thu, 13 Nov 2014 11:37:38 -0500
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: emacs-devel@gnu.org
> 
> On Thu, 13 Nov 2014 18:21:53 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> > > Date: Thu, 13 Nov 2014 11:00:17 -0500
> > > From: "Perry E. Metzger" <perry@piermont.com>
> > > 
> > > .dir-locals.el at the top level still has a reference to one's
> > > "bazaar.conf" file.
> > > 
> > > etc/CONTRIBUTE still refers to the repo as being bazaar based.
> > 
> > Switching to git does not magically make any such changes.  Humans
> > (who care) should do that instead of complaining.
> > 
> 
> I'm afraid I don't have commit access. I'm thus not really in a
> position to make changes on my own.

Please consider submitting patches.  TIA.

Re: minor bzr->git changes missed

[Paul Eggert]

On 11/13/2014 09:16 AM, Eli Zaretskii wrote:
> Please consider submitting patches.

Yes, patches would be nice for this sort of thing in the future.  This 
time I just wrote something up and installed it.

Re: minor bzr->git changes missed

[Eli Zaretskii]

> Date: Thu, 13 Nov 2014 09:18:24 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 11/13/2014 09:16 AM, Eli Zaretskii wrote:
> > Please consider submitting patches.
> 
> Yes, patches would be nice for this sort of thing in the future.  This 
> time I just wrote something up and installed it.

Thanks.  But why on master?  All the changes of this kind should go to
the branch.

Re: minor bzr->git changes missed

[Perry E. Metzger]

On Thu, 13 Nov 2014 19:36:07 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> Thanks.  But why on master?  All the changes of this kind should go
> to the branch.

For reference, is there a description of the full development
process, updated for the git world, one can read? I was under the
impression that people tracking development were supposed to be
operating off of master and that the 24 branch was only for bug fixes
to 24 -- that 25 would eventually be branched off of master in other
words. Clearly this is not the correct impression...

-- 
Perry E. Metzger		perry@piermont.com

Re: minor bzr->git changes missed

[Eli Zaretskii]

> Date: Thu, 13 Nov 2014 12:44:05 -0500
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: Paul Eggert <eggert@cs.ucla.edu>, emacs-devel@gnu.org
> 
> On Thu, 13 Nov 2014 19:36:07 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> > Thanks.  But why on master?  All the changes of this kind should go
> > to the branch.
> 
> For reference, is there a description of the full development
> process, updated for the git world, one can read?

Yes, admin/notes/repo and admin/notes/commits.

> I was under the impression that people tracking development were
> supposed to be operating off of master and that the 24 branch was
> only for bug fixes to 24 -- that 25 would eventually be branched off
> of master in other words. Clearly this is not the correct
> impression...

The key issue here is "tracking development".  What exactly do you
mean by that, and how is that related to the issue at hand?

I wasn't talking to people who "track the development", I was talking
to contributors, whether actual or potential, to Emacs development and
maintenance.  Such contributors are expected, among other things, to
fix bugs when they see them, and bugs that exist on the release branch
should be fixed there (and later merged to master).

In this case, the leftover references to bzr are "bugs" on the branch
as well, because the next stable release will be made out of that
branch, and we don't want to disseminate incorrect information about
our repository.

Re: minor bzr->git changes missed

[Perry E. Metzger]

On Thu, 13 Nov 2014 20:08:00 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> In this case, the leftover references to bzr are "bugs" on the
> branch as well, because the next stable release will be made out of
> that branch, and we don't want to disseminate incorrect information
> about our repository.

Ah. My confusion was that I thought your message asked him to commit
*only* to the branch. I didn't understand (now obvious in context)
that you were asking why he didn't *also* commit the fix to the
branch. My apologies for misunderstanding.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: minor bzr->git changes missed

[Eli Zaretskii]

> Date: Thu, 13 Nov 2014 13:14:20 -0500
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> Ah. My confusion was that I thought your message asked him to commit
> *only* to the branch.

That's indeed what I said.  These changes will be later merged to
master, so no need to commit twice.  (Of course, when a commit was
already done to master, the way to fix that is to make another commit
to the branch, but that's contingency.)

Re: minor bzr->git changes missed

[Perry E. Metzger]

On Thu, 13 Nov 2014 20:37:48 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Thu, 13 Nov 2014 13:14:20 -0500
> > From: "Perry E. Metzger" <perry@piermont.com>
> > Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> > 
> > Ah. My confusion was that I thought your message asked him to
> > commit *only* to the branch.
> 
> That's indeed what I said.  These changes will be later merged to
> master, so no need to commit twice.

Out of curiosity, how is that handled? That is, when a bug is fixed
on the branch, does one immediately merge that fix to master, or does
that happen at some fixed interval, or does something else happen?

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: minor bzr->git changes missed

[Eli Zaretskii]

> Date: Thu, 13 Nov 2014 14:11:27 -0500
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> > > Ah. My confusion was that I thought your message asked him to
> > > commit *only* to the branch.
> > 
> > That's indeed what I said.  These changes will be later merged to
> > master, so no need to commit twice.
> 
> Out of curiosity, how is that handled? That is, when a bug is fixed
> on the branch, does one immediately merge that fix to master, or does
> that happen at some fixed interval, or does something else happen?

Some Helpful Soul (TM) does that whenever they like.

Also, sometimes people who need to make a change on master that
depends on some bugfix on the branch do the merge because they need
it.

In general, everybody with write access are encoraged to do these
merges when they have a moment.

Re: minor bzr->git changes missed

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> For reference, is there a description of the full development
>> process, updated for the git world, one can read?
>
> Yes, admin/notes/repo and admin/notes/commits.

I scanned this and I scanned Git for Emacs Devs, but I'm still not sure
how to push stuff to the emacs-24 branch.

Could someone please just write recipe on how to do this, starting with

git clone --local emacs emacs-24

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: minor bzr->git changes missed

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: "Perry E. Metzger" <perry@piermont.com>,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Thu, 13 Nov 2014 22:54:35 +0100
> MailScanner-NULL-Check: 1416520475.64046@ljevEl7WkIEO5ZseDB61fA
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> For reference, is there a description of the full development
> >> process, updated for the git world, one can read?
> >
> > Yes, admin/notes/repo and admin/notes/commits.
> 
> I scanned this and I scanned Git for Emacs Devs, but I'm still not sure
> how to push stuff to the emacs-24 branch.
> 
> Could someone please just write recipe on how to do this, starting with
> 
> git clone --local emacs emacs-24

AFAIU, by using "clone --local", you defined a personalized workflow
that is not what the Wiki describes.  The Wiki describes the situation
where you have a repository cloned from the remote.  Then you just
"git checkout" the branch, make your changes, commit them, and push
them.  Exactly like you do with master, with the addition of the
checkout step.

It's unreasonable to expect the related documentation to describe
every possible personal workflow out there.  If you use your own
workflow, you are expected to know how, or google, or ask specific
questions.

Re: minor bzr->git changes missed

[Achim Gratz]

Lars Magne Ingebrigtsen writes:
> Could someone please just write recipe on how to do this, starting with
>
> git clone --local emacs emacs-24

If you clone like that you'll need to set up the upstream remote by
hand.  A better way to do that is

git clone --reference emacs git://git.savannah.gnu.org/emacs.git emacs-24

If you follow this workflow, it is best to always do the remote updates
in the reference repository first.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: minor bzr->git changes missed

[H. Dieter Wilhelm]

Achim Gratz <Stromeko@nexgo.de> writes:

> Lars Magne Ingebrigtsen writes:
>> Could someone please just write recipe on how to do this, starting with
>>
>> git clone --local emacs emacs-24
>
> If you clone like that you'll need to set up the upstream remote by
> hand.  A better way to do that is
>
> git clone --reference emacs git://git.savannah.gnu.org/emacs.git emacs-24

I've got a followup question.  Wouldn't it be cleaner to apply

git clone --reference emacs git://git.savannah.gnu.org/emacs.git emacs-25
git clone -b emacs-24 --reference emacs git://git.savannah.gnu.org/emacs.git emacs-24

Thanks
        Dieter
-- 
Best wishes
H. Dieter Wilhelm
Darmstadt, Germany

Re: minor bzr->git changes missed

[Paul Eggert]

On 11/13/2014 09:36 AM, Eli Zaretskii wrote:
> But why on master?  All the changes of this kind should go to
> the branch.

Since those changes didn't fix any bugs, I assumed they weren't needed 
in the emacs-24 branch.  It's possible that our definitions of "bug" differ.

Re: minor bzr->git changes missed

[Eli Zaretskii]

> Date: Thu, 13 Nov 2014 09:56:05 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: perry@piermont.com, emacs-devel@gnu.org
> 
> On 11/13/2014 09:36 AM, Eli Zaretskii wrote:
> > But why on master?  All the changes of this kind should go to
> > the branch.
> 
> Since those changes didn't fix any bugs, I assumed they weren't needed 
> in the emacs-24 branch.  It's possible that our definitions of "bug" differ.

No, our definitions don't differ in this case.  But a change in a
documentation file or in .gitignore cannot possibly do any harm to the
stability of the release branch, and the fact that we switched to Git
is true for the branch as well.  So leaving references to bzr on the
branch sounds wrong to me, even if it is not a bug in the literal
sense.

Re: minor bzr->git changes missed

[Paul Eggert]

On 11/13/2014 10:01 AM, Eli Zaretskii wrote:
> a change in a
> documentation file or in .gitignore cannot possibly do any harm to the
> stability of the release branch

I thought the emacs-24 branch was for fixing bugs rather than for not 
doing harm, but it's no big deal either way so I gave a shot at 
backporting the patch.

Re: minor bzr->git changes missed

[Eli Zaretskii]

> Date: Thu, 13 Nov 2014 12:40:43 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 11/13/2014 10:01 AM, Eli Zaretskii wrote:
> > a change in a
> > documentation file or in .gitignore cannot possibly do any harm to the
> > stability of the release branch
> 
> I thought the emacs-24 branch was for fixing bugs rather than for not 
> doing harm

Since not having files in .gitignore causes _us_ harm, it is a kind of
"bug", really.

> but it's no big deal either way so I gave a shot at backporting the
> patch.

Thank you.

Re: minor bzr->git changes missed

[Perry E. Metzger]

On Thu, 13 Nov 2014 09:18:24 -0800 Paul Eggert <eggert@cs.ucla.edu>
wrote:
> On 11/13/2014 09:16 AM, Eli Zaretskii wrote:
> > Please consider submitting patches.
> 
> Yes, patches would be nice for this sort of thing in the future.
> This time I just wrote something up and installed it.
> 

I have to admit I wasn't entirely clear on what the text should
say for the .dir-locals.el file, but I probably could have done
something for CONTRIBUTING -- I'll include patches where possible with
messages about this sort of thing in the future.

-- 
Perry E. Metzger		perry@piermont.com

Re: minor bzr->git changes missed

[Eric S. Raymond]

Perry E. Metzger <perry@piermont.com>:
> .dir-locals.el at the top level still has a reference to one's
> "bazaar.conf" file.
> 
> etc/CONTRIBUTE still refers to the repo as being bazaar based.

Added to my notes.  I'll let these accumulate for a bit and do a cleanup
patch, probably nexr week.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>