 Welcome. Now we will see the talk about Debian packaging with Git, with David Bremner, David is a computer science professor and he is a Debian developer for about 10 months. David, please. Thank you. So from that introduction you can conclude that I'm prone to useless levels of abstraction and I have not much experience, so you should be really looking forward to the talk. I think, I don't claim actually to be the expert on this topic. I think the experts are elsewhere, but somebody should give this talk, so here I am. I think a lot of people are already packaging with Git, with some expertise, but a lot of people are thinking about it right now. Even the Pearl team is considering this huge transition. They managed to slow down the transition by saying that I had to actually pull the trigger. So it's the usual duocracy as procrastination. So that's enough preamble. Should you sneak out now? Well, I don't really expect you to know too much. I already said that I don't know too much, so I don't expect you to know too much more than I do. You should know what a source package is, and I guess almost everybody who's here knows what that is. If not, well, that's something we need to talk about in another context. And you know what a Git branch, you have some use Git a little bit. You know a little bit about the branching model. If not, Thomas, who's offering a Git tutorial in an hour, are you in the room, Thomas? Okay, so wave and encourage people to go to that if you're still interested after this talk. If not, I'm really sorry about that, Thomas, to lose your audience. Okay, so I thought about doing a really sort of, you know, interactive laboratory-style thing, and somehow the room killed that idea for me. So it will be a bit high level, and it will be somehow not a how-to, but a why-to. A more what's going on underneath, and maybe to help you make some choices. I think as soon as you start using Git, you realize that Git people think that a mass of choices is a good thing, and this is no exception. So what I want to do is sort of sketch out different workflows that are possible, and then hopefully get some feedback from people in the audience about what they think are best practices. I mean, I'm not trying to be, you know, the packaging dictator, which would be a position no one would want, I suppose. Okay, so while I'm thinking about in the context of this talk, what's the packaging cycle? Well, we start with some upstream source. Sometimes it's us with a different hat, writing that upstream source. But anyway, we write some source, which is sort of generic. It's not specific to Debian. Okay, leaving aside native packages and some... And then we remove some non-free stuff, maybe, right? Lots of... We already discussed how we probably have the strictest definition of what's okay to ship. Or just some really huge and not helpful things, right? So binaries for Windows that are 300 megabytes, we probably want to remove those from the source. Then we do some packaging, right? So step three is somehow compressed in this talk, but it's, you know, the main part of packaging is editing files in this special directory. And of course, more often than we'd like, we have to patch the upstream source. Sometimes we're lucky, we don't have to do that, but... And then from the point of view of this talk, the problem is solved once we have a source package. Everybody knows we're going to any day now have source-only uploads, so never mind building the binary package. Okay, that's not really the point. The point is that building a binary package from a source package doesn't really interact with version control systems, right? I mean, at least that's my point of view. So the first step is you have to somehow get the upstream source into a state where you can use it in version control. And then you have what I'm calling repacking, is you have to get rid of the parts that you don't want to keep. And I guess almost everybody has done both these things. Maybe not, you might have used SVN Inject or something if you're using Subversion. So there are some buttons here. If anybody is wanting to take a sort of more techy detour we can, just tell me. And by the way, it's supposed to be a tutorial, so please stop. And if I went off in some direction it's not making any sense to you. Okay, the gray blobs. Okay, so I'll read it out for you. So you want to get the upstream version control history. I mean, this is a motivation for using a version control system in your packaging is to have the whole upstream history in your packaging repository. And I think so people have various reasons why this is nice. I think the most compelling argument for me is that you can cherry pick upstream commits from the future and turn them into patches for your current Debian package. So this is something that I find really nice. It gives you a very nice way of tracking things. And you often want to unpack a tarball. Even when you're using a direct import of upstream history, it's nice to have that check some identical tarball with upstream. And so, well, it's a small trick which Russ already discussed a few days ago or a week ago on the Debian developers and I'll mention again how to do that. It's very simple. Okay, you can then, and then you need to commit the changes to version control. So one of the things that I'm happy to go over, for example, in a hack lab with somebody or as a question is, well, I don't want to use any of these fancy tools. I just want to get a tarball and use basic Git commands to get that into my Git repository. Maybe you're the kind of person that finds that horrifying, in which case I won't tell you. So that's what this button says. Pristine tar. I think I saw Joey somewhere in the audience. So he's responsible for that. It's a nifty tool. And I'll mention a bit about that. The point of pristine tar is that you can, for almost free, have a check some identical copy of your original tarball in the repository. And that's often convenient. Typically, the way that people work with Git is to have a merged branch, integration branch, with packaging commits and upstream source, either from the tarball or from upstream commits. And maybe as part of this whole process you want to take. So this is the generic, so I told you it would be a bit sort of how things work. Mostly you will be typing one command to do all these things. But when you want to get a little bit outside the normal thing, you say, oh, I'm not using Git build package, can I still use the import tool from that? Then hopefully this will help you understand that the answer is yes. So what is pristine tar? Pristine tar is a little bit of black magic from Joey that uses xdelta fundamentally. That's the key step. Xdelta plus accumulated tax and heuristics on top. Yeah, okay. So xdelta plus things that Joey doesn't want to talk about. Okay, so there you go. And it's very nice. It means that you clone a repository and you've already downloaded effectively the pristine upstream source. If you use this checkout command, then you have the exact tar ball back. I forget if recently it has failed completely for me, sometimes it just xdelta and various hacks can't really make a small little encoding of that tar ball and essentially keeps a copy of the whole tar ball in the repository. And pristine tar will report that as a failure. I would say you will encounter this. If you use pristine tar, Joey claims you'll never encounter it. It happens to me two or three times in my long Debian career of 10 months. No, okay, and before that too. Okay, so pristine tar is definitely something to know about and most of the sort of convenience tools will say, oh, and you can use pristine tar. So what surprised me in talking to people is that they don't know that pristine tar is an independent tool that you can just use to do its thing without using some of these wrappers. And that turns out to be useful from time to time. For example, the wrappers all like to do lots of very convenient stuff but some of that stuff is only, like making tags, is only good to do once. So the second time you have to import things because it didn't work out the first time, then you have to sort of know how this process works and use pristine tar by itself. Okay, so you would like to have upstream history because it seems like the cool thing to do and plus you could cherry-pick commits and conceivably you could use, for example, Git bisect to look for the upstream commit that caused your bug. This is hypothetically possible. I don't know how often people are doing that. Anybody in the audience looking for bugs using Git bisect? Okay, in your own code, yes, in Debian packages. So definitely a few. So BDL probably should be giving this talk, I suspect. Okay, he denies it. Well, that's why I'm here, right? I'm the gullible one. Okay, so what do you do? Well, you just get the history on the branch and then you import the tar ball on top of the branch and how tar ball import works is it just says what's currently in the repository? What's the difference between that and what's in the tar ball? Great, that's a commit. Can you do this on top of the current history, the correct upstream tag from which upstream generated the tar ball? Well, depending on how crazy upstream is, that diff should be small. But okay, we all know about auto tools, right? And so there will be differences between the tag in general, between the tag in upstream's SVN or Git, or Mercurial or whatever, and the tar ball they ship. And that's more or less on purpose. Okay, so that is easy to do and it's my standard, I do it by default because it's not really any more work. Okay, so how would you do this in practice? Well, I think the most widely tool, the widely used tool is Git import a ridge, which comes with Git build package, but it's not really tied to it. It does the import, it knows how to use pristine tar, it follows the conventions, the branching conventions of Git build package, which is that Debian packaging happens on the master branch and you have a branch named upstream. And that's about it. So it's not a huge convention. So it knows how to use pristine tar if you tell it in a config file or as an option, and it merges the upstream into master, right? So you get a new upstream release, obviously you want to now use that upstream source in your packaging work, and it, I guess, no, not really optionally adds some tags. So that's why if things don't go right the first time, it helps to know what it was that Git import a ridge was trying to do. If you use Git DPM by Bernard Link, it has a similar option. It does all the same things. And then this is sort of a running theme with Git DPM. It does a little Git DPM specific bookkeeping. It has a hidden file under dot slash Debian where it keeps track of some things, essentially so it can help you know when you probably meant to do a step and you didn't do it, right? So when it does some sanity checking, and of the tools I'm going to discuss today, it's pretty much the only one that sort of does sanity checking in that way. I'm saying, okay, you imported a new upstream release, but you never really merged that into master, and probably you wanted to merge it into master, right? So there's a little help there. Okay, so that was importing. It's a good place to stop and try and wake you up. Anybody have questions about importing things they'd like to be able to do? Think that tar balls are dead and we're all just going to use Git anyway. The whole discussion is pointless. Yeah, okay. That's your point of view or you have a question? Okay. We have to wake up the video team. Wow, it takes some skill. Try to speak loudly. Okay, I was just wondering the suggested workflow there about having both the upstream Git history and their releases. It doesn't mean you have one branch upstream as in their Git repository and then upstream as in what they release and then have like letter merges, like two lines and then they're connected by the tar balls or... So what I usually do is have one upstream branch, but I mean my upstream essentially, and I merge from tags. So upstream makes a tag, I merge that tag. So yeah, in the graph you will still see that merge into upstream. So you have the tag in here and then piled on top of that, you'll have the fix this up to make it look exactly like the tar ball. Your upstream reflects the tar balls, not upstream's Git repository. Right. Okay, thanks. I mean, like everything else I say, I think there's no absolute correct way to do it. It's my habit. Any other? Okay. So the other really simple thing to do is, well, you have a tar ball, repack it, right, and use your favorite script or... Sorry. Oh, another question. Relaying from IRC. Okay. Someone was wondering why you use the master branch and not Debian. So I guess it's the branch that as a packager you will use most often, but I think you really have to blame the author of Git build package for that convention, which I think Git build package was the tool most of us use first. But there's no reason not to use a branch, Debian. It just, you will mean a command line argument to Git build package to make it work. I see. And the follow-up question that... Well, never mind. You answered it. Thank you. Bidale needs a mic. I was just going to suggest that even though that's the Git build package default to use the master branch, I personally find life much less confusing if I create a Debian branch and update the Git build package config file to note that that's the branch I want to use for Debian things. There are too many people in the world who've overloaded the use of the master branch. And I personally these days prefer branches or Git repositories that don't have a master branch because then you don't deal with that at all. No assumptions. Okay. It's a good point. Yeah. So for sure, none of the tools I'm talking about today would have a problem with that. So far we know about Git build package and Git TPM. And that's... Okay. So you can also... I think a lot of the time and what I talk about today, you can either try to do something new or not. And I mean, it's worthwhile just to use Git as a version control system and continue with your old packaging habits. You don't, I think, lose something. Maybe you don't win as much as you could. But you also don't get confused and struggle with some new technology when you just want to get bug fix out the door. So you can also repack, make your DFSG1 tar ball and then import that on top of the Git history. And the fact that the files are deleted in the tar ball will kill them from the current repository. Now, one thing we're a little slack about is we're... In that case, and in the other case, if you're taking upstream history and upstream history has non-free things in them, then that history is still really there, right? Unless you go to extraordinary lengths. And I think we're relatively tolerant of that, for example, of repositories on git.dbn.org, that maybe not in the latest revision but somewhere in their history have things buried in them that we don't want to distribute. And if that's a serious issue, I'm happy to talk about that. But I think it's kind of an orthogonal to this discussion. Okay, so not much changes as far as how you do your real packaging, right? You edit dbn rules, you spend days compiling a 4000 line dbn slash copyright. Git isn't going to help you with any of these tasks. Sorry about that. But I just wanted to mention, I know a few people are not used to this idea of having everything in the version control. And, of course, you can just, in the style, I think some people still do this even in git, is to only keep dbn, the dbn directory in version control. Well, I don't know. If all you're optimizing is disk space, then I think that's probably a false trade-off. Maybe somebody else will get angry about me. I mean, I know that we do have disk space issues from time to time, but I don't think that this is why we have disk space issues, right? We have disk space issues because we have huge blobs of various kinds. Okay, so you can do that, but I think you lose out a lot of possibilities. Some people like to keep dbn directory on its own branch, and this is very clean and tidy, right? You do all your packaging on one branch, and then you merge that into an integration branch. I don't really see the motivation. Maybe somebody else can articulate it better. I tried this when I more or less took over racket recently. It was like that, and I tried it for a while. I just couldn't make myself do it. I kept committing on the master branch, but I don't know. I think that if you're doing that, you're probably missing out the fact that it's pretty easy to look at the history of the master branch and say, did this commit touch files outside of Debian? And I have a sort of ugly pearl script to do that, but it's only a page long, I'm sure somebody can do it in a line of awk or something. So there's a challenge for you. For those of you who are finding this all completely trivial, do a shell one liner that says, look at the commits in a certain range, so say upstream dot dot master, and tell me which ones touch files outside of dot slash Debian. It's conceptually easy. You can do it in a page of pearl. That's because I'm lazy. As I said, so have some shell golf fun. Okay, so how do we handle patches? Okay, so why don't I keep to my own idea here and stop and say, is there anything mysterious here? I mean, really, this is just sort of justifying a workflow that I find convenient, and most people using git for packaging find convenient, which is just your main packaging branch has the source and the Debian packaging in it, and that's the only place that the Debian packaging commits live is on that branch. Anybody think that's a really incredibly stupid idea? And they say you can't get a room full of Debian people to agree about anything. I'd like to defend the idea of having only Debian in a version control system with the argument that once we discuss the next chapter, how to manage your changes against upstream, you will see lots of different approaches and some like them and some like others. And if you have a package that's maintained by a larger team, having only Debian in the repository basically remove this process from the repository. So everybody is free to use whatever he wants to use to edit the contents of Debian patches, but the central interface is basically the Quill 3.0 specification of Debian, and it makes it easy to cooperate. You don't have to force the process about how do we track the patches on them. There's a canonical choice. It's the Debian directory. So that might be an argument for using only Debian in a version control system and be using it in Haskell team, but it doesn't matter here. And I think I'm quite happy with it. Okay, so that's a... I don't want to sound snide, but that's a classic example of a technical solution to a social problem, right? Which we usually use as a put-down, but if we're honest, we know that that's half of what we do, right? I mean, spam is a technical problem? I don't think so. It's a social problem of not having enough time to track spammers down and explain to them the error of their ways. Okay, so... Okay, good. So if you want to keep... If you want to keep Debian on its own branch, then as Joachim... Did I get your name? Approximately. Says... Then there's no choice, really. Or it doesn't matter, right? How people manage patches. So, indeed, whether or not you keep the upstream source on your packaging branch, you can stick to just using Quilt in the normal way, or DePatch, or whatever your favorite patch management system is. Quilt is the obvious one, right? Given that there's a source format that is kind to it. So this has the advantage of working, and your team knows how to use it already. And it doesn't... It never goes wrong in new and strange ways, right? So you don't ever wake up to someone screaming at you about how your workflow is crap. On the other hand, you know, that's great. It's the most conservative approach. Maybe you'll see some benefits to trying some less conservative things. I mean, if you wanted the most conservative approach, then probably upstream tarball plus Quilt, and no version control. Well, I mean, version control is nice, even if you only use it as a way to undo things. Okay. I think the other approach, which is probably underappreciated within Debian, is to ignore Quilt entirely, ignore version three packages, just ignore source packages as a publication mechanism. And I know this is perhaps a controversial idea. Say, hey, this is the, you know, 2011th century or whatever it is, and people, if they want to know what you have done to upstream source, they'll get your repository and look at it in a much more convenient way. So if you do that, it's not so bad. As I mentioned before, you can run a simple script and say, okay, which of these commits that I've been committing willy-nilly to the packaging branch ought I to consider sending upstream? And you can do that. It has the nice, this workflow has the nice feature that when upstream takes your patch, you don't have to do anything, right? When you merge the new upstream source in, all that patch is already applied, everything is very nice. I mean, you know, unless things go wrong, but in general, everything works very nice. And it's less obvious how to generate nice source packages from this where somebody can, whereby nice, I guess I mean not one big diff, right? So version one, if you think that's nice, then great. This is the workflow for you. If you're making version one packages anyway, then you might as well do this because you're going to get the same output at the end and it's less effort for you and it has some advantages. All right, so anybody like to yell at me about this? Yes, please, give the man a microphone. You just want to yell, nothing in specific. Fair enough, duly note it. So like I said, I mean, I think this is a matter, right, for individual developers, for teams to talk over. I mean, if somebody thinks there ought to be a policy that thou shalt not throw out crappy source packages that are no fun for people to read, well, the policy team is somewhere else, right? And go to it, by all means, make that policy. I don't see that as current policy. But anyway, I'm also not trying to enforce this on anybody, okay. So my own packages, by the way, are a mix. I've been trying out different things. I do that in one package and some fancier things in another package. So fancier things come down to, oh, wait a minute, why am I using quilt to manage patches and this git thing, which seems like it manages patches too? I mean, there's some sort of aesthetic problem there. And so, well, the overall plan is you're going to store patches either as git branches. So you might have, you know, if you think about a patch as a big change to upstream source, which hopefully we're not doing very much, but sometimes we are, then maybe it makes sense to think of that as a whole branch, right? You have a whole sequence of commits that are about working on this feature. That's a typical feature branch in git talk. You somehow, or the simpler notion is I just want a convenient way to manipulate a set of patches against upstream. So I have this directory dbn slash patches and I can manipulate that with quilt. I want to suck that into git and suddenly I can do some new things that I couldn't do before and then splat it back out. So those are your two options. There are details like do you want to commit patches? So do you keep dbn slash patches committed to your repository? And I think almost everybody does, just because it's somehow the most foolproof way of doing things. There are ways of not doing that. And the other question is if you have this set of patches against upstream source, should those patches be merged into your packaging branch? I think this is actually a more interesting question because, well, it sure is a nice way to see if your patches are going to apply cleanly. But it's going to mess up your history a bit because every upstream release you're going to rebase those patches. You have to, same with quilt, you have to regenerate your patches against the new upstream version and those are going to show up as new patches in git history as well. It's not the end of the world but it's something to be aware of. So how do you generate patches from git? Well, of course, git has a command to say turn this commit or this range of commits or the difference between these two commits into patches. The question is what should you feed to that command? And the simplest way to do it is to use the rebase command so you have a branch which is patches on top of the old upstream source and you say, hey, I have a new upstream source, transplant those patches and we'll work out any new conflicts and we'll get a new set of patches. So it's more or less what you would do by hand with quilt except that it typically takes less than a second. I mean, in the nice case, rebasing your packaging patches against a new upstream is pretty much very fast and simple and the cool thing is, again, the patches that have been incorporated upstream magically get removed, well not magically, but technologically get removed from your patch series. Okay, and finally, so I'm going to mention briefly something called Topgit and it has another way of dealing with this. It essentially keeps a separate branch to keep track of what your patches are against. Okay, so when I arrived in Banyuluka and I was jet lagged and super tired, I had this brilliant idea that what you could do is just scan your Git history. I've already claimed that it's easy to pick out the commits which touch things outside of .slashdebian and then just call those quilt patches. Well, you don't need to start telling me reasons why this is bad, but I couldn't really get it to work out very well in practice, but I still think it's a cool idea. It just doesn't happen to be a cool idea which works. So if somebody liked to transform it into a cool idea which works, I think that would be very nice, right? The lazy Git-head approach of just working this Git branch and add commits and then say go through that history and rip out everything which needs to be a patch. Now, the thing which gave me hope, let's skip that and come back, the thing that gave me hope that that might work is that deep package source detects, well, heuristically detects when patches have been applied, right? So if you have a version 3 package, when you generate the source package, it guesses whether your patches are applied yet and it does so by trying to apply the first patch and checking the return code. So that's a little fragile. Nonetheless, that's what it's already doing. So in fact, Git DPM exploits this. That's how merging... So you have this branch of patches, right? However, you're working with Git DPM or with Git build package and if you want to merge that into master, then in principle, that should work fine. It should be no different than working, you know, checking your patches applied, right? There's this debate back and forth on the mailing list about whether you should have your patches applied or not when you check in things into version control. Well, there's a nice way to have your patches applied, have them merged in as Git commits. And then, well, it's no more fragile than what people are already doing. Okay. So I sort of skipped talking about TopGit. I'm happy to talk about it afterwards, but I think that most of the people who are using it for packaging have given up on it, mainly because I think upstream gave up on it and it never really got beyond the prototype stage. Okay, so now I've probably offended somebody out there. Sorry. Okay, so how do you manage these branches of patches? Well, one way to do it is a cryptically named utility from Git build package called GBP PQ, Git build package patch queue, I think. And the idea there is that each developer on a team will privately import the Git pack... Okay, import the patches from Quilt, work on them however is convenient, maybe cherry pick some new patches from Git, and then export back to Quilt. So it's more or less the same outside view of sharing via Quilt, right? It's just that individual developers are free to have the convenience of while they're working on getting all this stuff working of using Git commands. Similarly, Git DPM works pretty similar. The main difference is that, as I mentioned, it keeps the patches merged into the master branch. You can do this by hand, and I want to play around with this a bit and see how it works out. Using some other tool, I think it's an interesting idea, and quite a few people are using Git DPM, so it can't be completely insane to do this, or we'd have lots of build failures. So it's an idea that's at least field tested a bit. Finally, there's the hook for Git package I wrote, which does something similar, except that it's a little more general. You give it a recipe for how to extract patches from Git. So you give it a file, and each line in that file is basically something to pass to Git format patch with some substitution variables in it. So the idea in this tool, that's, thank you, very helpful, is that you use tags to control things. So you tag upstream, and you say you tag the current set of patches, and then when Git package constructs your source package for you, it knows where to grab the patches from. So essentially, the big difference here is that the patches are not explicitly stored in your dvn-slash-patches directory in version control. One can argue about whether this is a good idea. It makes things a little more delicate. I managed to convince the Lintian maintainer to add a check for the error that can arise from here, so it's not too bad. So making a source package, I think that's not so interesting, so I want to stop here and leave the last few minutes for questions. So I probably sped through that a little quickly, but at least the concept is clear, I hope, that the seemingly most effective way of dealing with patches in Git is to have a branch which you rebase against master. Questions? Yeah, so about the question, should you keep patches applied or not in your dvn-branch or master, however you call it? So I've started now to experiment with doing my work in feature branches, that are just forks of upstream, and merging those into the dvn-branch at the point where I merge, then I generate the quilt patch out of it. So it's a little bit more manual work, but I feel more confident that with the feature branch I have something to give to upstream in case I want to merge it. You have the nice history, and you also have the quilt branch. So I think that that can be automated, and I think to a certain extent Git DPM does that, but it's not smart enough to do multiple feature branches, which is obviously a big failing for you, anyway. Yeah, I've been carrying this idea around since year or two and given to talks about it at Debian Mini Conference in Paris and Berlin, but haven't had the time to implement it yet. But I wonder if any of those tools you mentioned is able to have the patches stored in kiln format and export them back to Git branches, but with their history. So if I change patches over time and export them from kiln format to Git branches, is there any tool that can keep the history of the branches? So conceptually, TopGit is lovely for that very reason, that you use essentially a feature branch to generate a quilt patch, and you have the whole history of that feature branch over time. When you rebase, you essentially just have that one patch series. I tried TopGit first, and I think it is too complicated for broad adoption. That's probably fair, yeah. So that's kind of why I skipped through it. But technically, what you ask is possible, I think the UI is not there. And I'm a guy who thinks that Git has a nice UI, so you know that's a strong statement. Two questions. First, you talk about detecting commits which touch upstream source. How do you deal with commit which touch both upstream source and Debian directory? You say oops, and you revert the part which touches the upstream. You revert one of those halves and make a new commit which you can send to upstream. I've done this. Sure, you only send the upstream patches to upstream, but if you merge them later, you will still need to make sure they are applied at the same time. The upstream change and your change to the Debian directory sometimes. Well, you essentially split the commit into two. So if you make a commit, you revert that commit totally, say oops, and make two new commits that do what you meant to in the first place. Okay, and the other question is about non-maintainer uploads. Deptif is interface. As a maintainer, you get send adaptive. How do your tools cope with that? Because some of them sound like applying adaptive sent to you by your non-maintainer uploader is not very easy. I have to be honest, and people actually don't send me Deptif, but that's a different rant. So, well, it essentially would be... I mean, hopefully it would be a patch, and you would apply it just on top of your current repository. And Git actually has reasonable tools for picking apart a big diff and making it into reasonable commits. So... Hello? Adaptive applies against the source package. So actually generating the source package is... Well, your packaging directory is effectively a source package. Okay. You applied against that? Nothing technical to say, but just to let people know, I use TopGit, and while I share your view that it is a bit overkill, I also found that the features and the possibilities it offers are quite worth of its being overkill. So I'm using for a few packages, and at the moment I think it's the solution of the solution I've tried is the one I prefer. Okay. Yeah, I did prefer it until it... I couldn't do an upload because TopGit was broken, and then I was angry. And unlike people, you know, tools, if they make you angry you can stop. One thing I'm still really looking for is some tool which allows me to check out pretty much the complete source package at an older version. Right now, if you maintain each patch as a separate branch which you always rebase into the new version, you pretty much lose everything, every situation where this patch was once applied to another upstream version. And TopGit has the infrastructure to do this, but doesn't yet offer any command which can do this. You would pretty much have to pop a tag onto each of those branches which maintain patches so that you know which branch this once applied to, and I don't know, is there any solution for that problem yet? I would say that most people using rebasing are just having a single branch which they tag when they upload. So in that sense it's very easy to go back. As far as maintaining lots of different branches, that's, I agree, not so well solved. I'll be happy to continue talking to people, but I think the talkmeister is going to execute me. Thank you.