[Aptitude-devel] Rebasing published software and avoid git revert/merge
abe at debian.org
Wed Sep 5 11:15:33 BST 2012
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
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
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/
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.
,''`. | 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
More information about the Aptitude-devel