Re: PROPOSAL: Move to git, now that bzr is no longer a req.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Ting-Yu Lin (林庭宇)]

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

+1 for git.

BTW, it is more pleasant to use git in Emacs with
magit<https://github.com/magit/magit>
.

Tingy-Yu

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

bzr is dying; Emacs needs to move

[Eric S. Raymond]

I am posting this because I think it is my duty as a topic expert in
version-control systems and the surrounding tools to do so, not because
I have any desire to be in the argument that is certain to ensue.

The bzr version control system is dying; by most measures it is
already moribund.  The dev list has flatlined, most of Canonical's
in-house projects have abandoned bzr for git, and one of its senior
developers has written a remarkably candid assessment of why bzr
failed:

http://www.stationary-traveller.eu/pages/bzr-a-retrospective.html

I urge all Emacs developers to read this, then sleep on it, then read
it again - not least because I think Emacs development has fallen into
some of the same traps the author decribes.  But *that* is a discussion for
another day; the conversation we need to have now is about escaping
the gravitational pull of bzr's failure.

In theory, that failure need not affect us at all providing the bzr
codebase is sufficently mature to continue in use as a production
tool.  I judge that, in fact, it *is* sufficiently mature.

In practice, I judge that sticking with bzr would have social and
signaling effects damaging to Emacs's prospects. Sticking to a 
moribund version-control system will compound and exacerbate the 
project's difficulty in attracting new talent.

The uncomfortable truth is that many younger hackers already think
Emacs is a dinosaur - difficult, bulky, armor-plated, and generally
stuck in the last century. If we're going to fight off that image, we
cannot afford to make or adhere to choices that further cast the
project as crusty, insular, and backward-looking.

As of right about now, continuing with bzr is such a choice.  We'll
lose potential recruits, not merely because bzr has a learning cost
but because crusty, insular, etc.  The opportunity cost of not getting
out will only rise with time.

git won the mindshare war.  I regret this - I would have preferred
Mercurial, but it too is not looking real healthy these days.  I have
made my peace with git's victory and switched.  I urge the Emacs
project to do likewise.

I can be technical lead on the migration - as the author of
reposurgeon I have the skills and experience for that (I recently
moved GNU troff from CVS to git). But the project leadership needs
to make the go decision first.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

No one who's seen it in action can say the phrase "government help" without
either laughing or crying.

Re: bzr is dying; Emacs needs to move

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

I don't insist that Emacs should stay with bzr.  I chose to support
bzr because it was still a contender at the time.


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

PROPOSAL: Move to git, now that bzr is no longer a req.

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
>I don't insist that Emacs should stay with bzr.  I chose to support
>bzr because it was still a contender at the time.

Now that RMS has dropped the bzr requirement, I propose we move to git.
ESR has graciously offered to be technical lead for such a migration.

Does anyone think we should stay on bzr, or choose a VCS other than git?

If there is significant support for a different system, then I guess we
should hold a poll.  But my (tentative) expectation is that there will
be a pretty clear overall group preference for git -- 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.

-Karl

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bastien]

Karl Fogel <kfogel@red-bean.com> writes:

> Does anyone think we should stay on bzr, or choose a VCS other than
> git?

+1 for using Git.

-- 
 Bastien

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Nathan Trapuzzano]

Bastien <bzg@gnu.org> writes:

> +1 for using Git.

Ditto.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Toby Cubitt]

On Thu, Jan 02, 2014 at 11:12:42AM -0500, Nathan Trapuzzano wrote:
> Bastien <bzg@gnu.org> writes:
> 
> > +1 for using Git.
> 
> Ditto.

For what it's worth, I agree with moving to git.

It seems clear that it'll happen eventually, even if the decision gets
postponed again this time. But ESR makes a good case for doing it sooner
rather than later.

Toby
-- 
Dr T. S. Cubitt
Royal Society University Research Fellow
and Fellow of Churchill College, Cambridge
Centre for Quantum Information
DAMTP, University of Cambridge

email: tsc25@cantab.net
web:   www.dr-qubit.org

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Jose E. Marchesi]

    
    > Does anyone think we should stay on bzr, or choose a VCS other than
    > git?
    
    +1 for using Git.

Same here.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Ulrich Mueller]

>>>>> On Thu, 02 Jan 2014, Bastien  wrote:

> Karl Fogel <kfogel@red-bean.com> writes:
>> Does anyone think we should stay on bzr, or choose a VCS other than
>> git?

> +1 for using Git.

+1

Using Git would improve my workflow both for maintaining distro
specific patches and for submitting them upstream.

Ulrich

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Mitchel Humpherys]

On Thu, Jan 02 2014 at 07:56:34 AM, Bastien <bzg@gnu.org> wrote:
> Karl Fogel <kfogel@red-bean.com> writes:
>
>> Does anyone think we should stay on bzr, or choose a VCS other than
>> git?
>
> +1 for using Git.

+1

I recently submitted my first (trivial) patch to Emacs. It was painful
enough to deter me from making a few other changes that I've wanted to
make recently... In contrast, I shoot off "drive-by" patches to
third-party Elisp projects about once a week because it's dead simple
with Git. I know that I could become proficient in bzr with a little
effort but it's just not worth the time investment since there are only
2 or 3 projects that I care about using bzr, while everyone else is
using git.


-- 
Mitch

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Sebastian Wiesner]

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

Am 02.01.2014 22:30 schrieb "Mitchel Humpherys" <mitch.special@gmail.com>:
>
> On Thu, Jan 02 2014 at 07:56:34 AM, Bastien <bzg@gnu.org> wrote:
> > Karl Fogel <kfogel@red-bean.com> writes:
> >
> >> Does anyone think we should stay on bzr, or choose a VCS other than
> >> git?
> >
> > +1 for using Git.
>
> +1
>
> I recently submitted my first (trivial) patch to Emacs. It was painful
> enough to deter me from making a few other changes that I've wanted to
> make recently... In contrast, I shoot off "drive-by" patches to
> third-party Elisp projects about once a week because it's dead simple
> with Git. I know that I could become proficient in bzr with a little
> effort but it's just not worth the time investment since there are only
> 2 or 3 projects that I care about using bzr, while everyone else is
> using git.

+1

That's exactly the situation I found in.  I contributed my first patch some
weeks ago, and found Bazaar alone daunting enough to put me off making any
further contributions.

>
>
> --
> Mitch
>

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Fabián Ezequiel Gallina]

Karl Fogel <kfogel@red-bean.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>>I don't insist that Emacs should stay with bzr.  I chose to support
>>bzr because it was still a contender at the time.
>
> Now that RMS has dropped the bzr requirement, I propose we move to git.
> ESR has graciously offered to be technical lead for such a migration.
>
> Does anyone think we should stay on bzr, or choose a VCS other than git?
>

I'm +1 to git. Currently a fair amount of third party packages (and even
the GNU ELPA repository) are using git, making it a sensible choice.

--
Regards,
Fabián.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eric S. Raymond]

Karl Fogel <kfogel@red-bean.com>:
> ESR has graciously offered to be technical lead for such a migration.

Because reposurgeon. I should have known the doom that would fall on 
me when I wrote it - to become the go-to buy for messy repo conversions.
Like groff a couple of weeks ago.

This one *should* be relatively easy, DVCS to DVCS usually is. Cross 
your fingers.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Andreas Schwab]

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

> This one *should* be relatively easy, DVCS to DVCS usually is. Cross 
> your fingers.

There is already git://git.sv.gnu.org/emacs, so there shouldn't be much
to do, if any.

Andreas.

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eric S. Raymond]

Andreas Schwab <schwab@linux-m68k.org>:
> There is already git://git.sv.gnu.org/emacs, so there shouldn't be much
> to do, if any.

Who owns that mirror?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Andreas Schwab]

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

> Andreas Schwab <schwab@linux-m68k.org>:
>> There is already git://git.sv.gnu.org/emacs, so there shouldn't be much
>> to do, if any.
>
> Who owns that mirror?

I'm maintaining the mirroring.

Andreas.

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eric S. Raymond]

Andreas Schwab <schwab@linux-m68k.org>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> 
> > Andreas Schwab <schwab@linux-m68k.org>:
> >> There is already git://git.sv.gnu.org/emacs, so there shouldn't be much
> >> to do, if any.
> >
> > Who owns that mirror?
> 
> I'm maintaining the mirroring.
> 
> Andreas.

As you say, there may be nothing that needs doing other than decommissioning
the bzr repo and changing documentation to point to the git one.

Are you aware of any CVS conversion artifacts that should be cleaned up?  I'm
thinking of, in particular:

1. Unmerged commit cliques.

2. Out-of-place release tags.

3. Fossil CVS commit references in commit comments.

If there is any of this sort of cruft, the time to fix it is before the
git repo goes official.  I have good tools for this.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Andreas Schwab]

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

> Are you aware of any CVS conversion artifacts that should be cleaned
> up?

I did a lot of cleanup when I converted the old CVS repository to bzr.
That included stitching in sources of history in other repositories
(even some tla archives), creating merge commits where the commit
message would indicate, removing dummy commits that were created by CVS
due to files appearing on branches.

> I'm thinking of, in particular:
>
> 1. Unmerged commit cliques.

I don't know what that means.

> 2. Out-of-place release tags.

I think I fixed them all up.

> 3. Fossil CVS commit references in commit comments.

I didn't change any of the commit comments, on purpose.

Andreas.

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eric S. Raymond]

Andreas Schwab <schwab@linux-m68k.org>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> 
> > Are you aware of any CVS conversion artifacts that should be cleaned
> > up?
> 
> I did a lot of cleanup when I converted the old CVS repository to bzr.

Great.  Less work for me. Maybe none; that would be nice.  

What did you use for the cleanup? reposurgeon?  Something else? 

> > I'm thinking of, in particular:
> >
> > 1. Unmerged commit cliques.
> 
> I don't know what that means.

Many converters don't do a perfect job of detecting CVS file commit cliques
that ought to be merged to changesets.  The symptom of this is runs of 
single-file commits with identical comments.  One way it can happen is if
the CVS exporter's commit-time-difference window was set too small.

(It has many other uses now, but I originally wrote reposurgeon to make
cleaning up this kind of artifact easy to do.)

> > 2. Out-of-place release tags.
> 
> I think I fixed them all up.

Oh, good.  One less tedious task.
 
> > 3. Fossil CVS commit references in commit comments.
> 
> I didn't change any of the commit comments, on purpose.

That is one philosophy. 

I, on the other hand, have way too much experience with repositories that
have geological strata of crap from multiple previous conversions in
them. My goal that for someone browsing a history I have converted,
the VCS transitions should be *invisible*.

This means:

1. Changing source-system ignore files to target-system conventions, not
just in the head revision but in the entire history.

3. Fixing up commit references in change comments so they are either in
the target system's native format or in a VCS-independent form.

We may decide these things should not be done in this case.  But I have
the tools and experience to do them, and that option should be on the
table.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> Date: Thu, 2 Jan 2014 13:06:13 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: Karl Fogel <kfogel@red-bean.com>, emacs-devel@gnu.org
> 
> > > 1. Unmerged commit cliques.
> > 
> > I don't know what that means.
> 
> Many converters don't do a perfect job of detecting CVS file commit cliques
> that ought to be merged to changesets.  The symptom of this is runs of 
> single-file commits with identical comments.  One way it can happen is if
> the CVS exporter's commit-time-difference window was set too small.

When Emacs used CVS, we almost never committed several files at once
with the same commit message.  Every file was a separate commit.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> When Emacs used CVS, we almost never committed several files at once
> with the same commit message.  Every file was a separate commit.

That is generally not a problem for convertors, since they have to use a
commit-time window anyway (even if you commit all files with one
command, commit times may still differ, especially for files in separate
directories).

Andreas.

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Andreas Schwab]

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

> What did you use for the cleanup? reposurgeon?  Something else? 

I've used my own scripts.

> Many converters don't do a perfect job of detecting CVS file commit cliques
> that ought to be merged to changesets.  The symptom of this is runs of 
> single-file commits with identical comments.  One way it can happen is if
> the CVS exporter's commit-time-difference window was set too small.

I don't think there are any such occurrences left.

Andreas.

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Thu, 02 Jan 2014 09:41:06 -0600
> 
> Now that RMS has dropped the bzr requirement, I propose we move to git.
> ESR has graciously offered to be technical lead for such a migration.

As Andreas points out, there's nothing to migrate, except ourselves.

> Does anyone think we should stay on bzr, or choose a VCS other than git?

I love bzr and hate git.  I hope Emacs will not switch from bzr in my
lifetime, not to git anyway.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> I love bzr and hate git.  I hope Emacs will not switch from bzr in my
> lifetime, not to git anyway.

I can understand hating git; the UI is pretty nasty, and there is at least
a colorable argument that containerlessness is a bug.  I use git in spite 
of its defects, not because I don't know they're there.

I don't understand loving bzr; my experiences with it have been unpleasant. 
I would be interested to hear your apologia for it.  

Mind you, I think opposing git adoption is like trying to stop the tide
from coming in, at this point (and have my own mixed feelings about that).
But I am genuinely curious about your reasons.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> Date: Thu, 2 Jan 2014 12:28:04 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: Karl Fogel <kfogel@red-bean.com>, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org>:
> > I love bzr and hate git.  I hope Emacs will not switch from bzr in my
> > lifetime, not to git anyway.
> 
> I can understand hating git; the UI is pretty nasty, and there is at least
> a colorable argument that containerlessness is a bug.  I use git in spite 
> of its defects, not because I don't know they're there.

I use git, too.  That's why I hate it, not because I've read about it
in some blog.

> I don't understand loving bzr; my experiences with it have been unpleasant. 
> I would be interested to hear your apologia for it.  

I don't know where to begin.  In a nutshell, it is simple to use, yet
powerful enough to give me several important workflows, and an easy
way to fix any mistakes I happen to make (although lately there are
almost none).  It works on Unix and on Windows alike, and does both
seamlessly.  The UI is orders of magnitude simpler and easier to grasp
that that of git.  The documentation, while it can use some serious
improvement, is nevertheless orders of magnitude more clear than git's
man pages, which seem to have been written by some math professor who
can produce rigorous formal papers, but doesn't have the slightest
idea how to write useful and efficient user documentation.

And of course, everything is similar but subtly different from bzr, to
the point that I need to consult my notes on every step, for fear of
making a mistake.  The switch from CVS to bzr was very simple by
comparison, even though the d in dVCS did require some mind shift.

> Mind you, I think opposing git adoption is like trying to stop the tide
> from coming in, at this point (and have my own mixed feelings about that).

You probably don't know me well enough, if you are surprised by my
trying to stop the tide.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bozhidar Batsov]

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

On 2 January 2014 19:56, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Thu, 2 Jan 2014 12:28:04 -0500
> > From: "Eric S. Raymond" <esr@thyrsus.com>
> > Cc: Karl Fogel <kfogel@red-bean.com>, emacs-devel@gnu.org
> >
> > Eli Zaretskii <eliz@gnu.org>:
> > > I love bzr and hate git.  I hope Emacs will not switch from bzr in my
> > > lifetime, not to git anyway.
> >
> > I can understand hating git; the UI is pretty nasty, and there is at
> least
> > a colorable argument that containerlessness is a bug.  I use git in spite
> > of its defects, not because I don't know they're there.
>
> I use git, too.  That's why I hate it, not because I've read about it
> in some blog.
>
> > I don't understand loving bzr; my experiences with it have been
> unpleasant.
> > I would be interested to hear your apologia for it.
>
> I don't know where to begin.  In a nutshell, it is simple to use, yet
> powerful enough to give me several important workflows, and an easy
> way to fix any mistakes I happen to make (although lately there are
> almost none).  It works on Unix and on Windows alike, and does both
> seamlessly.


Try running bzr with Python 3 for instance... Probably this is never going
to happen. I took quite some time for
bzr to become compatible with Python 2.7. Git works pretty well on Windows
these days, but admitted this was not the situation
few years ago.


> The UI is orders of magnitude simpler and easier to grasp
> that that of git.


Is this so? Many things in bzr seem like black magic to me. Such assertions
are extremely subjective, of course.


> The documentation, while it can use some serious
> improvement, is nevertheless orders of magnitude more clear than git's
> man pages, which seem to have been written by some math professor who
> can produce rigorous formal papers, but doesn't have the slightest
> idea how to write useful and efficient user documentation.
>

I think the git man pages are pretty decent and the online docs are superb.


>
> And of course, everything is similar but subtly different from bzr, to
> the point that I need to consult my notes on every step, for fear of
> making a mistake.  The switch from CVS to bzr was very simple by
> comparison, even though the d in dVCS did require some mind shift.
>

I have the same problem using bzr - as everything is different from git in
subtle and not
so subtle ways.


>
> > Mind you, I think opposing git adoption is like trying to stop the tide
> > from coming in, at this point (and have my own mixed feelings about
> that).
>
> You probably don't know me well enough, if you are surprised by my
> trying to stop the tide.
>

bzr has some pretty serious weaknesses - its conflict resolution mechanism
is terrible for instance.
On the Emacs side of things - git users can benefit from the power of magit
and with bzr we have only vc-dir to work with.
I think this is a tide not worth fighting. I had some problems years ago
migrating from SVN (and the associated mindset) to
git, but once I grokked git I've never looked back.

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> Date: Thu, 2 Jan 2014 20:40:40 +0200
> From: Bozhidar Batsov <bozhidar@batsov.com>
> Cc: Eric Raymond <esr@thyrsus.com>, Karl Fogel <kfogel@red-bean.com>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
> Try running bzr with Python 3 for instance... Probably this is never going
> to happen. I took quite some time for
> bzr to become compatible with Python 2.7.

Why should I care what version of Python is used under the hood?
(Mine is 2.6.6, btw.)

> Git works pretty well on Windows these days

Pretty well my foot: it requires a complete separate shell set up with
a separate PATH, to keep its singular version of MSYS out of my main
development environment.

> bzr has some pretty serious weaknesses - its conflict resolution mechanism
> is terrible for instance.

There's a single command to learn, and once you done that, you will
never have any problems with conflicts.

> On the Emacs side of things - git users can benefit from the power of magit
> and with bzr we have only vc-dir to work with.
> I think this is a tide not worth fighting. I had some problems years ago
> migrating from SVN (and the associated mindset) to
> git, but once I grokked git I've never looked back.

Didn't I tell that I do use git?

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Git works pretty well on Windows these days
>
> Pretty well my foot: it requires a complete separate shell set up with
> a separate PATH, to keep its singular version of MSYS out of my main
> development environment.

This is not correct. You only need git.cmd in the PATH and, IIRC, that
is avoidable too if you use git from Emacs interfaces (VC and/or Magit).

As a curiosity, I'll mention that MSYSGit git.exe doesn't depend on
MSYS.dll (it is a "native" Windows executable.) It would be interesting
to know which functionality is missing if you remove the stuff that
depends on MSYS.dll from MSYSGit package.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 02 Jan 2014 22:22:17 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Git works pretty well on Windows these days
> >
> > Pretty well my foot: it requires a complete separate shell set up with
> > a separate PATH, to keep its singular version of MSYS out of my main
> > development environment.
> 
> This is not correct. You only need git.cmd in the PATH and, IIRC, that
> is avoidable too if you use git from Emacs interfaces (VC and/or Magit).

That is only a solution if you don't use git from the command line.

> As a curiosity, I'll mention that MSYSGit git.exe doesn't depend on
> MSYS.dll

No, but some git commands need Bash and shell scripts, and thus invoke
MSYS programs that do need the MSYS DLL.

> It would be interesting to know which functionality is missing if
> you remove the stuff that depends on MSYS.dll from MSYSGit package.

If someone knows where to find this information, please speak up.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> This is not correct. You only need git.cmd in the PATH and, IIRC, that
>> is avoidable too if you use git from Emacs interfaces (VC and/or Magit).
>
> That is only a solution if you don't use git from the command line.

git.cmd can be used from the command line. BTW, on my latest install
there is no git.cmd, but a single git.exe executable in Git\cmd
directory.

>> As a curiosity, I'll mention that MSYSGit git.exe doesn't depend on
>> MSYS.dll
>
> No, but some git commands need Bash and shell scripts, and thus invoke
> MSYS programs that do need the MSYS DLL.

You don't need MSYS on the PATH, so whatever those commands use is an
interal implementation detail.

[snip]

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 03 Jan 2014 15:53:01 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> This is not correct. You only need git.cmd in the PATH and, IIRC, that
> >> is avoidable too if you use git from Emacs interfaces (VC and/or Magit).
> >
> > That is only a solution if you don't use git from the command line.
> 
> git.cmd can be used from the command line.

Did you actually try that, for real?  git.cmd sets PATH to include
git's binaries, which include MSYS DLL.  This means you cannot use in
the same session any commands that might conflict.  E.g., consider
what would happen if you invoke git.cmd from a Makefile, or the other
way around.  I tried that, and got stuck and crashing programs.  No,
thanks.

> > No, but some git commands need Bash and shell scripts, and thus invoke
> > MSYS programs that do need the MSYS DLL.
> 
> You don't need MSYS on the PATH, so whatever those commands use is an
> interal implementation detail.

No, it isn't.  When MSYS DLL is loaded, any other program that is
linked to that DLL will try to use it -- and will fail if it needs an
incompatible version of that DLL.  Therefore, you can't invoke, say,
the MSYS 'make' from the Git Bash shell, or from any Git command.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> git.cmd can be used from the command line.
>
> Did you actually try that, for real?  git.cmd sets PATH to include
> git's binaries, which include MSYS DLL.  This means you cannot use in
> the same session any commands that might conflict.  E.g., consider
> what would happen if you invoke git.cmd from a Makefile, or the other
> way around.  I tried that, and got stuck and crashing programs.  No,
> thanks.

git.cmd is not meant to permanently set any variable. It is invoked from
a shell as

`git <args>'

Whatever environment variables it sets are effective only until the
command finishes, and for that sole command.

As previously mentioned, there is no git.cmd anymore but a git.exe that
knows where the other commands are located.

>> > No, but some git commands need Bash and shell scripts, and thus invoke
>> > MSYS programs that do need the MSYS DLL.
>> 
>> You don't need MSYS on the PATH, so whatever those commands use is an
>> interal implementation detail.
>
> No, it isn't.  When MSYS DLL is loaded, any other program that is
> linked to that DLL will try to use it -- and will fail if it needs an
> incompatible version of that DLL.  Therefore, you can't invoke, say,
> the MSYS 'make' from the Git Bash shell, or from any Git command.

Are you sure about this? Windows allows multiple DLLs with the same
names and every application will load one of them as per the effective
environment when the application is launched. So if you don't put
MSYSGit binary directory on the PATH, its existence shouldn't make a
difference for the rest of the system. A different history is if you
invoke an MSYS (or Cygwin) executable from MSYSGit, or vice-versa, but
that is an improbable scenario (please keep in mind that git.exe is not
a MSYS binary, so invoking it from Cygwin/MSYS shouldn't be problematic,
at least for the usual git commands.)

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 03 Jan 2014 16:32:46 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> git.cmd can be used from the command line.
> >
> > Did you actually try that, for real?  git.cmd sets PATH to include
> > git's binaries, which include MSYS DLL.  This means you cannot use in
> > the same session any commands that might conflict.  E.g., consider
> > what would happen if you invoke git.cmd from a Makefile, or the other
> > way around.  I tried that, and got stuck and crashing programs.  No,
> > thanks.
> 
> git.cmd is not meant to permanently set any variable. It is invoked from
> a shell as
> 
> `git <args>'
> 
> Whatever environment variables it sets are effective only until the
> command finishes, and for that sole command.

Yes, and what happens if that command then invokes something that is
not in the git's bin directory?

> As previously mentioned, there is no git.cmd anymore but a git.exe that
> knows where the other commands are located.

I still have git.cmd after installing the latest msysgit, FWIW.  Not
that I'm using it.

> >> > No, but some git commands need Bash and shell scripts, and thus invoke
> >> > MSYS programs that do need the MSYS DLL.
> >> 
> >> You don't need MSYS on the PATH, so whatever those commands use is an
> >> interal implementation detail.
> >
> > No, it isn't.  When MSYS DLL is loaded, any other program that is
> > linked to that DLL will try to use it -- and will fail if it needs an
> > incompatible version of that DLL.  Therefore, you can't invoke, say,
> > the MSYS 'make' from the Git Bash shell, or from any Git command.
> 
> Are you sure about this? Windows allows multiple DLLs with the same
> names and every application will load one of them as per the effective
> environment when the application is launched.

Not if they have the same name.  An application that was linked
against FOO.DLL will ask the OS to load the first FOO.DLL on the DLL
search path.  If a DLL with the same base name is already in memory,
Windows doesn't look for it, it just uses what's already in memory.
See this page for the details:

  http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx

You _can_ have different DLLs with the same functionality, but they
must have different names, as in libpng13.dll and libpng16.dll, and
each executable should specify the name it wants in its import table.

When you install both msysgit and MSYS that uses a different MSYS DLL,
you have a small DLL hell on your hands.  That's why I keep them
separate: to avoid that.

> A different history is if you invoke an MSYS (or Cygwin) executable
> from MSYSGit, or vice-versa, but that is an improbable scenario
> (please keep in mind that git.exe is not a MSYS binary, so invoking
> it from Cygwin/MSYS shouldn't be problematic, at least for the usual
> git commands.)

Well, I run git from Bash, so an MSYS binary is already in the air
when I invoke any git commands.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Whatever environment variables it sets are effective only until the
>> command finishes, and for that sole command.
>
> Yes, and what happens if that command then invokes something that is
> not in the git's bin directory?

How could that happen? MSYSGit is self-contained. You can set some git
configuration params for using external diff tools, for instance, but
then you should make sure that those tools are compatible with MSYSGit
(which means, essentially, that no Cygwin or MSYS binaries allowed.)

>> As previously mentioned, there is no git.cmd anymore but a git.exe that
>> knows where the other commands are located.
>
> I still have git.cmd after installing the latest msysgit, FWIW.  Not
> that I'm using it.

I'm using MSYSGit 1.8.4.msysgit.0 and int Git/cmd there is git.exe and
gitk.cmd. There is no git.cmd anywhere. Maybe they reverted that change.

>> Are you sure about this? Windows allows multiple DLLs with the same
>> names and every application will load one of them as per the effective
>> environment when the application is launched.
>
> Not if they have the same name.  An application that was linked
> against FOO.DLL will ask the OS to load the first FOO.DLL on the DLL
> search path.  If a DLL with the same base name is already in memory,
> Windows doesn't look for it, it just uses what's already in memory.
> See this page for the details:
>
>   http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx

Those rules affects a given process. That means that the fact that
process `foo' loaded certain DLLs does not affect which DLLs are loaded
for process `bar', even when `bar' is executed from `foo'.

For Cygwin and MSYS processes the incompatibility doesn't come from the
DLL loading system (assuming that each executable loads the correct DLL,
as it should because they live on the same directory) but from
collisions on objects that are used or created by Cygwin/MSYS.

[snip]

> Well, I run git from Bash, so an MSYS binary is already in the air
> when I invoke any git commands.

It would be quick enough to run some common git commands from MSYS shell
to see if it works: clone, pull, status, log...

BTW, there is MSYS2 [1], that comes with lots of packages (managed with
pacman, an awesome package manager) including git. I built Emacs from
MSYS2 a few days ago and it worked (just a small compile issue related
to MinGW-w64.) MSYSGit is quite faster than MSYS2 git, though.

[1] https://sourceforge.net/projects/msys2/

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 03 Jan 2014 17:28:50 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Whatever environment variables it sets are effective only until the
> >> command finishes, and for that sole command.
> >
> > Yes, and what happens if that command then invokes something that is
> > not in the git's bin directory?
> 
> How could that happen?

You wanna bet?  I prefer an environment where I know what can and what
cannot happen.

> Those rules affects a given process. That means that the fact that
> process `foo' loaded certain DLLs does not affect which DLLs are loaded
> for process `bar', even when `bar' is executed from `foo'.

I invoked 'make' from the Bash that was installed by msysgit.  That
'make' hang.  The same command runs just fine from the MSYS Bash I use
for configuring and building packages.  That's a fact.  I think I know
the reasons, but if you want to disagree and live dangerously, that's
fine by me.

> It would be quick enough to run some common git commands from MSYS shell
> to see if it works: clone, pull, status, log...

I already tried, see above.

> BTW, there is MSYS2 [1], that comes with lots of packages (managed with
> pacman, an awesome package manager) including git. I built Emacs from
> MSYS2 a few days ago and it worked (just a small compile issue related
> to MinGW-w64.) MSYSGit is quite faster than MSYS2 git, though.

Thanks, I know about MSYS2.  My current MSYS environment is well tuned
and satisfies me, so I feel no need to switch.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> You wanna bet?  I prefer an environment where I know what can and what
> cannot happen.

So yo do worry about hypothetical, unknown problems (unknown unknowns).
That's fine, but hardly a serious argument against MSYSGit.

>> Those rules affects a given process. That means that the fact that
>> process `foo' loaded certain DLLs does not affect which DLLs are loaded
>> for process `bar', even when `bar' is executed from `foo'.
>
> I invoked 'make' from the Bash that was installed by msysgit.  That
> 'make' hang.  The same command runs just fine from the MSYS Bash I use
> for configuring and building packages.  That's a fact.  I think I know
> the reasons, but if you want to disagree and live dangerously, that's
> fine by me.

IIUC you invoked MSYS `make' from MSYSGit `bash'. As I said multiple
times, that's not expected to work.

>> It would be quick enough to run some common git commands from MSYS shell
>> to see if it works: clone, pull, status, log...
>
> I already tried, see above.

No, you didn't. As git.exe does not depend on MSYS.dll, the problems you
experienced with `make' shouldn't happen. And, indeed, invoking MSYSGit
git.exe from a MSYS terminal worked fine for the commands I mentioned
above.

[snip]

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 03 Jan 2014 21:37:08 +0100
> 
> > I invoked 'make' from the Bash that was installed by msysgit.  That
> > 'make' hang.  The same command runs just fine from the MSYS Bash I use
> > for configuring and building packages.  That's a fact.  I think I know
> > the reasons, but if you want to disagree and live dangerously, that's
> > fine by me.
> 
> IIUC you invoked MSYS `make' from MSYSGit `bash'. As I said multiple
> times, that's not expected to work.

Right, and that's why I keep the two segregated.  That was all I was
saying from day one: it's a PITA to have two similar, but incompatible
environments.  E.g., I cannot build a package from the same shell
where I "git pull" it.

> >> It would be quick enough to run some common git commands from MSYS shell
> >> to see if it works: clone, pull, status, log...
> >
> > I already tried, see above.
> 
> No, you didn't. As git.exe does not depend on MSYS.dll, the problems you
> experienced with `make' shouldn't happen. And, indeed, invoking MSYSGit
> git.exe from a MSYS terminal worked fine for the commands I mentioned
> above.

Until that git.exe invokes a sub-command that needs Bash or Perl, and
will then invoke its own Bash pr Perl that need an incompatible
msys.dll (and other DLLs, like libiconv).

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> IIUC you invoked MSYS `make' from MSYSGit `bash'. As I said multiple
>> times, that's not expected to work.
>
> Right, and that's why I keep the two segregated.  That was all I was
> saying from day one: it's a PITA to have two similar, but incompatible
> environments.  E.g., I cannot build a package from the same shell
> where I "git pull" it.

As already mentioned, you can `git pull' on a MSYS shell, so it is false
that you can't `make' on the same shell that you did the `pull'
operation.

>> No, you didn't. As git.exe does not depend on MSYS.dll, the problems you
>> experienced with `make' shouldn't happen. And, indeed, invoking MSYSGit
>> git.exe from a MSYS terminal worked fine for the commands I mentioned
>> above.
>
> Until that git.exe invokes a sub-command that needs Bash or Perl, and
> will then invoke its own Bash pr Perl that need an incompatible
> msys.dll (and other DLLs, like libiconv).

Curiously enough, `git pull' seems to be a Perl script (the executables
and scripts are on Git/libexec/git-core.) But it works from MSYS, hence
somehow the problem is not so serious.

I suggest that for the time being we stop worrying about what unkown
problems might be lurking and wait for something concrete to
materialize.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 03 Jan 2014 22:38:35 +0100
> 
> Curiously enough, `git pull' seems to be a Perl script (the executables
> and scripts are on Git/libexec/git-core.) But it works from MSYS, hence
> somehow the problem is not so serious.

For you, maybe, and with the current versions of the MSYS DLL that you
have in msysgit and in MSYS.  But relying on this is living
dangerously and _will_ some day require you to deal with strange
failures and crashes during a build.  No, thanks.  I've fought that
war once and decided that I never again want to go that way.

> I suggest that for the time being we stop worrying about what unkown
> problems might be lurking and wait for something concrete to
> materialize.

If you use MSYS and msysgit my way, you don't have to wait for
anything to materialize, because it won't.  It's just inconvenient, as
I need to have 2 separate shell sessions open at all times, and
remember to switch to the right one depending on what I want to do.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

> If you use MSYS and msysgit my way, you don't have to wait for
> anything to materialize, because it won't.  It's just inconvenient, as
> I need to have 2 separate shell sessions open at all times, and
> remember to switch to the right one depending on what I want to do.

Why do you need an MSYSGit shell open at all times? Have you tried any
of the Emacs interfaces for Git? (I highly recommend Magit, which is
*immensely* more convenient than the command line for everyday's work)

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 04 Jan 2014 18:30:53 +0100
> 
> Why do you need an MSYSGit shell open at all times?

Because that's the only way to ensure everything in git will work as
best as it can.

> Have you tried any of the Emacs interfaces for Git? (I highly
> recommend Magit, which is *immensely* more convenient than the
> command line for everyday's work)

I don't trust any of these interfaces to work correctly with MSYS
based commands and scripts, sorry.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Why do you need an MSYSGit shell open at all times?
>
> Because that's the only way to ensure everything in git will work as
> best as it can.
>
>> Have you tried any of the Emacs interfaces for Git? (I highly
>> recommend Magit, which is *immensely* more convenient than the
>> command line for everyday's work)
>
> I don't trust any of these interfaces to work correctly with MSYS
> based commands and scripts, sorry.

So you are using an inconvenient setup because you are afraid of
hypothetical problems and refuse to switch to an alternative, convenient
setup because you are afraid of other, even more hypothetical problems?
:-)

I'm using MSYSGit + VC + Magit on Windows for several years and it never
caused a single data-loss issue. At the very beginning, long time ago, I
had problems with line-endings but then MSYSGit was "fixed".

OTOH I have a hack on my .emacs to prevent Emacs + Bzr from garbling the
commit messages. Something related to character encodings.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 04 Jan 2014 21:19:43 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Why do you need an MSYSGit shell open at all times?
> >
> > Because that's the only way to ensure everything in git will work as
> > best as it can.
> >
> >> Have you tried any of the Emacs interfaces for Git? (I highly
> >> recommend Magit, which is *immensely* more convenient than the
> >> command line for everyday's work)
> >
> > I don't trust any of these interfaces to work correctly with MSYS
> > based commands and scripts, sorry.
> 
> So you are using an inconvenient setup because you are afraid of
> hypothetical problems and refuse to switch to an alternative, convenient
> setup because you are afraid of other, even more hypothetical problems?
> :-)

They are not hypothetical, believe me.  I have a lot gray hair to
vouch for that, and too little time to waste on this again.

> I'm using MSYSGit + VC + Magit on Windows for several years and it never
> caused a single data-loss issue.

Good for you.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> They are not hypothetical, believe me.  I have a lot gray hair to
> vouch for that, and too little time to waste on this again.

If you experienced problems, Magit/MSYSGit/Emacs maintainers will be
happy to address them.

>> I'm using MSYSGit + VC + Magit on Windows for several years and it never
>> caused a single data-loss issue.
>
> Good for you.

Thanks. I think it is important that people reading this ml should not
end under the impression that using Git on Windows is problematic.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 04 Jan 2014 21:47:43 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > They are not hypothetical, believe me.  I have a lot gray hair to
> > vouch for that, and too little time to waste on this again.
> 
> If you experienced problems, Magit/MSYSGit/Emacs maintainers will be
> happy to address them.

These problems cannot be helped, because they stem from fundamental
incompatibilities between native and MSYS programs.

> I think it is important that people reading this ml should not end
> under the impression that using Git on Windows is problematic.

It's not problematic, but it has its annoyances.  I think it's
important that people reading this ml know the truth, even if it is
not entirely nice.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[David De La Harpe Golden]

On 03/01/14 20:12, Eli Zaretskii wrote:

> Thanks, I know about MSYS2.  My current MSYS environment is well tuned
> and satisfies me, so I feel no need to switch.
>
>

Just had a weird idea, though after searching looks like I mightn't have 
been the only one in history to have it [1]:

Have you ever tried jgit [2] on windows i.e. that pure java 
reimplementation of git?  It was mostly developed by and for use with 
Eclipse (ugh), but actually has its own little standalone command line 
interface. Not as featureful as real git, but pretty self-contained, it 
looks like it might have just about enough for a reasonable dev workflow 
on its own [3].

This is not a recommendation, I've never used the thing, might be a dead 
end, but OTOH might be worth a look.

[1] 
http://sandeep.wordpress.com/2010/09/13/using-git-on-windows-without-any-of-the-cygwinmsysgit-nonsense/

[2] http://www.eclipse.org/jgit/
[3] http://wiki.eclipse.org/JGit/User_Guide#Running_the_JGit_CLI

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Óscar Fuentes]

David De La Harpe Golden <david@harpegolden.net> writes:

> Just had a weird idea, though after searching looks like I mightn't
> have been the only one in history to have it [1]:
>
> Have you ever tried jgit [2] on windows i.e. that pure java
> reimplementation of git?  It was mostly developed by and for use with
> Eclipse (ugh), but actually has its own little standalone command line
> interface. Not as featureful as real git, but pretty self-contained,
> it looks like it might have just about enough for a reasonable dev
> workflow on its own [3].
>
> This is not a recommendation, I've never used the thing, might be a
> dead end, but OTOH might be worth a look.
>
> [1]
> http://sandeep.wordpress.com/2010/09/13/using-git-on-windows-without-any-of-the-cygwinmsysgit-nonsense/
>
> [2] http://www.eclipse.org/jgit/
> [3] http://wiki.eclipse.org/JGit/User_Guide#Running_the_JGit_CLI

First of all, I object against the FUD on the blog post [1]. For all
practical effects, there is nothing *nixy about Git on Windows (as
implemented by MSYSGit) You can use git.exe from a Windows command
prompt and you are not required to use the *nixy tools that comes with
the MSYSGit package.

Second, there are some great Emacs front-ends for git you can use on
Windows (Magit) and Emacs own VC works fine. Even if that java tool is
compatible with git's command-line options required by Emacs (something
I doubt) using it from Emacs would be damn slow, unless it supports some
type of server functionality where a single instance serves multiple
requests.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Óscar Fuentes]

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

> Eli Zaretskii <eliz@gnu.org>:
>> I love bzr and hate git.  I hope Emacs will not switch from bzr in my
>> lifetime, not to git anyway.
>
> I can understand hating git; the UI is pretty nasty,
[snip]

Emacs has some superb front-ends for git. They do a great job at hiding
the underlying UI. I loathe git command line but Magit is among the
tools that makes me enjoy my job.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stephen J. Turnbull]

Eric S. Raymond writes:

 > I don't understand loving bzr; my experiences with it have been
 > unpleasant.

If you use basically centralized workflows (and Emacs's *is* basically
centralized -- that's why people bitch so much about feature freeze,
for example), bzr has a lot of optimizations for that.

 > Mind you, I think opposing git adoption is like trying to stop the
 > tide from coming in, at this point (and have my own mixed feelings
 > about that).

You got that right.  I don't have any mixed feelings about it, though;
Bazaar does its best to prevent me from working the way I think, while
Mercurial got its colocated branching wrong, although the mq extension
makes up for that to a great extent.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stefan Monnier]

> I love bzr and hate git.  I hope Emacs will not switch from bzr in my
> lifetime, not to git anyway.

I've learned to appreciate Bzr and have trouble reproducing my
workflow with Git (especially the shared repository which Git seems only
able to somewhat approximate in a half-assed way, not mentioning the
lightweight checkouts which Git seems unable to handle).

But I really hope you don't die before Emacs switches to Git, because
I think this switch will happen pretty soon.


        Stefan

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Daniel Colascione]

On 01/02/2014 11:48 AM, Stefan Monnier wrote:
> I've learned to appreciate Bzr and have trouble reproducing my
> workflow with Git (especially the shared repository which Git seems only
> able to somewhat approximate in a half-assed way, not mentioning the
> lightweight checkouts which Git seems unable to handle).

What do you mean? git clone will use hardlinks when cloning a local 
repository, so it's very fast for me. Isn't speed (and some space 
efficiency) the reason to use bzr shared repositories?

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stefan Monnier]

>> I've learned to appreciate Bzr and have trouble reproducing my
>> workflow with Git (especially the shared repository which Git seems only
>> able to somewhat approximate in a half-assed way, not mentioning the
>> lightweight checkouts which Git seems unable to handle).
> What do you mean? git clone will use hardlinks when cloning a local
> repository, so it's very fast for me.

Yes, it's shared when you "git clone" but 3 years down the line, there's
not much sharing left.  I.e. the sharing is only approximated.

> Isn't speed (and some space efficiency) the reason to use bzr
> shared repositories?

Yes, speed and space (inefficient space usage is a problem both for
speed and for backup purposes).


        Stefan

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[David De La Harpe Golden]

On 02/01/14 21:05, Stefan Monnier wrote:

> Yes, it's shared when you "git clone" but 3 years down the line, there's
> not much sharing left.  I.e. the sharing is only approximated.
>

Hmm. Is it really git-new-workdir you're wanting? So you can have a few 
working trees for different branches from the one repo live at once?

On a typical debian box, it'll be squirreled away in
/usr/share/doc/git/contrib/workdir/git-new-workdir

(along with a whole bunch of other sorta-useful probably-working things 
that haven't quite made it into git's grab-bag of official commands.)

Someone's got a blog post here about it:

http://nuclearsquid.com/writings/git-new-workdir/

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Andreas Schwab]

David De La Harpe Golden <david@harpegolden.net> writes:

> Hmm. Is it really git-new-workdir you're wanting? So you can have a few
> working trees for different branches from the one repo live at once?
>
> On a typical debian box, it'll be squirreled away in
> /usr/share/doc/git/contrib/workdir/git-new-workdir

FWIW, there is work in progress making git new-workdir a first class git
citizen (ie. moving its functionality to git-core and fixing its
shortcomings).

Andreas.

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stefan Monnier]

> Hmm.  Is it really git-new-workdir you're wanting?

Yes, but without its shortcomings.


        Stefan

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Karl Fogel <kfogel@red-bean.com>,  emacs-devel@gnu.org
> Date: Thu, 02 Jan 2014 14:48:56 -0500
> 
> But I really hope you don't die before Emacs switches to Git

I might die of sadness.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[joakim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Karl Fogel <kfogel@red-bean.com>,  emacs-devel@gnu.org
>> Date: Thu, 02 Jan 2014 14:48:56 -0500
>> 
>> But I really hope you don't die before Emacs switches to Git
>
> I might die of sadness.
>

Keeping Eli happy is imho a pretty important use case for the vcs used
by Emacs. No, really. We don't have many hard-core contributors.

I prefer git, but I think I get along pretty well with the git-bzr
bridge.

Perhaps it would be possible to use bzr on top of a git repo, such that
everyone can be happy?
-- 
Joakim Verona

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: joakim@verona.se
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  kfogel@red-bean.com,  emacs-devel@gnu.org
> Date: Fri, 03 Jan 2014 07:33:00 +0100
> 
> Keeping Eli happy is imho a pretty important use case for the vcs used
> by Emacs. No, really. We don't have many hard-core contributors.

Thank you.

> Perhaps it would be possible to use bzr on top of a git repo, such that
> everyone can be happy?

No, this isn't workable.  I tried that in the past with several git
repositories.  The bzr-git plugin is unfinished (the biggest
shortcoming is that it doesn't support pushing), and its developer
officially announced he no longer works on it.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Juanma Barranquero]

On Fri, Jan 3, 2014 at 7:33 AM,  <joakim@verona.se> wrote:

> Keeping Eli happy is imho a pretty important use case for the vcs used
> by Emacs. No, really. We don't have many hard-core contributors.

+1

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bastien]

It seems to me that this thread is taking a wrong path:
it started as "please use Git" and continues as "please
keep Eli."

Maybe Eli if you could suggest an alternative to bzr
(that is not Git, which you hate) people would be open
to your suggestions?

I for one would be open to using another dVCS as long
as it makes current contributors happier and allows to
get more contributions.

-- 
 Bastien

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[David Engster]

Bastien writes:
> It seems to me that this thread is taking a wrong path:
> it started as "please use Git" and continues as "please
> keep Eli."

It's exactly the right path. There's a real danger of reducing the
productivity of one of the most important core developers.

> I for one would be open to using another dVCS as long
> as it makes current contributors happier and allows to
> get more contributions.

I predict there won't be a significant increase in new
contributions. The real hurdles to participate in Emacs development lie
elsewhere.

-David

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Date: Fri, 03 Jan 2014 14:46:56 +0100
> Cc: Juanma Barranquero <lekktu@gmail.com>, Joakim Verona <joakim@verona.se>,
> 	Emacs developers <emacs-devel@gnu.org>, Karl Fogel <kfogel@red-bean.com>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>
> 
> I predict there won't be a significant increase in new
> contributions. The real hurdles to participate in Emacs development
> lie elsewhere.

I'm afraid you are right.  What's more, I don't see new people coming
aboard who would advance Emacs into the future (as opposed to
contributing minor improvements and bugfixes -- which are, of course,
important as well).  I hope I'm wrong, and they will come, with or
without git.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Tom]

David Engster <deng <at> randomsample.de> writes:
> 
> I predict there won't be a significant increase in new
> contributions. The real hurdles to participate in Emacs development lie
> elsewhere.

The more roadblocks are removed the better.

There were several people in this thread who said bzr kept them 
from contributing. (Unfamiliar DVCS while git is becoming the
DVCS which is pretty much known by everyone these days.)

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[David Engster]

Tom writes:
> David Engster <deng <at> randomsample.de> writes:
>> 
>> I predict there won't be a significant increase in new
>> contributions. The real hurdles to participate in Emacs development lie
>> elsewhere.
>
> The more roadblocks are removed the better.

Well, the switch will happen, so let's just wait and see. I'd love to be
proven wrong.

> There were several people in this thread who said bzr kept them 
> from contributing.

No offense to those guys, but in my book, Eli's vote counts more.

-David

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eric S. Raymond]

David Engster <deng@randomsample.de>:
> I predict there won't be a significant increase in new
> contributions. The real hurdles to participate in Emacs development lie
> elsewhere.

It's not "or", but "and".

The fact that there are other reasons contribution is difficult (and yes, I 
have a fairly long list in mind) does not mean that the friction losses 
inflicted by bzr are acceptable.

We have direct testimony in this thread from two people who wanted to
contribute but found bzr a crash landing.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Cc: Joakim Verona <joakim@verona.se>,  Karl Fogel <kfogel@red-bean.com>,  Eli Zaretskii <eliz@gnu.org>,  Stefan Monnier <monnier@iro.umontreal.ca>,  Emacs developers <emacs-devel@gnu.org>
> Date: Fri, 03 Jan 2014 14:01:19 +0100
> 
> It seems to me that this thread is taking a wrong path:
> it started as "please use Git" and continues as "please
> keep Eli."

I didn't feel it was that way.  Karl asked for opinions and I provided
mine.  I hope no one, including Karl, expected to hear only the YES
kind of responses.  I didn't ask anyone to please me, and didn't say I
will stop working on Emacs if it did switch.

> Maybe Eli if you could suggest an alternative to bzr
> (that is not Git, which you hate) people would be open
> to your suggestions?

I don't see the need.  Either we switch to git or we don't, it's that
simple.  No one will switch to anything else.

> I for one would be open to using another dVCS as long
> as it makes current contributors happier and allows to
> get more contributions.

As someone else said, git sucked all the oxygen there was, so here we
are.  As for more contributions, I hope you are right, but I have my
doubts.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

> I didn't ask anyone to please me, and didn't say I
> will stop working on Emacs if it did switch.

Okay.  It was suggested that the switch would discourage
you from contributing, I'm glad to read otherwise.

>> Maybe Eli if you could suggest an alternative to bzr
>> (that is not Git, which you hate) people would be open
>> to your suggestions?
>
> I don't see the need.  Either we switch to git or we don't, it's that
> simple.  No one will switch to anything else.

(I thought Mercurial was another possible choice.)

>> I for one would be open to using another dVCS as long
>> as it makes current contributors happier and allows to
>> get more contributions.
>
> As someone else said, git sucked all the oxygen there was, so here we
> are.  As for more contributions, I hope you are right, but I have my
> doubts.

I don't think we will magically get tons of new contributors,
but I know that past contributors like Thierry V. and John W.
said they are more likely to contribute back again, which
already counts as "more contributors" for me.

-- 
 Bastien

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eric S. Raymond]

Bastien <bzg@gnu.org>:
> I don't think we will magically get tons of new contributors,
> but I know that past contributors like Thierry V. and John W.
> said they are more likely to contribute back again, which
> already counts as "more contributors" for me.

Another one of those people is me.

There are other reasons I've been inactive, but I too have found 
bzr a significant blocker.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Antonio Nikishaev]

Eli Zaretskii <eliz@gnu.org> writes:

>> Maybe Eli if you could suggest an alternative to bzr
>> (that is not Git, which you hate) people would be open
>> to your suggestions?
>
> I don't see the need.  Either we switch to git or we don't, it's that
> simple.  No one will switch to anything else.

There is hg. It's pretty popular.

(And it has nice ui and far less wtfs than git)

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stephen J. Turnbull]

Antonio Nikishaev writes:

 > There is hg. It's pretty popular.

True, but it doesn't have the momentum of git.

 > (And it has nice ui and far less wtfs than git)

Git has not WTF'ed me since the first week I used it.  But then, I
thought the concept was cool and read the whole theory of operations
part of the old man page (several times until I understood it).  Most
developers don't want to do that, which is not a problem.  But many of
those developers also want git to fit their preconceptions, which it
doesn't, and that is a problem.

Mercurial, OTOH, has several WTFs, sufficiently F-ed up that I don't
ever use the corresponding features ("named branches", rebase, there
are several others less important).

I also don't really understand the complaints about the git CLI.  I
have a fairly complex set of practices in git, but I use the same
number of commands and *fewer* options in git than I do in hg or bzr.
(This can be improved by using plugins.)  And when I want to do
something complex in git (like filter-branch), I *can* do it, whereas
I can't in hg or bzr.

I'll grant that git's ref-relative commit addressing (including the
whole ref algebra of HEAD^2~6^3) was a bit disconcerting at first, but
it saves me substantial keystrokes compared to the bzr and hg
equivalents (not to mention a lot of screen space that isn't used up
with log or id commands to get hold of a revno).

It's true that Bazaar has some useful features, such as shared repos,
whose performance characteristics are hard to emulate accurately in
git.  I can't speak to Stefan's experience, of course, but when I look
at my git repos, in fact sharing is quite high because branches in
separate repos tend to be very divergent (so only the original shared
objects *can* be shared), and when the main feature branch gets
merged, the whole repo usually gets deleted so the failure of "git
fetch" to hardlink pulled objects isn't a big space leak.  I also
periodically clean up dormant branches by pulling them into a
"warehouse" repo, and then deleting the separate repo.  (I have plenty
of space, this is to clean up the directory listing, not the disk
usage.  But it sure helps conserve disk.)

The only bzr features that I don't see how to emulate effectively in
git are "log -n ...", bound branches, and lightweight checkouts.  But
I've never missed them in git.  I suspect that when the move to git
happens, Stefan will find alternative, functionally equivalent,
workflows appropriate to git after a while.  Unfortunately I can't
promise that.  (In the case of log -n, I far prefer the graphical DAG
displays anyway.)

Steve

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Barry Warsaw]

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

On Jan 04, 2014, at 05:15 AM, Stephen J. Turnbull wrote:

>It's true that Bazaar has some useful features, such as shared repos,
>whose performance characteristics are hard to emulate accurately in
>git.  I can't speak to Stefan's experience, of course, but when I look
>at my git repos, in fact sharing is quite high because branches in
>separate repos tend to be very divergent (so only the original shared
>objects *can* be shared), and when the main feature branch gets
>merged, the whole repo usually gets deleted so the failure of "git
>fetch" to hardlink pulled objects isn't a big space leak.

I know Stephen knows this, but Bazaar shared repos are really just a way to
efficiently store revision objects in a parent directory, such that you can
have a number of subdirectories inside there that represent working
directories of different branches.  Or put it another way, it just moves the
.bzr directory up one level so everything underneath it can share that.  In
most cases, most branches share probably 90% of their revisions, and that's
what makes local branching and remote pulling into a shared repo pretty fast.

I'm another big bzr fan, and while colocated branches are interesting, I find
them to be completely counter to my way of working.  If I'm going to be
working on a number of branches, I want separate working directories for each.
So for example, in Mailman (under bzr) I'll have a shared repo directory
containing working directories each containing a different in-progress feature
(topic) branch.

For Python hg's and other projects git repos, I basically have multiple clones
inside a parent directory that's nothing special.  It works, but doesn't map
to my way of working as well as bzr.

The other thing I sorely miss when working with git repositories is bzr's main
line of development approach.  Once you understand this, and use it correctly
(i.e. merges in the right direction), it's a very nice simplifying feature.
It allows you to have human friendly revision numbers[1], with dotted revision
numbers for side branches.  More importantly, it means that there's no cultural
pressure for history changing rebases, `bzr log` by default only follows the
main line (so side branches are hidden by default, unless you *want* to see
them), and bisect doesn't make you unhappy by landing you in non-working
revisions.

I think if git had this concept and --help text that wasn't 20 pages long (629
lines for `git merge --help`!) it would go a long way to improving the user
friendliness of git, IMHO of course.

That said, it's pretty clear that git has won this round of dVCS wars.
Mercurial will probably hang on and hopefully even thrive as a viable
alternative, but network effects have given git most of the mindshare.  At
least until something better comes along, as it has with CVS and svn in their
times.

-Barry

[1] Yes, they are local-only, and yes they can change, and yes you still have
unique hashes to unambiguously reference a revision, but it's still darn
convenient.  I'd much rather say "Are you on revision 7250 of branch
lp:mailman?"

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
>I didn't feel it was that way.  Karl asked for opinions and I provided
>mine.  I hope no one, including Karl, expected to hear only the YES
>kind of responses.  I didn't ask anyone to please me, and didn't say I
>will stop working on Emacs if it did switch.

Eli's response was exactly the kind of information I was hoping to
elicit, yes.

I also agree that a vote from someone like Eli should somehow count more
than a vote from (say) me.  But even adjusting for that, the total vote
weight in favor of switching to git is still pretty clear in this
thread, as others have noted.

>I don't see the need.  Either we switch to git or we don't, it's that
>simple.  No one will switch to anything else.

That does seem right.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stefan Monnier]

> Maybe Eli if you could suggest an alternative to bzr
> (that is not Git, which you hate) people would be open
> to your suggestions?

That would be pointless.  As it stands currently, it's either Bzr
or Git.  The arguments in favor of Git aren't technical but social and
I can't see any other VCS where similar social pressure applies.

From where I stand, it seems pretty clear that Emacs will switch to Git,
the only remaining question is when.


        Stefan

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Ted Zlatanov]

On Fri, 03 Jan 2014 09:54:39 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> From where I stand, it seems pretty clear that Emacs will switch to Git,
SM> the only remaining question is when.

After the code freeze?  Pleeze?

Ted

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Karl Fogel]

Ted Zlatanov <tzz@lifelogs.com> writes:
>On Fri, 03 Jan 2014 09:54:39 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
>
>SM> From where I stand, it seems pretty clear that Emacs will switch to Git,
>SM> the only remaining question is when.
>
>After the code freeze?  Pleeze?

+1.  No need for us to pick gratuitously inconvenient timing.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I love bzr and hate git.  I hope Emacs will not switch from bzr in my
> lifetime, not to git anyway.

I have no fondness for git (it has a way of complicating things
unnecessarily), but I do think it would be a good idea to switch over.
And if we do make the switch, I hope your hope doesn't come true.  >"?

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Ted Zlatanov]

On Thu, 02 Jan 2014 23:31:19 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Eli Zaretskii <eliz@gnu.org> writes:
>> I love bzr and hate git.  I hope Emacs will not switch from bzr in my
>> lifetime, not to git anyway.

LMI> I have no fondness for git (it has a way of complicating things
LMI> unnecessarily), but I do think it would be a good idea to switch over.
LMI> And if we do make the switch, I hope your hope doesn't come true.  >"?

Predictably, I'm strongly in favor of moving to Git.  Besides the things
listed already, I think it will make the life of Katsumi Yamaoka, who
tirelessly synchronizes commits between Gnus and Emacs, a bit easier
when both those projects are using Git.

Ted

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[David Engster]

Ted Zlatanov writes:
> Besides the things listed already, I think it will make the life of
> Katsumi Yamaoka, who tirelessly synchronizes commits between Gnus and
> Emacs, a bit easier when both those projects are using Git.

It should at least be noted that CEDET is using bzr, and when Emacs
switches, we will probably have to do that as well; not really for
technical reasons, but simply to not be the last man standing.

I don't see which advantages git has w.r.t. cross-repository merges. It
really boils down to playing the patch|diff game.

-David

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Christoph]

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

On Thu, Jan 2, 2014 at 8:41 AM, Karl Fogel <kfogel@red-bean.com> wrote:

>
> Does anyone think we should stay on bzr, or choose a VCS other than git?
>

+1 for git.

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bozhidar Batsov]

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

+1 from me for migration to git.

On 2 January 2014 17:41, Karl Fogel <kfogel@red-bean.com> wrote:

> Richard Stallman <rms@gnu.org> writes:
> >I don't insist that Emacs should stay with bzr.  I chose to support
> >bzr because it was still a contender at the time.
>
> Now that RMS has dropped the bzr requirement, I propose we move to git.
> ESR has graciously offered to be technical lead for such a migration.
>
> Does anyone think we should stay on bzr, or choose a VCS other than git?
>
> If there is significant support for a different system, then I guess we
> should hold a poll.  But my (tentative) expectation is that there will
> be a pretty clear overall group preference for git -- 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.
>
> -Karl
>
>

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Daniel Colascione]

On 01/02/2014 07:41 AM, Karl Fogel wrote:
> Now that RMS has dropped the bzr requirement, I propose we move to git.
> ESR has graciously offered to be technical lead for such a migration.

+1 for git. Mercurial would be acceptable as well, but I prefer git: hg 
got branching wrong and git got it right. Sure, git's UI is finnicky, 
but it's the emerging standard, and there's an incredibly rich ecosystem 
built around it.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Paul Eggert]

+1 for git as well.  It has its flaws but it's significantly better
for my usage.  Disclaimer: I'm biased, as the lead git developer
is a friend of mine.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Michael Albinus]

Karl Fogel <kfogel@red-bean.com> writes:

> Does anyone think we should stay on bzr, or choose a VCS other than git?

+1 for git. No tremendous technical reason (I can live with any VCS
supported by vc.el), but Tramp lives already in git, and the sync
between Tramp and Emacs might be easier then.

> -Karl

Best regards, Michael.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Xue Fuqiao]

On Thu, Jan 2, 2014 at 11:41 PM, Karl Fogel <kfogel@red-bean.com> wrote:
> Now that RMS has dropped the bzr requirement, I propose we move to git.
> ESR has graciously offered to be technical lead for such a migration.
>
> Does anyone think we should stay on bzr, or choose a VCS other than git?

+1 for using Git.  IIRC there are major bugs which have been in their
bug-tracker for years now.

And this problem has troubled me for a long time:
http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/75075

-- 
http://www.gnu.org/software/emacs/

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stephen Eglen]

On Thu, Jan 02 2014, Karl Fogel wrote:

> If there is significant support for a different system, then I guess we
> should hold a poll.  But my (tentative) expectation is that there will
> be a pretty clear overall group preference for git -- 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.

+1 for git.

John Wiegley's posts in this thread convinced me of this last year, and
it seems nothing has changed to weaken the usefulness of git.

  http://comments.gmane.org/gmane.emacs.devel/158242

Stephen

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Thierry Volpiatto]

+1 for git.
I have stopped contributing to emacs to avoid using bzr.
I have even removed myself from emacs savanah.
Also would be great to stop writing unuseful changelog files.

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Michael Albinus]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Also would be great to stop writing unuseful changelog files.

They are useful. A tar distribution does not contain the git repo with
the history of commitments.

Another question is, whether we still want to write ChangeLogs manually,
or whether we want to extract them from commit comments. That's not such
easy, see all the "fix typo" comments.

Best regards, Michael.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Thierry Volpiatto]

Michael Albinus <michael.albinus@gmx.de> writes:

> They are useful. A tar distribution does not contain the git repo with
> the history of commitments.

Not sure people getting their emacs from tarball read changelog files...
Anyway they can read these infos online.

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bastien]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> They are useful. A tar distribution does not contain the git repo with
>> the history of commitments.
>
> Not sure people getting their emacs from tarball read changelog
> files...

I do, when testing release candidates.

> Anyway they can read these infos online.

Grep'ing through Changelogs is really fast, and thanks to the
uniformity of style, really useful.  I know I can grep through
commit messages using git grep (or magit, FWIW), but there is
a layer of UI between me and the Changelogs then.

-- 
 Bastien

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bastien]

Michael Albinus <michael.albinus@gmx.de> writes:

> They are useful. A tar distribution does not contain the git repo with
> the history of commitments.

+1.

> Another question is, whether we still want to write ChangeLogs manually,
> or whether we want to extract them from commit comments. That's not such
> easy, see all the "fix typo" comments.

I'm all for writing them manually, it's a useful exercise.

IMHO git commit messages should reproduce ChangeLogs, not the
other way around.

-- 
 Bastien

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Rüdiger Sonderfeld]

On Friday 03 January 2014 10:17:00 Bastien wrote:
> > Another question is, whether we still want to write ChangeLogs manually,
> > or whether we want to extract them from commit comments. That's not such
> > easy, see all the "fix typo" comments.
> 
> I'm all for writing them manually, it's a useful exercise.
> 
> IMHO git commit messages should reproduce ChangeLogs, not the
> other way around.

Generating them from commit messages would do exactly that.  Right now most 
people copy all or at least parts of the ChangeLog entry to the commit message 
anyway.  I agree that the format is useful and I absolutely agree that the 
commit message should not necessarily only be a copy of the ChangeLog entry.

But those points are not really an obstacle or argument against auto-
generation of the ChangeLog _files_ from the commit messages

Regards,
Rüdiger

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Daniel Colascione]

On 01/03/2014 01:35 AM, Rüdiger Sonderfeld wrote:
> On Friday 03 January 2014 10:17:00 Bastien wrote:
>>> Another question is, whether we still want to write ChangeLogs manually,
>>> or whether we want to extract them from commit comments. That's not such
>>> easy, see all the "fix typo" comments.
>>
>> I'm all for writing them manually, it's a useful exercise.
>>
>> IMHO git commit messages should reproduce ChangeLogs, not the
>> other way around.
>
> Generating them from commit messages would do exactly that.  Right now most
> people copy all or at least parts of the ChangeLog entry to the commit message
> anyway.  I agree that the format is useful and I absolutely agree that the
> commit message should not necessarily only be a copy of the ChangeLog entry.
>
> But those points are not really an obstacle or argument against auto-
> generation of the ChangeLog _files_ from the commit messages

It's a lot safer to fix an error in ChangeLog than to interactively 
rebase and force-push a new history. Would this automated ChangeLog 
generation system be tolerant of manual ChangeLog editing?

If we're going to have ChangeLog files anyway, we're still going to have 
to deal with merging. Since we have to write change descriptions in any 
case and since we already have mature tools for making ChangeLog 
additions, we might as well retain the current system. It would be nice, 
though, to auto-fill commit messages based on ChangeLog deltas.

By the way: git-merge-changelog from gnulib looks useful.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> Date: Fri, 03 Jan 2014 01:53:05 -0800
> From: Daniel Colascione <dancol@dancol.org>
> Cc: Bastien <bzg@gnu.org>, Michael Albinus <michael.albinus@gmx.de>,
> 	Thierry Volpiatto <thierry.volpiatto@gmail.com>
> 
> By the way: git-merge-changelog from gnulib looks useful.

Yes.  And a native Windows binary is available, if anyone is
interested.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stephen J. Turnbull]

Daniel Colascione writes:

 > It's a lot safer to fix an error in ChangeLog than to interactively 
 > rebase and force-push a new history. Would this automated ChangeLog 
 > generation system be tolerant of manual ChangeLog editing?

git help notes

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bastien]

Rüdiger Sonderfeld <ruediger@c-plusplus.de> writes:

> But those points are not really an obstacle or argument against auto-
> generation of the ChangeLog _files_ from the commit messages

Commit messages are not meant to be edited, while it's good to be
able to edit Changelog files.

We use the workflow you suggest in Org (i.e. using only commit
messages and producing ChangeLogs from them) and I can tell how
frustrating this is: you need to review all typos and mistakes
from all contributors, because the script to generate the logs
will not do it for you.

-- 
 Bastien

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Tassilo Horn]

Bastien <bzg@gnu.org> writes:

>> Another question is, whether we still want to write ChangeLogs
>> manually, or whether we want to extract them from commit comments.
>> That's not such easy, see all the "fix typo" comments.
>
> I'm all for writing them manually, it's a useful exercise.

The problem with ChangeLog files is that they provoke conflicts.

When I contribute to some git-using project that has manually written
ChangeLog files, I usually create a new branch, do my changes, write a
ChangeLog entry in a _temporary_ buffer, and then commit providing a
one-line description plus the ChangeLog entries (without the author/date
headline).

Then I sometimes rebase that branch onto master (which works just fine
since the ChangeLog hasn't been changed) until upstream is satisfied
with my changes.  At that point, I put my commit message as real entry
into the ChangeLog, commit, squash the ChangeLog commit with the commit
implementing my changes, and finally push/submit the patch/send the pull
request.

That said, bzr with its changelog_merge plugin is nice, too.  Then you
can make a real, persistent ChangeLog entry along with your commit
implementing the code changes, but once you merge your branch into trunk
you have to remember to pull your entry to the top of the ChangeLog and
re-date it.

Bye,
Tassilo

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stefan Monnier]

>> Also would be great to stop writing unuseful changelog files.
> They are useful.  A tar distribution does not contain the git repo with
> the history of commitments.

Please let's not rehash old arguments: the tarball contains many files
that are generated, so it would be trivial to include the "git log"
output in it.


        Stefan

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bastien]

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

> Please let's not rehash old arguments: the tarball contains many files
> that are generated, so it would be trivial to include the "git log"
> output in it.

How would we handle fixing in such generated logs?
By revising the git history through rebasing?

Not a rhetorical question, just curious, as I do have a
problem with the current way Org generates its ChangeLogs.

-- 
 Bastien

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Achim Gratz]

Bastien writes:
> How would we handle fixing in such generated logs?

The same way we do today if we only care about the Changelog file.
Otherwise, we'd have to come up with something using Git notes (as
already mentioned earlier in this thread).

> By revising the git history through rebasing?

Nope.

> Not a rhetorical question, just curious, as I do have a
> problem with the current way Org generates its ChangeLogs.

For the benefit of other participants in this discussion you might
mention that Org doesn't have a ChangeLog and the only reason we
generate one is that when changes are imported into Emacs there is
suddenly a need to document that merge (typically produced by ~1000
commits from Org) in Emacs' ChangeLog.  Since that operation throws away
all history from Org, it also means you can't use the commit messages
directly for the ChangeLog, no matter how hard you'd wish you could.
That wouldn't necessarily be a problem in Emacs' case where the
correspondence between commit and ChangeLog would be 1:1.


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

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien writes:
>> How would we handle fixing in such generated logs?
>
> The same way we do today if we only care about the Changelog file.

We don't do "it" today.

Org ChangeLogs are generated using a script, and these changelogs are
added to Emacs when we merge Org.  It's fine fixing these changelogs
manually because newly generated Changelogs don't overwrite previous
ones.

My question is: if Emacs generates Changelogs from commit messages,
and if commit messages contain ill-formated changelogs, how do you
fix generated changelogs?

One idea is to generate only new changes (and fix them manually if
needed), not to generate all ChangeLogs.

> Otherwise, we'd have to come up with something using Git notes (as
> already mentioned earlier in this thread).
>
>> By revising the git history through rebasing?
>
> Nope.
>
>> Not a rhetorical question, just curious, as I do have a
>> problem with the current way Org generates its ChangeLogs.
>
> For the benefit of other participants in this discussion you might
> mention that Org doesn't have a ChangeLog

I did: http://article.gmane.org/gmane.emacs.devel/167136

> and the only reason we
> generate one is that when changes are imported into Emacs there is
> suddenly a need to document that merge (typically produced by ~1000
> commits from Org) in Emacs' ChangeLog.  Since that operation throws away
> all history from Org, it also means you can't use the commit messages
> directly for the ChangeLog, no matter how hard you'd wish you could.

It's a matter of convention: if Emacs generates Changelog files from
commit messages, I guess we will enforce some policy on how to write
suitable commit messages.

Additional (not suitable for ChangeLogs) information could then be
stored in git notes.

> That wouldn't necessarily be a problem in Emacs' case where the
> correspondence between commit and ChangeLog would be 1:1.

Yes.

-- 
 Bastien

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Achim Gratz]

Bastien writes:
> My question is: if Emacs generates Changelogs from commit messages,
> and if commit messages contain ill-formated changelogs, how do you
> fix generated changelogs?

If you've got a version-controlled ChangeLog file (status quo), it is
completely immaterial of how the entries are produced.  Even if they are
all generated, you can still edit the file, just as you've done all the
time.

> One idea is to generate only new changes (and fix them manually if
> needed), not to generate all ChangeLogs.

Generating all ChangeLogs is superfluous since then you don't need a
ChangeLog at all.

> It's a matter of convention: if Emacs generates Changelog files from
> commit messages, I guess we will enforce some policy on how to write
> suitable commit messages.

Again, this is an argument to abolish ChangeLogs altogether.

> Additional (not suitable for ChangeLogs) information could then be
> stored in git notes.

Git notes are simply a way to augment or correct the original commit
message (which can't be separated from the commit without rewriting
history).  As such it should be used sparingly, if at all.  I'd rather
have code review that ensures the commit messages are good than git
notes.


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

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> If you've got a version-controlled ChangeLog file (status quo), it is
> completely immaterial of how the entries are produced.  Even if they are
> all generated, you can still edit the file, just as you've done all the
> time.

I wish I didn't have to do it all the time, hence my question.

-- 
 Bastien

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stefan Monnier]

> Generating all ChangeLogs is superfluous since then you don't need a
> ChangeLog at all.

Hello?  This thread is about removing Emacs's ChangeLog files because
they are (by design) redundant.


        Stefan

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Florian Weimer]

* Bastien:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Please let's not rehash old arguments: the tarball contains many files
>> that are generated, so it would be trivial to include the "git log"
>> output in it.
>
> How would we handle fixing in such generated logs?
> By revising the git history through rebasing?

There's also "git notes".  It would provide a clean way of amending
log entries, but I haven't seen it used in the wild yet.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eric S. Raymond]

Thierry Volpiatto <thierry.volpiatto@gmail.com>:
> Also would be great to stop writing unuseful changelog files.

+1.  But that's the next battle, not this one.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

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

Our ChangeLog files are very useful in debugging.
They complement the diffs between versions of the source files.

-- 
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: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> Our ChangeLog files are very useful in debugging.
> They complement the diffs between versions of the source files.

I think everyone agrees with this.

The question is whether we should edit them separately
from the commit messages, or if we should produce them
by (programmatically) extracting them from the commit
messages.

-- 
 Bastien

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eric S. Raymond]

Bastien <bzg@gnu.org>:
> Richard Stallman <rms@gnu.org> writes:
> 
> > Our ChangeLog files are very useful in debugging.
> > They complement the diffs between versions of the source files.
> 
> I think everyone agrees with this.

I don't.  I think Changelogs are, while not completely without value,
not worth the maintainance load when your VCS has changesets.  I've
seem the same objection from others in the discussion.  But this is a
separate argument from which DVCS we should be using.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Lars Magne Ingebrigtsen]

Bastien <bzg@gnu.org> writes:

> The question is whether we should edit them separately
> from the commit messages, or if we should produce them
> by (programmatically) extracting them from the commit
> messages.

If we decided on having a vc-log commit mode for Emacs that would
enforce the ChangeLog style, then that would be interesting.  But I
don't really see a super-obvious way of implementing that.

Here's a typical ChangeLog entry from a single commit (I think):

2013-12-27  Stefan Monnier  <monnier@iro.umontreal.ca>

	* icomplete.el (icomplete-show-matches-on-no-input): Default to nil
	(bug#16251).

	* electric.el: Move all electric-pair-* to elec-pair.el.
	* elec-pair.el: New file, split from electric.el.

When I edit stuff, I usually change a function, hit `C-x 4 a' (well, I
have that bound to `Hyper-a'), type in what I did, then perhaps change
the caller, and `C-x 4 a' again, and write what I did there.

Then I commit what I've done.

When I'm programming without a ChangeLog, I edit the first function,
edit the second function, and then commit, writing a summary of what I
did, but I don't mention the function names affected, for instance.

So there's no way to reconstruct a full ChangeLog entry from a normal
commit message, unless we make a `C-x 4 a' equivalent that works without
an actual ChangeLog file.

A temporary ChangeLog file?  A temporary ChangeLog "vc check in" buffer?

A different question is whether this style of change tracking is
valuable or not...

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Thierry Volpiatto]

Bastien <bzg@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> Our ChangeLog files are very useful in debugging.
>> They complement the diffs between versions of the source files.
>
> I think everyone agrees with this.

No, I still think changelog files are unuseful when using a decent dVCS.
With git you have "git-log --grep" and "git-grep" and even
"git-log -p --grep", and "git-log" is also just _working_.

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bastien]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> No, I still think changelog files are unuseful when using a decent dVCS.
> With git you have "git-log --grep" and "git-grep" and even
> "git-log -p --grep", and "git-log" is also just _working_.

This is for developers.

It's nice for advanced Emacs users to be able to read Changelog
files and check when a new command has been introduced.  If we
require users to know how to use Git for this, the audience shrinks.

My point about keeping Changelogs is that they a useful read for
advanced users *and* for developers who want to know how to format a
correct commit message.

I spend *a lot* of time educating Org's contributors on how to write
a correct commit message.  If we had a Changelog directly in Org, I'd
spend less time, because occasional contributors would immediately
spot those tiny conventions.

-- 
 Bastien

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[David Kastrup]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Bastien <bzg@gnu.org> writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>> Our ChangeLog files are very useful in debugging.
>>> They complement the diffs between versions of the source files.
>>
>> I think everyone agrees with this.
>
> No, I still think changelog files are unuseful when using a decent dVCS.
> With git you have "git-log --grep" and "git-grep" and even
> "git-log -p --grep", and "git-log" is also just _working_.

I actually use git repositories for working with Subversion based
projects, and obviously also for working with Bazaar based projects.
The first thing I do is checking out a Git mirror or running the (often
expensive) import from Subversion.

And the most important reason for that is not the workflow for
_creating_ new patches (though being able to privately rebase is good),
but for navigating the history of a project and searching its
information.

This is so much more workable than using the _native_ tools of the
respective repositories that it isn't funny.

Now the one thing that will _always_ cause trouble when creating/vetting
a contribution for Emacs is the ChangeLog.  Since Emacs is a reasonably
fast-moving project and the ChangeLog is a central contention point like
the Windows registry, you will _always_ get ChangeLog merge conflicts
when committing.

Now as long as the "native" repository of Emacs is Bazaar with its
absurdly slow log generation, discussing the usefulness or uselessness
of ChangeLog for daily work independently from Git migration seems
pointless: the pros and cons cannot really be estimated by people not
yet using Git.

I'm quite convinced that nobody will miss ChangeLog files when working
with Git.  It's not even a tradeoff.  In my book, that's one of the most
important advantages of Git, but of course it is a hen-and-egg problem
to convince people of that when their current experience tells them a
ChangeLog file can be useful in the course of daily work.

-- 
David Kastrup

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bastien]

David Kastrup <dak@gnu.org> writes:

> I'm quite convinced that nobody will miss ChangeLog files when working
> with Git.

Users?  Especially those who use Emacs from a preinstalled version,
not from a Git clone.

-- 
 Bastien

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[David Kastrup]

Bastien <bzg@gnu.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> I'm quite convinced that nobody will miss ChangeLog files when working
>> with Git.
>
> Users?

What about "when working with Git" did you not understand?

> Especially those who use Emacs from a preinstalled version, not from a
> Git clone.

So?  You can generate a ChangeLog file from Git, and we likely would do
so.  But frankly: it is quite unlikely for users to look at a ChangeLog
file.  What's interesting for users is NEWS.  For anything beyond that,
you'll likely just clone the git repository as it is

a) cheap to do (we are not talking about Bazaar here)
b) so much more convenient to search.

-- 
David Kastrup

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bastien]

David Kastrup <dak@gnu.org> writes:

> Bastien <bzg@gnu.org> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> I'm quite convinced that nobody will miss ChangeLog files when working
>>> with Git.
>>
>> Users?
>
> What about "when working with Git" did you not understand?

I'm not a native english speaker, I may have misunderstood.

I've read the sentence above as "I'm quite convinced that nobody will
miss ChangeLog files whenever we will be working with Git" -- which I
disagree with.

>> Especially those who use Emacs from a preinstalled version, not from a
>> Git clone.
>
> So?  You can generate a ChangeLog file from Git, and we likely would do
> so.  But frankly: it is quite unlikely for users to look at a ChangeLog
> file.  

I did so when I was just a user.  But sure, that's probably a minority.

> What's interesting for users is NEWS.  For anything beyond that,
> you'll likely just clone the git repository as it is
>
> a) cheap to do (we are not talking about Bazaar here)
> b) so much more convenient to search.

I don't see anything to gain in preventing mere users from reading
ChangeLog files, and I see nothing to lose in editing Changelogs that
you copy into commit messages.  It does not even take more time thanks
to C-x v v inserting Changelogs in commit messages directly.

-- 
 Bastien

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Per Starbäck]

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

>
> > So?  You can generate a ChangeLog file from Git, and we likely would do
> > so.  But frankly: it is quite unlikely for users to look at a ChangeLog
> > file.
>
> I did so when I was just a user.  But sure, that's probably a minority.
>
>
I do that as well.

Also, there is a point about credit that I don't think has been made: Even
though I don't have write access to the Emacs repository I'm mentioned in
some Changelogs because of fixes I've mailed when reporting bugs. I think I
was somewhat thrilled the first times developers put my name there instead
of their own when checking in those fixes. It is maybe not a big point, but
still a point, since that feeling can be an impetus to making more fixes.

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

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[David Kastrup]

Per Starbäck <per@starback.se> writes:

>>
>> > So?  You can generate a ChangeLog file from Git, and we likely would do
>> > so.  But frankly: it is quite unlikely for users to look at a ChangeLog
>> > file.
>>
>> I did so when I was just a user.  But sure, that's probably a minority.
>>
>>
> I do that as well.
>
> Also, there is a point about credit that I don't think has been made:
> Even though I don't have write access to the Emacs repository I'm
> mentioned in some Changelogs because of fixes I've mailed when
> reporting bugs. I think I was somewhat thrilled the first times
> developers put my name there instead of their own when checking in
> those fixes. It is maybe not a big point, but still a point, since
> that feeling can be an impetus to making more fixes.

So what?  If you send in a patch formatted with git format-patch, you
will be listed the author of the patch automatically when the patch is
applied with git am, regardless of who pushes it (the pusher of a patch
is only a minor information you have to ask explicitly for: the normal
log does not mention him or her, the main information being the author
of a patch).

Even if you send in just a diff, it can be committed using the --author
option in order to preserve proper credit.

So your "point about credit" is not more than a misconception.

-- 
David Kastrup

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Glenn Morris]

Per Starbäck wrote:

> Also, there is a point about credit that I don't think has been made: Even
> though I don't have write access to the Emacs repository I'm mentioned in
> some Changelogs because of fixes I've mailed when reporting bugs. I think I
> was somewhat thrilled the first times developers put my name there instead
> of their own when checking in those fixes. It is maybe not a big point, but
> still a point, since that feeling can be an impetus to making more fixes.

That's why we encourage use of --author when committing things by other
people.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Achim Gratz]

Bastien writes:
> Richard Stallman <rms@gnu.org> writes:
>> Our ChangeLog files are very useful in debugging.
>> They complement the diffs between versions of the source files.
>
> I think everyone agrees with this.

FWIW, I don't.  I've used ChangeLogs and Journals while I was still
using RCS and I'm glad I don't have to anymore.  With properly written
commit messages, I get more easily accessible and much more accurate
information than by just looking at a ChangeLog or trying to align
ChangeLog entries with a diff.

> The question is whether we should edit them separately
> from the commit messages, or if we should produce them
> by (programmatically) extracting them from the commit
> messages.

If the information in the commit message and the ChangeLog is different
to begin with, then you're doing something wrong.  If it is (supposed to
be) identical, then manually entering the same information in two
different places is unnecessarily complex and error-prone, so generating
one format from the other is the only sane option.


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

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Juanma Barranquero]

On Sat, Jan 4, 2014 at 2:07 PM, Achim Gratz <Stromeko@nexgo.de> wrote:

> With properly written
> commit messages

And how will we get that? Something as obvious as making the first
line a summary so it shows correctly in --line logs has been suggested
(repeatedly) in the past, and yet it's often ignored, even by some
highly experienced developers.

Generating ChangeLogs from commit messages will be easier and faster
that what we do now, but I'm willing to bet a few euros it will give
us *much* worse ChangeLogs.

    J

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Jarek Czekalski]

W dniu 01/04/2014 09:03 PM, Juanma Barranquero pisze:
> (...) Something as obvious as making the first
> line a summary so it shows correctly in --line logs has been suggested
> (repeatedly) in the past, and yet it's often ignored, even by some
> highly experienced developers.

You will have to repeat it many times more if you don't put it in the 
right place, which is
http://www.emacswiki.org/emacs/BzrForEmacsDevs

Jarek

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Achim Gratz]

Juanma Barranquero writes:
>> With properly written commit messages
>
> And how will we get that?

Where do the ChangeLog entries come from today, then?

> Something as obvious as making the first line a summary so it shows
> correctly in --line logs has been suggested (repeatedly) in the past,
> and yet it's often ignored, even by some highly experienced
> developers.

There are various ways to prevent such commits wending their way into
the official repo and there are also ways to add fixes if necessary.
These would perhaps trigger workflow changes that have little if
anything to do with Git, although it might be a good time to discuss
them before switching from Bzr.


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

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Juanma Barranquero]

On Sat, Jan 4, 2014 at 9:37 PM, Achim Gratz <Stromeko@nexgo.de> wrote:

> Where do the ChangeLog entries come from today, then?

People write them, obviously. Somehow, many people seem more careful
when writing the ChangeLog than doing the same in the commit log
buffer or the commit command in the command line.

Also, many ChangeLog entries are fixed or reworded afterwards (and I'm
not talking about obvious typos and whitespace, but duplicates,
factual errors, etc.). You can not fix a commit log message.

   J

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 4 Jan 2014 21:53:14 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> You can not fix a commit log message.

If git is supported as well as we are told, perhaps the git developers
can be asked to add a feature that will allow commit messages to be
fixed, at least as far as the output of "git log" etc. is concerned.
CVS allowed such changes, btw.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Juanma Barranquero]

On Sat, Jan 4, 2014 at 10:13 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> If git is supported as well as we are told, perhaps the git developers
> can be asked to add a feature that will allow commit messages to be
> fixed, at least as far as the output of "git log" etc. is concerned.

There's notes (git notes etc.). Perhaps it would make sense to use
some commit hook to move the commit log message to a note
automagically... That wouldn't be ideal, but it would go a long way to
make losing the ChangeLogs palatable.

    J

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Nathan Trapuzzano]

Eli Zaretskii <eliz@gnu.org> writes:

> If git is supported as well as we are told, perhaps the git developers
> can be asked to add a feature that will allow commit messages to be
> fixed, at least as far as the output of "git log" etc. is concerned.
> CVS allowed such changes, btw.

git rebase --interactive

With a source repository like Emacs', which is shared by so many people,
doing that is a terrible idea.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stefan Monnier]

>> If git is supported as well as we are told, perhaps the git developers
>> can be asked to add a feature that will allow commit messages to be
>> fixed, at least as far as the output of "git log" etc. is concerned.
>> CVS allowed such changes, btw.
> git rebase --interactive
> With a source repository like Emacs', which is shared by so many people,
> doing that is a terrible idea.

Right: by "edit past commit messages" we mean "without rewriting
history".  I know it sounds contradictory, but it is only paradoxical.


        Stefan

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Right: by "edit past commit messages" we mean "without rewriting
 > history".  I know it sounds contradictory, but it is only paradoxical.

It's neither.  It's an artifact of git implementation.

I'm pretty sure there are VCSes that don't make the commit message
part of history, but I think that's disgusting and don't allow VCSes
like that in my house.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stefan Monnier]

> be) identical, then manually entering the same information in two
> different places is unnecessarily complex and error-prone, so generating

If you enter it twice, you're not using your tool right.  Emacs can
extract the commit message from the ChangeLog file right before you
commit, so you don't have to enter it twice.

IOW, please guys re-read the corresponding thread from a few years back.
Nothing much has changed.

The main issues were (and are) the following:
- How to edit past commit messages when they're incorrect/incomplete/...?
- How to do C-x 4 a when there's no ChangeLog file?
- This last one can get a bit more delicate if you want to be able to do

     hack..hack..hack
     C-x 4 a
     hack..hack..
     C-x C-c
     restart Emacs
     ...
     commit

  since this requires saving the commit message which you started
  writing in the first Emacs session: the ChangeLog file naturally lives
  across Emacs sessions, whereas the *VC-Log* buffer doesn't.
  

        Stefan

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Achim Gratz]

Stefan Monnier writes:
>> be) identical, then manually entering the same information in two
>> different places is unnecessarily complex and error-prone, so generating
>
> If you enter it twice, you're not using your tool right.  Emacs can
> extract the commit message from the ChangeLog file right before you
> commit, so you don't have to enter it twice.

That's exactly what I said in the next line of that sentence which you
didn't quote.  I purposefully avoided the contentious issue of saying
which direction I might prefer.

> The main issues were (and are) the following:
> - How to edit past commit messages when they're
> incorrect/incomplete/...?

Git notes still seems like a good solution.

> - How to do C-x 4 a when there's no ChangeLog file?

You don't need to.  I'm usually writing the commit messages as I stage
the diffs for the upcoming commit.  I also frequently rewrite commits
before pushing them upstream.  Extracting that information from a
ChangeLog to build the commit message is completely backwards with that
kind of workflow and easily leads to typical errors like documenting
changes that aren't actually committed or implemented differently or
additional undocumented changes that might or might not be intended to
be part of the commit.


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

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stefan Monnier]

>> The main issues were (and are) the following:
>> - How to edit past commit messages when they're
>> incorrect/incomplete/...?
> Git notes still seems like a good solution.

AFAIK "git notes" is a low-level tool which clever scripts might be able
to leverage to provide the ability to "edit past commit messages".
I've never seen those clever scripts, tho.

>> - How to do C-x 4 a when there's no ChangeLog file?
> You don't need to.

I do.

> I'm usually writing the commit messages as I stage
> the diffs for the upcoming commit.  I also frequently rewrite commits
> before pushing them upstream.  Extracting that information from a
> ChangeLog to build the commit message is completely backwards with that

C-x 4 a has nothing to do with extracting the message from
the ChangeLog.  I usually use C-x 4 a from the *vc-diff* buffer.


        Stefan

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stephen J. Turnbull]

Stefan Monnier writes:

 > The main issues were (and are) the following:

 > - How to edit past commit messages when they're
 >   incorrect/incomplete/...?

Best solution: no commit without review.  Not gonna happen :-) so,
"git notes".

 > - How to do C-x 4 a when there's no ChangeLog file?

ln -s $PROJECT_ROOT/.tmp_commit_log $PROJECT_ROOT/ChangeLog

works for me in private projects.  The commit alias removes
.tmp_commit_log, so I can't commit without writing a commit log
("fatal: could not read log file '.tmp_commit_log': No such file or
directory").

 > - This last one can get a bit more delicate if you want to be able
 >   to do

Yeah, probably it's still a bit delicate.

 >   since this requires saving the commit message which you started
 >   writing in the first Emacs session: the ChangeLog file naturally lives
 >   across Emacs sessions, whereas the *VC-Log* buffer doesn't.

but not for that reason. ;-)  Dunno if that trick works on Windows,
for one.

Steve

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Sun, 05 Jan 2014 17:34:47 +0900
> Cc: Achim Gratz <Stromeko@nexgo.de>, emacs-devel@gnu.org
> 
>  > - How to do C-x 4 a when there's no ChangeLog file?
> 
> ln -s $PROJECT_ROOT/.tmp_commit_log $PROJECT_ROOT/ChangeLog
> 
> works for me in private projects.

I don't understand why you need the symlink.  Why not let Emacs create
ChangeLog, then delete it when the commit is done?  Or use any other
file name (if you don't want to see ChangeLog for some reason): the
Change Log mode can be turned on in any file, regardless of its name.
For that matter, why not reuse .git/COMMIT_EDITMSG?

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Date: Sun, 05 Jan 2014 17:34:47 +0900
 > > Cc: Achim Gratz <Stromeko@nexgo.de>, emacs-devel@gnu.org
 > > 
 > >  > - How to do C-x 4 a when there's no ChangeLog file?
 > > 
 > > ln -s $PROJECT_ROOT/.tmp_commit_log $PROJECT_ROOT/ChangeLog
 > > 
 > > works for me in private projects.
 > 
 > I don't understand why you need the symlink.  Why not let Emacs create
 > ChangeLog, then delete it when the commit is done?

IIRC, it was as a marker, I only wanted one of them, and didn't feel
like debugging logic to find the project root by other means.

The point in mentioning it here is that there are trivial hacks that
don't require any changes to add-change-log-entry.

 > Or use any other file name (if you don't want to see ChangeLog for
 > some reason): the Change Log mode can be turned on in any file,
 > regardless of its name.

As above, it was important (maybe only to my paranoia) that ChangeLog
be present in the directory but not be a readable file.

 > For that matter, why not reuse .git/COMMIT_EDITMSG?

Caution.  Who knows what else git might be using it for?  Or maybe I
just didn't know that was the name of the editmsg file at that time --
it was a long time ago.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stefan Monnier]

>> - How to do C-x 4 a when there's no ChangeLog file?
> ln -s $PROJECT_ROOT/.tmp_commit_log $PROJECT_ROOT/ChangeLog
> works for me in private projects.  The commit alias removes
> .tmp_commit_log, so I can't commit without writing a commit log
> ("fatal: could not read log file '.tmp_commit_log': No such file or
> directory").

Right, that's the kind of direction I'd like to go.  But this
.tmp_commit_log file seems to be a personal convention, so making `C-x
4 a' use such a thing by default is more difficult.


        Stefan

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stephen J. Turnbull]

Stefan Monnier writes:
 > >> - How to do C-x 4 a when there's no ChangeLog file?
 > > ln -s $PROJECT_ROOT/.tmp_commit_log $PROJECT_ROOT/ChangeLog

 > Right, that's the kind of direction I'd like to go.  But this
 > .tmp_commit_log file seems to be a personal convention, so making `C-x
 > 4 a' use such a thing by default is more difficult.

C-x 4 a doesn't know about .tmp_commit_log, that's the point of the
symlink.  It just does what it always does.

I don't see why this can't be a project convention, perhaps using
.git/GIT_EDITMSG as Eli suggests.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stefan Monnier]

> I don't see why this can't be a project convention, perhaps using
> .git/GIT_EDITMSG as Eli suggests.

I'd like Emacs to support it for all projects.


        Stefan

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stephen J. Turnbull]

Stefan Monnier writes:
 > > I don't see why this can't be a project convention, perhaps using
 > > .git/GIT_EDITMSG as Eli suggests.
 > 
 > I'd like Emacs to support it for all projects.

And?  I don't see a problem:

  (setq vc-message-file (format (vc-message-file-fmt vc-backend)
                                project-root))

with the "obvious" (== I'm in a hurry, ask me if not) semantics for
`vc-message-file' and `vc-message-file-fmt' (and don't shoot me if
there are obviously better ways to implement it in vc.el or
add-log.el, just do it! ;-)

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stefan Monnier]

>> > I don't see why this can't be a project convention, perhaps using
>> > .git/GIT_EDITMSG as Eli suggests.
>> I'd like Emacs to support it for all projects.
> And?  I don't see a problem:
>   (setq vc-message-file (format (vc-message-file-fmt vc-backend)
>                                 project-root))
> with the "obvious" (== I'm in a hurry, ask me if not) semantics for
> `vc-message-file' and `vc-message-file-fmt' (and don't shoot me if
> there are obviously better ways to implement it in vc.el or
> add-log.el, just do it! ;-)

That's the idea, yes.  But then you want to make sure the file is
ignored by the VCS; that it gets erased after commit, and things
like that.

Also, you'd probably want to "unify" that file and *VC-Log*, which
brings in more details with which to deal.

I'm not saying it's fundamentally necessarily hard.  But someone has to
write the code, and deal with the problems that can show up.


        Stefan

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

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

    The question is whether we should edit them separately
    from the commit messages, or if we should produce them
    by (programmatically) extracting them from the commit
    messages.

I think it is best for commit messages to be brief high-level 
summaries of the changes, and put the details only in ChangeLog.
I think that these two forms of desription complement each other
and that it is useful to have both available.

-- 
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: PROPOSAL: Move to git, now that bzr is no longer a req.

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>     The question is whether we should edit them separately
>     from the commit messages, or if we should produce them
>     by (programmatically) extracting them from the commit
>     messages.
>
> I think it is best for commit messages to be brief high-level 
> summaries of the changes, and put the details only in ChangeLog.
> I think that these two forms of desription complement each other
> and that it is useful to have both available.

Git treats the first line of a commit message specifically as a summary.
When formatting a commit for mailing, this line is used as the subject
of the mail while the rest of the commit message appears in the mail
body.

This inherent subdivision of commit messages maps well enough to the GNU
subdivision of complementing summary/detail that it becomes mostly
pointless in practice to maintain a separate file for storing this
information.

-- 
David Kastrup

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Glenn Morris]

David Kastrup wrote:

> Git treats the first line of a commit message specifically as a summary.
> When formatting a commit for mailing, this line is used as the subject
> of the mail

That would be nice. Please fix the emacs-elpa-diffs list accordingly:

http://lists.gnu.org/archive/html/emacs-elpa-diffs/2013-12/index.html

Because currently I find it less useful than it was under bzr.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stefan Monnier]

>> Git treats the first line of a commit message specifically as a summary.
>> When formatting a commit for mailing, this line is used as the subject
>> of the mail
> That would be nice. Please fix the emacs-elpa-diffs list accordingly:
> http://lists.gnu.org/archive/html/emacs-elpa-diffs/2013-12/index.html

Yes, please.

> Because currently I find it less useful than it was under bzr.

Quite!


        Stefan

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Stephen J. Turnbull]

Richard Stallman writes:

 > I think it is best for commit messages to be brief high-level 
 > summaries of the changes, and put the details only in ChangeLog.

This violates the "don't repeat yourself" principle to some extent,
and conflicts with habits formed in other projects.  Some projects
don't have ChangeLogs (or don't bother about commit messages, but
that's very rare), so the preferred format gets all data, usually with
some convention about a single line that *identifies* the commit, but
may not be a full "executive summary".  (For those who know Darcs,
think "patch name".)

I also get the feeling that a lot of committers feel that they receive
ambiguous, even conflicting, advice about commit message and ChangeLog
entries (eg, "follow the GNU Coding Standard" vs. "here's how you
should do it" if Florian's characterization is correct).

 > I think that these two forms of desription complement each other
 > and that it is useful to have both available.

There's absolutely no reason why both can't be in a single "place".
The implementation in commit messages could be done via a VCS feature
like "git notes" (resp, a special log formatter -- Jordi says
Mercurial has a whole template language that can be used in logs), so
you don't see the detail unless you ask for notes (resp, the verbose
form).  It could be done via a log-viewer Emacs mode.

But as Eric says, this is not the thread to discuss that, because it
changes workflow.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>     The question is whether we should edit them separately
>     from the commit messages, or if we should produce them
>     by (programmatically) extracting them from the commit
>     messages.
>
> I think it is best for commit messages to be brief high-level 
> summaries of the changes, and put the details only in ChangeLog.
> I think that these two forms of desription complement each other
> and that it is useful to have both available.

FWIW, I fully agree.

-- 
 Bastien

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
> Our ChangeLog files are very useful in debugging.
> They complement the diffs between versions of the source files.

So do commit messages.  What makes Git commit messages eternally more
useful in practice is the versatility: I can _immediately_ view just the
messages pertaining to a subdirectory, or a file, or a branch (without
checking it out), and when I use the --grep option, I get the matching
commit messages in full rather than a -3 style context when using grep
on a ChangeLog file.  And even when I want to search for a flat text in
the single ChangeLog of the top directory, the best use case for a
ChangeLog file, this is less convenient the moment a ChangeLog file has
to be split.

And git log is reliable.  When I ask Git for all commit messages
touching a certain file, it will not miss changes.  It will, when I
want, give the respective diffs (-p option) along with the commit
messages, or just a list of changed files (--stat).

-- 
David Kastrup

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Florian Weimer]

* Richard Stallman:

> Our ChangeLog files are very useful in debugging.

Then you're not following the GNU Coding Standards. :-)

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

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

    > Our ChangeLog files are very useful in debugging.

    Then you're not following the GNU Coding Standards. :-)

There is no constructive point there, only an insult.

If you have some constructive criticism, please state it clearly.

-- 
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: PROPOSAL: Move to git, now that bzr is no longer a req.

[Florian Weimer]

* Richard Stallman:

>     > Our ChangeLog files are very useful in debugging.
>
>     Then you're not following the GNU Coding Standards. :-)
>
> There is no constructive point there, only an insult.

It was not intended as such, I'm sorry if it came across this way.

> If you have some constructive criticism, please state it clearly.

In particular, this advice does not make much sense to me:

| For changes to code, there’s no need to describe the full purpose of
| the changes or how they work together. If you think that a change
| calls for explanation, you’re probably right. Please do explain it—but
| please put the full explanation in comments in the code, where people
| will see it whenever they see the code. For example, “New function” is
| enough for the change log when you add a function, because there
| should be a comment before the function definition to explain what it
| does.

<http://www.gnu.org/prep/standards/html_node/Change-Log-Concepts.html>

I find this pretty strange because adding comments typically does not
make sense when one removes code (which sometimes needs *more*
explanation than adding code).  And when rearranging code, there is
often no single place to put a comment *why* this was done.

I never consult changelog files if I have the full VCS history.  In my
experience, grepping diffs, annotate/blame, or bisecting is more
helpful (assuming that I have a hunch history provides an explanation)
because the raw bits are usually less misleading, and the changelog
files are often deliberately devoid of any additional information.
The lisp/ changelog seems to deviate from this a bit, but there are
other GNU projects where the changelog rules are enforced through
review.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

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

    I find this pretty strange because adding comments typically does not
    make sense when one removes code (which sometimes needs *more*
    explanation than adding code).  And when rearranging code, there is
    often no single place to put a comment *why* this was done.

I find there is generally some place in the source file where
the explanation belongs.  It can be in some related place in the code,
someplace where people will see it when it is relevant.

But why not put it in ChangeLog?  It wouldn't be horrible to put it
there, from time to time.  But preferably not often.

One ChangeLog file covers many source files, and if we generally put
the explanations in ChangeLog, it would become cumbersome.  So it is
better to put those explanations in the source code.

Also, most often an explanation is directly relevant to existing code,
and the best way to make sure people see it is to put it there.

    I never consult changelog files if I have the full VCS history.

I do.  I use the ChangeLog files to see what changes affected
a certain function.  Then I use VC history to look at the changes
that are relevant to the issue.

-- 
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: PROPOSAL: Move to git, now that bzr is no longer a req.

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I never consult changelog files if I have the full VCS history.
>
> I do.  I use the ChangeLog files to see what changes affected a
> certain function.

I tend to use C-x v g for that (it maps to git blame).  Its drawback is
that it also reflects whitespace changes, but then it's easy to navigate
across them with the proper keybindings (usually A) until finding the
change one is looking for, then getting the corresponding log with l.

> Then I use VC history to look at the changes that are relevant to the
> issue.

I'm not saying that this is an "invalid" workflow.  However, the generic
VC support of Emacs allows, when coupled with a version control system
that is reasonably fast, to use alternate workflows that do not suffer
from significant drawbacks compared to the benefits from not having to
maintain manual ChangeLog files separately.

This is not specific to Git (actually, it was already available in CVS).
What is noticeable, however, is that Git's performance does not make
this a waiting game, and that Git is often able to track the origin of
lines even when material was rearranged beyond the renaming of files.

Git offers several options for the amount of history searching it should
perform: what is intransparent is just which options vc.el happens to be
using and how one can change them in case something goes wrong.

In general, it's more often than not the case that Git finds out more
than one expected, but when the reverse happens, vc-git does not make it
easily discoverable how one can tell Git to search more thoroughly.

I digress: what I wanted to say is that one gets a few tools (and with
an Emacs interface) that work reasonably well for addressing most of the
tasks one would otherwise use a ChangeLog to get done.

-- 
David Kastrup

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Mon, 06 Jan 2014 15:53:28 +0100
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> >     I never consult changelog files if I have the full VCS history.
> >
> > I do.  I use the ChangeLog files to see what changes affected a
> > certain function.
> 
> I tend to use C-x v g for that (it maps to git blame).

This can be annoyingly slow (and with git is slower than with bzr).
E.g., try xdisp.c: it takes git more than 4 minutes to display
anything in response to "C-x v g" (2 minutes if done from the shell).
Looking into ChangeLog's is surely faster.

Someone, I think it was you, once told me that the slow operation of
'git blame' was a deliberate design decision of the git developers.
So it doesn't sound like this is supposed to be the first tool to be
used for such jobs.  FWIW, I use that only after I already have some
idea about what I'm looking for and in which time period.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Jordi Gutiérrez Hermoso]

On Mon, 2014-01-06 at 18:09 +0200, Eli Zaretskii wrote:

> E.g., try xdisp.c: it takes git more than 4 minutes to display
> anything in response to "C-x v g" (2 minutes if done from the
> shell). Looking into ChangeLog's is surely faster.

As a point of comparsion, on my system

    $ time hg blame xdisp.c > foo

    real  0m55.426s
    user  0m54.083s
    sys   0m1.032s

    $ time git blame xdisp.c > foo

    real  3m24.979s
    user  3m5.920s
    sys   0m3.032s

I suppose this is because git's data structures aren't very fast for
single-file operations. The only way to get data for a single file in
git is to walk the entire changelog and grab all associated tree
objects looking for the blob you care about. Hg's data structures
instead, changes across a single file using a so-called revlog, which
is a series per-file deltas with occasional full file copies (the
analogy for revlogs is video compression with key frames).

- Jordi G. H.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: Jordi Gutiérrez Hermoso <jordigh@octave.org>
> Cc: David Kastrup <dak@gnu.org>, emacs-devel@gnu.org
> Date: Mon, 06 Jan 2014 12:57:49 -0500
> 
> On Mon, 2014-01-06 at 18:09 +0200, Eli Zaretskii wrote:
> 
> > E.g., try xdisp.c: it takes git more than 4 minutes to display
> > anything in response to "C-x v g" (2 minutes if done from the
> > shell). Looking into ChangeLog's is surely faster.
> 
> As a point of comparsion, on my system
> 
>     $ time hg blame xdisp.c > foo
> 
>     real  0m55.426s
>     user  0m54.083s
>     sys   0m1.032s
> 
>     $ time git blame xdisp.c > foo
> 
>     real  3m24.979s
>     user  3m5.920s
>     sys   0m3.032s

I don't see any point in these comparisons (having been there before),
but since you started...

  D:\gnu\bzr\emacs\trunk>timep bzr annotate src/xdisp.c > foo
  real    00h00m29.265s
  user    00h00m26.578s
  sys     00h00m00.843s

  $ time git blame src/xdisp.c > foo
  real    2m5.281s
  user    0m0.015s
  sys     0m0.000s

(This is on Windows, so in the case of git, the user and system times
are bogus, because Windows provides no means of accounting for
grandchildren subprocesses.)

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Mon, 06 Jan 2014 15:53:28 +0100
>> 
>> Richard Stallman <rms@gnu.org> writes:
>> 
>> >     I never consult changelog files if I have the full VCS history.
>> >
>> > I do.  I use the ChangeLog files to see what changes affected a
>> > certain function.
>> 
>> I tend to use C-x v g for that (it maps to git blame).
>
> This can be annoyingly slow (and with git is slower than with bzr).
> E.g., try xdisp.c: it takes git more than 4 minutes to display
> anything in response to "C-x v g" (2 minutes if done from the shell).

Oh wow.  Impressive.  Not my average experience, but certainly a
sobering outlier.

> Someone, I think it was you, once told me that the slow operation of
> 'git blame' was a deliberate design decision of the git developers.

Yes and no.  The information is reconstructed rather than stored, but in
general the information is reconstructed rather fast.

git blame also has an incremental mode.  For cases such like this, it
might make sense trying to find a way to integrate this into the
operation of C-x v g though I have to admit that I am somewhat at a loss
regarding how to do this in a pleasant way.

> So it doesn't sound like this is supposed to be the first tool to be
> used for such jobs.  FWIW, I use that only after I already have some
> idea about what I'm looking for and in which time period.

In general, it works pretty well for me.  I have to admit that xdisp.c
is convincingly bad in that regard.

-- 
David Kastrup

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 06 Jan 2014 19:07:02 +0100
> 
> I have to admit that xdisp.c is convincingly bad in that regard.

Well, it's a monster file which gets a lot of changes, so it's
definitely not the average.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Mon, 06 Jan 2014 15:53:28 +0100
>> 
>> Richard Stallman <rms@gnu.org> writes:
>> 
>> >     I never consult changelog files if I have the full VCS history.
>> >
>> > I do.  I use the ChangeLog files to see what changes affected a
>> > certain function.
>> 
>> I tend to use C-x v g for that (it maps to git blame).
>
> This can be annoyingly slow (and with git is slower than with bzr).
> E.g., try xdisp.c: it takes git more than 4 minutes to display
> anything in response to "C-x v g" (2 minutes if done from the shell).
> Looking into ChangeLog's is surely faster.
>
> Someone, I think it was you, once told me that the slow operation of
> 'git blame' was a deliberate design decision of the git developers.

No, not really: it's just that blaming a file is not cheaper than
blaming a directory.

At any rate, I'm currently just analyzing the code for git-blame, and
for better or worse, it's appallingly bad (quadratic in file size, times
number of commits).  It should be fairly straightforward to bring down
the time rather dramatically.  Several inner loops are run more than
2^32 times for "git blame src/xdisp.c".

It's not a design decision, it is just bad programming.  Salvageable.
Considering how much life time I spent waiting for some git-gui blame (I
conveniently forgot about that, I have to admit) it's sort of amusing
that I never thought of looking at its code (several years ago,
I improved some of the performance-critical but already efficient parts
of git).  This should be rather low-hanging fruit.

Of course, it will likely take a year to trickle down even if I
contribute something in the next weeks.

-- 
David Kastrup

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Tue, 07 Jan 2014 20:17:15 +0100
> 
> At any rate, I'm currently just analyzing the code for git-blame, and
> for better or worse, it's appallingly bad (quadratic in file size, times
> number of commits).  It should be fairly straightforward to bring down
> the time rather dramatically.  Several inner loops are run more than
> 2^32 times for "git blame src/xdisp.c".
> 
> It's not a design decision, it is just bad programming.  Salvageable.
> Considering how much life time I spent waiting for some git-gui blame (I
> conveniently forgot about that, I have to admit) it's sort of amusing
> that I never thought of looking at its code (several years ago,
> I improved some of the performance-critical but already efficient parts
> of git).  This should be rather low-hanging fruit.

It would be nice, as for me xdisp.c is a file into whose history I
must dig very frequently.

Thanks.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Rüdiger Sonderfeld]

On Tuesday 07 January 2014 20:17:15 David Kastrup wrote:
> It's not a design decision, it is just bad programming.  Salvageable.
> Considering how much life time I spent waiting for some git-gui blame (I
> conveniently forgot about that, I have to admit) it's sort of amusing
> that I never thought of looking at its code (several years ago,
> I improved some of the performance-critical but already efficient parts
> of git).  This should be rather low-hanging fruit.
> 
> Of course, it will likely take a year to trickle down even if I
> contribute something in the next weeks.

Please fix this.  Running git blame on a large file is quite a pain 
(especially when done through `magit-blame-mode' or other synchronous emacs 
blame mode).

Regards
Rüdiger