* Re: [PATCH] git-cvsserver: detect/diagnose write failure, etc.
From: Junio C Hamano @ 2007-07-11 21:52 UTC (permalink / raw)
To: Jim Meyering; +Cc: git, Frank Lichtenheld
In-Reply-To: <87vecx4tel.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> Beware: in some contexts (when running as server), one must
> not "die", but rather return an "error" indicator to the client.
> I did that in the second hunk. However, I haven't carefully
> audited the others, and so, some of the "die" calls I added may
> end up killing the server, when a gentler failure is required.
>
> I've just looked, and can confirm that my change to req_Modified
> (first hunk) is wrong. It should not die. Rather, it should probably
> do something like the "print "E ... in hunk#2. Ideally, someone
> would write a test to exercise code like this, to make sure it works.
>
> Jim
> diff --git a/git-cvsserver.perl b/git-cvsserver.perl
> index 5cbf27e..8d8d6f5 100755
> --- a/git-cvsserver.perl
> +++ b/git-cvsserver.perl
> @@ -644,7 +644,7 @@ sub req_Modified
> $bytesleft -= $blocksize;
> }
>
> - close $fh;
> + close $fh or die "Failed to write temporary, $filename: $!";
True; dying is not appropriate here.
> @@ -901,8 +901,13 @@ sub req_update
> # projects (heads in this case) to checkout.
> #
> if ($state->{module} eq '') {
> + my $heads_dir = $state->{CVSROOT} . '/refs/heads';
> + if (!opendir HEADS, $heads_dir) {
> + print "E [server aborted]: Failed to open directory, $heads_dir: $!\n"
> + . "error\n";
> + return 0;
> + }
> print "E cvs update: Updating .\n";
> - opendir HEADS, $state->{CVSROOT} . '/refs/heads';
> while (my $head = readdir(HEADS)) {
> if (-f $state->{CVSROOT} . '/refs/heads/' . $head) {
> print "E cvs update: New directory `$head'\n";
Hmph. The clients get no entries in the listing either way, but
I would say this is an improvement.
> @@ -1754,7 +1759,9 @@ sub req_annotate
> # git-jsannotate telling us about commits we are hiding
> # from the client.
>
> - open(ANNOTATEHINTS, ">$tmpdir/.annotate_hints") or die "Error opening > $tmpdir/.annotate_hints $!";
> + my $a_hints = "$tmpdir/.annotate_hints";
> + open(ANNOTATEHINTS, '>', $a_hints)
> + or die "Failed to open '$a_hints' for writing: $!";
> for (my $i=0; $i < @$revisions; $i++)
> {
> print ANNOTATEHINTS $revisions->[$i][2];
Hmph, we seem to have:
$log->warn("Error in annotate output! LINE: $_");
print "E Annotate error \n";
which suggest me that throwing "E error" at the client and
returning might be better?
> @@ -1765,11 +1772,11 @@ sub req_annotate
> }
>
> print ANNOTATEHINTS "\n";
> - close ANNOTATEHINTS;
> + close ANNOTATEHINTS or die "Failed to write $a_hints: $!";
>
> - my $annotatecmd = 'git-annotate';
> - open(ANNOTATE, "-|", $annotatecmd, '-l', '-S', "$tmpdir/.annotate_hints", $filename)
> - or die "Error invoking $annotatecmd -l -S $tmpdir/.annotate_hints $filename : $!";
> + my @cmd = (qw(git-annotate -l -S), $a_hints, $filename);
> + open(ANNOTATE, "-|", @cmd)
> + or die "Error invoking ". join(' ',@cmd) .": $!";
> my $metadata = {};
> print "E Annotations for $filename\n";
> print "E ***************\n";
Likewise...
> @@ -1996,12 +2003,12 @@ sub transmitfile
> {
> open NEWFILE, ">", $targetfile or die("Couldn't open '$targetfile' for writing : $!");
> print NEWFILE $_ while ( <$fh> );
> - close NEWFILE;
> + close NEWFILE or die("Failed to write '$targetfile': $!");
> } else {
> print "$size\n";
> print while ( <$fh> );
> }
> - close $fh or die ("Couldn't close filehandle for transmitfile()");
> + close $fh or die ("Couldn't close filehandle for transmitfile(): $!");
> } else {
> die("Couldn't execute git-cat-file");
> }
Ok.
> @@ -2501,17 +2508,14 @@ sub update
> if ($parent eq $lastpicked) {
> next;
> }
> - open my $p, 'git-merge-base '. $lastpicked . ' '
> - . $parent . '|';
> - my @output = (<$p>);
> - close $p;
> - my $base = join('', @output);
> + my $base = safe_pipe_capture('git-merge-base',
> + $lastpicked, $parent);
> chomp $base;
> if ($base) {
> my @merged;
> # print "want to log between $base $parent \n";
> open(GITLOG, '-|', 'git-log', "$base..$parent")
> - or die "Cannot call git-log: $!";
> + or die "Cannot call git-log: $!";
> my $mergedhash;
> while (<GITLOG>) {
> chomp;
Ok.
^ permalink raw reply
* Re: test suite fails if sh != bash || tar != GNU tar
From: Junio C Hamano @ 2007-07-11 21:43 UTC (permalink / raw)
To: David Frech; +Cc: Junio C Hamano, Johannes Schindelin, Linus Torvalds, git
In-Reply-To: <7154c5c60707111433r64ae5109o314778655cbc017e@mail.gmail.com>
"David Frech" <david@nimblemachines.com> writes:
> One issue is that my server is on dynamic IP, and my lame ISP (the
> local telco) doesn't give me a proper SMTP relay - they want us to
> send our mail via HTTP to MSN! Completely lame.
>
> So sending mail can be an issue, if the receiver blocks mail from dynamic IPs.
I think I heard gmail has incoming SMTP for its subscribers, and
I would not be surprised if other free e-mail providers have the
same. Perhaps you can use one of them for this purpose?
^ permalink raw reply
* Re: test suite fails if sh != bash || tar != GNU tar
From: David Frech @ 2007-07-11 21:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Linus Torvalds, git
In-Reply-To: <7v7ip64opa.fsf@assigned-by-dhcp.cox.net>
On 7/11/07, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> I'll see what I can do. As I'm planning on running git on both FreeBSD
> >> and DragonFly for the forseeable future, and plan to track git's
> >> evolution (running stable releases if not more bleeding-edge code), I
> >> can run the test suite every time I build a new git.
> >
> > If you want to, I can help you setting up a nightly cron job to fetch what
> > is the current "next", run the tests, and report failures by email.
>
> Wow. Nightly builds of 'next' on various platforms would
> actually be quite useful, especially from non Linux and non bash
> world.
I found and fixed the shell issues. Once I've got a "fix" for tar I'll
send a patch. I think the BSD sh has a bug wrt to negating the return
code from a pipeline.
I'd be happy to do a nightly build on my DragonFly box, and that
should catch anything that also doesn't work for FreeBSD. The failure
modes were exactly the same - though the DFly box has an additional
iconv-related problem (with git-mailinfo) that I still haven't tracked
down...
Is there a canned script to get me started?
One issue is that my server is on dynamic IP, and my lame ISP (the
local telco) doesn't give me a proper SMTP relay - they want us to
send our mail via HTTP to MSN! Completely lame.
So sending mail can be an issue, if the receiver blocks mail from dynamic IPs.
- David
--
If I have not seen farther, it is because I have stood in the
footsteps of giants.
^ permalink raw reply
* Re: finding the right remote branch for a commit
From: Johannes Schindelin @ 2007-07-11 21:26 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list, Matthias Lederhofer
In-Reply-To: <20070710144907.GA324@piper.oerlikon.madduck.net>
Hi,
On Tue, 10 Jul 2007, martin f krafft wrote:
> I am trying to figure out a way to store ~/.etc in git. With SVN,
> I would have a .etc repository for each machine, which would use
> svn:externals to reference locations of the various subdirectories,
> which SVN would then pull and assemble. Thus, my ~/.etc might be
>
> ~/.etc
> ~/.etc/ssh [svn+ssh://svn.madduck.net/priv/etc/ssh]
> ~/.etc/vim [svn+ssh://svn.madduck.net/pub/etc/vim]
> ...
>
> [...]
>
> Thus, the vim repository might look like this:
>
> .etc/
> |-- vim/
> | `-- rc.vim
> `-- .vimrc -> .etc/vim/rc.vim
>
> and the ssh configuration might be
>
> .etc/
> |-- ssh/
> | |-- config
> | `-- authorized_keys
> `-- .ssh -> .etc/ssh/
Okay, after discussing this for a bit on IRC, here is what I would do (I
already said this on IRC, but the mailing list is really the better medium
for this):
I would actually rename .etc/ into gits/, because it is not a directory
containing settings, but a directory containing repositories.
Then I would create bare repositories gits/vim.git/, gits/ssh.git/,
gits/mutt.git/, etc. but as soon as I created them, I would make them
"unbare", i.e. "git config core.bare false".
Everytime I would work on, say, .vimrc, I would say
"--git-dir=$HOME/gits/vim.git", or maybe even make an alias in
$HOME/.gitconfig, which spares me that:
$ git config --global vim '!git --git-dir=$HOME/gits/vim.git'
Then I could see the status with
$ git vim status
Come to think of it, this is maybe what I would have done, but it appears
to me that this is the _ideal_ use case for worktree:
In $HOME/gits:
$ mkdir vim.git && cd vim.git
$ git --work-tree=$HOME init
$ cat >> info/exclude < EOF
*
!/.vimrc
EOF
Then you could do all Git operations like push, fetch, pull, log in
$HOME/gits/vim.git, and all editing in $HOME.
At least that is the theory.
In practice, and I consider these all bugs, it does not work:
- you have to say
$ git --work-tree=$HOME --bare init
which is a bit counterintuitive. After all, it is _not_ a bare
repository. The whole purpose of worktree, as far as I understand, is
to have a _detached_ repository, which would otherwise be called bare.
- $ git status
does not do what you would expect: it fails, telling you that it needs a
work tree, of all things. You can say (tongue-in-cheek)
$ (export GIT_DIR="$(pwd)" && cd "$(git config core.worktree)" &&
git status)
So, git knows about the location of the working tree, but just ignores
that.
- In the case that you forget to set GIT_DIR, you better not have any
.git/ repository in $HOME/ or $HOME/gits/, because it will pick up that
instead! Even if you are _inside_ a detached git directory!
So you better not try some games like this in a subdirectory of your
local git.git repository. It is a fine way to get completely confused.
And certainly do _not_ do something like "git reset --hard <branch>"
there.
- Of course, it would be nice if something like that worked:
$ cd $HOME/gits/vim.git
$ git add $HOME/.vimrc
But it does not work, because it wants to _be_ in the work tree. Of
course, you have to specify the GIT_DIR again, because the working tree
does not know about the location of the repository, but vice versa.
Those are serious bugs. Matthias, any idea how to fix them?
Ciao,
Dscho
^ permalink raw reply
* Re: test suite fails if sh != bash || tar != GNU tar
From: Junio C Hamano @ 2007-07-11 21:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Frech, Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0707111209160.4516@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I'll see what I can do. As I'm planning on running git on both FreeBSD
>> and DragonFly for the forseeable future, and plan to track git's
>> evolution (running stable releases if not more bleeding-edge code), I
>> can run the test suite every time I build a new git.
>
> If you want to, I can help you setting up a nightly cron job to fetch what
> is the current "next", run the tests, and report failures by email.
Wow. Nightly builds of 'next' on various platforms would
actually be quite useful, especially from non Linux and non bash
world.
^ permalink raw reply
* Re: --ignore-invalid flag to git log et al.?
From: Junio C Hamano @ 2007-07-11 21:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18068.34542.502048.222112@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> What would you think about a --ignore-invalid flag for things like git
> rev-list and git log, to tell it to ignore any refs on the command
> line that are not valid objects?
>
> Currently there is a buglet in gitk where if a user puts some sort of
> ref on the command line, and then makes the ref invalid (e.g. by
> deleting the ref if it is a head or tag, or doing a git prune if it is
> a sha1 ID with no head/tag pointing to it), and then does "Update" in
> gitk, it will get an error because of the now-invalid ref. (Yes, this
> is a bit of a corner case, but I have had a user point out this
> behaviour to me.) With a --ignore-invalid flag, gitk could use this
> when doing "Update" to avoid the error.
I suspect a much less corner case schenario is an old saved view
where you used to care about "master..experimental -- gitweb/",
but now you are done with gitweb experiments and got rid of the
branch. Then choosing that view would say "experimental? what
are you talking about?".
I wonder what the "--ignore-invalid" option should do. If it
silently ignores, the command line to rev-list from the saved
view would become "^master -- gitweb" and the user is left with
emptiness without any indication of errors. Is that a better
behaviour? I would think not. Giving results from a command
that is different from what the user thought is done without
telling the user is not very nice, so I think you would instead
need "--error-on-invalid".
> An alternative would be to have some way to validate refs. I don't
> know how to do that efficiently. I think I would not want to have to
> do a fork/exec for every ref that I wanted to check.
Is it a possibility to let the rev-list do its job when there is
no error, but catch the error if it does not understand the
command line, because of a revision that is now made invalid,
and then in the error path validate the revs one by one? At
that point in the error path you do not particularly care about
the efficiency I would think.
^ permalink raw reply
* Re: Installation failure caused by CDPATH environment variable
From: Junio C Hamano @ 2007-07-11 21:26 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <9693D8E9-6F11-4AA1-AFCA-7E8456FA6420@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> install: all
> $(INSTALL) -d -m755 '$(DESTDIR_SQ)$(template_dir_SQ)'
> - (cd blt && $(TAR) cf - .) | \
> + cd blt && $(TAR) cf - . | \
> (cd '$(DESTDIR_SQ)$(template_dir_SQ)' && $(TAR) xf -)
> + cd -
Actually I suspect replacing the "cd blt" in the original with
"cd ./blt", without changing anything else, would squelch the
CDPATH problem.
We could write it as "$(TAR) Ccf blt - ." if we can rely on the
'C' option, but I suspect it is a GNU extension. Does anybody
have POSIX.1 handy?
^ permalink raw reply
* Re: Hook after pull ?
From: Junio C Hamano @ 2007-07-11 21:26 UTC (permalink / raw)
To: Alex Riesen; +Cc: Claudio Scordino, git, Johannes.Schindelin, Sam Vilain
In-Reply-To: <20070711183341.GA2798@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Claudio Scordino, Wed, Jul 11, 2007 17:29:19 +0200:
>> >>If no, does exist any easy way of creating such hook ?
>> >
>> >What for? What do you want to do?
>> >
>> I just need my script to be called after a pull. My script just sends an
>> email saying that the repository has been pulled (I already did it for the
>> push).
>
> Ach, on _remote_ repo. Where it is _pulled_from_.
> There are none. You can catch log output of git-daemon, but...
> Isn't it a bit extreme? A fetch (part of a pull) is *very* common
> operation, sometime you'll get a *real* lot of mail.
>
> P.S. BTW, there is no hooks for pull in local (where it is pulled
> into): it is not needed, you already control everything what happens.
I am not sure I am reading this exchange correctly, but I think
Claudio wants to say
$ git pull repo.or.cz:somebody/project.git/ the-branch
and have it automatically send e-mail to the somebody (obviously
the hook script needs to have a mapping from the repository to
whom to notify). As the daemon side cannot tell if the local is
only fetching (and possibly discarding the result) or pulling
(resulting in a merge), I do not think it is reasonable to do
the hooking on the remote side. It has to be done on the local
if ever.
As you said, the local side has all the control, so in the
strictest sense there is no need for post-* hook, but we do
support a few hooks for local operations, such as post-commit.
(Sam Vilain CC'ed as he wanted to have hooks during and after a
merge).
I suspect that a post merge hook (that also is called in
fast-forward case) would be a good thing to have if people would
want to do this kind of thing often. The hook most likely wants
to get the ORIG_HEAD and the updated HEAD as parameters, and can
act differently based on the nature of the merge (e.g. was it
fast-forward, was it a merge between the commits made by the
same committer as myself, etc.)
^ permalink raw reply
* Re: git-rm isn't the inverse action of git-add
From: Junio C Hamano @ 2007-07-11 21:26 UTC (permalink / raw)
To: Jan Hudec; +Cc: Jakub Narebski, git
In-Reply-To: <20070711185644.GA3069@efreet.light.src>
Jan Hudec <bulb@ucw.cz> writes:
> If index matches any of that, but the working tree version does not match any
> parent, the index entry should be removed (which currently isn't -- that's
> the proposed change), but the file left in wokring tree. That would make
> git-add + git-rm get you right back where you started, with nothing in index
> and unversioned file in working tree.
Don't think of 'rm' as inverse of 'add'. That would only
confuse you.
A natural inverse of 'add' is 'un-add', and that operation is
called 'rm --cached', because we use that to name the option to
invoke an "index-only" variant of a command when the command can
operate on index and working tree file (e.g. "diff --cached",
"apply --cached").
A life of a file that does _not_ make into a commit goes like
this:
[1]$ edit a-new-file
This is 'create', not 'add'. git is not involved in this step.
[2]$ git add a-new-file
This is 'add'; place an existing file in the index. When you do
not want it in the index, you 'un-add' it.
[3]$ git rm --cached a-new-file
This removes the entry from the index, without touching the
working tree file. If you do not want that file at all (as
opposed to, "I am making a series of partial commits, and the
addition of this path does not belong to the first commit of the
series, so I am unstaging"), this is followed by
[4]$ rm -f a-new-file
Again, git is not involved in this step.
The thing is, people sometimes want to have steps 3 and 4
combined, and it meshes well with the users' expectation when
they see the word "rm". Think of "git rm" without "--cached" as
a shorthand to do 3 and 4 in one go to meet that expectation.
Obviously, we cannot usefully combine steps 1 and 2. We could
have "git add --create a-new-file" launch an editor to create a
new file, but that would not be very useful in practice.
The fact that steps 3 and 4 can be naturally combined, but steps
1 and 2 cannot be, makes "add" and "rm" not inverse of each
other.
^ permalink raw reply
* Re: [PATCH] git-merge: run commit hooks when making merge commits
From: Junio C Hamano @ 2007-07-11 21:26 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <11841499201242-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> writes:
> git-merge.sh was not running the commit hooks, so run them in the two
> places where we go to commit.
>
> Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
> ---
> Not sure if it should call these or some specialist hooks, like
> git-am does.
I suspect some people have pre-commit scripts that have been
meant to catch style errors for their own commits, and invoking
that on merge would wreak havoc --- there is not much you can do
if you want to get the work done by somebody else at that point.
Introducing a new pre-merge-commit hook would probably be safer;
if one wants to use the same check as one's pre-commit does, the
new hook in the repository can exec $GIT_DIR/hooks/pre-commit.
The commit-msg hook I have no clue what people usually use it
for in the real world, but a merge commit message tends to be
quite different from the message you would give to your own
straight line commits, so custom reformatting rules people have
in commit-msg hook may not apply to merge commit messages.
Same for post-commit, but probably to lessor extent, as I
suspect people use that mostly for per-commit notification
mechanism.
^ permalink raw reply
* Re: pushing changes to a remote branch
From: Junio C Hamano @ 2007-07-11 21:26 UTC (permalink / raw)
To: Jan Hudec; +Cc: Brian Gernhardt, Jeff King, git discussion list
In-Reply-To: <20070711193152.GC3069@efreet.light.src>
Jan Hudec <bulb@ucw.cz> writes:
>> $ git checkout origin/master
>> Note: moving to "origin/master" which isn't a local branch
>> If you want to create a new branch from this checkout, you may do so
>> (now or later) by using -b with the checkout command again. Example:
>> git checkout -b <new_branch_name>
>> HEAD is now at f4855d4... 1
>
> The problem of this warning is, that it does not actually say anything about
> detached and that potential commit won't update the ref being checked out.
"Being detached" is a rather geekish synonym to "which isn't a
local branch", isn't it?
^ permalink raw reply
* Re: [PATCH] gitweb: snapshot cleanups & support for offering multiple formats
From: Junio C Hamano @ 2007-07-11 21:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Matt McCutchen, git, Petr Baudis, Luben Tuikov
In-Reply-To: <200707111755.50018.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> I'm not sure if we want to store whole 'application/x-gzip' or only
> 'x-gzip' part of mime type, and if we want to store compressor as
> '| gzip' or simply as 'gzip'.
>
>> This however will break people's existing gitweb configuration,
>> so if we were to do this it should be post 1.5.3, I would say.
>
> This would break not only existing _gitweb_ configuration (when
> gitweb admin installs new gitweb it isn't that hard to correct
> gitweb config), but also git _repositories_ config: gitweb.snapshot
> no longer work as it worked before, for example neither 'gzip'
> nor 'bzip2' values work anymore ('zip' doesn't stop working).
I realized after seeing your other message on this patch that
this can be done while retaining backward compatibility, as you
suggested. Matt, does Jakub's suggestion make sense to you?
^ permalink raw reply
* Re: [PATCH] gitweb: New cgi parameter: filter
From: Jakub Narebski @ 2007-07-11 21:19 UTC (permalink / raw)
To: git
In-Reply-To: <20070708013543.GD29994@genesis.frugalware.org>
[Cc: git@vger.kernel.org]
Miklos Vajna wrote:
> + ((defined $filter and $filter == "nomerges") ? ("--no-merges") : ()),
Shouldn't it be '$filter eq "nomerges"' instead?
Besides, I'd rather have generalized way to provide additional options
to git commands, like '--no-merges' for RSS and Atom feeds, log, shortlog
and history views, '-C' for commitdiff view, '--remove-empty' for history
view for a file, perhaps even '-c' or '--cc' for commitdiff for merges
instead of abusing 'hp' argument for that.
But that doesn't mean that this patch should be not applied... it doesn't
mean it should be applied neither ;-)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: 'git log FILE' slow
From: Linus Torvalds @ 2007-07-11 21:03 UTC (permalink / raw)
To: Yakov Lerner; +Cc: Git Mailing List
In-Reply-To: <f36b08ee0707111333q38004cb5x152f25e2055e2796@mail.gmail.com>
On Wed, 11 Jul 2007, Yakov Lerner wrote:
>
> 'git-log FILE' takes 10-13 sec. What can I do to identify
> the reason ? 'git log >/dev/null' takes 0.1 sec (cached).
"git log FILE" is simply *fundamnentally* much more expensive than "git
log".
There's nothing to "identify". Both go through the whole log of the
project, but "git log file" has to look at every tree, and see where the
file actually changed.
However, "fundmanetally more expensive" doesn't actually mean that it
should be that slow. I suspect that your archive is not packed, so you
have probably thousands of individual objects in the filesystem, and are
slowing down your git usage totally needlessly.
So do
git gc
on the archive, and you'll probably be happy.
That said, 10-13 seconds *can* be valid for a really big archive, ie
that's the kinds of times you might eventually expect for something like
the full KDE archive (if they don't split the subprojects up).
I doubt that's it.
> On the cloned copy, the times are approximately same.
This is a big clue. Cloning will generate a new pack.
> The 'git-count-objects -v' shows:
>
> count: 9830
> size: 241412
> in-pack: 12080
> packs: 18
> prune-packable: 188
> garbage: 0
Tons of packs, and lots of unpacked objects.
Just get used to doing "git gc" once a week (or maybe once a month - I
guess you've not done it at all?)
> The strace shows only thousands of sbrk during the 10-13 sec time
> (after some initial I/O). Ltrace, I was not able to complete, takes too much.
Hmm. I'd have expected to see some "stat()/open()" calls if it was really
just about packing, so I'm a bit surprised, but I really do think you
should just garbage collect your packs. Having 12k objects in 18 packs is
ridiculous - each pack must be pitifully small.
Here's my kernel archive:
[torvalds@woody linux]$ git count-objects -v
count: 364
size: 2328
in-pack: 506495
packs: 12
prune-packable: 5
garbage: 0
ie I have forty times the objects, in fewer packs than you do (and most of
it is in one big one). After a "git gc", it looks like
[torvalds@woody linux]$ git count-objects -v
count: 0
size: 0
in-pack: 506090
packs: 1
prune-packable: 0
garbage: 0
and everything is happier (not that it was unhappy before either, but
mine was much better packed than yours was).
Linus
^ permalink raw reply
* Re: cg switch -l doesn't work when branches point to the same commit
From: Bill Lear @ 2007-07-11 20:44 UTC (permalink / raw)
To: Sean; +Cc: Alex Riesen, Bradford Smith, git, pasky
In-Reply-To: <20070711163446.cb8d9c52.seanlkml@sympatico.ca>
On Wednesday, July 11, 2007 at 16:34:46 (-0400) Sean writes:
>On Wed, 11 Jul 2007 15:36:39 +0200
>"Alex Riesen" <raa.lkml@gmail.com> wrote:
>
>> Cogito is unmaintained ATM.
>
>Wonder who maintains the http://git.kernel.org site? The front page
>there still suggests the use of Cogito.
Petr Baudis, CCd here.
Bill
^ permalink raw reply
* Re: cg switch -l doesn't work when branches point to the same commit
From: Sean @ 2007-07-11 20:34 UTC (permalink / raw)
To: Alex Riesen; +Cc: Bradford Smith, git
In-Reply-To: <81b0412b0707110636u77b56f1biccb221489933972a@mail.gmail.com>
On Wed, 11 Jul 2007 15:36:39 +0200
"Alex Riesen" <raa.lkml@gmail.com> wrote:
> Cogito is unmaintained ATM.
Wonder who maintains the http://git.kernel.org site? The front page
there still suggests the use of Cogito.
Sean
^ permalink raw reply
* Re: Build error with qgit4
From: Jan Hudec @ 2007-07-11 20:33 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: Marco Costalba, Git Mailing List
In-Reply-To: <cc723f590707110919i7def2fbal94b1a437f189040@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 961 bytes --]
On Wed, Jul 11, 2007 at 21:49:25 +0530, Aneesh Kumar wrote:
> lude/qt4/QtGui -I/usr/include/qt4 -I../src -I../build -I../build -o
> ../build/fileview.o fileview.cpp
> ../build/ui_fileview.h: In member function 'void
> Ui_TabFile::setupUi(QWidget*)':
> ../build/ui_fileview.h:63: error: 'class QHBoxLayout' has no member
> named 'setLeftMargin'
> ../build/ui_fileview.h:64: error: 'class QHBoxLayout' has no member
> named 'setTopMargin'
> ../build/ui_fileview.h:65: error: 'class QHBoxLayout' has no member
> named 'setRightMargin'
> ../build/ui_fileview.h:66: error: 'class QHBoxLayout' has no member
> named 'setBottomMargin'
> ../build/ui_fileview.h:71: error: 'class QVBoxLayout' has no member
> named 'setLeftMargin'
That's strange, because the errors are in Qt-generated file when working with
Qt class. Are you sure it uses uic and moc from the same Qt version as qmake
and the headers?
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* 'git log FILE' slow
From: Yakov Lerner @ 2007-07-11 20:33 UTC (permalink / raw)
To: Git Mailing List
[git version 1.5.1.3]
'git-log FILE' takes 10-13 sec. What can I do to identify
the reason ? 'git log >/dev/null' takes 0.1 sec (cached).
On the cloned copy, the times are approximately same.
The 'git-count-objects -v' shows:
count: 9830
size: 241412
in-pack: 12080
packs: 18
prune-packable: 188
garbage: 0
The strace shows only thousands of sbrk during the 10-13 sec time
(after some initial I/O). Ltrace, I was not able to complete, takes too much.
Yakov
^ permalink raw reply
* Re: mtimes of working files
From: Jan Hudec @ 2007-07-11 20:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0707111940080.4516@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
On Wed, Jul 11, 2007 at 19:42:10 +0100, Johannes Schindelin wrote:
> Hi list,
>
> > > > How difficult is it to have script (or maybe existing git option)
> > > > that would make mtimes of all working files equal to time of last
> > > > commit ?
>
> Now I slowly get really curious. Does _anybody_ know a scenario where
> this makes sense?
>
> (No, Eric, there are enough corner cases where your example of a clustered
> webserver breaks down, so I am not fully convinced that this is a useful
> case.)
>
> Anybody enlighten me?
I don't see any case where it would be useful, though I know some version
control systems that provide that feature. I think it is supposed to just be
used for checking which view has newer version.
I first thought the idea had something to do with make, but it will actually
promptly break most build tools, because change to earlier version is
a change too, but they wouldn't detect it.
However I am getting really curious about different thing -- the solution.
Because I think the arguments from keyword expansion discussion apply here
that prevent any *reliable* (you can have unreliable ones just as you can
have unreliable keyword expansion) solution.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Getting version output for a file.
From: Brian Gernhardt @ 2007-07-11 19:48 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86abu3dv9o.fsf@lola.quinscape.zz>
I don't know lisp very well, and elisp not at all, but I can help you
with what command lines would give you the results you might want.
On Jul 11, 2007, at 7:39 AM, David Kastrup wrote:
> (vc-git-previous-version FILE REV)
> Return the version number immediately preceding REV for FILE,
> or nil if there is no previous version.
If you want the last revision where the file was altered, you could
easily use
git rev-list -2 $current_rev -- $file | tail -1
The result would be a SHA-1 of the next commit where the file was
altered.
> (vc-git-next-version FILE REV)
> Return the version number immediately following REV for FILE,
> or nil if there is no previous version.
This is a little more problematic as git doesn't have forward links
in it's history. If you have a ref to start with (HEAD is a good one
to use, if you don't have anything else) you could use a similar
command to the above
git rev-list $ref -- $file | grep -C1 -m1 $current_rev | head -1
If you don't have a ref to start from, you could use --all, but that
may not be what the user expects.
If you want a human readable name for either you could use name-rev.
(Add "| git name-rev --stdin" to the end of the above.) It places a
human readable name after the SHA-1 in parentheses. (example:
"54dadbdb29668fbd51effefd0a0c65d915f5422b (master~3)")
~~ Brian
^ permalink raw reply
* Re: pushing changes to a remote branch
From: Jan Hudec @ 2007-07-11 19:34 UTC (permalink / raw)
To: Sean Kelley; +Cc: git
In-Reply-To: <a2e879e50707102044l864b9dcre5b6fa5893ff4803@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 725 bytes --]
On Tue, Jul 10, 2007 at 22:44:58 -0500, Sean Kelley wrote:
> If you then do a push from that new_branch_name will it create a new
> branch on the remote? I am struggling with just being able to add a
> remote. Create a local branch that maps to the remote. Then
> committing and pushing changes to the remote - all without creating a
> new branch on the remote.
git push takes a refspec, which is local-branch:remote-branch. So you can
push from local branch of any name to remote branch of any other name. You
can also define the relationships in the config, but you'll have to look up
what exactly you should specify in the manuals (of git-push and git-config).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: pushing changes to a remote branch
From: Jan Hudec @ 2007-07-11 19:31 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Jeff King, git discussion list
In-Reply-To: <844FC382-DFB3-4762-93C2-6512612136AC@silverinsanity.com>
[-- Attachment #1: Type: text/plain, Size: 880 bytes --]
On Tue, Jul 10, 2007 at 14:10:01 -0400, Brian Gernhardt wrote:
> Indeed, in master, git outputs a hint to that when you checkout the remote
> branch.
>
> $ git checkout origin/master
> Note: moving to "origin/master" which isn't a local branch
> If you want to create a new branch from this checkout, you may do so
> (now or later) by using -b with the checkout command again. Example:
> git checkout -b <new_branch_name>
> HEAD is now at f4855d4... 1
The problem of this warning is, that it does not actually say anything about
detached and that potential commit won't update the ref being checked out.
> Perhaps git-commit should also also output a warning? "Commit made on
> detached HEAD. Use "git branch <new_branch_name>" to save your commit"?
> That's bad wording, but the idea is there.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: pushing changes to a remote branch
From: Jan Hudec @ 2007-07-11 19:29 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <20070710143614.GA29681@piper.oerlikon.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]
On Tue, Jul 10, 2007 at 16:36:14 +0200, martin f krafft wrote:
> git checkout origin/vim
> Note: moving to "origin/vim" which isn't a local branch
There is more to that message, no? However, it only says "Head is now at
<commit-id>", which does not really indicate, that the HEAD has been
"detached". This means that it now contains a commit-id rather than name of
some branch.
Git detaches head whenever you check out, without -b option, anything other
than branch (without it's refs/heads prefix). If you than check out a branch,
you can't see the commit on any branch anymore. However, you can still access
it in reflog, ie. via expressions like HEAD@{1} or HEAD@{1 hour ago}.
You should also be able to:
git push origin HEAD:vim
after the commit, and even (I didn't try it, but documentation seems to claim
it should work):
git push origin HEAD@{1}:vim
if you already changed HEAD more.
You can see this "metahistory" of HEAD via:
git reflog
which is shorthand for git reflog show HEAD
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: how to combine two clones in a collection
From: martin f krafft @ 2007-07-11 19:22 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <Pine.LNX.4.64.0707111929120.4516@racer.site>
[-- Attachment #1: Type: text/plain, Size: 3156 bytes --]
Thanks, Johannes, for this explanation. I actually had to prod him
on IRC a bit more until I understood, but the result is now
available on my blog:
http://blog.madduck.net/vcs/2007.07.11_creating-a-git-branch-without-ancestry
[...]
Update: Johannes Schindelin taught me how to do the same without
touching files in .git/:
$ git symbolic-ref HEAD refs/heads/newbranch
[...]
and also addressed the issue which would have all files already
committed to the "master" branch now appear in the git status
output as staged.
This is because the index contains the full copy of a revision of
a file, as it would be if committed at any point. git status shows
the differences between what has been committed, what would be
committed, and what is available in the working tree. Since we
pointed HEAD to nowhere ("newbranch" does not yet exist), the
index and what has been committed (nothing in this case) diverge,
the files are still staged, and thus are scheduled to be part of
the impending commit.
The way to fix this is to remove the index:
$ rm .git/index
This may seem weird, but it works, because git recreates the index
whenever you switch branches:
piper:~> git init-db
Initialized empty Git repository in .git/
piper:~> echo 1 > a; git add a; git commit -m.
Created initial commit e774324: .
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
piper:~> git symbolic-ref HEAD refs/heads/newbranch
piper:~> rm .git/index
piper:~> git status
# On branch newbranch
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# a
nothing added to commit but untracked files present (use "git add" to track)
piper:~> echo 2 > b; git add b; git commit -m.
Created initial commit 54ff342: .
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 b
piper:~> git branch
master
* newbranch
piper:~> git checkout master
fatal: Untracked working tree file 'a' would be overwritten by merge.
piper:~> git checkout -f master
Switched to branch "master"
piper:~> git status
# On branch master
nothing to commit (working directory clean)
piper:~> ls
a
piper:~> git checkout newbranch
Switched to branch "newbranch"
piper:~> git status
# On branch newbranch
nothing to commit (working directory clean)
piper:~> ls
b
As you can see, the creation of the branch is a bit complex, but
once you (forcefully) switched back to master, you can then
freely switch between and commit to them.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"when women love us, they forgive us everything, even our crimes;
when they do not love us, they give us credit for nothing,
not even our virtues."
-- honoré de balzac
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] Function stripspace now gets a buffer instead file descriptors.
From: Johannes Schindelin @ 2007-07-11 19:17 UTC (permalink / raw)
To: Carlos Rica; +Cc: git, Junio C Hamano, Kristian Høgsberg
In-Reply-To: <4695267A.7080202@gmail.com>
Hi,
On Wed, 11 Jul 2007, Carlos Rica wrote:
> @@ -28,52 +26,67 @@ static int cleanup(char *line, int len)
> * Remove empty lines from the beginning and end
> * and also trailing spaces from every line.
> *
> + * Note that the buffer will not be null-terminated.
> + *
> * Turn multiple consecutive empty lines between paragraphs
> * into just one empty line.
> *
> * If the input has only empty lines and spaces,
> * no output will be produced.
> *
> + * If last line has a newline at the end, it will be removed.
> + *
Please let me comment about the rationale for both changes: The
stripspace() function (which this hunk is about) is more useful if it does
not allocate a new buffer, but works in-place.
And since it knows the new length already, it can just as well return the
length, and _not_ NUL terminate (which would mean that we have to
reallocate if we used read_pipe() to get the buffer).
The reason for the missing newline at the end is the same: since we accept
buffers with a missing newline at the end, we would have to reallocate in
that case.
So for the sake of simplicity, we neither NUL-terminate, nor \n terminate
the buffer, and leave that to the callers.
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