TopGit: how to deal with upstream inclusion

TopGit: how to deal with upstream inclusion

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

Hi Petr, hi Gits,

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.

How do I retire the fixes/destdir branch? Do I manually remove the
dependency from depending branches?

Thanks,

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
"one should never allow one's mind
 and one's foot to wander at the same time."
                                -- edward perkins (yes, the librarian)
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: TopGit: how to deal with upstream inclusion

[Petr Baudis]

  Hi,

On Sun, Sep 14, 2008 at 09:30:43PM +0100, martin f krafft wrote:
> 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.

  upstream should never pull TopGit branches! They have ugly history and
contain .topdeps and .topmsg junk files. That's what tg patch and
tg export is there for. :-)

  If upstream applies the changes, the branch becomes unnecessary and
then it is ok to have some command like 'tg depend rm' to get rid of the
branch, since the *changes* aren't going away, thus we don't need to
create any "revert commits", which is the real issue with the general
'tg depend rm' command.

> How do I retire the fixes/destdir branch? Do I manually remove the
> dependency from depending branches?

  Almost. The real 'tg depend rm' (or maybe rather, 'tg depend fold' as
in "this topic branch got folded to that branch") command would be
slightly more complicated, I think, in order to ensure that no
mysterious leftovers of the retired patch are lurking in your patch
tree. Assuming

	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?

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: TopGit: how to deal with upstream inclusion

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

also sprach Petr Baudis <pasky@suse.cz> [2008.09.14.2203 +0100]:
> 	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?

Yes, it does. One might want to consider to make the use of -s ours
in (iiii) configurable, but otherwise that's it.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
all information contained in the above is false,
for reasons of military security.
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: TopGit: how to deal with upstream inclusion

[Petr Baudis]

On Fri, Sep 19, 2008 at 06:04:06PM +0100, martin f krafft wrote:
> 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.

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.

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: TopGit: how to deal with upstream inclusion

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

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?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"on the other hand, with the advent of msvc 5, i can claim i use
 emacs because it's smaller and more efficient." :-)"
                                                    -- darin johnson
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: TopGit: how to deal with upstream inclusion

[Petr Baudis]

On Tue, Sep 23, 2008 at 08:35:50AM +0200, martin f krafft wrote:
> 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?

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.

				Petr "Pasky" Baudis

Re: TopGit: how to deal with upstream inclusion

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

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?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
the reason the mainstream is thought of as a stream
is because it is so shallow.
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: TopGit: how to deal with upstream inclusion

[Petr Baudis]

On Wed, Sep 24, 2008 at 01:21:15PM +0200, martin f krafft wrote:
> 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?

Please read again carefully :-) :

>   (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

-s ours keeps vanilla version.

-- 
				Petr "Pasky" Baudis
People who take cold baths never have rheumatism,
but they have cold baths.

Re: TopGit: how to deal with upstream inclusion

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]

also sprach Petr Baudis <pasky@suse.cz> [2008.09.24.1729 +0200]:
> Please read again carefully :-) :

Oh. dear. Sorry.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"i worked myself up from nothing to a state of extreme poverty."
                                                       -- groucho marx
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]