Comparison with Git, Mercurial or Darcs?

[Ali Sabil]

On Wed, Nov 4, 2009 at 1:35 PM, Daniel Carrera <dcarrera at gmail.com> wrote:
> On Wed, Nov 4, 2009 at 1:06 PM, Ben Finney <ben+bazaar at benfinney.id.au> wrote:
>> Daniel Carrera <dcarrera at gmail.com> writes:
>>> When I'm working on a new feature I send a lot of small test patches
>>> to the test server until it works. When it works, I obliterate them on
>>> the server, unrecord them on my laptop, and re-record them as a nice
>>> set of well organized patches.
>>
>> All of which would be more straightforward done as a parallel line of
>> development, allowing the changes to *remain* in history when later
>> merged, and not be obliterated. In other words, a branch.
>
> I don't think we are communicating. I don't *want* a history full of
> patches with the web equivalent of "printf('Debug: Entered function
> foo()\n')". When I'm developing, most of the time I'm entering
> debugging information, or very small incremental changes ("let's try
> making to text green... no, let's try red..."). I don't want all of
> that junk in my history. I want to finish the feature and when it's
> done I'll record a set of logical, self-contained patches.
>

Actually nothing really stops you from doing this in bzr. It just
happens that the general bzr "culture" prefers using merge instead of
rebase/sqashing commits to keep the complete history and then rely on
the "view" layer to only display the relevant commits: you can for
example try to run "bzr qlog lp:qbzr" to see what I mean.

Also, there is already a plugin for bzr called bzr-rewrite which aims
at providing history manipulation commands. It provides a rebase
command and a replay command, and I submitted a patch some time ago to
add a filter-branch command to it as well, maybe we should work on
adding a squash command so that you can combine commits into a single
commit.

Cheers,

Ali