Re: Standardizing the layout of git packaging repositories

On 28 August 2014 00:41, Paulo Tomé <paulo.jorge.tome@gmail.com> wrote:

rebasing is not an option for any branch that is published, and is very ride to your downstream developers. if git-dpm requires that model of software development, one would have to consider it unsuitable for non trivial package development. I certainly hope that is not the case.

I second that.

See this mail from Linus Torvals mostly related with Git Rebase - http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html

I completely missed these emails before, sorry. My time and ability to reply is somewhat limited.

I think you really need to understand what dpm is doing.

Also git rebase is a very general purpose tool, with different purposes.

What Linus is talking about is using rebasing as a tool to recreate past history in order to "clean it up" in some way. This is confusing to everything else who is using that branch, because suddenly their work is based on a non-existant not-supported branch.

However, with git-dpm, no branch is ever destroyed. Every branch is always merged into the Debian branch. The Debian branch itself always heads in a single forward direction and this branch is never rebased. Furthermore, because this is a pseudo-standard, everything can expect this is what will happen.

See http://git-dpm.alioth.debian.org/ for details.

I think this is different from gbp-pq, and maybe the concerns for rebasing are valid for gbp-pq - if you push the branches directory.

In another email by Manoj Srivastava:

> That is really a matter of displaying history. The diagram displays Git history, not the patches; when B21 is committed, > there is no patch representing B12, however, that commit is still in <top>/.git/objects since it is a parent of the Node D3. This > is relevant when I am trying to trying to bisect and understand history. git-debcherry has fewer commits being carried around, > which makes it easier on my aging brain.

Sorry, I think you have this wrong. (also nitpick: B12 is a parent of D5, not D3).

When you commit B21, you have to replace B12 in the git history (e.g. git commit --amend). Otherwise, when the patches are exported, you will get both B12 and B21 appearing as separate patches debian/patches in D6. dpm has no way of knowing that B12 and B21 are part of the same patch and should be merged.

Maybe your point that debcherry is better still stands - it appears to work better with your concept of "feature branches", however I find it hard to use your document to compare the two when it contains errors like this.

Brian May <brian@microcomaustralia.com.au>