On Tuesday, February 14, 2017 06:23:43 PM Brian May wrote: > Scott Kitterman <deb...@kitterman.com> writes: > > We know in the DPMT context what debcheckout will produce, so for our > > purposes they don't matter. > > > > How does dgit avoid maintainer forgot to push problems without being > > limited to the granularity of one commit per upload? > When you upload a package, you upload the *.debs and push to git a the > same time. With the one dgit command that checks everything is > consistant, and tags things appropriately. I not sure of the exact > details of how the push is done yet. > > I think dgit would really help with the problem I occasionally get: Does > this git source really correspond with the package that was > uploaded. Mistakes can happen in git that can result in you looking at > one git version that is very different to what was uploaded. Yes, this > does happen. > > Mostly however, I think the prime benefit of using dgit would be that it > helps other non-team members maintain the package - as does happen from > time to time in the form on NMUs. We can help these people by sticking > to a standard that others can use. > > It would not directly help DPMT workflow, as that mostly remains as > is. Hence my first priority would be to change to GBP PQ for work flow, > and then worry about dgit after I have had a chance to play with dgit a > bit more.
Thanks. I agree we should wait on this. Scott K