* Re: git branch performance problem?
From: Han-Wen Nienhuys @ 2007-10-10 21:30 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <f329bf540710101424q22309489sada99907e94b2cd0@mail.gmail.com>
2007/10/10, Han-Wen Nienhuys <hanwenn@gmail.com>:
> More to the point, I seemed to have lost my entire repository. This is
> the type of surprise I don't enjoy.
>
> Now, can someone explain why 'git branch' takes forever if there are
> only two non-remote branches ?
So,
Here is a question: I would like to share commitishes between two checkouts
of a repository. The reason for this is that I want to easily cherry
pick back and forth between the two. The files of in one of them
should be continually available, since I am running out of that
directory.
The way I solved that, was to have both repositories pointing to each
other, using alternates.
Now, after a couple of gc and pack-refs iterations, I am greeted by
hanwen@lilypond:~/vc/git6$ git fsck
missing tree 12b00ec3190f7b46a5fe0a3235445bead4c9645b
broken link from tree 1718d09e0394d113c162e4a3471e7a1f20914a94
to blob 635e2802568b85017007698c0e6dd4d28dca496f
broken link from tree 926899798fce75038e24f8fa1838f6da8bcf105f
to tree f1b852d270ebbaaf95d8ddc06c52763bad11ff25
missing blob 99f0c0d63276fce444e3a200167b636236784c52
missing tree f1b852d270ebbaaf95d8ddc06c52763bad11ff25
missing blob 236962a87fafae8ca2dce2dc550d344aa7a8884a
missing blob 7d69ca297f392a954c4cdcb62bb4c8a90ddb862b
missing blob 9e39be8f5cb4eeff97fcfd6eb77fefeda02f0e71
dangling blob f3a93f023080ce9fc6becb397e366cc4ceb192f5
could it be that GC does not handle cyclic alternates correctly?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH] Fixed crash in fetching remote tags when there is not tags.
From: Jeff King @ 2007-10-10 21:33 UTC (permalink / raw)
To: Alex Riesen; +Cc: Väinö Järvelä, git, Junio C Hamano
In-Reply-To: <20071010212735.GB16635@steel.home>
On Wed, Oct 10, 2007 at 11:27:35PM +0200, Alex Riesen wrote:
> Still, I'd suggest move the test into the caller, firstly because it
> is the only place that special. Also, I can't think of a proper reason
Yes, I agree with that. I came very close to suggesting it in my other
mail, but then realized I had never even looked at the surrounding code,
and I ought not to be making assessments of how that data structure
should be used. But now there are two of us. :)
-Peff
^ permalink raw reply
* Re: git branch performance problem?
From: Lars Hjemli @ 2007-10-10 21:34 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <f329bf540710101424q22309489sada99907e94b2cd0@mail.gmail.com>
On 10/10/07, Han-Wen Nienhuys <hanwenn@gmail.com> wrote:
> 2007/10/10, Han-Wen Nienhuys <hanwenn@gmail.com>:
> > > You probably want to run 'git gc' (which will run 'git pack-refs',
> > > i.e. put all files currently under .git/refs into a single file). This
> > > should speed up 'git branch' (and quite possibly other commands too).
> >
> > This seems rather unuseful. After running gc pack-refs --all, I lost my HEAD,
> >
> > hanwen@lilypond:~/vc/git5$ git show HEAD
> > fatal: ambiguous argument 'HEAD': unknown revision or path not in the
> > working tree.
>
> More to the point, I seemed to have lost my entire repository. This is
> the type of surprise I don't enjoy.
Yeah, this is bad, I'm sorry to have caused you trouble. But I fail to
see how 'git pack-refs --all' could possibly trash your repository. A
few questions:
What version of git are you using?
What's the output from these commands:
$ cat .git/packed-refs
$ cat .git/HEAD
$ find .git/refs -type f | wc -l
> Now, can someone explain why 'git branch' takes forever if there are
> only two non-remote branches ?
That's because git-branch always traverses the complete directory tree
below .git/refs, even if you only want to see the 'local' branches (I
have a patch cooking to fix this).
--
larsh
^ permalink raw reply
* RE: [FEATURE REQUEST] git clone, just clone selected branches?
From: Joakim Tjernlund @ 2007-10-10 21:36 UTC (permalink / raw)
To: 'Linus Torvalds'; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0710101236350.20690@woody.linux-foundation.org>
> -----Original Message-----
> From: Linus Torvalds [mailto:torvalds@linux-foundation.org]
> Sent: den 10 oktober 2007 21:38
> To: Joakim Tjernlund
> Cc: git@vger.kernel.org
> Subject: Re: [FEATURE REQUEST] git clone, just clone selected
> branches?
>
>
>
> On Wed, 10 Oct 2007, Joakim Tjernlund wrote:
> >
> > I know I can use git remote to do this, but it is a bit clumsy
> > when starting a new repo.
>
> How about just
>
> git init
> .. set up remote tracking info in .git/config ..
> git fetch remote
>
> which should do what you want.
>
> Linus
>From git remote man page:
o Imitate git clone but track only selected branches
$ mkdir project.git
$ cd project.git
$ git init
$ git remote add -f -t master -m master origin git://example.com/git.git/
$ git merge origin
yes, this does the trick too but that is more to type so I thought
it would be simpler if I could just tell git clone which branches I want.
Now, this isn't a killer feature to me so if you don't like it, I good
with that too.
Jocke
^ permalink raw reply
* Re: git branch performance problem?
From: J. Bruce Fields @ 2007-10-10 21:39 UTC (permalink / raw)
To: hanwen; +Cc: Lars Hjemli, git
In-Reply-To: <f329bf540710101430i63926b25q7d55976af96b891d@mail.gmail.com>
On Wed, Oct 10, 2007 at 06:30:02PM -0300, Han-Wen Nienhuys wrote:
> 2007/10/10, Han-Wen Nienhuys <hanwenn@gmail.com>:
> > More to the point, I seemed to have lost my entire repository. This is
> > the type of surprise I don't enjoy.
> >
> > Now, can someone explain why 'git branch' takes forever if there are
> > only two non-remote branches ?
>
> So,
>
> Here is a question: I would like to share commitishes between two checkouts
> of a repository. The reason for this is that I want to easily cherry
> pick back and forth between the two. The files of in one of them
> should be continually available, since I am running out of that
> directory.
>
> The way I solved that, was to have both repositories pointing to each
> other, using alternates.
>
> Now, after a couple of gc and pack-refs iterations, I am greeted by
>
> hanwen@lilypond:~/vc/git6$ git fsck
> missing tree 12b00ec3190f7b46a5fe0a3235445bead4c9645b
> broken link from tree 1718d09e0394d113c162e4a3471e7a1f20914a94
> to blob 635e2802568b85017007698c0e6dd4d28dca496f
> broken link from tree 926899798fce75038e24f8fa1838f6da8bcf105f
> to tree f1b852d270ebbaaf95d8ddc06c52763bad11ff25
> missing blob 99f0c0d63276fce444e3a200167b636236784c52
> missing tree f1b852d270ebbaaf95d8ddc06c52763bad11ff25
> missing blob 236962a87fafae8ca2dce2dc550d344aa7a8884a
> missing blob 7d69ca297f392a954c4cdcb62bb4c8a90ddb862b
> missing blob 9e39be8f5cb4eeff97fcfd6eb77fefeda02f0e71
> dangling blob f3a93f023080ce9fc6becb397e366cc4ceb192f5
>
>
> could it be that GC does not handle cyclic alternates correctly?
Does it handle alternates at all? If you run git-gc on a repository
which other repositories get objects from, then my impression was that
bad things happen.
--b.
^ permalink raw reply
* Re: git branch performance problem?
From: Lars Hjemli @ 2007-10-10 21:45 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: hanwen, git
In-Reply-To: <20071010213925.GB2963@fieldses.org>
On 10/10/07, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Wed, Oct 10, 2007 at 06:30:02PM -0300, Han-Wen Nienhuys wrote:
> > could it be that GC does not handle cyclic alternates correctly?
>
> Does it handle alternates at all? If you run git-gc on a repository
> which other repositories get objects from, then my impression was that
> bad things happen.
>
AFAIK 'git gc' is safe, while 'git gc --prune' will remove loose
(unreferenced) objects.
--
larsh
^ permalink raw reply
* Re: git branch performance problem?
From: Han-Wen Nienhuys @ 2007-10-10 21:49 UTC (permalink / raw)
To: Lars Hjemli; +Cc: J. Bruce Fields, git
In-Reply-To: <8c5c35580710101445h232f9a67jd0c326b3b97ae3dd@mail.gmail.com>
2007/10/10, Lars Hjemli <hjemli@gmail.com>:
> On 10/10/07, J. Bruce Fields <bfields@fieldses.org> wrote:
> > On Wed, Oct 10, 2007 at 06:30:02PM -0300, Han-Wen Nienhuys wrote:
> > > could it be that GC does not handle cyclic alternates correctly?
> >
> > Does it handle alternates at all? If you run git-gc on a repository
> > which other repositories get objects from, then my impression was that
> > bad things happen.
> >
>
> AFAIK 'git gc' is safe, while 'git gc --prune' will remove loose
> (unreferenced) objects.
Yes, I think that in this case, gc --prune was run accidentally, but
given that the history of the program invoking git just died, I'm not
sure how to figure that out.
Maybe gc --prune could follow the alternates and abort if a cycle was detected?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: git branch performance problem?
From: J. Bruce Fields @ 2007-10-10 21:53 UTC (permalink / raw)
To: hanwen; +Cc: Lars Hjemli, git
In-Reply-To: <f329bf540710101449oad9c9dg85f3821f55fb85ea@mail.gmail.com>
On Wed, Oct 10, 2007 at 06:49:19PM -0300, Han-Wen Nienhuys wrote:
> 2007/10/10, Lars Hjemli <hjemli@gmail.com>:
> > On 10/10/07, J. Bruce Fields <bfields@fieldses.org> wrote:
> > > On Wed, Oct 10, 2007 at 06:30:02PM -0300, Han-Wen Nienhuys wrote:
> > > > could it be that GC does not handle cyclic alternates correctly?
> > >
> > > Does it handle alternates at all? If you run git-gc on a repository
> > > which other repositories get objects from, then my impression was that
> > > bad things happen.
> > >
> >
> > AFAIK 'git gc' is safe, while 'git gc --prune' will remove loose
> > (unreferenced) objects.
>
> Yes, I think that in this case, gc --prune was run accidentally, but
> given that the history of the program invoking git just died, I'm not
> sure how to figure that out.
>
> Maybe gc --prune could follow the alternates and abort if a cycle was detected?
Don't the alternates point in the wrong direction? You'd need pointers
back from the main repository to the repositories that depend on it for
objects.
Which would be nice....
--b.
^ permalink raw reply
* Re: git branch performance problem?
From: Johannes Schindelin @ 2007-10-10 21:53 UTC (permalink / raw)
To: hanwen; +Cc: Lars Hjemli, J. Bruce Fields, git
In-Reply-To: <f329bf540710101449oad9c9dg85f3821f55fb85ea@mail.gmail.com>
Hi,
On Wed, 10 Oct 2007, Han-Wen Nienhuys wrote:
> 2007/10/10, Lars Hjemli <hjemli@gmail.com>:
> > On 10/10/07, J. Bruce Fields <bfields@fieldses.org> wrote:
> > > On Wed, Oct 10, 2007 at 06:30:02PM -0300, Han-Wen Nienhuys wrote:
> > > > could it be that GC does not handle cyclic alternates correctly?
> > >
> > > Does it handle alternates at all? If you run git-gc on a repository
> > > which other repositories get objects from, then my impression was
> > > that bad things happen.
> > >
> >
> > AFAIK 'git gc' is safe, while 'git gc --prune' will remove loose
> > (unreferenced) objects.
>
> Yes, I think that in this case, gc --prune was run accidentally, but
> given that the history of the program invoking git just died, I'm not
> sure how to figure that out.
>
> Maybe gc --prune could follow the alternates and abort if a cycle was
> detected?
I think we talked about this quite some time ago, and the resolution was
that it is too hard.
Now that it bit somebody in real life, I think we have to try harder.
And probably the best place to check would be git-prune, not git-gc, since
that is the program (called by gc) that most probably killed your repo.
Come to think of it, it should probably be part of git-repack, too.
Will try to cobble up a patch,
Dscho
^ permalink raw reply
* [PATCH] git-branch: only traverse the requested refs
From: Lars Hjemli @ 2007-10-10 21:54 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git, Junio C Hamano
In-Reply-To: <f329bf540710101424q22309489sada99907e94b2cd0@mail.gmail.com>
This avoids looking at every single file below .git/refs when git-branch
is fetching the list of refs to display.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
This patch should make git-branch much more efficient when there exists
many files below .git/refs, but it does require two passes through
.git/packed-refs when -a is specified.
No benchmarking performed...
builtin-branch.c | 28 +++++++++-------------------
1 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 3da8b55..466e1e0 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -185,25 +185,8 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
{
struct ref_list *ref_list = (struct ref_list*)(cb_data);
struct ref_item *newitem;
- int kind = REF_UNKNOWN_TYPE;
int len;
- /* Detect kind */
- if (!prefixcmp(refname, "refs/heads/")) {
- kind = REF_LOCAL_BRANCH;
- refname += 11;
- } else if (!prefixcmp(refname, "refs/remotes/")) {
- kind = REF_REMOTE_BRANCH;
- refname += 13;
- } else if (!prefixcmp(refname, "refs/tags/")) {
- kind = REF_TAG;
- refname += 10;
- }
-
- /* Don't add types the caller doesn't want */
- if ((kind & ref_list->kinds) == 0)
- return 0;
-
/* Resize buffer */
if (ref_list->index >= ref_list->alloc) {
ref_list->alloc = alloc_nr(ref_list->alloc);
@@ -214,7 +197,7 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
/* Record the new item */
newitem = &(ref_list->list[ref_list->index++]);
newitem->name = xstrdup(refname);
- newitem->kind = kind;
+ newitem->kind = ref_list->kinds;
hashcpy(newitem->sha1, sha1);
len = strlen(newitem->name);
if (len > ref_list->maxwidth)
@@ -296,8 +279,15 @@ static void print_ref_list(int kinds, int detached, int verbose, int abbrev)
struct ref_list ref_list;
memset(&ref_list, 0, sizeof(ref_list));
+ if (kinds & REF_LOCAL_BRANCH) {
+ ref_list.kinds = REF_LOCAL_BRANCH;
+ for_each_branch_ref(append_ref, &ref_list);
+ }
+ if (kinds & REF_REMOTE_BRANCH) {
+ ref_list.kinds = REF_REMOTE_BRANCH;
+ for_each_remote_ref(append_ref, &ref_list);
+ }
ref_list.kinds = kinds;
- for_each_ref(append_ref, &ref_list);
qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* RE: [FEATURE REQUEST] git clone, just clone selected branches?
From: Johannes Schindelin @ 2007-10-10 21:56 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <011b01c80b84$222d1e70$04ac10ac@Jocke>
Hi,
On Wed, 10 Oct 2007, Joakim Tjernlund wrote:
> I should know better than to throw out ideas like this. Next time I have
> an suggestion I will think long and hard about it before posting again.
Hey, it was just a try.
Personally, I am not interested in the feature _you_ asked for, but I
thought it might be pretty easy for you to rewrite git-clone.sh to take
advantage of git-fetch and git-remote, and that your desired feature would
be easier to add then. So easy that the whole thing would have taken you
all of an hour or so.
But maybe somebody else is interested enough to scratch your itch.
Ciao,
Dscho
^ permalink raw reply
* Re: git branch performance problem?
From: Han-Wen Nienhuys @ 2007-10-10 22:01 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Lars Hjemli, git
In-Reply-To: <20071010215317.GC2963@fieldses.org>
2007/10/10, J. Bruce Fields <bfields@fieldses.org>:
> > Maybe gc --prune could follow the alternates and abort if a cycle was detected?
>
> Don't the alternates point in the wrong direction? You'd need pointers
> back from the main repository to the repositories that depend on it for
> objects.
>
> Which would be nice....
The development repo was cloned from the main repo; then sometimes I
cherry pick from development into the main repo. Hence alternates in 2
directions.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* [PATCH] clear_commit_marks(): avoid deep recursion
From: Johannes Schindelin @ 2007-10-10 22:14 UTC (permalink / raw)
To: git, hjemli, gitster; +Cc: spearce
Before this patch, clear_commit_marks() recursed for each parent. This
could be potentially very expensive in terms of stack space. Probably
the only reason that this did not lead to problems is the fact that we
typically call clear_commit_marks() after marking a relatively small set
of commits.
Use (sort of) a tail recursion instead: first recurse on the parents
other than the first one, and then continue the loop with the first
parent.
Noticed by Shawn Pearce.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
commit.c | 23 ++++++++++++++---------
1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/commit.c b/commit.c
index 20fb220..ac24266 100644
--- a/commit.c
+++ b/commit.c
@@ -441,17 +441,22 @@ struct commit *pop_most_recent_commit(struct commit_list **list,
void clear_commit_marks(struct commit *commit, unsigned int mark)
{
- struct commit_list *parents;
+ while (commit) {
+ struct commit_list *parents;
- commit->object.flags &= ~mark;
- parents = commit->parents;
- while (parents) {
- struct commit *parent = parents->item;
+ if (!(mark & commit->object.flags))
+ return;
- /* Have we already cleared this? */
- if (mark & parent->object.flags)
- clear_commit_marks(parent, mark);
- parents = parents->next;
+ commit->object.flags &= ~mark;
+
+ parents = commit->parents;
+ if (!parents)
+ return;
+
+ while ((parents = parents->next))
+ clear_commit_marks(parents->item, mark);
+
+ commit = commit->parents->item;
}
}
--
1.5.3.4.1169.g5fb8d
^ permalink raw reply related
* RE: [FEATURE REQUEST] git clone, just clone selected branches?
From: Joakim Tjernlund @ 2007-10-10 22:41 UTC (permalink / raw)
To: 'Johannes Schindelin'; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710102254340.4174@racer.site>
> -----Original Message-----
> From: Johannes Schindelin [mailto:Johannes.Schindelin@gmx.de]
>
> Hi,
>
> On Wed, 10 Oct 2007, Joakim Tjernlund wrote:
>
> > I should know better than to throw out ideas like this.
> Next time I have
> > an suggestion I will think long and hard about it before
> posting again.
>
> Hey, it was just a try.
Some people might get scared away from such tries
>
> Personally, I am not interested in the feature _you_ asked for, but I
NP, if it only me that is interested then this is probably not such a good idea.
> thought it might be pretty easy for you to rewrite
> git-clone.sh to take
> advantage of git-fetch and git-remote, and that your desired
> feature would
> be easier to add then. So easy that the whole thing would
> have taken you
> all of an hour or so.
Well, now I had to take a look and I think you are overestimating my capabilities :)
It is a 12KB script full of git-plumbing I have never used, nor do I do
sh scripts well. It might be an hour for you, but I would probably have
to spend the whole day :)
Jocke
>
> But maybe somebody else is interested enough to scratch your itch.
>
> Ciao,
> Dscho
>
>
>
^ permalink raw reply
* Re: Spam: Re: git branch performance problem?
From: Brandon Casey @ 2007-10-10 22:55 UTC (permalink / raw)
To: Lars Hjemli; +Cc: J. Bruce Fields, hanwen, git
In-Reply-To: <8c5c35580710101445h232f9a67jd0c326b3b97ae3dd@mail.gmail.com>
Lars Hjemli wrote:
> On 10/10/07, J. Bruce Fields <bfields@fieldses.org> wrote:
>> On Wed, Oct 10, 2007 at 06:30:02PM -0300, Han-Wen Nienhuys wrote:
>>> could it be that GC does not handle cyclic alternates correctly?
>> Does it handle alternates at all? If you run git-gc on a repository
>> which other repositories get objects from, then my impression was that
>> bad things happen.
>>
>
> AFAIK 'git gc' is safe, while 'git gc --prune' will remove loose
> (unreferenced) objects.
No, this is not the case, unless something has changed very recently
in git-gc or git-repack. Even git-gc with no arguments is unsafe if
the repository being gc'ed is listed in another's alternates.
git-gc calls repack with -a and -d. which causes a new pack to be
created which only contains the objects required by the local repository.
The other packs are then deleted. Objects contained in those packs and
required by a "sharing" repository (one using the alternates mechanism)
will be deleted if the local repository no longer references them.
Maybe git-gc should make use of repack's new -A option by default and
only use -a (and not -A) when --prune is specified...
-brandon
^ permalink raw reply
* Re: [PATCH] git-branch: only traverse the requested refs
From: Johannes Schindelin @ 2007-10-10 23:00 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Han-Wen Nienhuys, git, Junio C Hamano
In-Reply-To: <1192053283-2351-1-git-send-email-hjemli@gmail.com>
Hi,
On Wed, 10 Oct 2007, Lars Hjemli wrote:
> This avoids looking at every single file below .git/refs when git-branch
> is fetching the list of refs to display.
>
> [...]
>
> + if (kinds & REF_LOCAL_BRANCH) {
> + ref_list.kinds = REF_LOCAL_BRANCH;
> + for_each_branch_ref(append_ref, &ref_list);
> + }
The function for_each_branch_ref() calls do_for_each_ref(), which in turn
calls get_loose_refs(), which calls get_ref_dir() to read all loose refs,
if they have not yet been read.
So I think that your patch (unfortunately) will no help Han-Wen's
situation.
Ciao,
Dscho
^ permalink raw reply
* RE: [FEATURE REQUEST] git clone, just clone selected branches?
From: Johannes Schindelin @ 2007-10-10 23:01 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <011d01c80b8e$b0c0dc30$04ac10ac@Jocke>
Hi,
On Thu, 11 Oct 2007, Joakim Tjernlund wrote:
> > -----Original Message-----
> > From: Johannes Schindelin [mailto:Johannes.Schindelin@gmx.de]
> >
> > thought it might be pretty easy for you to rewrite git-clone.sh to
> > take advantage of git-fetch and git-remote, and that your desired
> > feature would be easier to add then. So easy that the whole thing
> > would have taken you all of an hour or so.
>
> Well, now I had to take a look and I think you are overestimating my
> capabilities :) It is a 12KB script full of git-plumbing I have never
> used, nor do I do sh scripts well. It might be an hour for you, but I
> would probably have to spend the whole day :)
Heh. git-clone is pretty crowded. But it predates git-remote. And I
have a hunch that git-clone will be a trivial script when it calls
git-remote and the git-fetch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-branch: only traverse the requested refs
From: Lars Hjemli @ 2007-10-10 23:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0710102358110.4174@racer.site>
On 10/11/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 10 Oct 2007, Lars Hjemli wrote:
> > + if (kinds & REF_LOCAL_BRANCH) {
> > + ref_list.kinds = REF_LOCAL_BRANCH;
> > + for_each_branch_ref(append_ref, &ref_list);
> > + }
>
> The function for_each_branch_ref() calls do_for_each_ref(), which in turn
> calls get_loose_refs(), which calls get_ref_dir() to read all loose refs,
> if they have not yet been read.
Ok, I'll see if get_loose_refs() could take 'const char *base' and
pass this on to get_ref_dir(), which should solve the problem.
Thanks for noticing.
--
larsh
^ permalink raw reply
* [PATCH 0/2] Add --dry-run option to git-push
From: Baz @ 2007-10-10 23:34 UTC (permalink / raw)
To: GIT list; +Cc: Junio C Hamano
Hi,
there was discussion recently about the default behaviour of git-push
having the potential to confuse, making it easy to push commits that
are still cooking in other branches.
Its also possible for newbies to make mistakes with refspecs, but
there's no way to know if you've got the syntax right without actually
pushing. Steffan suggested a dry-run flag, which I've always wanted
too, so here's an attempt. Patches git-send-pack, git-push, their
docs, and adds a test for git-push.
Treat me gentle... first patch to the list and the mailer will
probably mangle it (sigh)
Cheers,
Baz
Diffstat:
Documentation/git-push.txt | 6 +++++-
Documentation/git-send-pack.txt | 5 ++++-
builtin-push.c | 10 ++++++++--
send-pack.c | 31 +++++++++++++++++++------------
t/t5516-fetch-push.sh | 10 ++++++++++
5 files changed, 46 insertions(+), 16 deletions(-)
^ permalink raw reply
* [PATCH 1/2] Add a --dry-run option to git-send-pack.
From: Brian Ewins @ 2007-10-10 23:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Brian Ewins <brian.ewins@gmail.com>
---
Documentation/git-send-pack.txt | 5 ++++-
send-pack.c | 31 +++++++++++++++++++------------
2 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-
pack.txt
index 3271e88..9e2783c 100644
--- a/Documentation/git-send-pack.txt
+++ b/Documentation/git-send-pack.txt
@@ -8,7 +8,7 @@ git-send-pack - Push objects over git protocol to
another repository
SYNOPSIS
--------
-'git-send-pack' [--all] [--force] [--receive-pack=<git-receive-
pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]
+'git-send-pack' [--all] [--dry-run] [--force] [--receive-pack=<git-
receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]
DESCRIPTION
-----------
@@ -34,6 +34,9 @@ OPTIONS
Instead of explicitly specifying which refs to update,
update all heads that locally exist.
+\--dry-run::
+ Show what would have been updated, but do not send any updates.
+
\--force::
Usually, the command refuses to update a remote ref that
is not an ancestor of the local ref used to overwrite it.
diff --git a/send-pack.c b/send-pack.c
index f74e66a..e8bef4f 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -7,13 +7,14 @@
#include "remote.h"
static const char send_pack_usage[] =
-"git-send-pack [--all] [--force] [--receive-pack=<git-receive-pack>]
[--verbose] [--thin] [<host>:]<directory> [<ref>...]\n"
+"git-send-pack [--all] [--dry-run] [--force] [--receive-pack=<git-
receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]\n"
" --all and explicit <ref> specification are mutually exclusive.";
static const char *receivepack = "git-receive-pack";
static int verbose;
static int send_all;
static int force_update;
static int use_thin_pack;
+static int dry_run;
/*
* Make a pack stream and spit it out into file descriptor fd
@@ -282,16 +283,18 @@ static int send_pack(int in, int out, struct
remote *remote, int nr_refspec, cha
strcpy(old_hex, sha1_to_hex(ref->old_sha1));
new_hex = sha1_to_hex(ref->new_sha1);
- if (ask_for_status_report) {
- packet_write(out, "%s %s %s%c%s",
- old_hex, new_hex, ref->name, 0,
- "report-status");
- ask_for_status_report = 0;
- expect_status_report = 1;
+ if (!dry_run) {
+ if (ask_for_status_report) {
+ packet_write(out, "%s %s %s%c%s",
+ old_hex, new_hex, ref->name, 0,
+ "report-status");
+ ask_for_status_report = 0;
+ expect_status_report = 1;
+ }
+ else
+ packet_write(out, "%s %s %s",
+ old_hex, new_hex, ref->name);
}
- else
- packet_write(out, "%s %s %s",
- old_hex, new_hex, ref->name);
if (will_delete_ref)
fprintf(stderr, "deleting '%s'\n", ref->name);
else {
@@ -302,7 +305,7 @@ static int send_pack(int in, int out, struct
remote *remote, int nr_refspec, cha
fprintf(stderr, "\n from %s\n to %s\n",
old_hex, new_hex);
}
- if (remote) {
+ if (remote && !dry_run) {
struct refspec rs;
rs.src = ref->name;
rs.dst = NULL;
@@ -321,7 +324,7 @@ static int send_pack(int in, int out, struct
remote *remote, int nr_refspec, cha
}
packet_flush(out);
- if (new_refs)
+ if (new_refs && !dry_run)
ret = pack_objects(out, remote_refs);
close(out);
@@ -390,6 +393,10 @@ int main(int argc, char **argv)
send_all = 1;
continue;
}
+ if (!strcmp(arg, "--dry-run")) {
+ dry_run = 1;
+ continue;
+ }
if (!strcmp(arg, "--force")) {
force_update = 1;
continue;
--
1.5.2.5
^ permalink raw reply related
* [PATCH 2/2] Add a --dry-run option to git-push.
From: Brian Ewins @ 2007-10-10 23:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Brian Ewins <brian.ewins@gmail.com>
---
Documentation/git-push.txt | 6 +++++-
builtin-push.c | 10 ++++++++--
t/t5516-fetch-push.sh | 10 ++++++++++
3 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 6bc559d..2dd95ba 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated
objects
SYNOPSIS
--------
[verse]
-'git-push' [--all] [--tags] [--receive-pack=<git-receive-pack>]
+'git-push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-
pack>]
[--repo=all] [-f | --force] [-v] [<repository>
<refspec>...]
DESCRIPTION
@@ -63,6 +63,10 @@ the remote repository.
Instead of naming each ref to push, specifies that all
refs under `$GIT_DIR/refs/heads/` be pushed.
+\--dry-run::
+ Show what would have been updated, but do not perform
+ any updates.
+
\--tags::
All refs under `$GIT_DIR/refs/tags` are pushed, in
addition to refspecs explicitly listed on the command
diff --git a/builtin-push.c b/builtin-push.c
index 88c5024..141380b 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -7,9 +7,9 @@
#include "builtin.h"
#include "remote.h"
-static const char push_usage[] = "git-push [--all] [--tags] [--
receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v]
[<repository> <refspec>...]";
+static const char push_usage[] = "git-push [--all] [--dry-run] [--
tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force]
[-v] [<repository> <refspec>...]";
-static int all, force, thin, verbose;
+static int all, dry_run, force, thin, verbose;
static const char *receivepack;
static const char **refspec;
@@ -69,6 +69,8 @@ static int do_push(const char *repo)
argc = 1;
if (all)
argv[argc++] = "--all";
+ if (dry_run)
+ argv[argc++] = "--dry-run";
if (force)
argv[argc++] = "--force";
if (receivepack)
@@ -147,6 +149,10 @@ int cmd_push(int argc, const char **argv, const
char *prefix)
all = 1;
continue;
}
+ if (!strcmp(arg, "--dry-run")) {
+ dry_run = 1;
+ continue;
+ }
if (!strcmp(arg, "--tags")) {
add_refspec("refs/tags/*");
continue;
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index ca46aaf..4fbd5b1 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -244,4 +244,14 @@ test_expect_success 'push with colon-less
refspec (4)' '
'
+test_expect_success 'push with dry-run' '
+
+ mk_test heads/master &&
+ cd testrepo &&
+ old_commit=$(git show-ref -s --verify refs/heads/master) &&
+ cd .. &&
+ git push --dry-run testrepo &&
+ check_push_result $old_commit heads/master
+'
+
test_done
--
1.5.2.5
^ permalink raw reply related
* Re: git branch performance problem?
From: Linus Torvalds @ 2007-10-10 23:39 UTC (permalink / raw)
To: hanwen; +Cc: Lars Hjemli, git
In-Reply-To: <f329bf540710101430i63926b25q7d55976af96b891d@mail.gmail.com>
On Wed, 10 Oct 2007, Han-Wen Nienhuys wrote:
>
> The way I solved that, was to have both repositories pointing to each
> other, using alternates.
Ouch. Double un-good. Not a good idea. Especially not if you do
development in both and pull and push between them.
What will happen is that if you do alternates pointing both ways, you
basically end up having a "shared pool of objects". So it's pretty much
equivalent to just using a shared object directory, and it has *exactly*
the same issues with object reachability and references: you have a shared
pool of objects, but you only ever see *one* set of references, so garbage
collection cannot work - because it will always see just a subset of the
real references, while it sees essentially all objects.
> could it be that GC does not handle cyclic alternates correctly?
It's not about cyclic per se: it's about the fact that GC will do garbage
collection based on reachability with the local references.
Which is normally fine. It's normally fine, because the object tree is
"local" too. But when doing alternates:
- the tree that is being used as an alternate *has* to be totally stable.
It must *never* have been re-based, or have any GC'able objects in the
first place. IOW, doing a "git gc" on it will be safe, because there is
no way any objects that the other alternate depends on could be pruned.
- You definitely must *not* do a two-way alternate, because that violates
another rule: the rule that the "alternate base" (which is now *both*
of the repositories) is self-sufficient. Since they both point to each
other, there's no way to know whether they are self-sufficient or not:
they may be re-using each others objects *and* packs!
And in the above, the "*and* packs" is important, and probably the cause
of your problems. Because "git repack -a -d -l" (which is what "git gc"
does) will always gather up any loose objects even from remote sites, but
the "-l" means that it will not do so for alternate packed objects.
So what happens is that if one of the repositories can reach some object
that is in a pack in the other repository, "git gc" will still *leave* it
dependent on a pack in the other repository. But maybe that object isn't
even reachable in the other repo any more (for whatever reason - a rebase,
whatever), then when you repack the other repository, now all the packs
will be replaced by one new pack - and the one new pack will only contain
the objects reachable from the other repo.
IOW: alternates are dangerous. A shared object directory is dangerous. You
should basically only do it under very controlled circumstances, and
otherwise you should use either hardlinks or if you want added safety,
totally separate repositories.
Basically, here's an example of badness, with A and B being repos that
point to each other.
- do something in A
- pull it into B - this leaves the objects in A, because of the
alternates link.
- rebase A
- "git gc" in A: this removes unreachable objects from A, and now B is
screwed.
So the rule really is: never *ever* do anything but fast-forward in a repo
that is an alternate for another one. If you do a circular link, I think
it's still safe if you follow that rule, but now obviously the rule holds
for *both* repos (and quite frankly, I'd worry so much that I'd never do
it even then).
There should be another rule too: git on its own is not a backup system.
You can use git *as* a backup system, but you need to do so by mirroring
the whole repository, and not on the same disk.
(ie, for me, git *is* a backup system, but that's only because I push my
repos to other sites - a single git repo on its own has zero redundancy)
Linus
^ permalink raw reply
* [PATCH] git-gc: by default use safer "-A" option to repack when not --prune'ing
From: Brandon Casey @ 2007-10-10 23:49 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
This makes use of repack's new "-A" option which does not drop packed
unreachable objects. This makes git-gc safe to call at any time,
particularly when a repository is referenced as an alternate by
another repository.
git-gc --prune will use the "-a" option to repack instead of "-A", so
that packed unreachable objects will be removed.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
builtin-gc.c | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/builtin-gc.c b/builtin-gc.c
index 23ad2b6..779245b 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -26,7 +26,7 @@ static int gc_auto_pack_limit = 20;
#define MAX_ADD 10
static const char *argv_pack_refs[] = {"pack-refs", "--all", "--prune", NULL};
static const char *argv_reflog[] = {"reflog", "expire", "--all", NULL};
-static const char *argv_repack[MAX_ADD] = {"repack", "-a", "-d", "-l", NULL};
+static const char *argv_repack[MAX_ADD] = {"repack", "-d", "-l", NULL};
static const char *argv_prune[] = {"prune", NULL};
static const char *argv_rerere[] = {"rerere", "gc", NULL};
@@ -143,8 +143,6 @@ static int too_many_packs(void)
static int need_to_gc(void)
{
- int ac = 0;
-
/*
* Setting gc.auto and gc.autopacklimit to 0 or negative can
* disable the automatic gc.
@@ -158,14 +156,10 @@ static int need_to_gc(void)
* we run "repack -A -d -l". Otherwise we tell the caller
* there is no need.
*/
- argv_repack[ac++] = "repack";
if (too_many_packs())
- argv_repack[ac++] = "-A";
+ append_option(argv_repack, "-A", MAX_ADD);
else if (!too_many_loose_objects())
return 0;
- argv_repack[ac++] = "-d";
- argv_repack[ac++] = "-l";
- argv_repack[ac++] = NULL;
return 1;
}
@@ -211,6 +205,16 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
prune = 0;
if (!need_to_gc())
return 0;
+ } else {
+ /*
+ * Use safer (for shared repos) "-A" option to
+ * repack when not pruning. Auto-gc makes its
+ * own decision.
+ */
+ if (prune)
+ append_option(argv_repack, "-a", MAX_ADD);
+ else
+ append_option(argv_repack, "-A", MAX_ADD);
}
if (pack_refs && run_command_v_opt(argv_pack_refs, RUN_GIT_CMD))
--
1.5.3.4.207.g00000
^ permalink raw reply related
* Re: inexplicable failure to merge recursively across cherry-picks
From: Miklos Vajna @ 2007-10-11 0:08 UTC (permalink / raw)
To: David Brown; +Cc: Linus Torvalds, martin f krafft, git discussion list
In-Reply-To: <20071010154831.GA19226@old.davidb.org>
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
[ ehh, sorry for my previous mail, i must be doing something wrong.. ]
On Wed, Oct 10, 2007 at 08:48:31AM -0700, David Brown <git@davidb.org> wrote:
> There is a darcs-git project that tries to do the darcs things on top of
> git.
actually it's broken, according to its author:
http://www.mail-archive.com/darcs-users@darcs.net/msg03161.html
though i loved darcs, but yes - it scales horribly
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-gc: by default use safer "-A" option to repack when not --prune'ing
From: Johannes Schindelin @ 2007-10-11 0:12 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <470D6509.5020607@nrlssc.navy.mil>
Hi,
On Wed, 10 Oct 2007, Brandon Casey wrote:
> static int need_to_gc(void)
> {
> - int ac = 0;
> -
> /*
> * Setting gc.auto and gc.autopacklimit to 0 or negative can
> * disable the automatic gc.
> @@ -158,14 +156,10 @@ static int need_to_gc(void)
> * we run "repack -A -d -l". Otherwise we tell the caller
> * there is no need.
> */
> - argv_repack[ac++] = "repack";
> if (too_many_packs())
> - argv_repack[ac++] = "-A";
> + append_option(argv_repack, "-A", MAX_ADD);
> else if (!too_many_loose_objects())
> return 0;
> - argv_repack[ac++] = "-d";
> - argv_repack[ac++] = "-l";
> - argv_repack[ac++] = NULL;
> return 1;
> }
>
This is a nice cleanup, but it does not belong in this patch.
> @@ -211,6 +205,16 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
> prune = 0;
> if (!need_to_gc())
> return 0;
> + } else {
> + /*
> + * Use safer (for shared repos) "-A" option to
> + * repack when not pruning. Auto-gc makes its
> + * own decision.
> + */
> + if (prune)
> + append_option(argv_repack, "-a", MAX_ADD);
> + else
> + append_option(argv_repack, "-A", MAX_ADD);
> }
>
> if (pack_refs && run_command_v_opt(argv_pack_refs, RUN_GIT_CMD))
To use the append_option() function, you need to make sure that the argv
has enough space, so I suggest adding another NULL to argv_repack[]. This
is enough, since you only ever add one option. But you should mention it
somewhere, probably above the definition of argv_repack[].
Other than that: I think your patch makes tons of sense; much better than
what I tried to cobble together with the cyclic alternates detection.
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