Sean Whitton writes ("Re: Bug#932096: tag2upload. upstream handling"):
> What is the benefit of avoiding uploads where the upstream git tag is
> not, for whatever reason, an ancestor of the commit to be uploaded?I think it would usually be a mistake. > If the upstream tag provided does not actually correspond to the > upstream source, dgit will detect that already. Whether that tag is an > ancestor or not does not seem relevant. If it's not an ancestor then `git blame' and `git log' in the dgit view do not properly descend into the upstream history. > There may well be a git workflow someone uses where they have an > upstream tag, but they update their packaging branch by some means other > than merging that tag. This change would make git-debpush/tag2upload > not usable by them. And I do not see why we would want to do that. Hrm. So it would have to be optional and in accordance with our philosophy of "try to make git-debpush work even when dgit would have needed an explicit instruction", it would have to be off by default. Which makes it a bit pointless really. (With dgit you would have to explicitly specify the upstream tag, to get this check, since it's not going to go hunting for one. I suppose maybe there could be an option to enable it but it seems quite a minor benefit.) Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
