Thoughts on "usd-merge commit"

[Nish Aravamudan]

On 13.06.2016 [13:56:52 +0100], Robie Basak wrote:
> Hi Nish,
> 
> Thank you for fixing the refs issue. A couple more thoughts/surprises:
> 
> 1) I understand that it's in the definition of what it does, but it
> still surprises me a little that a command called "commit" also tags.
> I can't think of a better name to call it though.

I can make it commit-and-tag :)

Or we can make --tag a flag to commit. So it's more explicit what it
will do.

Really, I'm not sure the script will ever be used in that mode, it does
very little. But I wanted a way to encapsulate the full workflow in the
git repository's tooling, if possible.

> 2) It also surprised me a little that although I had your merge branch
> checked out, "usd-merge commit" didn't move HEAD up but did move
> ubuntu/yakkety up. Is this also a little wrong - shouldn't it be
> ubuntu/yakkety-proposed because there's no guarantee that the upload
> will pass proposed migration?

Absolutely right, it should go into proposed.

> Presumably I would need to push to the repository before uploading, so
> that the importer will pick up my commit in favour of importing its own
> even after we have it running automatically. I wonder though if it would
> be better to push to some other branch or tag (or even no branch, just
> the upload/<version> tag), and let the importer pull that into the
> correct pocket branch?

Right, I guess what we could do is for a version we plan on importing
(published), rather than assume we have to pull it down, we should see
if that version is tagged (import/<version> or upload/<version>). If it
is, then don't use dsc-commit, but use that commit as the basis for the
various branches' commits.

Would we want to do something like `git commit-tree $tag^{tree} -p
<changelog parent> -p <publish parent> -m ...` ?

My concern with the above, is that we lose the commit history for $tag,
as we're just taking the corresponding tree. And a major plus for the
workflow is once we have the 'logical/' tagged version, we can rebase
that on to debian for merges. But with the above, we won't replay the
history properly.

> If so, could it detect that the one of the parents of my upload commit
> is the same as that of the current pocket branch pointer, and just move
> the pocket branch pointer up? Is this logic sound?

It all depends on how rigid the upload commits end up being. Right now,
I think they end up being descendants of debian/sid, because that's what
we are merging to in LP. But debian/sid is not necessarily the parent,
just an ancestor (which we do check in `usd-merge commit` already). We
then try to parent in to the pocket branch pointer as appropriate. But
that's done all at `commit` time, which you're right isn't quite correct
(it should be publish time).

Here is my current thinking, totally rough:

for version to import
	if version is tagged
		sanity check that publish-import tree is identical to
		tagged tree
	if version is upload-tagged
		git cherry-pick all commits between the prior tagged
		version and upload-tagged version (so we get a proper
		history?)
	else
		current algorithm

I need to think this case over some more, though.

-Nish

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd