Re: making dput a wrapper around git
On 18/11/14 11:17, Ansgar Burchardt wrote:
> Hi,
>
> On 11/18/2014 09:45 AM, Daniel Pocock wrote:
>> How would people feel if dput was a wrapper around git?
> I think its not a good idea. It has too many problems, see below.
I agree it is not a trivial idea and is unlikely to appeal to everybody
>
>> This wouldn't imply that maintainers must use Git as their VCS
>>
>> For packages that do use git as the VCS, dput would do a "git tag" and
>> "git push", possibly using branches specifically intended for release.
> How would it know which branch to use? There are different conventions
> and integrating one in dput would force all to use the same convention.
Not quite - it would only use a unified VCS for dput purposes if the VCS
already used the layout that was expected
Otherwise it would just fall back to creating a second VCS or offering
to create branches it expects to use.
>> For packages that don't use git as the VCS, a Git repository would be
>> created dynamically without any direct effort by the maintainer. dput
>> would make a git clone behind the scenes, commit the latest source
>> package into the repository and push it.
> That fails on the second upload. Or when maintainers use different
> layouts for their Git repository. Or when doing NMUs when you would
> suddenly get a second Git repository by the NMUer.
>
>> Various other parts of Debian could then use the Git repositories
>> - signed tags instead of signed source packages
> That's not great either. Nothing guarantees both are identical. (And
> they are not in some cases.)
That is not a Git-specific issue, it is a general issue with source-only
uploads. If source-only uploads become the norm then signed tags should
be the same as source packages shouldn't they?
>> - the tool for browsing package source in the web browser could always
>> see the source in git
> The main reason why seeing the source in a VCS is useful (at least for
> me) is that you can see individual commits and commit messages. An
> automated system only importing release versions cannot provide that.
>
> (I assume dgit has the same problem.)
>
>> - the release team could rely on diffs from the designated git
>> repository instead of debdiff attachments
> No Git is required for that. There is already debdiff to diff packages
> if you really want to.
Yes, and I agree it works. With something like Git it may be easier for
the release team to enforce though. At the moment, there is nothing
which automatically ensures the consistency between the debdiff proposed
in an unblock request and the actual content of the upload. With a
Git-based solution, the release team could make a signed tag on some
commit and it would be built and allowed through to testing.
Reply to: