git-packaging workflows

[Reinhard Tartler]

On Mon, Apr 8, 2013 at 2:43 PM, Felipe Sateler <fsateler at debian.org> wrote:
> On Mon, Apr 8, 2013 at 7:07 AM, Jonas Smedegaard <dr at jones.dk> wrote:
>> Quoting Felipe Sateler (2013-04-08 06:56:51)
>>> On Sun, Apr 7, 2013 at 8:15 AM, Jonas Smedegaard <dr at jones.dk> wrote:
>>> > Quoting Reinhard Tartler (2013-04-06 09:32:04)
>>> >> Recently, Russ' blog post was echoed on http://planet.debian.org:
>>> >>
>>> >> http://www.eyrie.org/~eagle/journal/2013-04/001.html
>>> >>
>>> >> In that post, he describes how to combine both the "import tarball"
>>> >> and the "have upstream history" available in the upstream packaging
>>> >> branch. AFAIUI, the heavy work is implemented in git-buildpackage's
>>> >> --upstream-vcs-tag <tag> option.
>>> >>
>>> >> While that option is news to me, I wonder if maybe anyone else
>>> >> already experiments with this? Does the team feel that making it
>>> >> mandatory for our package would be beneficial and appropriate?
>>> >
>>> > I have (way more complex) practiced that for a few years for Sugar
>>> > packages.  Now that it has become dead simply to do with
>>> > git-buildpackage I wholeheartedly welcome mandating it - but only
>>> > for those of our upstreams that themselves use git, obviously.
>>>
>>> I suppose fixing the history would be too time consuming? So the
>>> history would remain as imported tarballs?
>>
>> Not sure what you mean, Felipe.
>
> I'm referring to how a transition to the new system would be made.
> Would we want to rewrite history to track the upstream repository in
> past releases? Or do we treat it as water under the bridge and just
> attach the upstream history for newer releases?

I think that the latter would be sufficient. First, not all of our
upstreams do have a git. Second, breaking the working git clones of
all team members is hardly worth it IMO.

-- 
regards,
    Reinhard