topgit patches from tags

[Stéphane Glondu]

martin f krafft wrote:
> I wish people would change subject lines more often...

Yes, it was time :-)

> See #500656.

Interesting... With Manoj's arguments and this bugreport, I now
paradoxically understand the point in having two separate build/master
branches.

IIUC, the problem is being able to recreate the patch series of an
earlier release: Manoj doesn't care and Martin keeps it in a branch, but
this branch is more an artifact than a "real" working branch. Please
correct me if I'm wrong.

Concerning #500656, and Martin's suggestion:
> It seems like the solution is a tg-tag command, which, when called
> like
> 
>   tg-tag debian/1.0-1 tgbranch[, tgbranch, ...]
> 
> tags the top-bases and tips of all specified tg-branches, e.g. like
> this:
> 
>   refs/top-tags/debian/1.0-1/base and
>   refs/top-tags/debian/1.0-1/tip

Doing it that way would pollute the tag namespace, IMO.

What about keeping this data in a dedicated, special branch, like
pristine-tar does? Then it would be quite easy to implement some kind of
tg-debcheckout that could "checkout" a specific Debian release (i.e. the
"right" revision + the "right" patch series). I am CC'ing #500656 with
this suggestion.

I don't mind having one tag per Debian release, but if we do what I say
in the previous paragraph, I think the tags would be meaningless, and
even misleading.

Another solution would be to create short-living branches at each Debian
release, that would just include the patch series and a final tag,
before being deleted. Something like this:

(master)-----------+----------+--------+----->
                    \          \        \
                   0.3-1      0.3-2    0.3-3

This approach seems clean to me, but I am not so fond of it after all
because it is quite error-prone (more than likely interference of things
related to git and things related to packaging), and I wouldn't
recommend it for a collaborative maintenance. (I know, I am strange to
propose things I don't like myself, but my thoughts might be interesting
to someone...)

After all, Martin's current approach (collapsing all the short-living
branches into one "build" branch) achieves the same goal, and now I kind
of agree with it (it wasn't the case when I've started writing this mail!).


Cheers,

-- 
Stéphane


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20080930/de9b44e6/attachment.pgp