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

[Axel Beckert]

Hi,

I'm lagging a little bit behind this thread, but I didn't want to
discard my previous mail of which most were written earlier this
morning.

Daniel Hartwig wrote:
> On 5 September 2012 15:48, Thomas Goirand <zigo at debian.org> wrote:
> > I never understood why everyone insist in using the default name "master".
> > This doesn't express anything at all. Instead, you should be using:
> >
> > - wheezy
> > - sid
> > - experimental
> 
> Right.  That has been a sort of long-term goal ;-)

:-)

> For historical reasons, aptitude is a non-native package.  We have a
> combined gbp and upstream setup at the moment:
> 
> - master (“upstream” development)
> - upstream (merged from master via git-import-orig)

"merged" not in the sense of merging the branch but in the sense of
reimporting it, right? At least I don't see an git-import-orig option
which allows "upstream-source" to be a git branch.

> [I have a local branch, stable-0.6, which is split from master at
> .8.

Can you push that branch to alioth, so that there's also such a branch
on alioth. Was looking for that branch there recently.

> This is the branch I want to replace master with; it has no debian/
> directory.]

Shouldn't hurt creating that branch now.

> I had planned to merge debian to master after Wheezy, making this a
> native package, and drop the upstream and debian branches.

Sounds like a good idea for me. There may be minor things which work
less well with a native package, but I think the advantages overrule.

> Perhaps instead of waiting I should just do both now, creating the
> wheezy/sid branches and forget about master.

I'd rename master then, too. Maybe in 0.6.9 or experimental-0.6.9 or such.

Florian Schlichting wrote:
> > The revert would be huge, which is why I wanted to avoid it.  You are
> > right that this is less disruptive to others who pull from the repo.
> 
> I'd say if you have more than two people who pulled from the repo, avoid
> it. Git doesn't care how big the revert is, the important thing IMHO is
> that by first reverting and then merging or cherry-picking, you are not
> going to have merge conflics, so it's pain-free.

Sounds fine to me.

> > Any thoughts about release .10 with most of .9 changes reverted, and
> > missing the NEWS entry for .9?
> 
> NEWS is what's shown to people when they upgrade, and it's purely
> informational: if there's nothing your users need to know when upgrading
> to .10, ommit it. Particularly if users upgrading from .8 would be shown
> confusing things for .9 that are no longer relevant in .10. If you're
> worried about "rewriting history", why not make a note about the
> deletion in d/changelog?

Yeah, I think the changelog is the better place. Just mention in the
0.6.10 changelog entry that the 0.6.9 branch was a dead end and 0.6.10
is based on 0.6.8. That should suffice.

		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