HI,
[Apologies if this is not the right place to ask; please let
me know if so...]
I know "tg depend" only has the "add" subcommand right now,
but is there a manual way of getting the effect of a
hypothetical "tg depend remove"?
For branches which do not introduce any changes of their
own, can I just "tg delete" the branch and "tg create" it
again with the reduced list of dependencies? How does this
affect the remote (which would still become a forced push of
some kind).
And is there a way to do this for dependent branches which
*do* have changes of their own? Even if it is manual and
comes with "here be dragons" warnings :-)
Thanks,
Sitaram
From: martin f krafft <hidden> Date: 2016-06-15 22:46:40
also sprach Sitaram Chamarty [off-list ref] [2009.04.28.1049 +0200]:
[Apologies if this is not the right place to ask; please let
me know if so...]
It is...
I know "tg depend" only has the "add" subcommand right now,
but is there a manual way of getting the effect of a
hypothetical "tg depend remove"?
No, not yet, see http://bugs.debian.org/505303 for further
discussion on the issue.
--
martin | http://madduck.net/ | http://two.sentenc.es/
"perfection is achieved, not when there is nothing more to add, but
when there is nothing left to take away."
-- antoine de saint-exupéry
spamtraps: madduck.bogus@madduck.net
Yes, I'd seen that on a google search, and it made my head
hurt :-) (My fault, not theirs...!)
I was latching onto the last line of that email: "Maybe in
your case this could be even simpler but this should be the
general process".
My situation _should_ be the simplest. Every topgit branch
starts off from master, and they're all notionally
independent of each other. As long as they're here, they're
"cooking", all together, in a branch called t/all.
When one branch is deemed to be cooked, a "tg export" takes
that code to master, and I intend to delete t/all and create
it afresh with the rest of the dependencies (the old set
minus the one that finished cooking).
I was hoping to hear if anyone sees any red flags in that
strategy.
Thanks again,
Sitaram
From: martin f krafft <hidden> Date: 2016-06-15 22:46:40
also sprach Sitaram Chamarty [off-list ref] [2009.04.28.1612 +0200]:
When one branch is deemed to be cooked, a "tg export" takes
that code to master, and I intend to delete t/all and create
it afresh with the rest of the dependencies (the old set
minus the one that finished cooking).
Are any of the t/* branches ever used by anyone else but you? Are
they published?
--
martin | http://madduck.net/ | http://two.sentenc.es/
"the search for the perfect martini is a fraud. the perfect martini
is a belt of gin from the bottle; anything else is the decadent
trappings of civilization."
-- t. k.
spamtraps: madduck.bogus@madduck.net
On 2009-04-28, martin f krafft [off-list ref] wrote:
also sprach Sitaram Chamarty [off-list ref] [2009.04.28.1612 +0200]:
quoted
When one branch is deemed to be cooked, a "tg export" takes
that code to master, and I intend to delete t/all and create
it afresh with the rest of the dependencies (the old set
minus the one that finished cooking).
Are any of the t/* branches ever used by anyone else but you? Are
they published?
No to both questions. Sorry I should have mentioned that
earlier :-)
Hello Uwe,
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
a new t/all created with the new set of dependencies.
I'm pretty sure this will work -- you could say I'm using tg
to automate the "throw-away merge" work flow.
Thanks,
Sitaram
Hello Uwe,
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
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
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.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
On 2009-04-29, Uwe Kleine-König [off-list ref] 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@gmail.com (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!
quoted
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.
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
quoted
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.
quoted
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?
yes. I think it's even save to just remove empty dependencies (and add
the dependencies of the patch branch to be deleted) from .topdeps.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |