Changeset identity

James Westby jw+debian at jameswestby.net
Wed Jul 30 10:20:21 BST 2008


On Wed, 2008-07-30 at 07:27 +0100, Russel Winder wrote:
> I know I should know the answer to this but...
> 
> Context:  I have a development mainline branch and a maintenance branch
> -- for certainty lets call the former Trunk and the latter 1.4.x -- for
> the truly nosey, the project name is Gant :-).  The branches are in a
> shared repository, but this is implementation detail.  Development
> changes occur only in Trunk and have no effect on 1.4.x -- except that
> some of the changes turn out to be bug fixes that should appear in a bug
> fix release and so need applying to 1.4.x.  Conversely almost all
> changes made in 1.4.x, being bug fixes, need applying also in Trunk.
> 
> So the question is, what is the officially approved way of naming a
> changeset so that it may be applied from one branch to another.

Firstly, as has been pointed out, Bazaar is snapshot based, and
so doesn't have changesets. Git is most definitely snapshot based,
and so neither does it.

By a changeset you mean the difference between two (usually
sequential) snapshots, i.e. revisions. That's fine, and what
most people understand from this, there is just a danger due to
the fact that some systems are changeset based, and so this
can be a source of confusion.

Naming a "changeset" in bzr is the same as naming the two revisions
that you would like the differences between, i.e. "-r m..n".

If you have done a "git cherry-pick REVISION" then you may be
deceived by the fact that you only specify a single revision,
and get the "changeset" associated with it. This is because
it takes the diff of that revision against its parent and applies
that. If the revision has more than one parent you are required
to specify the parent index to diff against (but cherry picking
a merge would be rare in git).

In bzr you can do this with the "-c n" notation, which diffs against
"n-1". If n is a merge then it uses the first parent to diff against,
as bzr often treats the first parent as special. This means that
in bzr if you cherry pick a merge you get all of the changes introduced
by the commits merged in to that revision. (That's what you get in
git as well, but it's treatment of all parents as equal means that
it doesn't know which parent to use to provide this behaviour by 
default).

>   Is push
> an acceptable technique here or is merge and commit mandated? 

You can't formulate a situation where you can push to two diverged
branches from a single branch, while still only pushing some of the
commits to one branch. The trunk branch will always have stuff
that you don't want in the stable branch, and if you can push to
both from your current branch then stable will end up with everything
currently in trunk. You always need another step to maintain
this arrangement of branches.

There are a few strategies:

  * Work always against trunk, cherry-pick merge the bug fixes in
    to the stable branch.
  * If you identify a stable bug fix before working on it do it
    in the stable branch and then merge it in to trunk (assuming
    *every* change in stable is wanted in trunk, if not then you
    could do a null merge of the unwanted changes back, or
    fall back to cherry-picking).
  * Do each bug fix in a branch taken from the point where trunk
    and stable diverged, or earlier. Then merge this branch in
    to each other branch.

As well as merging, you could do diff+patch (which a cherry-pick
merge is currently equivalent to), or a rebase operation (which is a
different way of combining two branches), but you always need
another step.

>  The issue
> then is that the changeset already has a commit message and no new
> commit message is needed so any sequence that requires an explicit
> commit seems sub-optimal, indeed unnecessary.

You could write a command that did the same as "git cherry-pick",
which did the cherry-pick merge, and then automatically commited
with the same message, optionally adding a "cherry picked from
bla bla bla" message. The commit is required, but it could be
automated (assuming there are no conflicts).

The only way I can think of to avoid the commit message is to use
rebase. I think it would be more effort, and it could be argued that
it just re-uses the commit message in the same way that I just
described.

Thanks,

James




More information about the bazaar mailing list