(topgit question) deleting a dependency

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

also sprach Sitaram Chamarty <sitaramc@gmail.com> [2009.04.28.1049 +0200]:

It is...

No, not yet, see http://bugs.debian.org/505303 for further discussion on the issue.

On 2009-04-28, martin f krafft <madduck@madduck.net> wrote:

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

also sprach Sitaram Chamarty <sitaramc@gmail.com> [2009.04.28.1612 +0200]:

Are any of the t/* branches ever used by anyone else but you? Are they published?

On 2009-04-28, martin f krafft <madduck@madduck.net> wrote:

No to both questions. Sorry I should have mentioned that earlier :-)

Hello Sitaram,

On Tue, Apr 28, 2009 at 11:41:38AM +0200, martin f krafft wrote:

But note that you might get some problems after doing that.  See

	http://thread.gmane.org/gmane.comp.version-control.git/116193/focus=116205

for some more details.

Best regards Uwe

On 2009-04-28, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:

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 Sitaram,

[mmh, your mail didn't have me in the addressees, wonder why.]

On Wed, Apr 29, 2009 at 12:52:54AM +0000, Sitaram Chamarty wrote:

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

On 2009-04-29, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:

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!

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.

How? When I update master from upstream and then tg update on t/all?

Regards,

Sitaram

Hello,

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