Hello Johannes, On Thu, Nov 23 2017, Johannes Schauer wrote:
> Quoting Sean Whitton (2017-11-23 01:25:19)
>> On Thu, Nov 23 2017, Johannes Schauer wrote:
>> > Another section that could be improved in the dgit-maint-merge man page is
>> > "NEW UPSTREAM RELEASES" "When upstream releases only tarballs".
>> >
>> > After running "gbp import-orig" the master branch will contain the new
>> > upstream version but changes from debian/patches are not applied. The
>> > man page could expand on best practices on how to carry over changes
>> > from the last upstream version to the new upstream version.
>> Right. It should at least say that this action needs to be taken.
>>
>> What are the best practices you mention?
>
> I was actually hoping that as the master mind behind the maint-merge workflow
> you would tell me that... XD
>
> What I did for my package was to manually collect my commits from the
> earlier upstream version and then re-apply these on top of the new
> upstream. But surely there should be a better way to handle this?
Heh, sorry, I've not yet used the workflow for a real upstream that
releases only tarballs; I've only tested gbp-import-orig(1) in
artificial scenarios.
I think that what you are hitting is the recent change of
gbp-import-orig(1)'s default from --merge-mode=merge to
--merge-mode=replace.
For this workflow we want --merge-mode=merge, so that git-merge(1)
handles the re-application of the Debian changes for us (that's the
whole point of the workflow, after all). So I will add
[import-orig]
merge-mode = merge
to the recommended gbp.conf.
If you want to test, you could just pass --merge-mode=merge to
gbp-import-orig(1).
> I don't really think I can be of much help here because I'm not familiar
> enough
> with git. Stuff like git merge-tree and merge-base is something I never used
> before. I'm just reporting this wishlist bug from a user perspective. :)
Yes. Your feedback is very valuable to me and I hope to incorporate all
of it in order to make the workflow easier for future users -- thank
you!
While /writing/ the workflow might have required moderately advanced git
knowledge on my part, /using/ the workflow should not require this
knowledge.
> Another small question:
>
> | "If you want to maintain a copy of your repository on alioth.debian.org,
> | you should push both the origin and the upstream branches:"
>
> Should that not be "both the master and the upstream branches to origin"?
Thanks, yes, that is the intended meaning (and fortunately the actual
commands given are correct).
> And a related side question (that maybe should also have an answer in
> the man page): What are the recommendations for the upstream branch?
> For "When upstream tags releases in git" you write "here is no need to
> maintain a separate 'upstream' branch" but does this also hold for
> "When upstream releases only tarballs"? Because if I don't push the
> upstream branch to anywhere, then the steps under "NEW UPSTREAM
> RELEASES" will fail because "gbp import-orig" doesn't see an upstream
> branch. So maybe the man page could also expand on the need for an
> upstream branch if upstream releases tarball and recommendations on
> where and when it should be pushed or how one can do without it. For
> example maybe the question can be answered whether the upstream branch
> can be pushed to dgit-repos or whether alioth has to be used for that.
Yes indeed, you need to maintain an upstream branch if upstream releases
only tarballs. The manpage currently suggests that pushing that branch
to alioth is optional, but as you say, it is actually required in order
for future gbp-import-orig(1) calls to succeed.
I will expand that section to say that you must push the upstream branch
somewhere; eventually dgit-repos, but until that is possible (#848678),
to alioth.
Thanks again.
--
Sean Whitton
signature.asc
Description: PGP signature
