Re: TopGit: How to retire obsolete topic branches?

[Manoj Srivastava]

On Sun, May 10 2009, martin f krafft wrote:

> also sprach Manoj Srivastava  [2009.05.10.0028 +0200]:
>> > Keep in mind that the branches accumulate remotely, so you'd have to
>> > pass -r or -a to git-branch to be exposed to them.
>> 
>> Accumulate?
> [...]
>> > Anyway, unfortunately, published branches cannot be renamed with
>> > Git, or retired, or anything of that sort, so the concern is valid:
>> 
>> Why not?
>
> Because they might exist in downstream repos and could be pushed
> back at any time. However, contrary to my initial believe, this
> requires explicit pushing with standard Git. TopGit currently,
> however, overrides the default push refspec and effectively defaults
> git-push to --all.

Ah. I coordinate with any repo which can push to my master repo
 (actually, I control them), and so this push-back is prohibited by my
 repo policy.

Removing branches is a significant event, so it is
 coordinated. Before push, one does a fetch, and does the rename/deletes
 shown below.

>>  git checkout topic--obsolete-later
>>  git checkout -b  old-obsolete-now
>>  git push --all
>> 
>>  git branch -d topic--obsolete-later
>>  git push origin :topic--obsolete-later
>>  git remote prune origin
>
> Right, until I push back topic--obsolete-later, which I had
> previously checked out.

And get your commit rights removed.

manoj
-- 
"Plastic gun.  Ingenious.  More coffee, please." The Phantom comics
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: How to retire obsolete topic branches?

[martin f krafft]

also sprach Manoj Srivastava  [2009.05.10.0028 +0200]:
> > Keep in mind that the branches accumulate remotely, so you'd have to
> > pass -r or -a to git-branch to be exposed to them.
> 
> Accumulate?
[...]
> > Anyway, unfortunately, published branches cannot be renamed with
> > Git, or retired, or anything of that sort, so the concern is valid:
> 
> Why not?

Because they might exist in downstream repos and could be pushed
back at any time. However, contrary to my initial believe, this
requires explicit pushing with standard Git. TopGit currently,
however, overrides the default push refspec and effectively defaults
git-push to --all.

>  git checkout topic--obsolete-later
>  git checkout -b  old-obsolete-now
>  git push --all
> 
>  git branch -d topic--obsolete-later
>  git push origin :topic--obsolete-later
>  git remote prune origin

Right, until I push back topic--obsolete-later, which I had
previously checked out.

> > you'd have to start a new feature branch as obsolete/new-feature
> > to be able to declare it obsolete later on, at which point we
> > might just as well not use the namespace. :)
> 
> This sounds wrong to me. What am I missing?

Mainly my list mail following this one. :)

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
wind catches lily,
scattering petals to the ground.
segmentation fault.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: How to retire obsolete topic branches?

[Manoj Srivastava]

On Sat, May 09 2009, martin f krafft wrote:

> also sprach Stefano Zacchiroli  [2009.05.07.1902 +0200]:
>> When I, as a newcomer of a given repo, do "git tag" I know I'm
>> looking at a lot of "not current" information. On the contrary,
>> when I do "git branch" I start trying figure out what each branch
>> means. Having around a lot of no longer used branches is very
>> annoying in that respect.
>
> Keep in mind that the branches accumulate remotely, so you'd have to
> pass -r or -a to git-branch to be exposed to them.

Accumulate?

> Obviously, any curious newcomer will do that, but then, a sane
> convention like Manoj hinted at will help, because you'd have to be
> amazingly curious to realy wonder about branches in the obsolete/*
> namespace.
>
> Anyway, unfortunately, published branches cannot be renamed with
> Git, or retired, or anything of that sort, so the concern is valid:

Why not?

 git checkout upstream
 git checkout -b topic--obsolete-later
   
 git push --all

At this point,  topic--obsolete-later and
 origin/topic--obsolete-later exist.

Upstream abso\rbes the topic branch, so it is now obsolete.

 git checkout topic--obsolete-later
 git checkout -b  old-obsolete-now
 git push --all

 git branch -d topic--obsolete-later
 git push origin :topic--obsolete-later
 git remote prune origin

Seems to me the topic--obsolete-later is pretty much retired.

> you'd have to start a new feature branch as obsolete/new-feature to
> be able to declare it obsolete later on, at which point we might
> just as well not use the namespace. :)

This sounds wrong to me. What am I missing?

manoj

-- 
Coward, n. one who in a perilous emergency thinks with his legs. Ambrose
Bierce
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: How to retire obsolete topic branches?

[martin f krafft]

also sprach Petr Baudis  [2009.05.09.1134 +0200]:
> You can do `git remote prune` to get rid of branches that disappeared
> upstream. Hypothetical `tg retire` (a stupid name, of course) would
> do git branch -d branch and git push origin :branch :refs/bases/branch.
> `tg update` or some other command would then have to do the `git remote
> prune` part and have some fancy logic to retire the branches locally
> too if there are no changes in them. The case when there are local
> changes in the retired branches is left as an exercise for the reader.
> ;-)

Sounds good. Only the "fancy logic" part is a bit murky right now.
:)

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
in africa some of the native tribes have a custom of beating the
ground with clubs and uttering spine chilling cries. anthropologists
call this a form of primitive self-expression. in america they call
it golf.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

deleting branches (was: TopGit: How to retire obsolete topic branches?)

[martin f krafft]

also sprach martin f krafft  [2009.05.09.1113 +0200]:
> b. teach Git how to retire/rename published branches
> 
> I'll think about (b) for a bit and see if this wouldn't make sense
> to be raised with the Git people. Comments welcome, of course.

http://colabti.org/irclogger/irclogger_log/git?date=2009-05-09#l734

It turns out that remotely-deleted branches don't just get pushed
back, unless someone explicitly pushes them, or uses --all. Any
project needs a barrel of tar and many feathers for people who do
that without knowing what they're doing. A pre-update hook could be
used to permanently ban certain branch-names or refs from being
pushed back. Thus, the only persistent mess would be local, and
that's everyone's own responsibility.

The reason why the above might be a bit problematic with TopGit is
because TopGit adds a push ref to the configuration:

push = +refs/top-bases/*:refs/top-bases/*
push = +refs/heads/*:refs/heads/*

This overrides the default ':', which only pushes branches already
present remotely, and causes all local branches to be pushed. I've
been bitten by this plenty of times before.

We can only hope that Marc Weber's tg-push will allow us to get rid
of the push refs:

  
http://news.gmane.org/find-root.php?group=gmane.comp.version-control.git&article=117554

Ideally, git-push should be able to push associated branches, e.g.
any TopGit refs related to a branch it pushes, instead of
implementing and maintaining the same logic in tg-push. We'll see.

To recap: if TopGit learnt how to fold branches and retire them, and
it would also remove remote branches appropriately, *and* people
with push access could be trusted not to dumbly push them back (or
a hook preventing them from doing so), we'd have what we want.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"twenty-four hour room-service must be one of the
 premiere achievements of modern civilization."
  -- special agent dale cooper


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: How to retire obsolete topic branches?

[Petr Baudis]

On Sat, May 09, 2009 at 11:13:17AM +0200, martin f krafft wrote:
> also sprach Stefano Zacchiroli  [2009.05.07.1902 +0200]:
> > When I, as a newcomer of a given repo, do "git tag" I know I'm
> > looking at a lot of "not current" information. On the contrary,
> > when I do "git branch" I start trying figure out what each branch
> > means. Having around a lot of no longer used branches is very
> > annoying in that respect.
> 
> Keep in mind that the branches accumulate remotely, so you'd have to
> pass -r or -a to git-branch to be exposed to them.
> 
> Obviously, any curious newcomer will do that, but then, a sane
> convention like Manoj hinted at will help, because you'd have to be
> amazingly curious to realy wonder about branches in the obsolete/*
> namespace.
> 
> Anyway, unfortunately, published branches cannot be renamed with
> Git, or retired, or anything of that sort, so the concern is valid:
> you'd have to start a new feature branch as obsolete/new-feature to
> be able to declare it obsolete later on, at which point we might
> just as well not use the namespace. :)
> 
> I see two required steps to solve this:
> 
> a. teach TopGit how to retire branches, as per debbug#505303
> 
> b. teach Git how to retire/rename published branches
> 
> I'll think about (b) for a bit and see if this wouldn't make sense
> to be raised with the Git people. Comments welcome, of course.

You can do `git remote prune` to get rid of branches that disappeared
upstream. Hypothetical `tg retire` (a stupid name, of course) would
do git branch -d branch and git push origin :branch :refs/bases/branch.
`tg update` or some other command would then have to do the `git remote
prune` part and have some fancy logic to retire the branches locally
too if there are no changes in them. The case when there are local
changes in the retired branches is left as an exercise for the reader.
;-)

-- 
Petr "Pasky" Baudis
The lyf so short, the craft so long to lerne. -- Chaucer

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: How to retire obsolete topic branches?

[martin f krafft]

also sprach Stefano Zacchiroli  [2009.05.07.1902 +0200]:
> When I, as a newcomer of a given repo, do "git tag" I know I'm
> looking at a lot of "not current" information. On the contrary,
> when I do "git branch" I start trying figure out what each branch
> means. Having around a lot of no longer used branches is very
> annoying in that respect.

Keep in mind that the branches accumulate remotely, so you'd have to
pass -r or -a to git-branch to be exposed to them.

Obviously, any curious newcomer will do that, but then, a sane
convention like Manoj hinted at will help, because you'd have to be
amazingly curious to realy wonder about branches in the obsolete/*
namespace.

Anyway, unfortunately, published branches cannot be renamed with
Git, or retired, or anything of that sort, so the concern is valid:
you'd have to start a new feature branch as obsolete/new-feature to
be able to declare it obsolete later on, at which point we might
just as well not use the namespace. :)

I see two required steps to solve this:

a. teach TopGit how to retire branches, as per debbug#505303

b. teach Git how to retire/rename published branches

I'll think about (b) for a bit and see if this wouldn't make sense
to be raised with the Git people. Comments welcome, of course.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"although occasionally there is something to be said for solitude."
  -- special agent dale cooper


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: How to retire obsolete topic branches?

[Manoj Srivastava]

On Thu, May 07 2009, Stefano Zacchiroli wrote:


> When I, as a newcomer of a given repo, do "git tag" I know I'm looking
> at a lot of "not current" information. On the contrary, when I do "git
> branch" I start trying figure out what each branch means. Having
> around a lot of no longer used branches is very annoying in that
> respect.

__> cd /usr/local/git/debian/libselinux/libselinux-2.0.80  ~/var/spool/mail
[master]__> git branch~base_dir
* master
  old-debian
  old-devo
  old-ia64-fix
  old-pkg-config
  old-tls-fix
  old-upstream
  pristine-tar
  test--init-static-variables
  test--tls-fix
  topic--debian
  topic--pkg-config
  upstream


Sometimes, just a sane convention is enough.

manoj
-- 
The primary function of the design engineer is to make things difficult
for the fabricator and impossible for the serviceman.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: How to retire obsolete topic branches?

[Stefano Zacchiroli]

On Thu, May 07, 2009 at 10:55:23AM +0200, martin f krafft wrote:
> also sprach Frédéric Brière  [2009.05.07.0232 +0200]:
> > Yeah, but it'll remain in your refs/heads namespace forever, won't it?
> > Kinda sucks to have git-branch spew out every patch that's ever existed.
> > :(
> Like git-tag "spews" out every tag ever created?

The level of annoyance is quite different.

When I, as a newcomer of a given repo, do "git tag" I know I'm looking
at a lot of "not current" information. On the contrary, when I do "git
branch" I start trying figure out what each branch means. Having
around a lot of no longer used branches is very annoying in that
respect.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: How to retire obsolete topic branches?

[martin f krafft]

also sprach Frédéric Brière  [2009.05.07.0232 +0200]:
> Yeah, but it'll remain in your refs/heads namespace forever, won't it?
> Kinda sucks to have git-branch spew out every patch that's ever existed.
> :(

Like git-tag "spews" out every tag ever created?

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
i welcome your constructive criticism and corrections.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: How to retire obsolete topic branches?

[Frédéric Brière]

martin f krafft  wrote:
> > tg-cleanexport.  As I said, I would either need to keep the (empty)
> > topic branch around forever, or override TG_BRANCHES forever, no?
>
> I think as soon as a branch is folded in the way pasky suggests, the
> TopGit diff would be empty, and tg-export knows not to dump empty
> patches, so effectively the branch would be retired.

Yeah, but it'll remain in your refs/heads namespace forever, won't it?
Kinda sucks to have git-branch spew out every patch that's ever existed.
:(

(Oh well, life can't be perfect.)


-- 
 abuse me.  I'm so lame I sent a bug report to debian-devel-changes
-- Seen on #Debian


___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: How to retire obsolete topic branches?

[martin f krafft]

also sprach Frédéric Brière  [2009.05.06.2016 +0200]:
> I don't think this addresses the same issue, though.  This is about
> making sure that a topic branch can be safely deleted even when other
> branches depend on it.  IOW, it's purely a TopGit issue.
> 
> My concern is what to do once the above has been done, to avoid breaking
> tg-cleanexport.  As I said, I would either need to keep the (empty)
> topic branch around forever, or override TG_BRANCHES forever, no?

I think as soon as a branch is folded in the way pasky suggests, the
TopGit diff would be empty, and tg-export knows not to dump empty
patches, so effectively the branch would be retired.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
a c programmer asked whether computers have buddha's nature.
as the answer, the master did "rm -rf" on the programmer's home
directory. and then the c programmer became enlightened...


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: How to retire obsolete topic branches?

[Frédéric Brière]

martin f krafft  wrote:
> See #505303. This is also not yet implemented, but pasky worked out
> the logic in the referenced URL
> http://thread.gmane.org/gmane.comp.version-control.git/95858

Yeah, I remember seeing this.  His merging made me dizzy.  :)

I don't think this addresses the same issue, though.  This is about
making sure that a topic branch can be safely deleted even when other
branches depend on it.  IOW, it's purely a TopGit issue.

My concern is what to do once the above has been done, to avoid breaking
tg-cleanexport.  As I said, I would either need to keep the (empty)
topic branch around forever, or override TG_BRANCHES forever, no?


-- 
Being overloaded is the sign of a true Debian maintainer.
-- JHM on #Debian


___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: TopGit: How to retire obsolete topic branches?

[martin f krafft]

also sprach Frédéric Brière  [2009.05.05.2154 +0200]:
> Let's say I've once created the topic branch fixes/foo, which has now
> been incorporated in the latest upstream release.  What is the best way
> of dealing with this now-obsolete branch?  (Let's pretend for
> simplicity's sake that it is not part of any other branch's base.)

See #505303. This is also not yet implemented, but pasky worked out
the logic in the referenced URL
http://thread.gmane.org/gmane.comp.version-control.git/95858

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
anyone who says sunshine brings happiness
has never danced in the rain.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

TopGit: How to retire obsolete topic branches?

[Frédéric Brière]

Let's say I've once created the topic branch fixes/foo, which has now
been incorporated in the latest upstream release.  What is the best way
of dealing with this now-obsolete branch?  (Let's pretend for
simplicity's sake that it is not part of any other branch's base.)

Am I right to assume that deleting/renaming it would be unsafe?  Anybody
working with an old git-clone/debcheckout copy would end up recreating
this patch on every tg-cleanexport, unless TG_BRANCHES is explicitly
set.

The other option would be to update the (now empty) topic branch, and
just let it rot there.  From what I understand, TopGit will smartly skip
over empty branches, so it will do no harm aside from polluting the
refs/heads namespace.

What would you do?


-- 
<-- Overfiend has quit ("venturing forth to destroy strange new
 worlds, and eat life and new civilizations")

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss