Re: Preferred git branch structure when upstream moves from tarballs to git

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

(adding #903392)

Ben Finney writes ("Re: Preferred git branch structure when upstream moves from tarballs to git"):
> What I remain unconvinced of is the worth of abandoning the clean
> separation between an upstream source repository (whether Git repository
> or not) and a VCS repository for Debian packaging (typically in Git).

I disagree with this but I'm not really interested in arguing you out
of it.  As Ian Campbell says, dgit doesn't want to change your
workflow.  It wants to help you help *users* and *downstreams* to
change theirs, from tarballs+diffs to git.

My interest is to make that possible, *without* maintainers having to
change their workflows.

For your workflow, I see broadly two possibilities, depending what
representation you use for upstream source code:

 (i) You use upstream tarballs as your representation of the upstream
     source code, and do not use upstream git branches.

     If this is the case then the benefits for everyone in me
     implementing #903392 for you, and you then using `dgit
     push-source', are - frankly - limited.  The resulting dgit git
     branch would still contain imports of .orig tarballs, rather than
     the actual upstream git history.

     The user of `dgit clone' would get your *packaging* history,
     sure, but this is a much more minor benefit.

 (ii) You use upstream git history, and generate .orig tarballs
     with (say) git-deborig.

     Implementing #903392 for this case should be straightforward,
     provided that your .orig tarballs and the git branch actually are
     identical.  Furthermore, it would be very useful to someone who
     `dgit clone's one of your packages: they would get a full and
     proper git history which would work exactly as they expect.

     The question here would be: how do you manage the upstream git
     branch ?  dgit push would need to automatically find (or be told,
     but that would be a UI nuisance) the upstream git commit.

     (And if that upstream git commit is in a separate tree somewhere,
     dgit would have to find that tree, too.)

If you are roughly in situation (ii) then I am quite interested in
supporting your use of dgit push, eg by working on #903392.  Please
engage in that bug, and encourage others in a similar position to do
the same.

If you are currently in situation (i) then your adoption of dgit is a
low priority for me, since to provide really useful output from `dgit
clone' it would be necessary for you to change your workflow.  (I do
have a wip branch but it is a mess and not tested.  So if someone
wants to work on this, let me know.)

I am not really interested in arguing that people's workflows are
wrong; it is a very religious kind of topic.  Let us save that for a
bar conversation some time ...

HTH.

Ian.

-- 
Ian Jackson <ijackson@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.