On 2009-04-29, Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > Hello Sitaram, > > [mmh, your mail didn't have me in the addressees, wonder why.] Sorry - I'm using gmane over slrn (NNTP) from a work server! Slrn splits the "nntp post" and sends it to gmane, which is quite happy to post on behalf of sitaramc@xxxxxxxxx (my personal address) but slrn then tries to deliver the "cc" part using my local (work) mailer, with my work email address as the "From". I'm explicitly cc-ing you now, so to you the email will appear to come from my work address. Sorry about that! >> This is a little beyond my comprehension :( However, this >> is also why I am limiting myself to >> >> - a single level of dependencies in tg, (master --> >> multiple t/something --> t/all), and >> >> - no changes of its own in t/all >> >> When any of the t/something graduates to master, t/all will >> be blown away (safe, since it has no changes of its own) and > What makes you think it will "be blown away"? Or alternatively, what do My mistake. I meant that I will blow it away myself, and create a new one with the same name except it's list of deps will exclude the one that graduated. > you mean saying that? I often use the same approach and I never had the > feeling anything is blown away. If upstream uses your t/something patch > it just merges into t/something making it empty without changing the How? When I update master from upstream and then tg update on t/all? > corresponding tree (assuming master contains no other changes). Then > when t/something is merged into t/all nothing happens, because > t/something's tree didn't change. > > So the only thing is that t/all depends on an empty tg-branch. Regards, Sitaram -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html