Bug#500656: topgit patches from tags

2008-09-30 Thread 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-20.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




signature.asc
Description: OpenPGP digital signature


Bug#500656: topgit patches from tags

2008-09-30 Thread martin f krafft
also sprach Stéphane Glondu [EMAIL PROTECTED] [2008.09.30.1019 +0200]:
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.

Yes and no. Normal tags are in refs/tags. I am proposing the
refs/top-tags namespace, which is reserved for topgit anyway (topgit
reserved refs/top-*).

Sure, gitk and the like would still show those refs (as grey refs,
not yellow tags or green branches), but git-tag wouldn't.

 What about keeping this data in a dedicated, special branch, like
 pristine-tar does?

You want to keep files with SHA-1 refs in a branch? I am not sure
I like that at all. First of all, this clearly seems like a feature
for upstream, and second, Git is all about keeping track of refs,
storing them as payload in a branch seems like patching patch files
:)

-- 
 .''`.   martin f. krafft [EMAIL PROTECTED]
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
an avocado-tone refrigerator would look good on your resume.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)


Bug#500656: topgit patches from tags

2008-09-30 Thread Stéphane Glondu
martin f krafft wrote:
 Yes and no. Normal tags are in refs/tags. I am proposing the
 refs/top-tags namespace, which is reserved for topgit anyway (topgit
 reserved refs/top-*).

Sorry, I didn't pay attention to this. I guess this needs a special
cloning/pushing/pulling procedure, then? BTW, you don't talk about
pushing/pulling/sharing with others in your quick tuto (but you do talk
about cloning).

 You want to keep files with SHA-1 refs in a branch? I am not sure
 I like that at all. [...]

Yes.

 [...] First of all, this clearly seems like a feature
 for upstream, [...] 

What do you mean by a feature for upstream?

 [...] and second, Git is all about keeping track of refs,
 storing them as payload in a branch seems like patching patch files
 :)

Indeed, it seems so. But I was getting inspiration from pristine-tar. I
guess *.id files that are committed there are not meant to be used
(and/or alterable) by human beings. Do we want this for historical
bases and tips of tg branches? I am not really at ease with mixing
live and dead script-manipulated references in the same place.
Anyway, as long as my tag namespace is not polluted, I guess I could
bear it.

-- 
Stéphane




signature.asc
Description: OpenPGP digital signature


Bug#500656: topgit patches from tags

2008-09-30 Thread martin f krafft
also sprach Stéphane Glondu [EMAIL PROTECTED] [2008.09.30.1159 +0200]:
 Sorry, I didn't pay attention to this. I guess this needs a special
 cloning/pushing/pulling procedure, then?

Yes, and that would be setup by tg-remote, which already sets this
up for refs/top-bases/*.

 BTW, you don't talk about pushing/pulling/sharing with others in
 your quick tuto (but you do talk about cloning).

tg-export should make this all transparent, i.e. you should be able
to push your branches like before, and top-bases will also be
pushed.

The nice thing about topgit is that it's really just a thin layer on
top of Git, so everything Git also works with TopGit.

  [...] First of all, this clearly seems like a feature
  for upstream, [...] 
 
 What do you mean by a feature for upstream?

Tagging previous version of topic branches/patches.

  [...] and second, Git is all about keeping track of refs,
  storing them as payload in a branch seems like patching patch files
  :)
 
 Indeed, it seems so. But I was getting inspiration from
 pristine-tar. I guess *.id files that are committed there are not
 meant to be used (and/or alterable) by human beings. Do we want
 this for historical bases and tips of tg branches? I am not
 really at ease with mixing live and dead script-manipulated
 references in the same place.

I am sure pristine-tar could be redesigned to git in with Git
better.

-- 
 .''`.   martin f. krafft [EMAIL PROTECTED]
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
now I lay me back to sleep.
the speaker's dull; the subject's deep.
if he should stop before I wake,
give me a nudge for goodness' sake.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)