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

[Daniel Hartwig]

On 5 September 2012 17:53, Axel Beckert <abe at debian.org> wrote:
>> 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.

Agreed.  These will definitely come back after Wheezy, but it is a big
change and my initial request to the release team was met with
aversion because of the tightened error conditions (required to
implement sane exit codes everywhere).

> 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.

[Note that some of the reimplemented changes are not yet released.]

My testing with this approach produces a massive diff that is hard to
follow.  There are so many conflicts it is difficult to sort out and
more difficult to verify that the result would be correct.  I gave up.

Likewise for reverting specific commits, because some of the
ok-for-wheezy changes are very intermixed with the others.

> (BTW, what's Launchpad doing with
> aptitude's git repo? Just mirroring or is there any added value?)

It is just a mirror.  There are also Debian and Ubuntu branches on
there which appear to be generated from the released files (i.e. one
commit per Debian release) and should be unaffected.

I assume, since it is just this mirror, that it is then easy for the
LP admins to fix any problem (or just drop and recreate the mirror) if
we replace master.

>> 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?

Reimporting, yes.

>> [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.

Done.  However it is not suitable to git-import-orig from this branch
yet, because debian-sid and upstream-sid branches will also need to be
pushed.

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

Also pushed this experimental-0.6.9 branch (just a copy of master).
Leaving for historical reasons.

> 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.

Ok.

I am going to leave this here, rather than also disrupting the debian
and upstream branches right now (needs to be done to keep using gbp).
I'll investigate the build, upgrade path after merging the debian
branch in to stable-0.6 and report back.

That would leave us with one git disruption as everyone moves to using
a new debian-sid branch.  Although this is a “needless” change during
release freeze, it does not practically impact the packages (unlike,
say, changing a debhelper compat level might).

Thanks to everyone for their pointers on this.

Regards