[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Locks on the Bzr repository

From: Óscar Fuentes
Subject: Re: Locks on the Bzr repository
Date: Tue, 24 Aug 2010 15:25:56 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Lluís <address@hidden> writes:


> If a bug is fixed on the release branch (emacs-23) using branch merges, so 
> that
> the history of emacs-23 will read "fix bug N", how can the same history 
> clarity
> be maintained in trunk? I mean, both the emacs-23 branch and trunk would like 
> to
> benefit from fixing those bugs, but if the release branch is merged into 
> trunk,
> the nice messages from emacs-23 are lost once merged into trunk,
> right?

To see them you'll need the -n0 switch, yes. This is an important case
that breaks the "niceness" of having a privileged arm on the DAG.

> And merging the new feature/fix branch into both emacs-23 and trunk
> would provide the desired history structure outcome, but this is kind
> of troublesome as the merge operation must be performed twice... I
> imagine this is exactly the place where rebase makes sense (merge new
> branch into emacs-23, then rebase emacs-23 into trunk), but this
> should in fact be an operation that is performed only by a small set
> of developers.

Rebasing has the undesirable effect of changing the identity of the
commits, so it is no longer possible to easily test the presence of one
change on several branches ("is commit 388743FA2 present in this
branch?") This is another reason for never rebasing commits that were
released to the public. So no, I don't think that `rebase' would be the
right tool for keeping a nice bzr log on the emacs-23/trunk exchange of


reply via email to

[Prev in Thread] Current Thread [Next in Thread]