Barry Warsaw <ba...@python.org> wrote:
> I'm asking because I don't know hg and git well enough to answer the
> question. In my own use of Bazaar over the last 4+ years, I've almost never
> rebased or even been asked to.
Maybe it depends on what kind of changes you commit. I consider
future maintainers the most important "customer" of the repository
history. As such, I try to make each commit a logical change that
takes a working system and produces another working system. In that
way, each change to be potentially reversed if later on if it found
to cause problems. Also, ideally, each revision can be tested to
narrow down the version where a bug was introduced.
I see a VCS system as having two related but different purposes.
The first is to help keep track of changes when they are developed.
This is messy. I don't know about you but I make lots of mistakes:
changes that don't do what I want, crazy ideas that turn into dead
ends, etc. I use a VCS to keep track of this experimentation and my
incremental progress.
The second is to keep a record of the change history of a long lived
piece of software. In that case, I like it that each change has a
logical purpose. In the first case the "customer" is the developer.
In the second it is the maintainer.
> In this graph:
>
>> A --- B ------------.
>> / \
>>... --- X --- C --- D --- E --- M
>
> A and B do exist, but I shouldn't care or notice them unless I explicitly
> drill down.
In my case, I usually have something like:
A --- B --- C
/
... --- X --- F --- G --- H
A, B, and C are messy and not logical. Maybe I write them so I have
two logical patches (assuming they are only in my private repo):
A' --- B'
/
... --- X --- F --- G --- H
Next, putting the merge in public repository generally serves no
purpose so I rebase on H:
... --- X --- F --- G --- H --- A'' --- B''
This very much matches the result I would get if using CVS or
Subversion. IMHO, the changes A, B, and C represent partially
complete development and there is no purpose to put them in the
public repo.
If you are able to directly commit A' and B' and your tool does a
good job of hiding the logically unimportant merge then I guess you
wouldn't miss the ability to modify history.
Neil
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
