Move to git is imminent - awaiting Stefan's approval

Move to git is imminent - awaiting Stefan's approval

[Eric S. Raymond]

The thread on the git move proposal is showing signs of exhaustion and
terminal topic drift.  We can ask Karl Fogel for a poll count but I
think we all know how that would turn out; the pro-git vote has
been overwhelming.

I have asked Andreas Schwab and he reports the Savannah git mirror
ready for production use. Having examined it, I agree. Andreas and I
have discussed the switchover and believe it should consist of the
following steps:

1. Andreas will turn off bzr commit mirroring.

2. Andreas will enter a small documentation commit recording the changeover.

3. Andreas will announce on the dev list that the git repo is live for
   developer pushes.

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

I am now recommending that Andreas perform steps 1-3 at his convenience, no
sooner than 2014-01-06T11:59:00  and no later than 2014-01-07T11:59:00 -
that is, sometime tomorrow.

Consideration of workflow changes is explicitly deferred. Developers
should continue writing ChangeLog entries as per established custom.

I want to extend a thank you to everyone who participated in the
debate, *including* the anti-git dissenters, for generally sticking to
real issues and maintaining civility.

Stefan, please either (a) confirm that you as the official maintainer
are authorizing this, or (b) put a hold on it and explain what 
additional steps or conditions you deem necessary before we move.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

A ``decay in the social contract'' is detectable; there is a growing
feeling, particularly among middle-income taxpayers, that they are not
getting back, from society and government, their money's worth for
taxes paid. The tendency is for taxpayers to try to take more control
of their finances...	-- IRS Strategic Plan, (May 1984)

Re: Move to git is imminent - awaiting Stefan's approval

[Jay Belanger]

> 1. Andreas will turn off bzr commit mirroring.
>
> 2. Andreas will enter a small documentation commit recording the changeover.
>
> 3. Andreas will announce on the dev list that the git repo is live for
>    developer pushes.
>
> 4. I will do the work required to update /etc and /admin for git use
>    over the following few days.

When we changed to bzr, the "Bzr for Emacs Devs" page on the wiki
was invaluable.  For the changeover, could someone (please?) do
something similar for git? 

Thanks,
Jay

Re: Move to git is imminent - awaiting Stefan's approval

[Eric S. Raymond]

Jay Belanger <jay.p.belanger@gmail.com>:
> When we changed to bzr, the "Bzr for Emacs Devs" page on the wiki
> was invaluable.  For the changeover, could someone (please?) do
> something similar for git? 

I'll put that on my todo list.  But updating the in-tree stuff comes first.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Move to git is imminent - awaiting Stefan's approval

[Jay Belanger]

>> When we changed to bzr, the "Bzr for Emacs Devs" page on the wiki
>> was invaluable.  For the changeover, could someone (please?) do
>> something similar for git? 
>
> I'll put that on my todo list.  But updating the in-tree stuff comes first.

Thanks, and of course.

Re: Move to git is imminent - awaiting Stefan's approval

[Stephen J. Turnbull]

Jay Belanger writes:

 > When we changed to bzr, the "Bzr for Emacs Devs" page on the wiki
 > was invaluable.  For the changeover, could someone (please?) do
 > something similar for git? 

http://www.python.org/dev/peps/pep-0374/ is a start.

Re: Move to git is imminent - awaiting Stefan's approval

[Eric S. Raymond]

Stephen J. Turnbull <stephen@xemacs.org>:
> Jay Belanger writes:
> 
>  > When we changed to bzr, the "Bzr for Emacs Devs" page on the wiki
>  > was invaluable.  For the changeover, could someone (please?) do
>  > something similar for git? 
> 
> http://www.python.org/dev/peps/pep-0374/ is a start.

I'm working this problem, which is why I've been quiet the last day.

Results to be announced shortly.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Move to git is imminent - awaiting Stefan's approval

[Eli Zaretskii]

> From: esr@thyrsus.com (Eric S. Raymond)
> Date: Mon,  6 Jan 2014 11:51:08 -0500 (EST)
> 
> I have asked Andreas Schwab and he reports the Savannah git mirror
> ready for production use. Having examined it, I agree. Andreas and I
> have discussed the switchover and believe it should consist of the
> following steps:
> 
> 1. Andreas will turn off bzr commit mirroring.
> 
> 2. Andreas will enter a small documentation commit recording the changeover.
> 
> 3. Andreas will announce on the dev list that the git repo is live for
>    developer pushes.
> 
> 4. I will do the work required to update /etc and /admin for git use
>    over the following few days.
> 
> I am now recommending that Andreas perform steps 1-3 at his convenience, no
> sooner than 2014-01-06T11:59:00  and no later than 2014-01-07T11:59:00 -
> that is, sometime tomorrow.

The above is not enough.  I would suggest to have the following
additional steps, before the switch:

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

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

 7. What about the mail messages to emacs-diffs mailing list?  That
    should be working as well, and support pushes to non-trunk
    branches.

 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.

I suggest to leave some time, certainly more than one day, for others
to come up with additional activities that need to be completed before
the switch.  I see no special reason to rush.

Re: Move to git is imminent - awaiting Stefan's approval

[Stefan Monnier]

> The above is not enough.  I would suggest to have the following
> additional steps, before the switch:

Sounds right.

I'd also like:

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

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

- The $5M mentioned by Eli sounds good as well.  Tho somehow I have the
  impression this isn't gonna happen.

> - He's not bringing any new argument that has not been discussed
> before; the only difference is that Richard and Stefan seem to accept
> now that Bazaar is beyond hope.

Side note: I've considered Bzr dead for a while now (hence the move to
Git for `elpa').  FWIW, my vote is on "have better things to do with my
time than worry about which VCS we use".
IOW the main change so far is that Richard does not insist on us using
Bzr any more.


        Stefan

Re: Move to git is imminent - awaiting Stefan's approval

[Óscar Fuentes]

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

[snip]

> I'd also like:
>
> - Improve vc-git.el so that it can automatically enable smerge-mode when
>   opening a conflicted file

We discussed a patch for this. IIRC it had the inconvenience of
requiring two git calls for each file, although in theory it was
possible to cache the results for the entire tree.

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

The config var is important.

Here, conflict is considered solved only after testing the changes (does
it compile? does it pass the regression tests?.)

[snip]

Re: Move to git is imminent - awaiting Stefan's approval

[Stefan Monnier]

>> and (probably conditional on a config var)
[...]
> The config var is important.

I know some people are very ticklish about it, which is why I mentioned
the config var.  I think the default should be to have the feature
enabled.

> Here, conflict is considered solved only after testing the changes (does
> it compile? does it pass the regression tests?.)

When Git resolves concurrent changes automatically, it doesn't mark the
file as "there was an unchecked change in here", so for the same reason
I think the default behavior of vc-git + smerge-mode should be to remove
the "conflicted" mark on files after the user has removed all
diff3 markers.


        Stefan

Automatically marking conflicts are resolved (was: Move to git is imminent - awaiting Stefan's approval)

[Óscar Fuentes]

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

>> Here, conflict is considered solved only after testing the changes (does
>> it compile? does it pass the regression tests?.)
>
> When Git resolves concurrent changes automatically, it doesn't mark the
> file as "there was an unchecked change in here",

Right, so you must consider everything as unchecked changes.

> so for the same reason
> I think the default behavior of vc-git + smerge-mode should be to remove
> the "conflicted" mark on files after the user has removed all
> diff3 markers.

On the compile/test phase it is useful to know which problems comes from
the automatic merge and which ones comes from the areas you edited while
resolving the conflicts.

I'm fine with the optional toggle, so there is no need to discuss this
further.

Re: Automatically marking conflicts are resolved

[David Kastrup]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> Here, conflict is considered solved only after testing the changes (does
>>> it compile? does it pass the regression tests?.)
>>
>> When Git resolves concurrent changes automatically, it doesn't mark the
>> file as "there was an unchecked change in here",
>
> Right, so you must consider everything as unchecked changes.
>
>> so for the same reason
>> I think the default behavior of vc-git + smerge-mode should be to remove
>> the "conflicted" mark on files after the user has removed all
>> diff3 markers.
>
> On the compile/test phase it is useful to know which problems comes from
> the automatic merge and which ones comes from the areas you edited while
> resolving the conflicts.

The commit message proposed by Git lists the merge conflicts.  While the
committer may remove this list, it is usually a good idea to keep it,
for exactly that reason.

-- 
David Kastrup

Re: Automatically marking conflicts are resolved

[Óscar Fuentes]

David Kastrup <dak@gnu.org> writes:

>> On the compile/test phase it is useful to know which problems comes from
>> the automatic merge and which ones comes from the areas you edited while
>> resolving the conflicts.
>
> The commit message proposed by Git lists the merge conflicts.  While the
> committer may remove this list, it is usually a good idea to keep it,
> for exactly that reason.

That's not enough and too late. I wont commit the merge without testing
it first and meanwhile a clear separation of conflicted areas is useful.

Re: Automatically marking conflicts are resolved

[David Kastrup]

Óscar Fuentes <ofv@wanadoo.es> writes:

> David Kastrup <dak@gnu.org> writes:
>
>>> On the compile/test phase it is useful to know which problems comes from
>>> the automatic merge and which ones comes from the areas you edited while
>>> resolving the conflicts.
>>
>> The commit message proposed by Git lists the merge conflicts.  While the
>> committer may remove this list, it is usually a good idea to keep it,
>> for exactly that reason.
>
> That's not enough and too late. I wont commit the merge without testing
> it first and meanwhile a clear separation of conflicted areas is useful.

Uh, why would that be too late?  Before committing the merge, git diff
lists all merge conflicts.  After committing the merge, the information
is in the commit message.  The commit can still be amended.

Whether or not you choose to commit first, test later (after all, a
commit is not the same as an upstream push and can always be amended) or
test first, commit later, the information is readily available.

-- 
David Kastrup

Re: Automatically marking conflicts are resolved

[Óscar Fuentes]

David Kastrup <dak@gnu.org> writes:

>> That's not enough and too late. I wont commit the merge without testing
>> it first and meanwhile a clear separation of conflicted areas is useful.
>
> Uh, why would that be too late?  Before committing the merge, git diff
> lists all merge conflicts.  After committing the merge, the information
> is in the commit message.  The commit can still be amended.
>
> Whether or not you choose to commit first, test later (after all, a
> commit is not the same as an upstream push and can always be amended) or
> test first, commit later, the information is readily available.

I'm wary of using commits as temporary storage for work-in-progress on
merges or any other atomic change. A distraction at the wrong moment may
cause big trouble. There is a policy here that says that, except for
experimental throw-away projects, all changes must pass some tests
before committing them.

Also it is convenient to have the diff updated as you work on fixing the
merge, with the merge-specific diff indicators.

Re: Automatically marking conflicts are resolved

[David Kastrup]

Óscar Fuentes <ofv@wanadoo.es> writes:

> David Kastrup <dak@gnu.org> writes:
>
>>> That's not enough and too late. I wont commit the merge without testing
>>> it first and meanwhile a clear separation of conflicted areas is useful.
>>
>> Uh, why would that be too late?  Before committing the merge, git diff
>> lists all merge conflicts.  After committing the merge, the information
>> is in the commit message.  The commit can still be amended.
>>
>> Whether or not you choose to commit first, test later (after all, a
>> commit is not the same as an upstream push and can always be amended) or
>> test first, commit later, the information is readily available.
>
> I'm wary of using commits as temporary storage for work-in-progress on
> merges or any other atomic change.

So what?  I repeat: at no point of time does the information become
unavailable.

> A distraction at the wrong moment may cause big trouble. There is a
> policy here that says that, except for experimental throw-away
> projects, all changes must pass some tests before committing them.

You are confused.  A "policy" cannot cover what may be _committed_ since
commits are private to each user.  A policy can only cover what is
_pushed_ to a central resource.

> Also it is convenient to have the diff updated as you work on fixing
> the merge, with the merge-specific diff indicators.

So what?  Fix a file, git add it, and it disappears from the diff (which
shows the difference between index and work directory by default)
without affecting the state of the repository.

-- 
David Kastrup

Re: Automatically marking conflicts are resolved

[Óscar Fuentes]

David Kastrup <dak@gnu.org> writes:

>> I'm wary of using commits as temporary storage for work-in-progress on
>> merges or any other atomic change.
>
> So what?  I repeat: at no point of time does the information become
> unavailable.

Availability + convenience is better than availability alone.

>> A distraction at the wrong moment may cause big trouble. There is a
>> policy here that says that, except for experimental throw-away
>> projects, all changes must pass some tests before committing them.
>
> You are confused.  A "policy" cannot cover what may be _committed_ since
> commits are private to each user.  A policy can only cover what is
> _pushed_ to a central resource.

Apparently you are not familiarized with safety operational procedures,
and you certainly don't know the workflow here, so your claim is
baseless.

>> Also it is convenient to have the diff updated as you work on fixing
>> the merge, with the merge-specific diff indicators.
>
> So what?  Fix a file,

Here, a file is not "fixed" until the whole set of "fixes" passes the
tests.

> git add it, and it disappears from the diff

This I want to avoid. When a merge contains conflicts, the diffs on the
"Unstaged changes" section of Magit contains the conflicts and,
eventually, my edits for resolving them. The non-conflicted files are on
the "Staged changes" section. I find this convenient because it
clearly separates the parts that required human intervention.

> (which
> shows the difference between index and work directory by default)
> without affecting the state of the repository.

Re: Automatically marking conflicts are resolved

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > I'm wary of using commits as temporary storage for work-in-progress
 > on merges or any other atomic change. A distraction at the wrong
 > moment may cause big trouble.

I don't see how this can cause more trouble than any time a train of
thought gets interrupted, and the developer incautiously proceeds to
commit and push.

Re: Move to git is imminent - awaiting Stefan's approval

[Leo Liu]

On 2014-01-07 05:09 +0800, Stefan Monnier wrote:
> FWIW, my vote is on "have better things to do with my time than worry
> about which VCS we use".

Pragmatism triumphs ;)

Leo

Re: Move to git is imminent - awaiting Stefan's approval

[Thierry Volpiatto]

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

>> The above is not enough.  I would suggest to have the following
>> additional steps, before the switch:
>
> Sounds right.
>
> I'd also like:
>
> - 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.

You can use git-mergetool with ediff-merge for this.

http://stackoverflow.com/questions/1817370/using-ediff-as-git-mergetool

When git fail to merge and signal a conflict, run git-mergetool in e.g
eshell will bring you a new frame with ediff-merge to resolve the
conflict manually, always worked fine for me.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Move to git is imminent - awaiting Stefan's approval

[Stefan Monnier]

> You can use git-mergetool with ediff-merge for this.

I find ediff too heavy, so it would have to be smerge-mode instead.

But, while I'd be happy to take patches to better support git-mergetool
(if needed), I prefer using the vc-find-conflicted-files workflow.
It could probably run git-mergetool internally.


        Stefan

Re: Move to git is imminent - awaiting Stefan's approval

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 07 Jan 2014 08:45:47 -0500
> Cc: emacs-devel@gnu.org
> 
> while I'd be happy to take patches to better support git-mergetool
> (if needed), I prefer using the vc-find-conflicted-files workflow.

Same here.  It's so dead easy that it's hard to beat: just visit the
offending file (which is automatically put in SMerge mode), edit to
resolve the conflict and remove the conflict markers, then save -- and
the VC back-end will automatically do whatever it takes to finish
conflict resolution.

Re: Move to git is imminent - awaiting Stefan's approval

[Barry Warsaw]

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

On Jan 06, 2014, at 04:09 PM, Stefan Monnier wrote:

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

Yes please!  It's one huge feature I'm missing when working in git repos as
opposed to bzr repos.

-Barry

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

Re: Move to git is imminent - awaiting Stefan's approval

[Stefan Monnier]

> Yes please!  It's one huge feature I'm missing when working in git repos as
> opposed to bzr repos.

I'm so glad to see people like it!


        Stefan "who had no idea!"

Re: Move to git is imminent - awaiting Stefan's approval

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 08 Jan 2014 19:04:34 -0500
> Cc: emacs-devel@gnu.org
> 
> > Yes please!  It's one huge feature I'm missing when working in git repos as
> > opposed to bzr repos.
> 
> I'm so glad to see people like it!

Count me in as well.  Great feature, indeed: seamless, does it job
silently and well.  When I first saw it, and "bzr conflicts" suddenly
said nothing at all after saving a fixed file, it was one of those WTF
moments.

Re: Move to git is imminent - awaiting Stefan's approval

[David Engster]

Eli Zaretskii writes:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Wed, 08 Jan 2014 19:04:34 -0500
>> Cc: emacs-devel@gnu.org
>> 
>> > Yes please!  It's one huge feature I'm missing when working in git repos as
>> > opposed to bzr repos.
>> 
>> I'm so glad to see people like it!
>
> Count me in as well.  Great feature, indeed: seamless, does it job
> silently and well.  When I first saw it, and "bzr conflicts" suddenly
> said nothing at all after saving a fixed file, it was one of those WTF
> moments.

I always thought it was a Bazaar feature...

-David

Re: Move to git is imminent - awaiting Stefan's approval

[Juanma Barranquero]

On Thu, Jan 9, 2014 at 7:32 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Great feature, indeed: seamless, does it job
> silently and well.  When I first saw it, and "bzr conflicts" suddenly
> said nothing at all after saving a fixed file, it was one of those WTF
> moments.

My thoughts exactly.

    J

Re: Move to git is imminent - awaiting Stefan's approval

[Juanma Barranquero]

On Mon, Jan 6, 2014 at 5:51 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> I am now recommending that Andreas perform steps 1-3 at his convenience, no
> sooner than 2014-01-06T11:59:00  and no later than 2014-01-07T11:59:00 -
> that is, sometime tomorrow.

Why? Where's the hurry? We're in a freeze, we should be concentrating
on fixing bugs, not learning new ways and new procedures...

    J

Re: Move to git is imminent - awaiting Stefan's approval

[Bastien]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Mon, Jan 6, 2014 at 5:51 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
>
>> I am now recommending that Andreas perform steps 1-3 at his convenience, no
>> sooner than 2014-01-06T11:59:00  and no later than 2014-01-07T11:59:00 -
>> that is, sometime tomorrow.
>
> Why? Where's the hurry? We're in a freeze, we should be concentrating
> on fixing bugs, not learning new ways and new procedures...

Agreed.  The discussion itself has been distracting, even if useful.
Also, a more formal count would help to let those who are less vocal
express their views/vote.

PS: I appreciate Jordi's points and have been testing hg more lately,
so maybe my previous vote will be git-or-hg.  Need to test more.

-- 
 Bastien

Re: Move to git is imminent - awaiting Stefan's approval

[Jarek Czekalski]

W dniu 01/06/2014 07:42 PM, Bastien pisze:
> Agreed.  The discussion itself has been distracting, even if useful.
> Also, a more formal count would help to let those who are less vocal
> express their views/vote.

Sure, let's remember how this thread started. Karl Fogel wrote:
> I'm mainly posting
> this so there's a place for people to follow up to express their
> preference, so we can quickly get a sense of whether moving to git is
> the obvious call for the group as a whole, not just for those of us who
> have been been expressing that preference for some time.

Now Eric turns this thread into voting:
> We can ask Karl Fogel for a poll count but I
> think we all know how that would turn out; the pro-git vote has
> been overwhelming.

If the decision is to be made by a poll, I would like to know:
- who votes
- if not only admins, what are the final positions of the admins (each of
them)

Please give this info in a separate thread, that would be easy to catch.
Please add a vote "both are ok for me" to the poll

I would like to support admins with my vote, if it counts.

Thanks,
Jarek

PS. I have problems posting to devel, forgive me if this arrives twice.



--
View this message in context: http://emacs.1067599.n5.nabble.com/Move-to-git-is-imminent-awaiting-Stefan-s-approval-tp308660p308684.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

RE: Move to git is imminent - awaiting Stefan's approval

[Drew Adams]

> > I am now recommending that Andreas perform steps 1-3 at his
> > convenience, no sooner than 2014-01-06T11:59:00  and no
> > later than 2014-01-07T11:59:00 - that is, sometime tomorrow.
> 
> Why?  Where's the hurry?  We're in a freeze, we should be
> concentrating on fixing bugs, not learning new ways and
> new procedures...

+1  Juanma gets the "Emperor's New Clothes" badge for pointing
    out something important that should be obvious but is
    seemingly ignored or overlooked.

    So much energy in this thread and its offshoots...
    So many 24.3.50 bugs...

Re: Move to git is imminent - awaiting Stefan's approval

[Eric S. Raymond]

Juanma Barranquero <lekktu@gmail.com>:
> Why? Where's the hurry? We're in a freeze, we should be concentrating
> on fixing bugs, not learning new ways and new procedures...

This *is* fixing a bug.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

RE: Move to git is imminent - awaiting Stefan's approval

[Drew Adams]

> > Why? Where's the hurry? We're in a freeze, we should be
> > concentrating on fixing bugs, not learning new ways and
> > new procedures...
> 
> This *is* fixing a bug.

It may be.  For Emacs 24.4?  What's the bug number, if so?

In any case, there are thousands of other bugs as well.
Is this one such a high priority for Emacs 24.4?

Re: Move to git is imminent - awaiting Stefan's approval

[Eric S. Raymond]

Drew Adams <drew.adams@oracle.com>:
> In any case, there are thousands of other bugs as well.
> Is this one such a high priority for Emacs 24.4?

I think it is, and that's why I'm putting effort into it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Move to git is imminent - awaiting Stefan's approval

[Juanma Barranquero]

On Mon, Jan 6, 2014 at 8:42 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> This *is* fixing a bug.

This is an *opinion*. Opinion are not bugs. They aren't even facts.

   J

Re: Move to git is imminent - awaiting Stefan's approval

[Stephen J. Turnbull]

Eric S. Raymond writes:

 > This *is* fixing a bug.
 > -- 
 > 		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Nonsense.  It can and should wait for the release to be complete.  It
would be different if Emacs released from a branch rather than the
trunk, but it doesn't.

Re: Move to git is not imminent - esr is just tired of talking about it

[Jordi Gutiérrez Hermoso]

esr, please don't pretend like the move is a fait accompli. While
there git is enjoying an obvious popularity, GNU packages doesn't make
decisions merely based on what is popular. If we just wanted
popularity, we would be putting videos of Miley Cyrus on the Emacs
splash page.

- Jordi G. H.

Re: Move to git is not imminent - esr is just tired of talking about it

[Daniel Colascione]

On 01/06/2014 09:49 AM, Jordi Gutiérrez Hermoso wrote:
> esr, please don't pretend like the move is a fait accompli. While
> there git is enjoying an obvious popularity, GNU packages doesn't make
> decisions merely based on what is popular. If we just wanted
> popularity, we would be putting videos of Miley Cyrus on the Emacs
> splash page.

In another thread, you raised the possibility of switching to Mercurial 
instead of git. After vigorous debate, you failed to change the broad 
consensus that has formed around git. I will not rehash that thread 
here, but I think we can agree that your concerns were heard. Please 
focus now on making the transition to git as smooth as possible. You are 
welcome to use hg-git once the transition is complete.

Re: Move to git is not imminent - esr is just tired of talking about it

[Jay Belanger]

> In another thread, you raised the possibility of switching to
> Mercurial instead of git. After vigorous debate, you failed to change
> the broad consensus that has formed around git.

Maybe not, but it's hard to tell.  I doubt that everyone who was swayed
came out and said so.

> Please focus now on making the transition to git as smooth as
> possible.

That's good advice for after the official word has come down.  Stefan
has said that he's pretty sure there will be a switch to git, but I
don't know if he's said anything final.

Re: Move to git is not imminent - esr is just tired of talking about it

[Juanma Barranquero]

On Mon, Jan 6, 2014 at 7:18 PM, Daniel Colascione <dancol@dancol.org> wrote:

> Please focus now on
> making the transition to git as smooth as possible.

Why?

I don't want to switch to Mercurial, so I'm not "siding" with Jordi
here. I like Bazaar, but I don't oppose switching to git. But Jordi's
right, the move to git is *not* imminent.

I'm sorry, but I don't see why Eric, who (according to my brief
perusal of the list's archive) has not posted on emacs-devel for about
five years, suddenly has the right to appear here, "suggest" that the
time has come to switch to git, and we should just say "yeah" on *his*
terms.

- He's not bringing any new argument that has not been discussed
before; the only difference is that Richard and Stefan seem to accept
now that Bazaar is beyond hope.

- His message urging us to switch was posted *four days ago*.

- He's appointed himself to the role of technical director of the
switch, deciding when and how we should do it, whether Savannah git
facilities are up to the task, timelines, etc. Why? There's no other
Emacs people with git and/or Savannah experience?

- Last, but not least: emacs-devel was not a democracy before, and it
is not now. Voting and informal polls are great, but at the end of the
day, it's Richard's and Stefan's opinion that counts. Yes, I know that
Eric's message's header says "awaiting Stefan's approval", but
frankly, this:

> Stefan, please either (a) confirm that you as the official maintainer
> are authorizing this, or (b) put a hold on it and explain what
> additional steps or conditions you deem necessary before we move.

is not how a polite request should look IMO. And, I'm sorry, but even
if Stefan says that it's OK and Eric's done nothing wrong and I have
my foot firmly in my mouth, I will still believe that we're being
pushed for no particular reason other than Eric's whims.

    J

Re: Move to git is not imminent - esr is just tired of talking about it

[Karl Fogel]

Juanma Barranquero <lekktu@gmail.com> writes:
>I don't want to switch to Mercurial, so I'm not "siding" with Jordi
>here. I like Bazaar, but I don't oppose switching to git. But Jordi's
>right, the move to git is *not* imminent.
>
>I'm sorry, but I don't see why Eric, who (according to my brief
>perusal of the list's archive) has not posted on emacs-devel for about
>five years, suddenly has the right to appear here, "suggest" that the
>time has come to switch to git, and we should just say "yeah" on *his*
>terms.
>
>- He's not bringing any new argument that has not been discussed
>before; the only difference is that Richard and Stefan seem to accept
>now that Bazaar is beyond hope.
>
>- His message urging us to switch was posted *four days ago*.
>
>- He's appointed himself to the role of technical director of the
>switch, deciding when and how we should do it, whether Savannah git
>facilities are up to the task, timelines, etc. Why? There's no other
>Emacs people with git and/or Savannah experience?

Whether or not there are such people, did you see any of them
volunteering, the way ESR did?

>- Last, but not least: emacs-devel was not a democracy before, and it
>is not now. Voting and informal polls are great, but at the end of the
>day, it's Richard's and Stefan's opinion that counts. Yes, I know that
>Eric's message's header says "awaiting Stefan's approval", but
>frankly, this:
>
>> Stefan, please either (a) confirm that you as the official maintainer
>> are authorizing this, or (b) put a hold on it and explain what
>> additional steps or conditions you deem necessary before we move.
>
>is not how a polite request should look IMO. And, I'm sorry, but even
>if Stefan says that it's OK and Eric's done nothing wrong and I have
>my foot firmly in my mouth, I will still believe that we're being
>pushed for no particular reason other than Eric's whims.

ESR is just trying to get something done in a fairly typical way that we
try to get things done around here.  He didn't "appoint himself"
technical director for the move -- he *volunteered* to do it, and when
no one else stepped forward volunteering the same, ESR proceeded on the
reasonable assumption that the responsibility was his.

Maybe he's being a little pushy as to schedule (I agree the switchover
can wait until after the release), but pushy isn't a sin -- in this case
it may be a virtue :-) -- and it's quite clear that ESR isn't going to
argue if Stefan says to wait until after the freeze is over (or for
whatever reason).  ESR's just trying to get something done, and has laid
his goals out clearly.  It's not just his whim: other people have been
saying for a long time that this move would be desirable.  It happened
that ESR's message came at the right moment, with bzr's decline finally
unmistakeable.

-K

Re: Move to git is not imminent - esr is just tired of talking about it

[Juanma Barranquero]

On Mon, Jan 6, 2014 at 9:06 PM, Karl Fogel <kfogel@red-bean.com> wrote:

> Whether or not there are such people, did you see any of them
> volunteering, the way ESR did?

Why should someone volunteer for something that has *not* yet been
decided, and that was proposed four days ago? Are you sure that no one
would, given a little more time and a little more thought? (And no, I
won't, because I don't have the desire or the technical expertise for
that role, so no sour grapes here.)

> ESR is just trying to get something done in a fairly typical way that we
> try to get things done around here.  He didn't "appoint himself"
> technical director for the move -- he *volunteered* to do it, and when
> no one else stepped forward volunteering the same, ESR proceeded on the
> reasonable assumption that the responsibility was his.

Oh, really? Reasonable? I know you have a lot of knowledge about how
free/open source projects work (great book, BTW). Have you
participated in many projects where someone who is not a regular
contributor, or he is but hasn't been active for years,
single-handledly assumed responsibility for something as important as
a VCS switch and put a date to it, in four days? Because what you call
"volunteering" I would call "trampling".

> Maybe he's being a little pushy as to schedule (I agree the switchover
> can wait until after the release)

I'm happy to see that we can agree at least in two points.

> but pushy isn't a sin -- in this case it may be a virtue :-)

Why? I fail to see any virtue in being pushed.

-- and it's quite clear that ESR isn't going to
> argue if Stefan says to wait until after the freeze is over (or for
> whatever reason).

It's quite clear that Eric is not going to go forward without Stefan's
consent. I wouldn't go to far as to say the he's not going to argue.

   J

Re: Move to git is not imminent - esr is just tired of talking about it

[Karl Fogel]

Juanma Barranquero <lekktu@gmail.com> writes:
>Oh, really? Reasonable? I know you have a lot of knowledge about how
>free/open source projects work (great book, BTW). Have you
>participated in many projects where someone who is not a regular
>contributor, or he is but hasn't been active for years,
>single-handledly assumed responsibility for something as important as
>a VCS switch and put a date to it, in four days? Because what you call
>"volunteering" I would call "trampling".

Like I said, to me he's just being aggressive about getting it done, but
I don't sense that he's trying to trample anything.  (Also, ESR has some
history of activity in Emacs over many years, though lately he has not
been very active -- of course, that's not immediately obvious from just
seeing his post, so it's understandable you might not have known it.)

Thank you for the kind comment about the book, by the way!

Best,
-K

Re: Move to git is not imminent - esr is just tired of talking about it

[Juanma Barranquero]

On Mon, Jan 6, 2014 at 11:12 PM, Karl Fogel <kfogel@red-bean.com> wrote:

> Like I said, to me he's just being aggressive about getting it done, but
> I don't sense that he's trying to trample anything.

We'll have to agree to disagree about that.

>  (Also, ESR has some
> history of activity in Emacs over many years, though lately he has not
> been very active -- of course, that's not immediately obvious from just
> seeing his post, so it's understandable you might not have known it.)

Oh, I was fully aware of that fact when I wrote my message. Changes nothing IMO.

> Thank you for the kind comment about the book, by the way!

You're welcome.

    J

Re: Move to git is not imminent - esr is just tired of talking about it

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Let's not argue about whether ESR should or should not have
volunteered.  He's clearly acting in good faith.  The real question is
whether and when to change VC system, and that is for Stefan to
decide.  He is the Emacs maintainer.

If he decides to move to git, he will also decide whether and how much
to accept ESR's help.

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

Re: Move to git is not imminent - esr is just tired of talking about it

[Juanma Barranquero]

On Tue, Jan 7, 2014 at 5:53 PM, Richard Stallman <rms@gnu.org> wrote:

> He's clearly acting in good faith.

I wasn't questioning *that*.

> The real question is
> whether and when to change VC system, and that is for Stefan to
> decide.

Of course.

   J

Re: Move to git is not imminent - esr is just tired of talking about it

[Bob Bobeck]

There's too much talk and not enough hacking. Can you all stop
flirting and just fork the damn project already if that's what it
takes? Call it esrmacs or whatever the hell, let's just cut this turd
and move on.

On 1/7/14, Richard Stallman <rms@gnu.org> wrote:
> [[[ 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. ]]]
>
> Let's not argue about whether ESR should or should not have
> volunteered.  He's clearly acting in good faith.  The real question is
> whether and when to change VC system, and that is for Stefan to
> decide.  He is the Emacs maintainer.
>
> If he decides to move to git, he will also decide whether and how much
> to accept ESR's help.
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call.
>
>
>
>

RE: Move to git is not imminent - esr is just tired of talking about it

[Drew Adams]

> If we just wanted popularity, we would be putting videos of Miley
> Cyrus on the Emacs splash page.

Finally!  Who said this thread shows no new ideas?

Re: Move to git is not imminent - esr is just tired of talking about it

[Werner LEMBERG]

>> If we just wanted popularity, we would be putting videos of Miley
>> Cyrus on the Emacs splash page.
> 
> Finally!  Who said this thread shows no new ideas?

We might use a wrecking ball as the new logo for Emacs.


     Werner

Re: Move to git is not imminent - esr is just tired of talking about it

[David Kastrup]

Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:

> esr, please don't pretend like the move is a fait accompli. While
> there git is enjoying an obvious popularity, GNU packages doesn't make
> decisions merely based on what is popular. If we just wanted
> popularity, we would be putting videos of Miley Cyrus on the Emacs
> splash page.

"Miley Cyrus" is almost an anagram of Mercurial.

At any rate, we could try to make the gnu on the splash screen twerk for
increased attention.

-- 
David Kastrup

RE: Move to git is not imminent - esr is just tired of talking about it

[Drew Adams]

> we could try to make the gnu on the splash screen twerk
> for increased attention.

+1  "Attention" is one word for it.

Re: Move to git is not imminent - esr is just tired of talking about it

[Juanma Barranquero]

On Mon, Jan 6, 2014 at 6:49 PM, Jordi Gutiérrez Hermoso
<jordigh@octave.org> wrote:

> we would be putting videos of Miley Cyrus on the Emacs splash page.

I would vote for Lorde, myself. Perhaps we should have a thread to
discuss it, unless the switch to Miley Cyrus has already been decided
and is imminent...

   J

Re: Move to git is imminent - awaiting Stefan's approval

[joakim]

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

> The thread on the git move proposal is showing signs of exhaustion and
> terminal topic drift.  We can ask Karl Fogel for a poll count but I
> think we all know how that would turn out; the pro-git vote has
> been overwhelming.
>
> I have asked Andreas Schwab and he reports the Savannah git mirror
> ready for production use. Having examined it, I agree. Andreas and I
> have discussed the switchover and believe it should consist of the
> following steps:
>
> 1. Andreas will turn off bzr commit mirroring.
>
> 2. Andreas will enter a small documentation commit recording the changeover.
>
> 3. Andreas will announce on the dev list that the git repo is live for
>    developer pushes.
>
> 4. I will do the work required to update /etc and /admin for git use
>    over the following few days.
>

What about branches? I have a long-lived branch in the bzr repo.

In my case I can just drop the branch and make a new git repo, but I
think we need a statement on branch handling nevertheless.


> I am now recommending that Andreas perform steps 1-3 at his convenience, no
> sooner than 2014-01-06T11:59:00  and no later than 2014-01-07T11:59:00 -
> that is, sometime tomorrow.
>
> Consideration of workflow changes is explicitly deferred. Developers
> should continue writing ChangeLog entries as per established custom.
>
> I want to extend a thank you to everyone who participated in the
> debate, *including* the anti-git dissenters, for generally sticking to
> real issues and maintaining civility.
>
> Stefan, please either (a) confirm that you as the official maintainer
> are authorizing this, or (b) put a hold on it and explain what 
> additional steps or conditions you deem necessary before we move.

-- 
Joakim Verona

Re: Move to git is imminent - awaiting Stefan's approval

[Andreas Schwab]

joakim@verona.se writes:

> What about branches? I have a long-lived branch in the bzr repo.

All branches are carried over.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Move to git is imminent - awaiting Stefan's approval

[joakim]

Andreas Schwab <schwab@suse.de> writes:

> joakim@verona.se writes:
>
>> What about branches? I have a long-lived branch in the bzr repo.
>
> All branches are carried over.

Fantastic!

> Andreas.

-- 
Joakim Verona

Re: Move to git is imminent - awaiting Stefan's approval

[Martin Geisler]

Eric S. Raymond <esr <at> thyrsus.com> writes:

> 
> The thread on the git move proposal is showing signs of exhaustion and
> terminal topic drift.  We can ask Karl Fogel for a poll count but I
> think we all know how that would turn out; the pro-git vote has
> been overwhelming.

I'm a Mercurial developer, but I wish you luck on the transition! In any
community, people should use the tool they like best and feel most
productive with.

However, let me just add that Facebook recently announced that they're
switching from Subversion to Mercurial after evaluating the performance of
Git. Their conclusion was that Git could not be improved as easily as
Mercurial so they went ahead and made Mercurial fast for their infrastructure:

  https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/

Also, I would like to hear what graphical tools people use with Git that
matches the cross-platform TortoiseHg tool? It is invaluable in showing the
DAG and quickly browsing revisions:

  http://tortoisehg.bitbucket.org/screenshots.html

(The screenshots are mostly from Windows, but I use it daily on Linux.)

-- 
Martin Geisler

Re: Move to git is imminent - awaiting Stefan's approval

[Stefan Monnier]

> Also, I would like to hear what graphical tools people use with Git that

You do realize you're talking to "emacs-devel", right?


        Stefan ;-)

Re: Move to git is imminent - awaiting Stefan's approval

[Martin Geisler]

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

>> Also, I would like to hear what graphical tools people use with Git that
>
> You do realize you're talking to "emacs-devel", right?

Heh, yeah :) I use Emacs and I always use it in X11, so it's a graphical
tool for me.

When I started with Git, the first thing I wondered was where all the
nice graphical tools were and that prompted my question. I don't need a
graphical tool for making commits, but I much prefer a graphical tool
for running annotate and for browsing the history.

-- 
Martin Geisler

Re: Move to git is imminent - awaiting Stefan's approval

[Stefan Monnier]

>>> Also, I would like to hear what graphical tools people use with Git that
>> You do realize you're talking to "emacs-devel", right?
> Heh, yeah :) I use Emacs and I always use it in X11, so it's a graphical
> tool for me.

Exactly, so you have the answer: "people" use Emacs for that.


        Stefan

Re: Move to git is imminent - awaiting Stefan's approval

[Rüdiger Sonderfeld]

On Wednesday 15 January 2014 16:57:56 Martin Geisler wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> >> Also, I would like to hear what graphical tools people use with Git that
> > 
> > You do realize you're talking to "emacs-devel", right?
> 
> Heh, yeah :) I use Emacs and I always use it in X11, so it's a graphical
> tool for me.
> 
> When I started with Git, the first thing I wondered was where all the
> nice graphical tools were and that prompted my question. I don't need a
> graphical tool for making commits, but I much prefer a graphical tool
> for running annotate and for browsing the history.

Magit is probably one of the most popular tools for using git in GNU Emacs.  
It is very nice to use and frequently seems to be the envy from users of other  
editors and users of other version control systems.  And honestly I never saw 
a better integration of a version control system into an editor myself.

(And not to forget vc.el which is shipped with GNU Emacs and provides a nice 
interface to all kinds of version control systems, including git and hg.)

Regards,
Rüdiger

Re: Move to git is imminent - awaiting Stefan's approval

[Yuri Khan]

On Thu, Jan 16, 2014 at 12:23 AM, Martin Geisler <martin@geisler.net> wrote:
>
> Also, I would like to hear what graphical tools people use with Git that
> matches the cross-platform TortoiseHg tool? It is invaluable in showing the
> DAG and quickly browsing revisions:

I use Git GUI and Gitk, which are included out-of-the-box in Windows
and are in separate packages on Debian/Ubuntu. Gitk is for browsing
the DAG (incl. filters by various conditions, e.g. only revisions
which modify a given file) and manipulating branches (branch, reset,
cherry-pick) while Git GUI is a commit tool (good for selective
staging).

Git GUI can also act as a frontend to git blame (when invoked as git
gui blame <filename>), but I usually just use vc-annotate from Emacs
for this.