* [PATCH] git-archive: inline default_parse_extra()
From: Rene Scharfe @ 2006-09-13 20:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Franck Bui-Huu, Git Mailing List
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
diff --git a/builtin-archive.c b/builtin-archive.c
index da3f714..6dabdee 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -145,17 +145,6 @@ void parse_treeish_arg(const char **argv
ar_args->time = archive_time;
}
-static const char *default_parse_extra(struct archiver *ar,
- const char **argv)
-{
- static char msg[64];
-
- snprintf(msg, sizeof(msg) - 4, "'%s' format does not handle %s",
- ar->name, *argv);
-
- return strcat(msg, "...");
-}
-
int parse_archive_args(int argc, const char **argv, struct archiver *ar)
{
const char *extra_argv[MAX_EXTRA_ARGS];
@@ -208,7 +197,8 @@ int parse_archive_args(int argc, const c
if (extra_argc) {
if (!ar->parse_extra)
- die("%s", default_parse_extra(ar, extra_argv));
+ die("'%s' format does not handle %s",
+ ar->name, extra_argv[0]);
ar->args.extra = ar->parse_extra(extra_argc, extra_argv);
}
ar->args.verbose = verbose;
^ permalink raw reply related
* Re: Marking abandoned branches
From: Junio C Hamano @ 2006-09-13 20:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ee9mff$qd1$1@sea.gmane.org>
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".
^ permalink raw reply
* Re: Marking abandoned branches
From: Jakub Narebski @ 2006-09-13 20:43 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90609131331p25923440w45eb49b56933f24b@mail.gmail.com>
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
^ permalink raw reply
* Re: Marking abandoned branches
From: Petr Baudis @ 2006-09-13 20:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ee9mff$qd1$1@sea.gmane.org>
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
^ permalink raw reply
* Re: cvs import
From: Martin Langhoff @ 2006-09-13 20:41 UTC (permalink / raw)
To: Jon Smirl; +Cc: Markus Schiltknecht, Git Mailing List, monotone-devel, dev
In-Reply-To: <9e4733910609131201q7f583029r72dac66cd0dd098f@mail.gmail.com>
On 9/14/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> Let's copy the git list too and maybe we can come up with one importer
> for everyone.
It's a really good idea. cvsps has been for a while a (limited, buggy)
attempt at that. One thing that bothers me in the cvs2svn algorithm is
that is not stable in its decisions about where the branching point is
-- run the import twice at different times and it may tell you that
the branching point has moved.
This is problematic for incremental imports. If we fudged that "it's
around *here*" we better remember we said that and not go changing our
story. Git is too smart for that ;-)
martin
^ permalink raw reply
* Re: Marking abandoned branches
From: Martin Langhoff @ 2006-09-13 20:31 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Petr Baudis, Git Mailing List
In-Reply-To: <9e4733910609131022y19327efy541ac451bdf4b009@mail.gmail.com>
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
^ permalink raw reply
* Re: Marking abandoned branches
From: Jakub Narebski @ 2006-09-13 19:34 UTC (permalink / raw)
To: git
In-Reply-To: <7vbqpja8wz.fsf@assigned-by-dhcp.cox.net>
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
^ permalink raw reply
* [ANNOUNCE] GIT 1.4.2.1
From: Junio C Hamano @ 2006-09-13 19:19 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.4.2.1 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.4.2.1.tar.{gz,bz2} (tarball)
git-htmldocs-1.4.2.1.tar.{gz,bz2} (preformatted docs)
git-manpages-1.4.2.1.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.4.2.1-1.$arch.rpm (RPM)
This release is primarily for these two fixes:
* git-mv was broken. Notably, this did not work:
git-mv foo foo-renamed
* git-http-fetch failed to follow objects/info/alternates on
the remote side. This broke a fetch from Paul's powerpc.git
repository.
I have built i386 and x86_64 RPM this time, since the machine I
do the former has become available again.
----------------------------------------------------------------
Changes since v1.4.2 are as follows:
Dennis Stosberg:
Solaris does not support C99 format strings before version 10
Johannes Schindelin:
git-mv: succeed even if source is a prefix of destination
git-mv: add more path normalization
git-mv: special case destination "."
git-mv: fix off-by-one error
builtin-mv: readability patch
Junio C Hamano:
finish_connect(): thinkofix
http-fetch: fix alternates handling.
Luben Tuikov:
Fix regex pattern in commit-msg
sample commit-msg hook: no silent exit on duplicate Signed-off-by lines
^ permalink raw reply
* Re: problem with http clone/pull
From: Junio C Hamano @ 2006-09-13 19:03 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
In-Reply-To: <17671.23044.481280.965798@cargo.ozlabs.ibm.com>
I'll do 1.4.2.1 with a fix for this and push it out hopefully
today.
^ permalink raw reply
* Re: cvs import
From: Jon Smirl @ 2006-09-13 19:01 UTC (permalink / raw)
To: Markus Schiltknecht, Git Mailing List; +Cc: monotone-devel, dev
In-Reply-To: <45084400.1090906@bluegap.ch>
Let's copy the git list too and maybe we can come up with one importer
for everyone.
On 9/13/06, Markus Schiltknecht <markus@bluegap.ch> wrote:
> Hi,
>
> I've been trying to understand the cvsimport algorithm used by monotone
> and wanted to adjust that to be more like the one in cvs2svn.
>
> I've had some problems with cvs2svn itself and began to question the
> algorithm used there. It turned out that the cvs2svn people have
> discussed an improved algorithms and are about to write a cvs2svn 2.0.
> The main problem with the current algorithm is that it depends on the
> timestamp information stored in the CVS repository.
>
> Instead, it would be much better to just take the dependencies of the
> revisions into account. Considering the timestamp an irrelevant (for the
> import) attribute of the revision.
>
> Now, that can be used to convert from CVS to about anything else.
> Obviously we were discussing about subversion, but then there was git,
> too. And monotone.
>
> I'm beginning to question if one could come up with a generally useful
> cleaned-and-sane-CVS-changeset-dump-format, which could then be used by
> importers to all sort of VCSes. This would make monotone's cvsimport
> function dependent on cvs2svn (and therefore python). But the general
> try-to-get-something-usefull-from-an-insane-CVS-repository-algorithm
> would only have to be written once.
>
> On the other hand, I see that lots of the cvsimport functionality for
> monotone has already been written (rcs file parsing, stuffing files,
> file deltas and complete revisions into the monotone database, etc..).
> Changing it to a better algorithm does not seem to be _that_ much work
> anymore. Plus the hard part seems to be to come up with a good
> algorithm, not implementing it. And we could still exchange our
> experience with the general algorithm with the cvs2svn people.
>
> Plus, the guy who mentioned git pointed out that git needs quite a
> different dump-format than subversion to do an efficient conversion. I
> think coming up with a generally-usable dump format would not be that easy.
>
> So you see, I'm slightly favoring the second implementation approach
> with a C++ implementation inside monotone.
>
> Thoughts or comments?
> Sorry, I forgot to mention some pointers:
>
> Here is the thread where I've started the discussion about the cvs2svn
> algorithm:
> http://cvs2svn.tigris.org/servlets/ReadMsg?list=dev&msgNo=1599
>
> And this is a proposal for an algorithm to do cvs imports independant of
> the timestamp:
> http://cvs2svn.tigris.org/servlets/ReadMsg?list=dev&msgNo=1451
>
> Markus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cvs2svn.tigris.org
> For additional commands, e-mail: dev-help@cvs2svn.tigris.org
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Marking abandoned branches
From: Junio C Hamano @ 2006-09-13 19:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ee9jv6$ga0$1@sea.gmane.org>
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".
^ permalink raw reply
* Re: Marking abandoned branches
From: Junio C Hamano @ 2006-09-13 18:58 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, Jakub Narebski
In-Reply-To: <20060913164937.GC29933@spearce.org>
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.
^ permalink raw reply
* Re: Marking abandoned branches
From: Jakub Narebski @ 2006-09-13 18:51 UTC (permalink / raw)
To: git
In-Reply-To: <7vmz93a9v9.fsf@assigned-by-dhcp.cox.net>
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
^ permalink raw reply
* Re: Marking abandoned branches
From: Junio C Hamano @ 2006-09-13 18:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Jon Smirl, Petr Baudis
In-Reply-To: <Pine.LNX.4.63.0609131729500.19042@wbgn013.biozentrum.uni-wuerzburg.de>
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),
^ permalink raw reply
* Re: Marking abandoned branches
From: Nicolas Pitre @ 2006-09-13 17:46 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Petr Baudis, Git Mailing List
In-Reply-To: <9e4733910609131022y19327efy541ac451bdf4b009@mail.gmail.com>
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
^ permalink raw reply
* Re: Marking abandoned branches
From: Jakub Narebski @ 2006-09-13 17:45 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910609131024v28ccce5cx7dd427a55002bc4f@mail.gmail.com>
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
^ permalink raw reply
* Re: Marking abandoned branches
From: Shawn Pearce @ 2006-09-13 17:32 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Petr Baudis, Git Mailing List
In-Reply-To: <9e4733910609131022y19327efy541ac451bdf4b009@mail.gmail.com>
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.
^ permalink raw reply
* Re: Marking abandoned branches
From: Jon Smirl @ 2006-09-13 17:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ee9d5j$lhd$1@sea.gmane.org>
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
^ permalink raw reply
* Re: Marking abandoned branches
From: Jon Smirl @ 2006-09-13 17:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0609131804050.19042@wbgn013.biozentrum.uni-wuerzburg.de>
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
^ permalink raw reply
* Re: Marking abandoned branches
From: Jakub Narebski @ 2006-09-13 16:55 UTC (permalink / raw)
To: git
In-Reply-To: <45083490.9020203@gmail.com>
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
^ permalink raw reply
* Re: Marking abandoned branches
From: Shawn Pearce @ 2006-09-13 16:49 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Jakub Narebski, git
In-Reply-To: <45083490.9020203@gmail.com>
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.
^ permalink raw reply
* Re: Marking abandoned branches
From: A Large Angry SCM @ 2006-09-13 16:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ee9akc$d62$1@sea.gmane.org>
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*
^ permalink raw reply
* Re: Marking abandoned branches
From: Jakub Narebski @ 2006-09-13 16:12 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910609130859v347a7a9ew5c3ebc982bf9b07b@mail.gmail.com>
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
^ permalink raw reply
* Re: Marking abandoned branches
From: Shawn Pearce @ 2006-09-13 16:09 UTC (permalink / raw)
To: Jon Smirl; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <9e4733910609130859v347a7a9ew5c3ebc982bf9b07b@mail.gmail.com>
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.
^ permalink raw reply
* Re: Marking abandoned branches
From: Johannes Schindelin @ 2006-09-13 16:05 UTC (permalink / raw)
To: Jon Smirl; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <9e4733910609130859v347a7a9ew5c3ebc982bf9b07b@mail.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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox