Hello, On Fri, Jun 22 2018, Ian Jackson wrote:
> I think both export-dsc and push-source on some arbitrary ref can work > if the quilt fixup is a no-op and there is no need to make a > pseudomerge (always the case for export-dsc, but in the case of > push-source might depend on whether we're in split brain mode, > --overwrite, etc.). This is always the case for Debian-native > packages, for example, and will often be the case for users of > git-debrebase and git-dpm. I knew they could work if no commits are needed, but didn't think arbitrary refs support restricted to those cases would be useful enough. Thanks for pointing out that git-debrebase, git-dpm and native packages will not need any commits a lot of the time -- now support for arbitrary refs looks more useful. >> Another problem with advancing the ref in the case of export-dsc is >> that it is quite unintuitive for an export command to make changes to >> the thing that it is exporting. It's less bad when the thing that >> changes is the branch you already have checked out. > > I agree. I think advancing the ref ought not to be done unless it's > HEAD (and the tree is clean). > > So I think for push-source: > > 886966 push-source should be usable on arbitrary refs 886625 > push-source should be usable no matter the state of the working tree > > These should work iff there would be no need to make any new commits. > When pushing or exporting a non-HEAD ref, the working tree state > should be ignored. Additionally, the implementation should never look at the working tree. It just has a safety check that if the ref supplied points at the same commit that HEAD points at, and the working tree is dirty, --ignore-dirty is needed to continue. > If new commits are to be made (where in a dgit view or otherwise), the > user should check out the branch to be pushed. Right. It can prompt them to check it out. > For export-dsc: > > 886969 Replace 'build-source' with 'export-dsc' > > We have a worse problem. What about split brain mode ? There is > nowhere to put the dgit view branch. This is less of a problem with > build-source because build-source is part of an upload workflow and > the dgit view will be reconstructed (probably, fished out of the > cache) during the subsequent push. I have not at any point looked into how split brain mode works in any detail. In particular, I don't know why the dgit view has to be stored, aside from performance reasons. > I am somewhat tempted to say that export-dsc should be forbidden with > split brain quilt modes. Indeed, it makes less sense. If you are in --gbp mode, for example, you probably want to use gbp to produce source packages, not dgit. I think we can safely defer this and have the first version of export-dsc work with only non-split brain, just like dgit pull. -- Sean Whitton
signature.asc
Description: PGP signature
