Development models, rewriting history (Re: Emacs Bazaar repository)

[Teemu Likonen]

Matthieu Moy kirjoitti:

> As opposed to that, in the git community, fixes done after 
> submitting a merge request are usually done by rewritting history.
> The idea is that each commit, not just the one in "mainline" should
> be correct.

It seems to me that you are partly wrong here.

> Take an example :
>
> revno: 3283
> committer: Canonical.com Patch Queue Manager <pqm at pqm.ubuntu.com>
> branch nick: +trunk
> timestamp: Sun 2008-03-16 02:26:32 +0000
> message:
>   (Andrew Bennetts) Fix some LockableFiles warnings from test_smart.
> [...]
>     ------------------------------------------------------------
>     revno: 3194.1.3
> [...]
>       Change "that that" to just "that".
>     ------------------------------------------------------------
>     revno: 3194.1.1
> [...]
>       Fix one LockableFiles warning from test_smart.py

> Revision 3194.1.3 fixes a typo introduced earlier in 3194.1.1.
>
> Had the same senario occured in the Git development, the author would
> have rewond his private branch to 3194.1.1, "git commit --anotate"-ed
> the patch to remove the typo, rebased the rest of the branch on top
> of it, and re-submitted the result for a merge.

If the patch series has not been applied to main upstream branches yet 
(only been discussed publicly), then the developer certainly modifies 
the series in his/her private branch (git add --interactive, git 
commit --amend, git rebase --interactive etc.) and publishes the series 
again to mailing list for reviewing. At this point there is not even 
any public revisions/commits for these patches and the series can be 
fine-tuned as much as possible. Patches sent to the git mailing lists 
are not automatically applied to any public branches.

If bug/typo is already in the upstream then only new commits are made to 
fix them. A developer fixing a bug will prepare a new commit on top of 
current tree. There's no messing with the past anymore. And new merge 
to the upstream will show this fix commit.

You can confirm this by browsing the history of maintainer's git tree 
and following the development. In the main git tree there's a file 
Documentation/howto/maintain-git.txt which promises that 
branches 'master', 'maint' and 'next' will never have their history 
rewritten. You can always safely pull from these. (These branches are 
what I have called 'upstream' earlier.)

Rebasing and other history rewriting happens in temporary feature 
branches and (people's personal) experimental branches. It happens when 
changes are being prepared (to keep changes up to date and in logical 
units), not after they have been merged to these official upstream 
branches.

I don't know what this has got to do with Emacs and Bazaar. Great tools 
both. I just felt that you were partly wrong about git development and 
the practice of rewriting history. :)