<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Forest Bond wrote:
<blockquote cite="mid:20091211032958.GA719@alittletooquiet.net"
type="cite">
<pre wrap="">Hi,
On Fri, Dec 11, 2009 at 10:58:56AM +0900, Stephen J. Turnbull wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Note that on the emacs-devel list there are a couple of vocal regulars
pushing for a git-oriented view (and this matters, because it would be
embedded in vc.el IIUC). Specifically, this history
3. merge "Fix a typo."
3.1 Fix a typo.
2. Add a Feature.
is being called evil. Andreas sorta backtracked on that, but I think
that's the way he really feels about it.
</pre>
</blockquote>
<pre wrap=""><!---->
I don't get it. If people want their merges to look like plain old commits,
they just need to tell bzr that. Why not merge "Fix a typo.", revert
--forget-merges, and then commit -m 'Fix a typo.'? A trivial script could save
some typing.
-Forest
</pre>
</blockquote>
<br>
I'd say this is a developer experience/education issue rather than a
bzr issue.<br>
Wouldn't the above situation happen in git or hg as well with no fast
forward?<br>
<br>
It sounds more like a gripe about developer slackness in writing good
commit messages than anything else... <br>
<br>
Also, couldn't the above be solved by merging changes into an
intermediary branch, so you can collapse a series of "wip" commits into
a couple of commits to be shared?<br>
<br>
eg. <br>
3. Fix for bug xxxx<br>
3.3 Updated documentation<br>
3.2 Fix for bug xxxx<br>
3.1 Unit tests<br>
<br>
David<br>
</body>
</html>