(Grr, I'd forgotten how Gmane silently loses posts the first time.)

martin f krafft <madd...@debian.org> wrote:
> … the thought of having debian/patches/* with a given patch foo
> inside the topic branch that creates foo just seems sort of, uh,
> cyclical to me, even though (Top)Git won't care as long as you don't

I hadn't thought about that.  You're right, it *is* yucky.

Given what I previously said about all debian/* topic branches falling
behind as soon as I commit something to master, I'm considering basing
them off the upstream branch.  After all, there's no technical reason
for basing them off master; I certainly won't be patching anything in

> Go see how things pan out for you.

Thanks!  Just wanted to make sure I wasn't missing something obvious.

> I still think the proper solution is the one discussed in #500656,
> specifically to implement refs/top-tags, which holds */base and
> */tip tags for each tg-tag. I don't actually think this is very hard
> to implement, but I've not been able to make time for it. If you

Hmm, I initially dismissed this as something I didn't need, but on
second thought (yeah, thanks Gmane) there is some appeal to the idea of
being able to run tg-cleanexport for previous versions.  Maybe this
could also be useful for backports and security updates?

(OTOH, I'm not particularly looking forward to having even more top-*
refs that I'll forget to push...)

Not that I'm volunteering right now, though.  :)  I've got enough on my
plate for the moment.  (Heck, I've been piling up logcheck reports for
over a year now.  Maybe I should start with *that*.)

<sangr> home is where the highest bandwidth is

vcs-pkg-discuss mailing list

Reply via email to