 Felly, rwy'n fawr i'r gweithio, yw fawr yn gwneud. Ond rwy'n fawr i'r plug de-git, sy'n sylwedd y sylwedd o'r ddebyn arcafwylau'r gilrwm. Felly, mae'n gwybod i'r ddigon. Yn ei wneud i'r gweithio'r gweithio'r fawr yn gweithio'r gweithio'r gyrdd. Yn eich munud wedi'i dwyndig sy'n gweithio'r gweithio, yw yw'n golygu'r gweithio'r gweithio'r gweithio, ddweud y cwestiynau ar y ddechrau. First of all, a bit of framing. When we work on Debian, we take on a variety of different roles. The biggest difference is between when we work on as a maintainer or maintainers of our own package and when we're doing something else. And indeed everyone else who's not necessarily a Debian developer or maintainer. So I'm going to start by presenting DeGit from the point of view of everyone else. So that's NMUers, people doing sponsorship, bug squashes, downstream distros, users, teams doing cross archive work like the transitions, reproducible builds, all that kind of thing. So if you're thinking about this primarily from what you've been maintained, please be patient, I will get to you. A bit later in the talk. So the point of DeGit is that it lets everyone treat the archive as if it were a Git repository. You can DeGit clone any package in any suite. So for example, CID or experimental or Weezy, if you like, and you get a Git tree which is identical to the output of ddweud-source-x. So DeGit always works the same from the non-maintainers point of view. On any package, the operation is completely uniform. You don't need to know anything about the maintainers, version control tools, or source format preferences, or Git workflow, anything like that. Once you've cloned it, you can work on the package in Git. Just you can with any other piece of software you might have done Git clone on. So you can commit locally. You can cherry pick changes from upstream branches. You can get reset, get clean. You can get rebase-i if you have made a more complicated set of changes and you want to polish them into a nice clean patch queue. You do all the usual git-ish stuff. Stuff like log and blame is less good for reasons that I will get onto. If you have the right authority, you can also DeGit push to upload. So a ddweud can upload any package in the archive with DeGit push. The ddweud can DeGit push those packages that they've been authorized for according to the information that the archive records. We still have binary packages and we haven't quite finished with the source only uploads. So you still have to do in general a build. DeGit doesn't replace your existing build infrastructure. So you have to build binary packages some way that you probably already do with sbuild or whatever. But DeGit does provide some helpful wrappers for some common build runes and it's a good idea to use them because of some quirks that I will get onto later. If you don't want to or you can't upload Debian but you do want to share your work with other people, you can git push the branch that came from DeGit and that you have edited anywhere. Anywhere suitable, any git server. So you could share your branch with your sponsor who could then approve it by running git fetch to fetch your branch, reviewing your changes and then running DeGit push themselves to push your work to the archive. DeGit's branches are completely ordinary git branches can be worked with just like any normal git branch. A downstream such as a derivative or maybe a partial derivative can use DeGit themselves directly as their upstream for all of their work and then they have a completely git based setup and they can do away with source packages entirely and just have a git server. So I'm going to go and explain how this works behind the scenes now with this data flow diagram I suppose you'd call it. So it works by providing a set of git repositories in parallel to the existing Debian archive and those are on a different server which is hosted by DSA. Every DeGit push is actually two underlying operations. There's a conventional, well first operation is a git signed tag and push to the DeGit Git server and the second is a conventional package upload with a slight wrinkle. That's not shown on this slide but the DSC of an upload done with DeGit contains an extra field with the git commit hash that you pushed. So fetch and clone, DeGit fetch and DeGit clone combine information from the archive and information from the git history. If the most recent upload was done with DeGit then the dot DSC will tell DeGit what it was that was pushed and it will produce that exact git commit for you as you'll check out. If the most recent upload was not done with DeGit, DeGit imports the source package into git. That is the dot DSC it gained from the archive, imports it into git and it stitches it into the existing git history if there is one. So there is a slight issue with a rig table because if you're going to build source packages for upload you still need to get your a rig table from somewhere. So the DeGit git branches need to be treated a bit specially if you're going to do a source package based upload. If you're not doing a new upstream version then DeGit fetch will get the correct a rig table from the archive and drop it in your dot dot for you and so everything will be fine and you don't need to really worry about it. If you are doing a new upstream version then I'm kind of assuming that you will have obtained an appropriate a rig table from somewhere and if you just leave it in the conventional place DeGit will use it to build the source package. So I should mention that the only thing that updates at the moment the DeGit history on the DeGit Git server is a DeGit push. So until the packages DeGit push for the first time it doesn't exist on the DeGit Git server and even after it's being pushed to DeGit for the first time non-DeGit based uploads are not recorded in that Git server. So the history on the DeGit Git server could at the moment still be out of date and I'm hoping to improve this in the future we'll get on to my plans for the future at the end of the talk. So my view is that in general the DeGit history structure that's on the DeGit Git server should be up to the maintainer at least if they care about this. What this means for an NMU-er is that if you're doing an NMU you should produce a straight forward linear structure of commits on top of the Git commit that you got from DeGit which is what you would do with any other Git upstream. So this means not only that if the maintainer is using DeGit they can DeGit fetch your changes and then easily include them in whatever way they'd like maybe by merging them or maybe by rebasing them onto their own preferred packaging branch or whatever but it also means that if they aren't using DeGit you've at least published a history which is suitable for rebasing onto their branch or whatever else it is that they might want to do with that. Also there's another reason to do that which is that for 3.0 quill packages so if you're doing an NMU of a 3.0 quill package you should just ignore the whole quill patch system thing and not touch Debian patches at all and you shouldn't use any of the tools that maintainers are often expected to use to rebase patches about or refresh patches. You should just make your commits to the source code where you will find it in the main source of the Git repository. When you do DeGit push DeGit will examine your history it will discover that this is what you've done and it will turn your nice tidy sequence of linear Git commits into a nice tidy sequence of patches so that the non-DeGit using maintainer of your package will just see that you have done a perfectly formed NMU and will have no cause for complaining and about the only wring call is that the name of the patch of course has to be auto generated and is not necessarily the prettiest but each individual patch will have the commit message from your Git commit in it and all the right authorship information and so on. So an ordinary NMU should not normally update a patch if they are using DeGit in the quilt stack directly so you shouldn't squash your changes into one of the existing commits. This is because if you do that the maintainer may find it harder to disentangle what you've done whereas it's much easier for the maintainer if they want to squash your patch they can do that themselves very easily and they've probably got a workflow tool that will help them do that whereas disentangling it is slightly harder. Also if you attempt to do that and work in Debian patches with DeGit you're likely to get confused and generate strange broken trees that don't work properly. Another reason that you probably don't want to be working in Debian patches directly is that you will end up reading interdiffs and interdiffs are very confusing. So in summary if you're doing cross archive work or you're bug squashing or you're downstream so any workflow where you're not the maintainer you can start using DeGit right away so all people everywhere in the world have anonymous read access to the Debian archive this way and I hope it will make your life easier. Sadly unless the maintainer uses DeGit the history you see in DeGit will not be the maintainer's history. You get something that looks a bit like this there's a synthetic commit generated by DeGit which is an archive import. The reason for this is that maintainer's git branches often indeed sometimes even usually differ from the source package in the archive. If you have if you DeGit cloner package and the package as comes from the archive has an ex VCS git header nominating some git repository that the maintainer prefers to use DeGit will set up a remote for you so you can fetch the maintainer's history and use it if you think that's going to be informative. So in that sense you can use DeGit the same you know you can use DeGit to do the same task as dev checkout but in general the ex VCS git tree is not necessarily usable by somebody who doesn't know what the maintainer does with it. So DeGit doesn't use the branch found in ex VCS git as a basis for anything. So difficulties that arise with ex VCS git that you often find is there are repositories out there where the ex VCS git header names a repository that contains only a Debian directory and no upstream source code at all or it might be a 3.0 quilt tree where there's a Debian patches directory and a pile of patches in a quilt stack but those patches haven't been actually applied to the source code in the tree. So git build package for example likes to work with those and the tag and sweet naming conventions can also vary. So while the maintainer's history is useful in the technology so you can have a look at it for git blame and git log it's not in the general case suitable for the use of DeGit unless the maintainer is using DeGit and therefore DeGit can't really rely on it and doesn't use it. Another problem with ex VCS git is that of course the maintainer's git server could be anywhere so it might be down or it might no longer even exist or it might have been compromised. So that's why if the maintainer didn't push with DeGit DeGit has to synthesize git history and the synthesized git history has this very basic structure. So that gets me on to the second part of the talk which is DeGit for maintainers. So for these reasons downstream git users would like you as a maintainer to use DeGit push to do your uploads. They'll then be able to see and directly work with your own history and they'll get that much richer history. And from a more general point of view the point of using a DVCS like git is to publish your work and the existing ways of publishing git histories for Debian packages aren't uniformly usable for users. The ex VCS git system gives you some git branch but the user can't rely on being able to use it directly they'll have to understand if you are a user who's working with lots of different packages you'll have to understand every maintainers special snowflake workflow and there are people who have done that and have internalized all that knowledge but I don't think that's for everybody. So what DeGit does from the maintainers point of view is it provides a way for you to publish a history which users can immediately rely on corresponding exactly to the archive and therefore the users of DeGit history can rely on using that history that you have published without needing to know anything about your workflow. But there's another selfish reason why you would want to upload a DeGit. If you use DeGit you'll be able to directly merge NMUs branches that you see and maybe pull request emails other kinds of similar contributions because in this case the DeGit using contributor will have based their work on your history. So their push will be fast forward of your last push. If you didn't use DeGit then they will be working on this stub history like you see on the left here and they'll make commits based on that stub history. So you can still DeGit fetch that work if you're not using DeGit to do the push but you're at the very least going to have to rebase NMU's work onto your own branch or maybe you'll have to use a non-Git based method of importing an NMU like a Git import DSC. So another advantage for using DeGit push is that it will put your actual history on browse.deagit.debion.org which is the Seagit view of the DeGit Git server rather than advertising DeGit's stub history which also might be out of date as I've discussed. And if you use DeGit push you get an extra check that the source package you're uploading is exactly the same as your Git head and that can save you some checks based on your DSC. It makes it for example more practical to do your upload tests in a Git-ish way and not have to run tests on the DSC. And of course as I say doing your uploads of DeGit will improve your users and downstream's lives. So back to this sort of data flow slide DeGit is not a replacement for any of the existing Git packaging tools it's intended to complement them so unlike Git DPM DeGit does not define a Git history structure the history structure can be anything. It doesn't define or suggest naming structures for upstream or downstream branches, pristine tar branches, whatever and it doesn't require a particular source package format it couldn't since it needs to work with any package in the archive. DeGit rather imposes only two requirements on your Git trees and these requirements stem directly from DeGit's objectives. The most important requirement is that your Git tree is identical to the unpacked source package. This is the whole point of DeGit because it enables DeGit to always present to the user a working tree which is the same as they would get from app get source. So considering that requirement for all native and source format 1.0 packages which includes anybody using raw Git to manage their delta from upstream a Git tree identical to the source package is already the interchange Git branch format. So if you're using format 1.0 you can start using DeGit right away for all maintainer uploads. So that includes all native packages and anything that's using any maintainer who's using 1.0.diff. For 3.0 quilt packages things are a bit more complicated. So the purpose of DeGit is to provide a Git view that's identical to the source package and can be worked on without knowledge of the maintainer's source format. This means that the DeGit Git tree for a 3.0 quilt package is what I think Raphael has called a patches applied packaging branch without .pc directory. What that means is that all of the changes made in Debian are represented both in the main source tree and in Debian patches. So for example if you add a new command line option to the program in a Debian patch there will be a Debian patch file in Debian patches whatever adding that command line option but that command line options that patch will be applied and the command line option will be present in the main source tree. This is obviously necessary so that somebody who doesn't know anything about Debian patches when they get the Git tree they're able to grab the source code and look at the main.c and see what the command line options are and not miss that this option would be there in the Debian package. So the most popular tool for working with 3.0 quilt I think probably I don't know if there's been a survey of this but it's probably Git build package and Git build package likes to work with patches unapplied trees. I'm sure about this the Git build package maintainer and we've had a couple of really good conversations we do have a plan for interoperating which involves DeGit synthesizing an additional commit or commits to apply the patches and pushing that synthesizing that is privately not applying that to the maintainers branch but that's what gets pushed to the DeGit Git server and I think it would be possible to integrate things this way I've done a bit of experimentation and that seems like it's going in the right direction So this patches applied versus unapplied problem doesn't apply to Git DPM which is I think probably the other most popular tool that people are using to manage 3.0 quilt packages but there's another problem which affects both Git build package and Git DPM Neither of these put the .gitignore or changes to the .gitignore in the source package that is you end up with a if for example the Debian maintainer adds a .gitignore the .gitignore occurs in the Git tree but does not occur in the source package and this is because they tell Debian source to ignore it when building the source package so this obviously is a problem and the reason that they do this is because they don't want to generate a patch in Debian patches that corresponds to the additional change to the .gitignore the 3.0 quilt source format can't represent the .gitignore any other way so that would be necessary I've spoken to Bernard Link about this he wasn't very keen on having Git DPM treat.gitignore normally and record.gitignore in a patch in the Git DPM branch so I mean I'm still talking to Bernard about this but if we can't think of a better solution then in much the same way as I'm proposing for Git build package DeGit will have to synthesize this .gitignore patch and effectively commit it privately on to the DeGit Git branch at the point of push so as to convert your Git branch into one that's both directly editable and equivalent to the source package right so there's a few other things I ought to cover since they often come up this sort of set of leftovers essentially is relevant to both maintainers and non-mainteners there are so firstly there's a few wrinkles I need to cover the first wrinkle is that DMs that's Debian maintainers who authorize to upload to only parts of the archive those people currently need to email me a signed copy of their SSH key before they can push this is because the DeGit repo server uses SSH as the transport and the Debian project does not right now have a systematic record of all DMs SSH keys we do have that record for DDs but not for DMs so there's some kind of ad hoc mechanism where I add the key the second thing that's less than ideal is that the DeGit Git history doesn't generally include the package upload history so you'll have seen on my slide here you get just this little stub Git import DSEs this can produce a Git branch more or less representing upload history but DeGit doesn't run that itself it would be difficult for DeGit to do that because it would have to decide which set of packages did it want to run that on and it would be a great deal of download and computation to run on the possibly the NMU as system now there's nothing saying that one couldn't push such a branch to the archive with DeGit push or indeed that there could be some kind of server side process that would generate such history and store it in the DeGit Git servers Git branches but so as I said earlier it seems to me that the Git history structure ought to be up to the maintainer and if the maintainer chooses to use DeGit then the maintainer's Git history is obviously much better than the import DSE snapshot based history so I think the real way to improve this situation is to persuade more maintainers to use DeGit if we discover that a lot of maintainers don't want to use DeGit you know at some point we will consider centrally maintaining a snapshot based history at the DeGit Git server but the most obvious challenge is DeGit's insistence that the source package and the Git tree are the same so sadly quite a few source packages contain files that aren't in the maintainer's Git branches but which are needed to build so there's not just .gitignore which isn't really needed to build but the most common example would be auto tools output so there are a lot of workflows that seem to involve having a source package that contains the auto tools output but a Git branch that doesn't such a Git branch is not usable with DeGit because the point of DeGit is that the user gets the same thing as the source package I don't think this is a terrible problem because nowadays the recommendation mostly seems to be that the package build should always rerun auto tools and if you do that then neither your Git tree nor your source package contain the auto tools output and everything is fine if that's not the workflow you want and there's some reason you don't want to do that then you can commit the auto tools output to Git this sometimes gets you merge conflicts you can resolve those easily just by rerunning auto tools and the second way that DeGit's rule seems mostly to byte is .gitignore and we've discussed that in the context of 3.0 Quilt most existing build tools remove .gitignore from the package build so even if you're using 1.0 source format your source packages don't include your .gitignore even though your Git tree did and this is why DeGit provides these wrappers you'll see there in the third synopsis line for the build operations if you use those tools to build for upload DeGit will pass some appropriate .i options to deep source to exclude exactly and only the .git directory and with source format 1.0 this is sufficient there's a compelling advantage of DeGit's Git based approach which you'll probably notice if you do cross archive work many packages have very strangely behaved buggy clean targets because DeGit knows that your Git tree is canonical it can help you work around this problem so you can just tell DeGit to use Git clean instead and never run the packages clean target if you're not in the habit of forgetting to say Git add then you can set a configuration option to have DeGit always use Git clean and then you'll never have to fight a buggy clean target again so I've got a few plans for the future which some of these I may even get around to I need to implement this automatic adjustment that I discussed earlier for Git build package and Git DPMs Git trees so that users of those tools can do DeGit push with 3.0 quilt and it's possible that they will have to be or that they're all to be some additional tooling to help those users deal with NMUs in a sensible way DeGit can't currently upload to delayed queues which makes it a bit awkward for a kind of fire and forget NMU so I've thought about how to implement this the obvious implementation is just to divert the .dsc the changes file to the delayed queue and immediately push but have DeGit still immediately push the upload to the DeGit Git branch but if the maintainer deleted that upload from the queue with de-cut the changes would still be present in the DeGit Git branch and so a future DeGit user would see that upload would look just like an upload that was stuck in a queue somewhere and if they then upload based on the DeGit branch the changes that were de-cut by the maintainer would be resurrected and I think that would be unpopular so at the very least there needs to be some way for a maintainer to revert a push which was accompanied by a delayed upload but I'm not convinced that maintainers are going to be happy having to do some special thing to undo some oh this DeGit weird tool did some strange thing and now I have to fight it so a better implementation would be to have the push DeGit branch stashed away in some corner somewhere just like the just like the source upload is and then at the appropriate point it would be revealed when it was ready if it was still a fast forward that makes it trickier for somebody else to find it if they want to work on top of it there might have to be some special option to fetch to say oh I actually want this delayed NNU because I need to update it and it's more work to implement but I think it will probably reduce the possibility for other maintainers becoming upset it will be very easy for DeGit when it is doing an NNU to construct the NNU diff that you're at the moment required to email to the BTS of course the maintainer can fetch your NNU as a Git commit easily with DeGit fetch but if the maintainer probably doesn't want to do that or maybe isn't using Git at all and you're supposed to comply with the existing policy so you have to send this email so I think DeGit should probably just construct that email itself and that has a few advantages because for example the DeGit generated email could specify the exact Git commit range that was pushed in a URL to fetch it from which the maintainer might find helpful along with the conventional debdiff when you're doing a source only upload you have to do slightly more work then you really should have to because there's no real need in that case for a separate build source package step so I think there should be easy way to have DeGit push generate the source package at the same time as DeGit push would generate the source package rather than you having to do it in advance since it can easily do so where are we right so the DeGit Git server has now a lot of access control machinery it knows who's a DD who's a DM it can receive signed updates to Git repositories so it's got most of the moving parts to become a fairly general purpose Git server with access control equivalent to the Debian archive so in this role it could replace some uses of Alioth which I think would be useful because Alioth is doing too many other things and isn't quite the right shape and Alioth is also I'm sure the Alioth people would not mind me saying this but Alioth is in need of help with its administration and care and feeding so taking that load off Alioth and using something also with better security properties would be an improvement so in particular I'm thinking of arranging that you can do signed pushes if you have signed pushes then a fully git-ish packaging workflow where you just pull the branch from the Git server and you can know that that branch was pushed already by somebody who was authorised at the time and there's some traceability of where that came from at the moment with Alioth or indeed any other Git server that's not really true I suspect many maintainers probably don't check what they find in their Alioth VCS Git master branch anyway and they probably often just push it knowing that it's the thing that they pushed themselves yesterday but in principle that's not good Digit requires the sweet branches to be fast forwarding if you have a workflow involving Git rebase you need to make a fake merge so one made with git merge-s hours at the tip of your own branch to make it be a fast forward to the previous state of the Digit sweet branch and when you want to work on the package again with Git rebase you'll need to strip that fake merge because Git rebase will choke on it you can do this you can do all of this with raw Git operations if you're a Git expert, Git merge and Git reset have all the relevant functionality but it's quite ugly and doing it by hand lacks some important safety catches so I'm intending to provide some tooling that will make this easier and make a fully Git rebase kind of workflow easier and the final thing I can do myself is arrange for non-Digit uploads to be automatically converted to history in the Digit Git server which would make the Digit Git service history at least not be up not up to date there are also some things I need help with so the documentation for how Digit works together with existing Git management tools is a bit out of date so ideally I think each Git management tool Git workflow tool would explain how or whether it works with Digit and it should explain for example what additional requirements there are that you have to sort out if you want to Digit push and how to incorporate changes made in an NMU into the tool's own favourite workflow and history format how to update a package to a new upstream version some of the maintainer tools don't cover that I'm spoken to the Git build package and Git DPM maintainers and I'm optimistic about that this is going to come particularly about Git build package finally there's a not finally, nearly finally there's a difficulty with empty directories in source packages Git refuses to handle or track empty directories I won't go into that in too much detail since I'm running a bit short of time there's a few exciting finally possibilities for new uses of Digit it would be very nice to have a way for a sponsor to provide a Digit-ish Git branch which the sponsor could work with directly and ultimately Digit push when it was ready I want to talk to people familiar with the sponsorship infrastructure about this when I had a look earlier about this a week or two ago sponsors Debian that seem to be down I don't know maybe there's some help needed there and secondly Digit is not just for Debian other distros currently using source package based workflow can use it too so we've read only support even any specific support at the distro end so you can Digit fetch from Ubuntu right now patches for read only support for Mint should be quite easy to or any other derivative should be quite easy to to provide Digit push support for a particular distro requires infrastructure support it needs a new Git server that ought to be under that project's control and it might need some thought so I hear rumours that Ubuntu might grow a Digit Git server and support Digit push and I just wanted to say that patches in that direction are also very welcome and finally there are some people I need to thank at least half of the design of Digit is Joey Hesse's at the now famous cardboard diagram session at Vilmarcu where we sketched it out on an old cardboard box DSA and particularly Peter Pylfrada have been absolutely brilliant and level of service and competence has been really outstanding every time I thought of some aspect of the setup I've forgotten and made some blaver as an ill thought out request a DSA would propose a much better alternative and implement it their end of it almost immediately I also like to thank the FTP Masters data service which has enabled me to extend Digit's usability to non-DDs and non-DMs so that's what I've preferred and there's a lot more detailed information in the man pages but I think we still hopefully have some time for questions are we going to do this with a roving mic? if you want to ask questions please go to the microphone you've sat in the wrong spot Manoj sorry use the roving one okay that seems to be on okay so you started introduction by saying that Digit's task is to represent the archive as I get remote and you're going through great length to make sure that individual commits that are there correspond to the content of our source file but it seems that you're mostly unless in the things to do list ignoring the fact that the Git repository is mostly about the history so I would have expected the first thing that you do is to have the complete history of the archive as a Git branch and then think about how you can maybe have each of these commits representing actual uploads have a secondary or tenary or whatever parent into the that's the actual Git history of the maintainer at least that seems something that I would prefer to see from Digit that there's a clear branch that I can look at and it's just commits representing uploads and then the maintainer Git history gets merged into that as a parent is there a reason why you didn't attack it from that angle yes because that's harder and less immediately useful so if you think that's important and you would like to arrange for the Digit Git server to have that Git history for all packages that have been uploaded to the Digit or all packages at all then I'm you know I'm happy to have help and there'll be obviously some server side work to be done there but yeah help very welcome is there any requirements on the local build infrastructure to using Digit do I have to use sbuild no you can use whatever you use to build packages right now obviously you should be using sbuild or maybe pbuilder but if you're not there's nothing stopping using digit and all it needs then is a .dev file in some well known location so when you say digit push it will expect to find in the parent changes that your build produced and it will so all the signing is done at the time of digit push because that's the atomic that's like the commit operation so at that point it will take your changes file and it will write the commit hash into the dsc re-edit the changes file sign all of the things and upload the result and your changes file presumably will include whatever binaries are required just sounds really useful I'm definitely going to use this but first of all thanks a lot for their works I'm sure that will help for a lot of NMUs and small packages which don't really warrant their own fancy history and I've got one question about NMUs, would it be possible to represent the stuff that is in delay queue as branches other than master in Digit so that you can access them if you want but they don't necessarily look like they would already be in the archive yes I think that would be the sensible way to go about that problem there's some there's going to be some slight wrinkles there because the way that the delayed queue works and the way that a second branch that you'd have to have maybe branches named after the date at which they would be uploaded or something I figure you would have to change like a branch delay2 delay3 delay4 and then update them every day or maybe there'd have to be some cron job that would on the server and you would see when the thing appear to the archive and go oh I'm supposed to shuffle this commit across now or maybe you can even get a notification from the delayed queue that said please update your branches now I just moved everything across from the delay3 so actually if it were in a second branch and then you did digit fetch because the .dsc would have once it's been accepted into the archive the .dsc would have a commit hash in it it would automatically use that commit on what it found on the git server so the suite branch is mostly it's there to record uploads that haven't made it into the archive yet but for uploads that are in the archive it's just really it's just there because git needs a ref to cause the objects to appear and it's the .dsc that really tells you what the value of the suite in the archive is so you just said that if you do digit push it it goes looking for a changes file and put a letter bit and then upload it is there any checks in place if you accidentally made a change after you last built and forgot about it then digit push that then it's no longer in sync yeah and digit will detect that and it will complain which which suites are supported I guess all suites are supported also proposed updates and other stuff any suite that is in the ftp master data service API is supported it is possible that there are suites that have strange properties that I don't know about where if you do digit clone squeeze wheezy proposed wombat needles that somehow exists in the ftp master data service API and I don't know about and if you run that maybe there's some strange bug that occurs but in principle every suite is supported that is on in the archive at all how are those merged for example if there is some NMU into experimental and an MNU based on that in unstable what would the history would the history be merged so if no the digit doesn't merge history from different branches if you do digit push then the history is just what you push so if you do digit fetch from experimental and then push to unstable the thing that you push to unstable will be a fast forward from experimental but you'll have to merge it because it will have to be a fast forward from unstable as well if you if you don't do a digit based for non-digit based upload the synthetic histories on the different suites are just constructed ad hoc and they constructed client side not server side hi to two small questions the first one you mentioned that you generate debent pages automatically somehow is it a git format page or is it something different I think it's duplicate source-commit ok the reason I'm asking is if it would be git format page upstream could just git AM the page directly from Debian which I as an upstream would find totally awesome are patches generated by deboost-commit usable for git AM great no no that was a question are they oh I don't know far that is a bug against duplicate source true and then so the reason I do it like that is because the quilt 3.0 thing is quite complicated enough already without digit kind of opening up the cover and starting to mess around with the insides as well so deep good source tries to pretend to deep good source that it is just a very sophisticated maintainer who knows exactly what to do and therefore and that's why for example I generate patches of the deep resource commit and arranges for a digit itself to be re-invoked as the editor so that it can supply the right commit message ok, thank you and the second question is did you ever encounter an oryctable that contains .git attributes or git modules I have a bug open about .git modules and the answer is .git modules doesn't actually cause any trouble git attribute will git attributes might if you have example packages of like weird pathologies in them nothing in the archive because that's what pretty much non free but I do have an upstream which generates such a top well if you have a thing that looks a bit like a source package that you think it won't work with send me the bit somehow because these wrinkles ought to be sorted out if at all possible thanks sorry for the remaining question if you could ask after the talk outside to let some time to the others to prepare for the next one and thanks for the presentation ok, thank you