Marking abandoned branches

Since branch refs are being worked on it would make sense to add an
object that marks a branch as being abandoned. The visualization tools
would use this to suppress viewing of these branches in their default
display.

For example Mozilla has 100s of branches that were abandoned five or
more years ago. No point in having them impact a current gitk display.

You would add an abandoned branch marker after the last commit on the
branch and adjust the branch ref to point at it. If you want to open
the branch again point the branch ref back to the last commit and let
git prune remove the marker.

Abandoned branches are common in CVS since it is not distributed.
People start working on something in the main repo and then decide it
was a bad idea. In the git world these branches usually don't end up
in the main repo.

-- 
Jon Smirl
jonsmirl@gmail.com

Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter
where Jon Smirl [off-list ref] said that...

Abandoned branches are common in CVS since it is not distributed.
People start working on something in the main repo and then decide it
was a bad idea. In the git world these branches usually don't end up
in the main repo.

Can't you just toss the branch away in that case? :-)

You could also stash the ref to refs/heads-abandoned/ instead of
refs/heads/ if you want to keep the junk around for some reason. Of
course you don't get the nice marker with explanation of why is this
abandoned and who decided that, but you can just use an empty commit for
the same purpose.

Object classes are precious things and we shouldn't get carried away.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Hi,

On Wed, 13 Sep 2006, Petr Baudis wrote:

Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter
where Jon Smirl [off-list ref] said that...

quoted

Abandoned branches are common in CVS since it is not distributed.
People start working on something in the main repo and then decide it
was a bad idea. In the git world these branches usually don't end up
in the main repo.

Can't you just toss the branch away in that case? :-)

You could also stash the ref to refs/heads-abandoned/ instead of
refs/heads/ if you want to keep the junk around for some reason. Of
course you don't get the nice marker with explanation of why is this
abandoned and who decided that, but you can just use an empty commit for
the same purpose.

... or a tag (remember, you can stash a tag into refs/abandoned/, instead 
of a commit) with the further benefit that you really cannot commit on top 
of that.

Object classes are precious things and we shouldn't get carried away.

Exactly.

Ciao,
Dscho

Johannes Schindelin wrote:

On Wed, 13 Sep 2006, Petr Baudis wrote:

quoted

Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter
where Jon Smirl [off-list ref] said that...

quoted

Abandoned branches are common in CVS since it is not distributed.
People start working on something in the main repo and then decide it
was a bad idea. In the git world these branches usually don't end up
in the main repo.

Can't you just toss the branch away in that case? :-)

You could also stash the ref to refs/heads-abandoned/ instead of
refs/heads/ if you want to keep the junk around for some reason. Of
course you don't get the nice marker with explanation of why is this
abandoned and who decided that, but you can just use an empty commit for
the same purpose.

... or a tag (remember, you can stash a tag into refs/abandoned/, instead 
of a commit) with the further benefit that you really cannot commit on top 
of that.

Or refs/Attic/ ;-)

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

On 9/13/06, Petr Baudis [off-list ref] wrote:

Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter
where Jon Smirl [off-list ref] said that...

quoted

Abandoned branches are common in CVS since it is not distributed.
People start working on something in the main repo and then decide it
was a bad idea. In the git world these branches usually don't end up
in the main repo.

Can't you just toss the branch away in that case? :-)

It is a historical import. Everything that was in the initial repo
needs to be preserved otherwise they aren't going to get rid of the
old CVS repo.

You could also stash the ref to refs/heads-abandoned/ instead of
refs/heads/ if you want to keep the junk around for some reason. Of
course you don't get the nice marker with explanation of why is this
abandoned and who decided that, but you can just use an empty commit for
the same purpose.

Object classes are precious things and we shouldn't get carried away.

If this is done with an object there should probably be some way to
encode it into the existing commit object.

Moving the refs into refs/abandoned would work too. We would need new
git commands to do this and flags on the visualization tools to
include the abandoned branches. On the other hand doing this is
recording state about the repository in the refs directory instead of
writing this state into the repo itself.

-- 
Jon Smirl
jonsmirl@gmail.com

Hi,

On Wed, 13 Sep 2006, Jon Smirl wrote:

Moving the refs into refs/abandoned would work too. We would need new
git commands to do this and flags on the visualization tools to
include the abandoned branches. On the other hand doing this is
recording state about the repository in the refs directory instead of
writing this state into the repo itself.

Well, the refs directory is _part_ of the repository. Think about it, if 
you do not know which branches are in the object database, you lack a lot 
of information.

BTW the moving of a branch to a tag in refs/abandoned/ is trivial.

Ciao,
Dscho

Jon Smirl [off-list ref] wrote:

On 9/13/06, Petr Baudis [off-list ref] wrote:

quoted

You could also stash the ref to refs/heads-abandoned/ instead of
refs/heads/ if you want to keep the junk around for some reason. Of
course you don't get the nice marker with explanation of why is this
abandoned and who decided that, but you can just use an empty commit for
the same purpose.

Object classes are precious things and we shouldn't get carried away.

If this is done with an object there should probably be some way to
encode it into the existing commit object.

I agree completely with what Petr is saying.  Allocating a new
class of object in Git is a *major* deal.  We don't really have
any IDs left.  Tags would quite easily carry information stating
that the branch is considered abandoned, who abandoned it, and
when the did so.  The tags can also easily be saved off into a
refs/abandoned directory.
 

Moving the refs into refs/abandoned would work too. We would need new
git commands to do this and flags on the visualization tools to
include the abandoned branches.

I fail to see why.  If a branch is abandoned then its not merged into
any of the active branches.  If this is the case then gitk doesn't
display it when viewing an active branch.  So what's the problem?

On the other hand doing this is
recording state about the repository in the refs directory instead of
writing this state into the repo itself.

Same difference.  The repository is a union of the objects stored
in the objects directory and the pack files and the symbolic
ref names holding the heads of the commit chains.  We're already
talking about some other ways to handle larger sets of refs, and
Linus has contributed some cleanup code heading in that direction.
The refs *are* the repository.

-- 
Shawn.

Jon Smirl wrote:

On 9/13/06, Petr Baudis [off-list ref] wrote:

quoted

Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter
where Jon Smirl [off-list ref] said that...

quoted

Abandoned branches are common in CVS since it is not distributed.
People start working on something in the main repo and then decide it
was a bad idea. In the git world these branches usually don't end up
in the main repo.

Can't you just toss the branch away in that case? :-)

It is a historical import. Everything that was in the initial repo
needs to be preserved otherwise they aren't going to get rid of the
old CVS repo.

You can leave this in historical repository, and strip current repository
from abandoned work, by the way.

quoted

You could also stash the ref to refs/heads-abandoned/ instead of
refs/heads/ if you want to keep the junk around for some reason. Of
course you don't get the nice marker with explanation of why is this
abandoned and who decided that, but you can just use an empty commit for
the same purpose.

If this is done with an object there should probably be some way to
encode it into the existing commit object.

As it was said somewhere in this thread, you can use tags (tag objects) for
that, i.e. tag each of the abandoned branches, explaining why branch wa
abandoned for example, remove head refs, and move tag refs to
refs/abandoned or refs/tags-abandoned/ or refs/Attic/ or in refs-abandoned/
(the last has the advantage to not be included by default in any command,
even when --all is given)
 

Moving the refs into refs/abandoned would work too. We would need new
git commands to do this and flags on the visualization tools to
include the abandoned branches. On the other hand doing this is
recording state about the repository in the refs directory instead of
writing this state into the repo itself.

There is no need for new flag. If you give --all flag to the gitk command
line or the list of commits option field, all the refs in $GIT_DIR/refs/
would be included. If you will use refs-abandoned/ instead, it would be
enough I guess to give refs-abandoned/ or refs-abandoned/*. Of course you
would need some change to visualisers to mar abandoned branches in
different way.

gitweb as of now uses only refs/heads and refs/tags; markers are taken from
$GIT_DIR/info/refs or "git-ls-remotes ." (i.e. all refs/)
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Jakub Narebski wrote:
...

As it was said somewhere in this thread, you can use tags (tag objects) for
that, i.e. tag each of the abandoned branches, explaining why branch wa
abandoned for example, remove head refs, and move tag refs to
refs/abandoned or refs/tags-abandoned/ or refs/Attic/ or in refs-abandoned/
(the last has the advantage to not be included by default in any command,
even when --all is given)

Using $GIT_DIR/refs-abandoned/ means changing a number of core parts;
think fsck and friends. Better to decide on a name in $GIT_DIR/refs/ and
teach the various visualizers to ignore that prefix by default. Maybe
even make the name a config item. *ducks*

A Large Angry SCM [off-list ref] wrote:

Jakub Narebski wrote:
...

quoted

As it was said somewhere in this thread, you can use tags (tag objects) for
that, i.e. tag each of the abandoned branches, explaining why branch wa
abandoned for example, remove head refs, and move tag refs to
refs/abandoned or refs/tags-abandoned/ or refs/Attic/ or in refs-abandoned/
(the last has the advantage to not be included by default in any command,
even when --all is given)

Using $GIT_DIR/refs-abandoned/ means changing a number of core parts;
think fsck and friends. Better to decide on a name in $GIT_DIR/refs/ and
teach the various visualizers to ignore that prefix by default. Maybe
even make the name a config item. *ducks*

How about using a regex or a shell wildcard in config such as:

	[core]
		hideRefs = refs/abandoned/
		hideRefs = refs/some-garbage-i-have/

?

-- 
Shawn.

A Large Angry SCM wrote:

Jakub Narebski wrote:
...

quoted

As it was said somewhere in this thread, you can use tags (tag objects)

for

quoted

that, i.e. tag each of the abandoned branches, explaining why branch wa
abandoned for example, remove head refs, and move tag refs to
refs/abandoned or refs/tags-abandoned/ or refs/Attic/ or in

refs-abandoned/

quoted

(the last has the advantage to not be included by default in any command,
even when --all is given)

Using $GIT_DIR/refs-abandoned/ means changing a number of core parts;
think fsck and friends. Better to decide on a name in $GIT_DIR/refs/ and
teach the various visualizers to ignore that prefix by default. Maybe
even make the name a config item. *ducks*

Well, visualisers IIRC shows only requested branches. The only place where
abandoned branches would show even when we probably don't want would be
--all... one can try to use --all --not refs/abandoned/*

I wonder if using the "hidden" directory for abandoned branches 
(i.e. refs/.abandoned) would work...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

On 9/13/06, Johannes Schindelin [off-list ref] wrote:

Hi,

On Wed, 13 Sep 2006, Jon Smirl wrote:

quoted

Moving the refs into refs/abandoned would work too. We would need new
git commands to do this and flags on the visualization tools to
include the abandoned branches. On the other hand doing this is
recording state about the repository in the refs directory instead of
writing this state into the repo itself.

Well, the refs directory is _part_ of the repository. Think about it, if
you do not know which branches are in the object database, you lack a lot
of information.

If you delete all of your heads you can recover them by following all
of the chains in the repo to find them. Doing this would recover the
abandoned branches too but it would mix them up with the active heads.
This is not a big deal but it is info that is getting stored outside
of the object db.

-- 
Jon Smirl
jonsmirl@gmail.com

On 9/13/06, Jakub Narebski [off-list ref] wrote:

A Large Angry SCM wrote:

quoted

Jakub Narebski wrote:
...

quoted

As it was said somewhere in this thread, you can use tags (tag objects)

for

quoted

quoted

that, i.e. tag each of the abandoned branches, explaining why branch wa
abandoned for example, remove head refs, and move tag refs to
refs/abandoned or refs/tags-abandoned/ or refs/Attic/ or in

refs-abandoned/

quoted

quoted

(the last has the advantage to not be included by default in any command,
even when --all is given)

Using $GIT_DIR/refs-abandoned/ means changing a number of core parts;
think fsck and friends. Better to decide on a name in $GIT_DIR/refs/ and
teach the various visualizers to ignore that prefix by default. Maybe
even make the name a config item. *ducks*

Well, visualisers IIRC shows only requested branches. The only place where
abandoned branches would show even when we probably don't want would be
--all... one can try to use --all --not refs/abandoned/*

In order to make the tools easier to use I would turn this around and
make --all show all active branches and the use something like
--include /refs/abandoned to include the abandoned ones.

I wonder if using the "hidden" directory for abandoned branches
(i.e. refs/.abandoned) would work...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Jon Smirl
jonsmirl@gmail.com

Jon Smirl [off-list ref] wrote:

On 9/13/06, Johannes Schindelin [off-list ref] wrote:

quoted

Hi,

On Wed, 13 Sep 2006, Jon Smirl wrote:

quoted

Moving the refs into refs/abandoned would work too. We would need new
git commands to do this and flags on the visualization tools to
include the abandoned branches. On the other hand doing this is
recording state about the repository in the refs directory instead of
writing this state into the repo itself.

Well, the refs directory is _part_ of the repository. Think about it, if
you do not know which branches are in the object database, you lack a lot
of information.

If you delete all of your heads you can recover them by following all
of the chains in the repo to find them. Doing this would recover the
abandoned branches too but it would mix them up with the active heads.
This is not a big deal but it is info that is getting stored outside
of the object db.

No.  Being able to get a ref back like that is like saying that I
can get files back in ext2 by deleting them then running fsck and
restoring the lost inodes to '/lost+found'.  Sure the data is there
but there's no way to tell which file is which!

The name of a ref, like the name of a file, is pretty important
when it comes to describing it.  Just having the SHA1 ID of 100
commits is pretty useless; it could take weeks to determine which
branch head is which.  The refs database is an important part of
the usability of a Git repository.

-- 
Shawn.

Jon Smirl wrote:

On 9/13/06, Jakub Narebski [off-list ref] wrote:

quoted

Well, visualisers IIRC shows only requested branches. The only place where
abandoned branches would show even when we probably don't want would be
--all... one can try to use --all --not refs/abandoned/*

In order to make the tools easier to use I would turn this around and
make --all show all active branches and the use something like
--include refs/abandoned to include the abandoned ones.

Not that easy. Usually one have only refs/heads and refs/tags... unless
one use --use-separate-remotes, and then one has refs/remotes/...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

On Wed, 13 Sep 2006, Jon Smirl wrote:

If you delete all of your heads you can recover them by following all
of the chains in the repo to find them. Doing this would recover the
abandoned branches too but it would mix them up with the active heads.

Well, just don't do that then.  ;-)

This is not a big deal but it is info that is getting stored outside
of the object db.

Sure, but the object db is useless without them anyway.


Nicolas

Hi Jon!

I guess what people are pointing at is that you can:

 - run your import
 - publish that as mozilla-historical.git
 - copy that to mozilla.git
 - rm all the old heads from mozilla.git
 - rm all the 'new' heads from mozilla-historical.git
 - run git-repack -a -d on both
 - make the historical repo read-only

later, it is trivial to 'archive'  branch. Similarly, other projects
run a repo-per-developer or perhaps thematic repos. No point in
painting 'policy'  when usage practices suffice.

By the way, gitk doesn't show all the branches by default. You have to
pass --all, which stands for... all ;-)

maybe gitk should have --recent-heads. However, I use
--since=3.months.ago all the time, and it works great.

cheers,


martin

Martin Langhoff wrote:

I guess what people are pointing at is that you can:

 - run your import
 - publish that as mozilla-historical.git
 - copy that to mozilla.git
 - rm all the old heads from mozilla.git
 - rm all the 'new' heads from mozilla-historical.git
 - run git-repack -a -d on both
 - make the historical repo read-only

Instead of copying mozilla-historical.git to mozilla.git,
it would be better to clone using --shared option
(which sets up appropriate alternates file). Of course both
repositories should be on the same machine for this to work,
and no, one wouldn't need to copy/clone them both.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Jon Smirl wrote:

It is a historical import. Everything that was in the initial repo
needs to be preserved otherwise they aren't going to get rid of the
old CVS repo.
  

You can tag a tree which contains the raw RCS files used for the import;
then they'll be available forever!

Sam