[debian] where to document branch layout

[Stefano Zacchiroli]

On Tue, Jul 15, 2008 at 03:39:27PM -0700, Russ Allbery wrote:
> Hm, that's a good point.  I'm not sure.  It's possible that maintaining a
> distinction between manipulating the output source package and
> manipulating the revision control system is good.  I've documented more
> details frequently on a team wiki page for the Debian package mantenance
> team.

Yes, the distinction might have sense, as explained in the current
wording, which states that the target of README.source is who ends up
having in her hands a source package.

But then we are back at the initial problem: where to document branch
layout and other DVCS related information. Even though this is not a
need for the random NMUer, it is a need for someone willing to
contribute "more" to the package, for example to propose a significant
change. In that case, understanding branch layout and publishing a
proper branch is definitely helpful.

Of the two one: either we say README.source is the right place or we
define a new suitable place.

> The system that I describe doesn't maintain any branches that are useful
> targets for git format-patch.  You'll end up with a pile of merge commits
> and other unuseful patches in your stack.

That was what I feared ...

> The best idea that I've seen for maintaining good branches for git
> format-patch is to also maintain features on branches that are rebased
> instead of merged against each new upstream.  This duplicates the change
> in two branches, one that's merged and one that's rebased, but you can use
> git rerere to automate resolution of the rebase and the merge using the
> results of whichever you do first.  (This idea is from Manoj.)
> 
> I'm not actually doing this in practice right now; so far, I'm just using
> git diff upstream..branch to generate patches to send to upstream, which
> obviously isn't ideal since it doesn't include the commit message.

I see. So basically you are accepting the fact that your .diff.gz get
"dirty", considering (I guess) that patches are clear enough while
looking at the git repo. My opinion is that this is acceptable *only if*
we standardize the place where to document branch layout, as per the
problem we started from. Otherwise, a random external observer
(upstream) included would have a too hard life in trying to understand
what happened to some software.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic  -- Manoj \/ right keys at the right time
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20080716/8a6753c9/attachment-0001.pgp