Re: topgit patches from tags
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/) ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: topgit patches from tags
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 ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: topgit patches from tags
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/) ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: topgit patches from tags
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 ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
