Marking abandoned branches

Marking abandoned branches

[Jon Smirl]

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

Re: Marking abandoned branches

[Petr Baudis]

Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter
where Jon Smirl <jonsmirl@gmail.com> 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

Re: Marking abandoned branches

[Johannes Schindelin]

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 <jonsmirl@gmail.com> 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.

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

Re: Marking abandoned branches

[Jakub Narebski]

Johannes Schindelin wrote:
> 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 <jonsmirl@gmail.com> 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.
> 
> ... 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

Re: Marking abandoned branches

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter
>> where Jon Smirl <jonsmirl@gmail.com> 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.
>
> ... 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.

Using tag has an added benefit that you now have a place to say
why you dropped it.  So what we would need to support this is an
agreed-upon name under $GIT_DIR/refs/ that is omitted from
display by convention across Porcelains (the core side should
not ignore them because even when you are abandoning them, you
do not want to lose them),

Re: Marking abandoned branches

[Jakub Narebski]

Junio C Hamano wrote:

> Using tag has an added benefit that you now have a place to say
> why you dropped it.  So what we would need to support this is an
> agreed-upon name under $GIT_DIR/refs/ that is omitted from
> display by convention across Porcelains (the core side should
> not ignore them because even when you are abandoning them, you
> do not want to lose them),

I think that using hidden directory (dot-directory), e.g.
$GIT_DIR/refs/.abandoned/ is a good idea... unless it conflicts somewhat
with the way lock files are named...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Marking abandoned branches

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano wrote:
>
>> Using tag has an added benefit that you now have a place to say
>> why you dropped it.  So what we would need to support this is an
>> agreed-upon name under $GIT_DIR/refs/ that is omitted from
>> display by convention across Porcelains (the core side should
>> not ignore them because even when you are abandoning them, you
>> do not want to lose them),
>
> I think that using hidden directory (dot-directory), e.g.
> $GIT_DIR/refs/.abandoned/ is a good idea... unless it conflicts somewhat
> with the way lock files are named...

Names are not interesting.  Visualizers ignoring them
consistently is.

By the way, does gitweb still walk $GIT_DIR/refs hierarchy by
hand to find out the set of refs?  When Linus is done with his
refs/ work, that way would become unsupported.  You would need
to read from "ls-remote $GIT_DIR".

Re: Marking abandoned branches

[Jakub Narebski]

Junio C Hamano wrote:

> By the way, does gitweb still walk $GIT_DIR/refs hierarchy by
> hand to find out the set of refs?  When Linus is done with his
> refs/ work, that way would become unsupported.  You would need
> to read from "ls-remote $GIT_DIR".

Still, unfortunately. We could change git_get_references to use
'git ls-remotes $GIT_DIR' (or 'git --git-dir=$GIT_DIR ls-remotes .'),
and use git_get_references("refs/heads") in git_heads (and git_summary), 
and git_get_references("refs/tags") in git_tags. This _could_ be slower
than current implementation. git-show-refs would help a bit, but I'd rather
have git-show-refs in released version of git before using it in gitweb.

Moreover, git currently reads appropriate ref directly in
git_get_hash_by_ref, not supporting even symrefs, not to mention packed
refs. One solution would be to add support for symrefs and packed refs
directly in gitweb (Git.pm can help here), another to use git core command
(git-rev-parse?) but that can make gitweb slower (additional fork).

I hope that Linus work will be left to mature first in 'pu', then in 'next'
branch... wouldn't refs cache (similar to current index for files) be
better idea?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Marking abandoned branches

[Petr Baudis]

Dear diary, on Wed, Sep 13, 2006 at 09:34:24PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> I hope that Linus work will be left to mature first in 'pu', then in 'next'
> branch...

  Yes, me too - I still need to fix Cogito. :-)

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

Re: Marking abandoned branches

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Moreover, git currently reads appropriate ref directly in
> git_get_hash_by_ref, not supporting even symrefs, not to mention packed
> refs. One solution would be to add support for symrefs and packed refs
> directly in gitweb (Git.pm can help here), another to use git core command
> (git-rev-parse?) but that can make gitweb slower (additional fork).

The only use of that function is in git_get_refs_list to read
refs by hand, one-by-one.  This calling function needs to be
updated to use the core more effectively to adjust to Linus's
refs/ anyway, so I think git_get_hash_by_ref is too low level
implementation detail to worry about.  What we want is a core
support that git_get_refs_list can use to get the list of refs
and information associated with them efficiently.

Now git_get_refs_list is called from four places, three
functions.  git_summary does two separate calls to refs/tags and
refs/heads.  git_tags and git_heads do one call each for their
own hierarchy.  What this suggests is that the core support we
will give needs a way to specify what subset of refs/* to
include.  peek-remote allows you to do this and it is fairly
efficient for local case (although it could be made more
efficient by not using the general git_connect() framework if we
want a faster local-only command), but it gives back only the
object names.  git_get_refs_list wants more than that.  So what
does it want to know? [*1*]

Looking at parse_ref [*2*]:

 - object name
 - type
   - for a 'tag':
     - what is tagged (type and object name)
     - the tag name
     - the tagger information (name, time, and zone)
     - comment but except PGP signature
     - if it directly [*3*] tags a 'commit':
       - its age based on the commit timestamp
  - for a 'commit':
     - the refname itself
     - the first line of the log message
     - commit timestamp
     - the age based on the commit timestamp
  - for others:
     - the refname itself

The parse_ref implementation itself uses two helpers: parse_tag
and parse_commit, and are used to show a single tag or commit
from git_tag and git_commit request.

So it appears to me that show-ref needs to have at least:

 (1) A way to specify what refs to show, via --tags, --heads,
     --all, and explicit refname parameters.

 (2) Output format specifier to give information of interest for
     each object, which includes the header fields and body of a
     tag and a commit object.  For a tag object, the same for
     the object the tag refers to needs to be availble.

The strawman man-page I sent out about a month ago satisfies the
above except the unpeeling of tag needed in the latter part of
(2).

I'll try to code the one specified by the original strawman up
sometime today; we can discuss enhancements after that.

> I hope that Linus work will be left to mature first in 'pu', then in 'next'
> branch...

That's the general idea.  A new topic always starts out in their
own topic branch, and when I have enough time to look at it in
isolation and I feel confident enough that it is in testable
shape together with what are already in 'next', it is merged
into 'next'.  I did not have enough concentration last night so
Linus's refs/ spent the night in 'pu'.  Hopefully I'll have
energy to look at it enough today to decide if it can be merged
to 'next', or other fix-ups are needed.

It may break 'gitweb' and possibly others.  I offhand do not
know what other things (including git Porcelainish) look at
refs/ directly; they obviously need fixing before the refs/ work
hits 'master', or maybe even 'next'.

> ... wouldn't refs cache (similar to current index for files) be
> better idea?

The ideal is to make a fast and easy way for Porcelains to
access what they want to know about the refs without knowing
their implementation.  We already provide ways to do so except
that they may not be fast nor easy.  And the "may not be fast"
part is what triggers 'cache would be better' reaction, but the
right thing to do is not to work it around with a clutch, but to
design what an appropriate core side support is and implement
it.


[*1*] Here, I am essentially designing what show-ref command
should look like.  I was hoping that Porcelain people who are
users of the core to do this sort of "requirement design" and
present a proposal based on their actual needs.  Unfortunately
it never happened.  Let me set an example by showing how it
should be done here.

[*2*] This is called only once from git_get_refs, so we can get
rid of this function when we rewrite git_get_refs.

[*3*] If we rewrite this part using "foo^{}", gitweb would lose
the ability to distinguish a tag that points directly at a
commit and a tag that points at a tag that points at a commit.
I do not think anybody currently appreciates it right now but
later we might miss it if we did so.

There unfortunately is no way to use rev^{whatever} syntax to
say "peel the onion only one level".

Re: Marking abandoned branches

[Jakub Narebski]

Junio C Hamano wrote:

>> ... wouldn't refs cache (similar to current index for files) be
>> better idea?
> 
> The ideal is to make a fast and easy way for Porcelains to
> access what they want to know about the refs without knowing
> their implementation.  We already provide ways to do so except
> that they may not be fast nor easy.  And the "may not be fast"
> part is what triggers 'cache would be better' reaction, but the
> right thing to do is not to work it around with a clutch, but to
> design what an appropriate core side support is and implement
> it.

The 'cache would be better' is because it is obviously backward
compatibile (which helps the porcelains and history viewers),
avoids some trouble with deleting (and renaming) branches, can
be fast (when used), and we can use symlinks/symrefs with it I guess. 

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Marking abandoned branches

[Jakub Narebski]

Junio C Hamano wrote:

> I'll try to code the one specified by the original strawman up
> sometime today; we can discuss enhancements after that.

I was thinking about implementing git-show-refs, "borrowing" format
parsing part from rpm (parseFormat function in rpmdb/header.c), but
what I had not found in core git was the function which parses object
into any_object like union; there is function which parses object,
but it extracts and returns only the common part as an object struct. 
And any_object union is local to object.c

I also thought that if format doesn't require object parsing (sha1id,
type, name and size we can get without parsing) then do not do parsing,
but I wonder if this is really worth it.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Marking abandoned branches

[Jakub Narebski]

Junio C Hamano wrote:

> What this suggests is that the core support we
> will give needs a way to specify what subset of refs/* to
> include.  peek-remote allows you to do this and it is fairly
> efficient for local case (although it could be made more
> efficient by not using the general git_connect() framework if we
> want a faster local-only command), but it gives back only the
> object names.

What is the difference between peek-remote and ls-remotes in the
local case, by the way?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Marking abandoned branches

[Jon Smirl]

On 9/13/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter
> where Jon Smirl <jonsmirl@gmail.com> 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? :-)

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

Re: Marking abandoned branches

[Johannes Schindelin]

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

Re: Marking abandoned branches

[Jon Smirl]

On 9/13/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 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.

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

Re: Marking abandoned branches

[Shawn Pearce]

Jon Smirl <jonsmirl@gmail.com> wrote:
> On 9/13/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >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.
> 
> 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.

Re: Marking abandoned branches

[Nicolas Pitre]

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

Re: Marking abandoned branches

[Martin Langhoff]

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

Re: Marking abandoned branches

[Jakub Narebski]

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

Re: Marking abandoned branches

[Shawn Pearce]

Jon Smirl <jonsmirl@gmail.com> wrote:
> On 9/13/06, Petr Baudis <pasky@suse.cz> wrote:
> >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.

Re: Marking abandoned branches

[Jakub Narebski]

Jon Smirl wrote:

> On 9/13/06, Petr Baudis <pasky@suse.cz> wrote:
>> Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter
>> where Jon Smirl <jonsmirl@gmail.com> 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? :-)
> 
> 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.

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

Re: Marking abandoned branches

[A Large Angry SCM]

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*

Re: Marking abandoned branches

[Shawn Pearce]

A Large Angry SCM <gitzilla@gmail.com> wrote:
> 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*


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

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

?

-- 
Shawn.

Re: Marking abandoned branches

[Junio C Hamano]

Shawn Pearce <spearce@spearce.org> writes:

> How about using a regex or a shell wildcard in config such as:
>
> 	[core]
> 		hideRefs = refs/abandoned/
> 		hideRefs = refs/some-garbage-i-have/

A suggestion to say "[core] anything" is out; this does _not_
belong to the core at all.

Depending on how much abandoned you want to make the abondond
refs, you can do one of the following:

 - If you just do not want visualizers to clutter what you are
   usually interested in viewing by default, teach visualizers
   to ignore that refs/ hierarchy.  Right now visualizers either
   use "ls-remote ." (e.g. gitk) or walking refs directory
   itself (e.g. gitweb) to find what refs are available.  Filter
   that and you are done.  If we were to do show-refs helper and
   if all the visualizers use it (we would need something like
   that when the refs/ work Linus is doing hits the mainline --
   walking refs directory to find available refs becomes
   officially unsupported when that happens), I am not opposed
   to give it --ignore=refs/abandoned option.  Similarly for
   ls-remote but _NOT_ peek-remote (the former is Porcelain-ish,
   the latter is core).

 - If you do not want to have even clone look at them, you need
   to have two repositories: with-clutter and main.  You call
   the current Mozilla full-import repository the former, make a
   copy of it and remove unwanted refs from it and repack.  Call
   that main and have people work on it.

   People who want to look at old, failed experiments can pull
   from with-clutter repository in two ways.  Either they can
   pull into their clone of 'main', or they make a separate
   clone using --reference option to cut the download time and
   to keep the cluttered part separate.

Re: Marking abandoned branches

[Jakub Narebski]

A Large Angry SCM wrote:

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

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

Re: Marking abandoned branches

[Jon Smirl]

On 9/13/06, Jakub Narebski <jnareb@gmail.com> wrote:
> A Large Angry SCM wrote:
>
> > 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*
>
> 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

Re: Marking abandoned branches

[Jakub Narebski]

Jon Smirl wrote:

> On 9/13/06, Jakub Narebski <jnareb@gmail.com> wrote:

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

Re: Marking abandoned branches

[Sam Vilain]

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