TopGit: how to deal with upstream inclusion

> So the Debian topgit package used to have a branch fixes/destdir to
> make the Makefile distro-friendly. TopGit 0.3 has integrated this,
> thus obsoleting the fixes/destdir branch.
> 
> I thought the way to handle this would be to simply delete the
> TopGit branch, but of course that breaks everything, e.g.:
> 
> lapse:..t/topgit|debian/locations|% tg update
> tg: fatal: some dependencies are missing: fixes/destdir
> 
> I now we had a recent discussion about how to remove branches, and
> that there's basically no way to do this. In the discussion,
> upstream inclusion was listed as one of the instances when this
> wouldn't be needed, but that refers to upstream pulling/am'ing my
> commits, not implementing the same functionality differently.

> 	tg depend fold RETIRED VANILLA
> 
>   (i) Take the RETIRED _base_ branch
> 
>   (ii) Merge in VANILLA
> 
>   (iii) Merge in RETIRED head branch with -s ours
> 
>   (iv) Now we have a commit that contains RETIRED topic branch, but with
> the RETIRED's changes taken from VANILLA instead of RETIRED
> 
>   (v) Merge this into the base of your current branch
> 
>   (vi) Merge base to the head of your current branch, replacing RETIRED
> with VANILLA (if not already there) in the .topdeps
> 
>   (vii) You do not have to add VANILLA if you depend on it recursively
> and ran tg update before to get it from your dependencies
> 
>   Maybe in your case this could be even simpler but this should be the
> general process. Does that sound right?

> also sprach Petr Baudis <pasky@suse.cz> [2008.09.14.2203 +0100]:
> >   (iii) Merge in RETIRED head branch with -s ours
> 
> Yes, it does. One might want to consider to make the use of -s ours
> in (iiii) configurable, but otherwise that's it.

> > Yes, it does. One might want to consider to make the use of -s ours
> > in (iiii) configurable, but otherwise that's it.
> 
> That might be pretty dangerous, since then your topic branch will have
> outstanding branches of the retired branch, but they will _NOT_ be
> visible to tg patch and others since they will be in both the base and
> head.

> also sprach Petr Baudis <pasky@suse.cz> [2008.09.21.1619 +0200]:
> > > Yes, it does. One might want to consider to make the use of -s ours
> > > in (iiii) configurable, but otherwise that's it.
> > 
> > That might be pretty dangerous, since then your topic branch will have
> > outstanding branches of the retired branch, but they will _NOT_ be
> > visible to tg patch and others since they will be in both the base and
> > head.
> 
> Well, but what if upstream implemented our solution slightly
> differently, and if it's only because they used tabs instead of
> spaces? We wouldn't want -s ours then, huh?

> > Well, but what if upstream implemented our solution slightly
> > differently, and if it's only because they used tabs instead of
> > spaces? We wouldn't want -s ours then, huh?
> 
> You still would want to get tabs in other patches that depended on
> the merged one, no? Otherwise tg patch output will produce patches
> that do not apply and tg export will change the tabs back to
> spaces.

> also sprach Petr Baudis <pasky@suse.cz> [2008.09.23.1155 +0200]:
> > > Well, but what if upstream implemented our solution slightly
> > > differently, and if it's only because they used tabs instead of
> > > spaces? We wouldn't want -s ours then, huh?
> > 
> > You still would want to get tabs in other patches that depended on
> > the merged one, no? Otherwise tg patch output will produce patches
> > that do not apply and tg export will change the tabs back to
> > spaces.
> 
> I would want to have to resolve all dependent branches and change
> them to use tabs, right. But since I used spaces and they used tabs,
> using -s ours would give preference to spaces, no?

>   (i) Take the RETIRED _base_ branch
>
>   (ii) Merge in VANILLA
>
>   (iii) Merge in RETIRED head branch with -s ours
>
>   (iv) Now we have a commit that contains RETIRED topic branch, but
>   with the RETIRED's changes taken from VANILLA instead of RETIRED