[Aptitude-devel] Rebasing published software and avoid git revert/merge

[Axel Beckert]

Hi,

Daniel Hartwig wrote:
> Two months ago I release aptitude 0.6.9 to experimental.  Many of
> those changes will not make it in to Wheezy and I am refactoring and
> publishing some of the updates under 0.6.8.n.  This refactoring is
> proving to be a better base of development going forward so I plan to
> forget about 0.6.9 and continue the stable updates using 0.6.10.

Ah, I already wondered about the future of the 0.6.9 branch.

> What I have is two git branches with some overlapping and some unique
> changes on each.  The 0.6.9 branch also has some changes which I will
> back out completely in the short term.
> 
>   C'--E stable-0.6 (0.6.8.1, unstable/testing)
>  /
> A---B---C---D master (0.6.9.1, experimental)
> 
> I wish to make stable-0.6 the new master while avoiding a merge or
> revert+merge on master (the difference between them is quite large).

I'd have expected a merge as I think the CLI fixups in 0.6.9 (which
are IIRC the main changes in 0.6.9) are generally a good thing. I
don't mind if you prefer to reimplement them, but things like having
consistent exit codes should really stay in aptitude.

> - ask that .9 be removed from experimental;

That will AFAIK happen automatically if you upload a 0.6.10 to
unstable.

> - delete published master (that is, “git push origin :master”);
> - rename stable-0.6 to master and push;
> - repeat previous two steps for the git-buildpackage branches (debian
> and upstream);

If explicitly stated, git can automatically merge changes with
conflicts by e.g. dropping one side. That would continue the master
branch while dropping most of it and merging in non-conflicting
changes. Nevertheless I never tried it and I'm not sure if it's easy
to see what has been merged and what has been dropped.

Without knowing the code, I'd still give a merge a try. If it doesn't
work out, you can just rebase your HEAD to before the merge before
pushing and continuing differently.

> - release next version as 0.6.10 without NEWS/changelog entries for
> .9 and a note saying that release has been reverted;
> - some bugs fixed in .9 will be marked as found in .10;

I think, _all_ bugs fixed in .9.* should be reopened except those
explicitly fixed in .8.*, too.

> Is this approach sane?

It's ugly IMHO. I though see that if you really consider the 0.6.9
branch not worth merging in, that renaming branches is the easiest
option from your point of view.

> I realise that deleting master and republishing will disrupt
> developers the next time they git pull.

I don't expect any other developers having problems with it as I think
all of them are or at least should be on aptitude-devel and now know
about this issue.

> Does anyone know how this would also affect services like
> launchpad.net and ohloh.net, which also pull from that branch?

Don't know about Launchpad. (BTW, what's Launchpad doing with
aptitude's git repo? Just mirroring or is there any added value?)

Ohloh is a good point, thanks for mentioning. At least the last time I
saw such a case, Ohloh stopped updating the whole project (not only
the rebased git repository) and you had to mail them that they
reinitialise it manually. Then, OTOH,
http://meta.ohloh.net/faq/ohloh-failed-to-download-my-source-code-now-what/
no more mentions any git issues. And since Ohloh projects with
hundreds of repos like https://www.ohloh.net/p/debian/enlistments are
no more permanently lagging due to the above issue, I suspect they
fixed at least parts of that issue in the meanwhile.

Not sure if just changing the relevant branch on Ohloh (i.e.
continuing with a branch not named master) would help.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5