git-packaging workflows

[Felipe Sateler]

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?

--

Saludos,
Felipe Sateler