(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