* Re: [PATCH] gc --auto: warn garbage collection happens soon
From: Jeff King @ 2011-12-28 18:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7vpqf94r8c.fsf@alter.siamese.dyndns.org>
On Tue, Dec 27, 2011 at 01:52:35PM -0800, Junio C Hamano wrote:
> And if the answer to that tongue-in-cheek question is no, what is the
> reason why the users will not find the messages disturbing, while loathing
> the auto-gc?
>
> I suspect that is because auto-gc takes long time, making the user wait,
> compared to the new message that may be noisy but quick. Perhaps the real
> cure for the disease is not to add the message but to make an auto-gc less
> painful, no?
>
> What are the things we could do to make auto-gc less painful?
>
> Are we doing something that is not necessary in auto-gc that takes time
> but that we can live without doing?
I don't personally find gc all that painful (though maybe that is
because I tend to gc myself and rarely hit the auto-gc), but I have
noticed that git-prune takes by far the most time to run. If you are
just doing an incremental pack, you might be packing only a few thousand
objects and not touching old history at all (and with many cores, the
delta compression flies by). But prune requires running "git rev-list
--objects --all", which takes something like 45 seconds for linux-2.6 on
my fast-ish laptop (and about 23 seconds for git.git).
We could perhaps cut out pruning in the auto-gc case unless there are a
lot of objects left over after the packing phase. It's not worth doing a
full prune to clean up a dozen objects[1]. It probably is if you have a
thousand objects left after packing.
-Peff
[1] Actually, it's not just having objects. You may have just exploded
unreachable objects from a pack, but they are still younger than the
2 week expiration period. Therefore trying to prune them is
pointless, because even if they are unreachable, you won't delete
them. So you really want to say "how many actual candidate objects
do we have for pruning?"
^ permalink raw reply
* Re: [PATCH 1/2] git-svn, perl/Git.pm: add central method for prompting passwords honoring GIT_ASKPASS and SSH_ASKPASS
From: Jakub Narebski @ 2011-12-28 18:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sven Strickroth, git, Jeff King
In-Reply-To: <7vboqt2zm4.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Sven Strickroth <sven.strickroth@tu-clausthal.de> writes:
> I only have a few minor nits, and request for extra set of eyeballs from
> Perl-y people.
>
> > sub _read_password {
> > my ($prompt, $realm) = @_;
> > - my $password = '';
> > - if (exists $ENV{GIT_ASKPASS}) {
> > - open(PH, "-|", $ENV{GIT_ASKPASS}, $prompt);
> > - $password = <PH>;
> > - $password =~ s/[\012\015]//; # \n\r
> > - ...
> > - while (defined(my $key = Term::ReadKey::ReadKey(0))) {
> > - last if $key =~ /[\012\015]/; # \n\r
> > - $password .= $key;
> > - }
> > - ...
> > + my $password = Git->prompt($prompt);
> > $password;
> > }
> > ...
> > +Check if GIT_ASKPASS or SSH_ASKPASS is set, use first matching for querying
> > +user and return answer. If no *_ASKPASS variable is set, the variable is
> > +empty or an error occoured, the terminal is tried as a fallback.
>
> Looks like a description that is correct, but I feel a slight hiccup when
> trying to read the first sentence aloud. Perhaps other reviewers on the
> list can offer an easier to read alternative?
Perhaps
Query user for password with given PROMPT and return answer. It respects
GIT_ASKPASS and SSH_ASKPASS environment variables, with terminal in a
password mode (no echo) as a fallback. Returns undef if it cannot ask
for password.
> > +sub prompt {
> > + my ($self, $prompt) = _maybe_self(@_);
> > + my $ret;
> > + if (exists $ENV{'GIT_ASKPASS'}) {
Wouldn't it be simpler and more resilent to just check for $ENV{'GIT_ASKPASS'}?
Assuming that nobody uses command named '0' it would cover both GIT_ASKPASS
not being set (!exists) and being set to empty value (eq '').
> > + $ret = _prompt($ENV{'GIT_ASKPASS'}, $prompt);
> > + }
> > + if (!defined $ret && exists $ENV{'SSH_ASKPASS'}) {
> > + $ret = _prompt($ENV{'SSH_ASKPASS'}, $prompt);
> > + }
> > + if (!defined $ret) {
> > + print STDERR $prompt;
> > + STDERR->flush;
> > + require Term::ReadKey;
> > + Term::ReadKey::ReadMode('noecho');
> > + while (defined(my $key = Term::ReadKey::ReadKey(0))) {
> > + last if $key =~ /[\012\015]/; # \n\r
> > + $ret .= $key;
I wonder if the last part wouldn't be better to be refactored into
a separate subroutine, e.g. _prompt_readkey.
>
> Unlike the original in _read_password, $ret ($password over there) is left
> "undef" here; I am wondering if "$ret .= $key" might trigger a warning and
> if that is the case, probably we should have an explicit "$ret = '';"
> before going into the while loop.
No that is not a problem. In Perl undefined variable functions as 0 in
numeric context ($foo++), as '' in string context ($foo .= $key), and []
in arrayref context (push @$foo, $key).
> > +sub _prompt {
> > + my ($askpass, $prompt) = @_;
> > + unless ($askpass) {
> > + return undef;
> > + }
>
> Perl gurus on the list might prefer to rewrite this with statement
> modifier as "return undef unless (...);" but I am not one of them.
>
> > + my $ret;
> > + open my $fh, "-|", $askpass, $prompt || return undef;
>
> I am so used see this spelled with the lower-precedence "or" like this
>
> open my $fh, "-|", $askpass, $prompt
> or return undef;
>
> that I am no longer sure if the use of "||" is Ok here. Help from Perl
> gurus on the list?
It is incorrect, which you can check with B::Deparse.
$ perl -MO=Deparse,-p -e 'open my $fh, "-|", $askpass, $prompt || return undef;'
open(my $fh, '-|', $askpass, ($prompt || return(undef)));
Anyway, wouldn't it be simpler and better to use command_oneline or its
backend here?
> > + $ret = <$fh>;
> > + $ret =~ s/[\012\015]//g; # strip \n\r, chomp does not work on all systems (i.e. windows) as expected
>
> The original reads one line from the helper process, removes the first \n
> or \r (expecting there is only one), and returns the result. The new code
> reads one line, removes all \n and \r everywhere, and returns the result.
>
> I do not think it makes any difference in practice, but shouldn't this
> logically be more like "s/\r?\n$//", that is "remove the CRLF or LF at the
> end"?
>
> > + close ($fh);
>
> It seems that we aquired a SP after "close" compared to the
> original. What's the prevailing coding style in our Perl code?
>
> This close() of pipe to the subprocess is where a lot of error checking
> happens, no? Can this return an error?
>
> I can see the original ignored an error condition, but do we care, or not
> care?
If we use command_oneline or its backend we wouldn't have to worry
about this.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] add post-fetch hook
From: Joey Hess @ 2011-12-28 19:30 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <4EFA3833.80409@kdbg.org>
[-- Attachment #1: Type: text/plain, Size: 3821 bytes --]
Johannes Sixt wrote:
> If I read the loop below correctly, you should be able to run it using
> only the functions sha1_to_hex(), strlen() and write_in_full(). This
> would avoid any problems with concurrent calls to xmalloc().
>
> > + int ret;
> > +
> > + for (ref = post_fetch_hook_refs; ref; ref = ref->next) {
> > + strbuf_addstr(&buf, sha1_to_hex(ref->old_sha1));
>
> sha1_to_hex() works with a static buffer. Are you certain that it is not
> called concurrently in the main thread?
Thanks very much for pointing that thread-unsafty out.
Based on that, my current thinking for a generic hook interface is that,
rather than the caller providing an arbitrary "feeder" function that gets
run async, the caller should provide a function that generates a strbuf
containing the stdout for the hook, and then a very simple async writer
can handle the actual writing.
static int feed_hook(int in, int out, void *data)
{
struct strbuf *buf = data;
return write_in_full(out, buf->buf, buf->len) != buf->len;
}
(I assume that write_in_full is safe to be run async?)
I am working on a patch that will involve adding a hook_complex()
and changing hook() to be implemented in terms of it. The header
for that is included below, you should get a very good idea of how
it will work from the data structure.
/*
* This data structure controls how a hook is run.
*/
struct hook {
/* The name of the hook being run. */
const char *name;
/* Parameters to pass to the hook program, not including the name
* of the hook. May be NULL. */
struct argv_array *argv_array;
/* Pathname to an index file to use, or NULL if the hook
* uses the default index file or no index is needed. */
const char *index_file;
/*
* An arbitrary data structure, can be populated and modified to
* communicate between the feeder, reader, and caller of the hook.
*/
void *data;
/*
* A hook can optionally not consume all of its stdin.
* If partial_stdin is 0, it is an error for some stdin not
* to be consumed.
*/
int partial_stdin;
/*
* feeder populates a strbuf with the content to send to the
* hook on its standard input.
*
* May be NULL, if the hook does not consume standard input.
*
* Note that feeder might be run more than once, if multiple
* programs are run as part of a single hook. It should avoid
* taking any actions except for reading from data and generating
* the strbuf. It will *not* be run async, and need not worry
* about contending with other threads.
*/
struct strbuf *(*feeder)(struct hook *hook);
/*
* reader processes the hook's standard output from the handle,
* returning 0 on success, non-zero on failure.
*
* May be NULL, if the hook's stdin is not processed. (It will
* instead be redirected to stderr.)
*
* Note that reader might be run more than once, if multiple
* programs are run as part of a single hook. It should avoid
* taking any actions except for reading from the input handle,
* changing the content of data, and printing any necessary
* warnings. It will *not* be run async, and need not worry
* about contending with other threads.
*/
int (*reader)(struct hook *hook, int handle);
};
extern int run_hook(const char *index_file, const char *name, ...);
extern int run_hook_complex(struct hook *hook);
This design allows for a future where multiple scripts get run for a
single hook. In that case, the feeder and reader functions would get
called repeatedly in a loop, with a data flow like this, where the
reader modifies hook.data, providing the next call of the feeder with
the new data read from the hook script:
feeder | hook_script_1 | reader | feeder | hook_script_2 | reader
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: Possible submodule or submodule documentation issue
From: Jens Lehmann @ 2011-12-28 19:47 UTC (permalink / raw)
To: Bill Zaumen; +Cc: git
In-Reply-To: <1325013859.1987.65.camel@yos>
Am 27.12.2011 20:24, schrieb Bill Zaumen:
> For the 'add' command, the man page for get-submodule states
>
> "<repository> is the URL of the new submodule’s origin repository. This
> may be either an absolute URL, or (if it begins with ./ or ../), the
> location relative to the superproject’s origin repository."
>
> and
>
> "In either case, the given URL is recorded into .gitmodules for use by
> subsequent users cloning the superproject. If the URL is given relative
> to the superproject’s repository, the presumption is the superproject
> and submodule repositories will be kept together in the same relative
> location, and only the superproject’s URL needs to be provided:
> git-submodule will correctly locate the submodule using the relative URL
> in .gitmodules."
>
> Based on that documentation, I tried the following sequence of commands:
>
> git init --bare library.git
> git init --bare library-pkg.git
> git clone library.git
> cd library;
> echo hello > hello
> git add hello
> git commit -m "initial"
> git push origin master
> cd ..
> git clone library-pkg.git
I assume you did forget to add a "cd library-pkg" here.
> echo goodbye > goodbye
> git add goodbye
> git submodule add ./library.git src <FAILS>
With Git 1.7.1 I get the following error message:
fatal: '/tmp/library-pkg.git/library.git' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
Clone of '/tmp/library-pkg.git/library.git' into submodule path 'src' failed
Which is rather what I would have expected: Using "./library.git src"
implies the library living *inside* the "library-pkg.git" repo, not
next to it (and the error message shows that). "../library.git" is the
correct relative path, so the next command works as expected.
> git submodule add ../library.git src <WORKS>
> git commit -a -m "initial pkg"
> git push origin master
>
> The documentation as written suggests that the first use of
> "git submodule add" is the one that should have worked because
> library.git is in the same directory as the origin repository
> library-pgk.git . I didn't try moving the two .git directories
> to a server to see if the behavior is the same in that case (my
> test was using the local file system).
Hmm, the documentation says "the location relative to the
superproject’s origin repository", not the directory containing
it. This means you have to use ".." first to get out of the
repository itself, no?
^ permalink raw reply
* Re: [PATCH] gc --auto: warn garbage collection happens soon
From: Junio C Hamano @ 2011-12-28 20:02 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20111228184000.GA18780@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> [1] Actually, it's not just having objects. You may have just exploded
> unreachable objects from a pack, but they are still younger than the
> 2 week expiration period. Therefore trying to prune them is
> pointless, because even if they are unreachable, you won't delete
> them. So you really want to say "how many actual candidate objects
> do we have for pruning?"
An obvious knee-jerk reaction is "Ugh, if we have very recently repacked,
don't we know what are reachable and what are not already, and use that
knowledge while pruning to avoid traversing everything again?"
My memory around repack, fsck and prune needs refreshing, though, to tell
if that suggestion is feasible.
^ permalink raw reply
* Re: GIT and SSH
From: Thomas Hochstein @ 2011-12-28 11:34 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20111228T091942-66@post.gmane.org>
Reza Mostafid schrieb:
> a.) Does the communication that takes place between a GIT `client` and a remote
> GIT `repository` involve 'ssh' traffic?
Depends on how you do it (as already described by others).
> Our connections here are heavily censored and ssh traffic is suppressed most of
> the time which is why I need to figure out why a simple
>
> $ git clone git://<URL>
>
> command chokes to a halt and freezes most of the time ( the same command when
> executed remotely on our V.P.S. in Europe works flawlessly ).
"git://" uses the git protocol which does not involve SSH.
$ git clone ssh://<URL>
would use SSH.
-thh
^ permalink raw reply
* Re: [PATCH 2/2] git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
From: Junio C Hamano @ 2011-12-28 21:00 UTC (permalink / raw)
To: Sven Strickroth; +Cc: git, Jakub Narebski, Jeff King
In-Reply-To: <4EFAF241.9050806@tu-clausthal.de>
Sven Strickroth <sven.strickroth@tu-clausthal.de> writes:
> Am 28.12.2011 03:41 schrieb Junio C Hamano:
>> I am afraid the extra "Certificate unknown. " prefix may make the prompt
>> way too long to fit on a line on the terminal or in the GUI. Would it be
>> Ok to perhaps add LF to make it a multi-line prompt? Do GUI based helpers
>> make that into a dialog box with multi-line prompt, or do they just barf?
>
> LF is problematic. But we could do $prompt =~ s/\n/ /g; in _prompt()-method.
I actually was hoping that the answer is "it depends on the helper
specified by *_ASKPASS".
In any case, let's not add that extra "Certificate unknown. " prefix at
all to avoid regressions and queue this patch series for real.
After somebody comes up with a way to deal with overlong prompt, building
on top of this series, we can work on making this particular prompt longer
and more descriptive.
^ permalink raw reply
* Re: [PATCH] gc --auto: warn garbage collection happens soon
From: Jeff King @ 2011-12-28 21:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7vfwg41n3p.fsf@alter.siamese.dyndns.org>
On Wed, Dec 28, 2011 at 12:02:18PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > [1] Actually, it's not just having objects. You may have just exploded
> > unreachable objects from a pack, but they are still younger than the
> > 2 week expiration period. Therefore trying to prune them is
> > pointless, because even if they are unreachable, you won't delete
> > them. So you really want to say "how many actual candidate objects
> > do we have for pruning?"
>
> An obvious knee-jerk reaction is "Ugh, if we have very recently repacked,
> don't we know what are reachable and what are not already, and use that
> knowledge while pruning to avoid traversing everything again?"
Especially now that prune has learned about progress reporting, it's
easy to see in "git gc" that the "Counting objects" phase of the repack
and the connectivity search in prune are counting the same objects. It
would obviously be easy to just dump the set of sha1s in packed binary
format, and let git-prune reference that.
But it doesn't work in the general case. Running "git gc" will repack
everything, and so it looks at all reachable objects. But "git gc
--auto" will typically do an incremental pack (unless you have too many
packs), which means its counting objects phase only looks at part of
the graph. So that result can't be used for object reachability, since
many objects won't be marked[1].
So yes, it's an optimization we can do, but it only works some of the
time. And worse, it works in the time we care less (when we are doing a
full repack anyway, so we are already spending more time counting
objects, and more I/O rewriting existing packed objects), but not when
we want it most (doing a few seconds of incremental repack during "git
gc --auto", which balloons to a minute because of the prune time).
-Peff
[1] It's tempting to say "well, we just repacked incrementally, so if
something was referenced and not packed, we would have just packed
it, right?" But look at how incremental packing works. We do a
traversal with "--unpacked", which means we don't dig down past
commit objects that are already packed. And that's why its fast.
But packs don't necessarily respect reachability. It's possible for
you to have object X in a pack, but X^{tree} is not (or X^, or
whatever)[2]. I believe using "git repack" would fail to actually
pack that. But that's OK, because it almost never happens, and the
worst case is that the object doesn't get packed until you do a full
repack.
But I'm not sure you would want the same level of shortcut for
git-prune, which would actually be _deleting_ the object. We want to
be very sure in that case.
[2] The obvious way to get into this situation is to give weird rev-list
parameters to pack-objects. But I think you could also do it
accidentally by having commit X loose, then fetching history
containing commit Y that builds on X. If the fetch is big enough,
we'll keep the pack that we got from the other side. So X remains
loose, but its ancestors are packed. Running an incremental repack
will stop the traversal at Y and never consider X for packing.
I didn't actually test this, but that's my reading of the code (see
the revs->unpacked check in revision.c:get_commit_action).
^ permalink raw reply
* Re: [PATCH 2/2] git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
From: Junio C Hamano @ 2011-12-28 21:38 UTC (permalink / raw)
To: git; +Cc: Sven Strickroth, Jakub Narebski, Jeff King
In-Reply-To: <7v39c41keo.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I actually was hoping that the answer is "it depends on the helper
> specified by *_ASKPASS".
>
> In any case, let's not add that extra "Certificate unknown. " prefix at
> all to avoid regressions and queue this patch series for real.
>
> After somebody comes up with a way to deal with overlong prompt, building
> on top of this series, we can work on making this particular prompt longer
> and more descriptive.
I've queued the two patches with minor tweaks.
I think the first patch is a definite improvement for both GUI users and
terminal users who use the *_ASKPASS environment variable. Other parts of
git already asks the latter their password using *_ASKPASS anyway, so I do
not foresee complaints from them saying that git-svn suddenly stopped
reading the password from the terminal.
I am however not sure if the second patch in this series is a good thing
in the current shape. For GUI users who do not have a terminal, earlier
they couldn't respond to these questions but now they can, so in that
narrow sense we are not going backwards.
But for people who use *_ASKPASS and are working from the terminal, it is
a regression to ask these non-password questions using *_ASKPASS. Most
likely, these helpers that are designed for password entry will hide what
is typed, and I also wouldn't be surprised if some of them have fairly low
input-length restriction that may be shorter than a long-ish pathname that
users might want to give as an answer, which they could do in the terminal
based interaction but will become impossible with this patch.
I suspect that we would need to enhance *_ASKPASS interface first, so that
we can ask things other than passwords. Until that happens, I do not think
we should apply the second patch to use *_ASKPASS for non-passwords.
^ permalink raw reply
* Re: [PATCH 2/2] git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
From: Sven Strickroth @ 2011-12-28 21:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jakub Narebski, Jeff King
In-Reply-To: <7vpqf8z8a6.fsf@alter.siamese.dyndns.org>
Am 28.12.2011 22:38 schrieb Junio C Hamano:
> I am however not sure if the second patch in this series is a good thing
> in the current shape. For GUI users who do not have a terminal, earlier
> they couldn't respond to these questions but now they can, so in that
> narrow sense we are not going backwards.
>
> But for people who use *_ASKPASS and are working from the terminal, it is
> a regression to ask these non-password questions using *_ASKPASS. Most
> likely, these helpers that are designed for password entry will hide what
> is typed, and I also wouldn't be surprised if some of them have fairly low
> input-length restriction that may be shorter than a long-ish pathname that
> users might want to give as an answer, which they could do in the terminal
> based interaction but will become impossible with this patch.
>
> I suspect that we would need to enhance *_ASKPASS interface first, so that
> we can ask things other than passwords. Until that happens, I do not think
> we should apply the second patch to use *_ASKPASS for non-passwords.
git-core also asks for username using *_ASKPASS, this is the reason why
I implemented it this way. I noticed it when I tried to push to google
code (using https).
--
Best regards,
Sven Strickroth
ClamAV, a GPL anti-virus toolkit http://www.clamav.net
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply
* Re: [PATCH] gc --auto: warn garbage collection happens soon
From: Nguyen Thai Ngoc Duy @ 2011-12-28 21:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpqf94r8c.fsf@alter.siamese.dyndns.org>
2011/12/28 Junio C Hamano <gitster@pobox.com>:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> This gives users a chance to run gc explicitly elsewhere if they do not
>> want gc to run suddenly in current terminal.
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>
> As I am still in a cheerly holiday mood, let's be a bit philosophical,
> step back a bit and think.
>
> After this patch gets applied, will the users start feeling bothered by
> repeated "you will soon see auto-gc" messages and will want "you will soon
> start seeing the you will soon see auto-gc messages" warnings?
They should not for most of the time, given the default settings is
warnings at 90% limits. If they do feel bothered, they could turn it
off or just run "gc".
> And if the answer to that tongue-in-cheek question is no, what is the
> reason why the users will not find the messages disturbing, while loathing
> the auto-gc?
>
> I suspect that is because auto-gc takes long time, making the user wait,
> compared to the new message that may be noisy but quick. Perhaps the real
> cure for the disease is not to add the message but to make an auto-gc less
> painful, no?
It's something with expected run time of a command. When I'm about to
run "commit", I know the command is fast and I expect the shell prompt
soon. When I run "fetch", I know it may take a bit (or a lot) of time
and I will be ready to make myself a cup of coffee while it's running.
auto-gc is an unknown factor and may break my expectations. I would
not mind if auto-gc is extremely fast, e.g. a couple of seconds
maximum. But gc time seems to be proportional to repository size.
> What are the things we could do to make auto-gc less painful?
>
> Are we doing something that is not necessary in auto-gc that takes time
> but that we can live without doing?
>
> It may be a better cure for the disease to force a full gc after
> operations that we know the users already know to take long time (e.g. a
> clone, a large fetch), so that the next auto-gc do not have to do much
> work.
git works best when everything is in one pack. So while we may be able
to skip stuff and make auto-gc fast the first few times, eventually we
need to do something like "git repack -ad" as part of auto-gc. I don't
see any way to make that part complete in a few secs regardless repo
size (unless packv4 comes in time and speeds up revlist
significantly). So the pain will be there in the end, it's just
delayed.
There's another possibility (but not sure if it's feasible): to make
auto-gc use up to certain amount of time. If it runs out of allocated
time, it needs to save its state somewhere, somehow and resumes in
next auto-gc.
--
Duy
^ permalink raw reply
* Re: [PATCH] gc --auto: warn garbage collection happens soon
From: Nguyen Thai Ngoc Duy @ 2011-12-28 22:09 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20111228213018.GA22811@sigill.intra.peff.net>
2011/12/29 Jeff King <peff@peff.net>:
> Especially now that prune has learned about progress reporting, it's
> easy to see in "git gc" that the "Counting objects" phase of the repack
> and the connectivity search in prune are counting the same objects. It
> would obviously be easy to just dump the set of sha1s in packed binary
> format, and let git-prune reference that.
>
> But it doesn't work in the general case. Running "git gc" will repack
> everything, and so it looks at all reachable objects. But "git gc
> --auto" will typically do an incremental pack (unless you have too many
> packs), which means its counting objects phase only looks at part of
> the graph. So that result can't be used for object reachability, since
> many objects won't be marked[1].
Hmm.. I was thinking of sharing this "counting objects" part when
repack is rewritten in C. I guess I can drop the idea now.
--
Duy
^ permalink raw reply
* Re: [PATCH 2/2] git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
From: Junio C Hamano @ 2011-12-28 22:29 UTC (permalink / raw)
To: Sven Strickroth; +Cc: git, Jakub Narebski, Jeff King
In-Reply-To: <4EFB8E78.4090205@tu-clausthal.de>
Sven Strickroth <sven.strickroth@tu-clausthal.de> writes:
>> I suspect that we would need to enhance *_ASKPASS interface first, so that
>> we can ask things other than passwords. Until that happens, I do not think
>> we should apply the second patch to use *_ASKPASS for non-passwords.
>
> git-core also asks for username using *_ASKPASS, this is the reason why
> I implemented it this way. I noticed it when I tried to push to google
> code (using https).
I thought that was updated with Peff's series recently?
In any case, your username has a lot minor annoyance factor if we force
you to type in blind, but the second patch in your series ask things other
than that using the same mechanism, so it is not a good excuse for this
usability regression in git-svn, I would think.
^ permalink raw reply
* [ANNOUNCE] Git 1.7.8.2
From: Junio C Hamano @ 2011-12-28 22:31 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git 1.7.8.2 is available. It contains
accumulated fixes that applies to the 1.7.8.X maintenance track that have
already been applied to the 'master' branch to be part of the upcoming
1.7.9 release.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
7187c1af96db0c181b801957d6e152ec7cd60ab6 git-1.7.8.2.tar.gz
9047175e5c46aa3260c42e6b4459cf4ee5a7bb8a git-htmldocs-1.7.8.2.tar.gz
cc394a0a9689297fddad40c1ccbded0ba9d708da git-manpages-1.7.8.2.tar.gz
Also the following public repositories all have a copy of the v1.7.8.2
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.7.8.2 Release Notes
==========================
Fixes since v1.7.8.1
--------------------
* Porcelain commands like "git reset" did not distinguish deletions
and type-changes from ordinary modification, and reported them with
the same 'M' moniker. They now use 'D' (for deletion) and 'T' (for
type-change) to match "git status -s" and "git diff --name-status".
* The configuration file parser used for sizes (e.g. bigFileThreshold)
did not correctly interpret 'g' suffix.
* The replacement implemention for snprintf used on platforms with
native snprintf that is broken did not use va_copy correctly.
* LF-to-CRLF streaming filter replaced all LF with CRLF, which might
be techinically correct but not friendly to people who are trying
to recover from earlier mistakes of using CRLF in the repository
data in the first place. It now refrains from doing so for LF that
follows a CR.
* git native connection going over TCP (not over SSH) did not set
SO_KEEPALIVE option which failed to receive link layer errors.
* "git branch -m <current branch> HEAD" is an obvious no-op but was not
allowed.
* "git checkout -m" did not recreate the conflicted state in a "both
sides added, without any common ancestor version" conflict
situation.
* "git cherry-pick $commit" (not a range) created an unnecessary
sequencer state and interfered with valid workflow to use the
command during a session to cherry-pick multiple commits.
* You could make "git commit" segfault by giving the "--no-message"
option.
* "fast-import" did not correctly update an existing notes tree,
possibly corrupting the fan-out.
* "git fetch-pack" accepted unqualified refs that do not begin with
refs/ by mistake and compensated it by matching the refspec with
tail-match, which was doubly wrong. This broke fetching from a
repository with a funny named ref "refs/foo/refs/heads/master" and a
'master' branch with "git fetch-pack refs/heads/master", as the
command incorrectly considered the former a "match".
* "git log --follow" did not honor the rename threshold score given
with the -M option (e.g. "-M50%").
* "git mv" gave suboptimal error/warning messages when it overwrites
target files. It also did not pay attention to "-v" option.
* Authenticated "git push" over dumb HTTP were broken with a recent
change and failed without asking for password when username is
given.
* "git push" to an empty repository over HTTP were broken with a
recent change to the ref handling.
* "git push -v" forgot how to be verbose by mistake. It now properly
becomes verbose when asked to.
* When a "reword" action in "git rebase -i" failed to run "commit --amend",
we did not give the control back to the user to resolve the situation, and
instead kept the original commit log message.
Also contains minor fixes and documentation updates.
^ permalink raw reply
* git clone problem
From: Steven Sroka @ 2011-12-28 23:08 UTC (permalink / raw)
To: git
Hello everyone,
I don't know whether I'm having a git problem or a Gitorious problem,
but when I try to clone a remote repository, I get this error:
[steven@chakra-pc Projects]$ git clone
https://git.gitorious.org/chakra/tribe.git
Cloning into 'tribe'...
error: Could not resolve host: git.gitorious.org; Cannot allocate
memory (curl_result = 6, http_code = 0, sha1 =
19e44a5608b262d81c06a00425db9e4f2d82ca98)
error: Unable to find 91fd634acca7d88abb449b379c7c6730bf0df33d under
https://git.gitorious.org/chakra/tribe.git
Cannot obtain needed tree 91fd634acca7d88abb449b379c7c6730bf0df33d
while processing commit 378b1f6d9bdca8ad3ce957a4f7a83c19691afb04.
error: Fetch failed.
Anyone know what is going one?
--
Steven Sroka
(lin-unix)
^ permalink raw reply
* git alias question
From: Michael Horowitz @ 2011-12-29 1:27 UTC (permalink / raw)
To: git
Hello all,
I have been unable to find a solution to this, so I figured I would
post to this list...
I am trying to make an easy command to let me look at the last diff to
a specified file, either plain or with a diff tool, such as vimdiff.
This is the last actual change, not just HEAD^, because the file may
not have changed in many commits.
I was able to make the following 2 aliases, which work perfectly
except for one problem...
ldiff = "!git diff `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
ldifft = "!git difftool `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
The problem is the limitation that shell commands are always executed
at the top-level directory of the repository. Normally I am in a
deeply nested directory, so if I specify the file name in that
directory, it doesn't work. Having to specify the full path relative
to the top level makes these aliases more cumbersome to use than their
worth.
Is there a way to get around this, or even a completely different way
to do this that I am missing? I want to avoid making a completely
separate shell script.
Thanks,
Mike
^ permalink raw reply
* Re: Possible submodule or submodule documentation issue
From: Bill Zaumen @ 2011-12-29 2:50 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <4EFB725C.7030600@web.de>
On Wed, 2011-12-28 at 20:47 +0100, Jens Lehmann wrote:
> Am 27.12.2011 20:24, schrieb Bill Zaumen:
> > For the 'add' command, the man page for get-submodule states
> >
> > "<repository> is the URL of the new submodule’s origin repository. This
> > may be either an absolute URL, or (if it begins with ./ or ../), the
> > location relative to the superproject’s origin repository."
> >
...
> I assume you did forget to add a "cd library-pkg" here.
Yes, sorry for miscopying.
>
> Hmm, the documentation says "the location relative to the
> superproject’s origin repository", not the directory containing
> it. This means you have to use ".." first to get out of the
> repository itself, no?
The problem is that the documentation also says that "<repository>
is the URL of the new submodule's origin repository" and the wording
would not make sense if the superproject's origin repository was not
also named by a URL. The rules for resolving relative URIs (a URL is
a specific type of URI) are given in
http://tools.ietf.org/html/rfc3986#section-5.4
which has some examples: if you resolve ./g against http://a/b/c/d;p?q
you get http://a/b/c/g (the rules are purely syntactic and the syntax
does not indicate that ".../foo.git" is a directory, and even the
slashes do not definitively indicate directories in the sense of a
file-system directory although they often do). Also, I've enclosed a
Java program illustrating the correct behavior (a method in the Java
class library can resolve URIs so this is an independent test).
import java.net.*;
public class Test {
public static void main(String argv[]) {
try {
URI base = new URI("file:///home/USER/Projects/test/repo.git");
URI relative = new URI("./submodule.git");
URI absolute = base.resolve(relative);
System.out.println(relative.toString() + " -> "
+absolute.toString());
relative = new URI("../submodule.git");
absolute = base.resolve(relative);
System.out.println(relative.toString() + " -> "
+absolute.toString());
} catch (Exception e) {
e.printStackTrace();
System.exit(1);
}
System.exit(0);
}
}
^ permalink raw reply
* Re: GIT and SSH
From: Reza Mostafid @ 2011-12-29 3:06 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20111228T091942-66@post.gmane.org>
Thanks for all the feedback so far.....helps me find out where to look.
Regards
Reza
^ permalink raw reply
* Re: git alias question
From: Miles Bader @ 2011-12-29 3:21 UTC (permalink / raw)
To: Michael Horowitz; +Cc: git
In-Reply-To: <CAFLRbopjqW7OEWN4kxy+6Gb828h4zBC_h=4WiP-q1__LeezxUw@mail.gmail.com>
Michael Horowitz <michael.horowitz@ieee.org> writes:
> I was able to make the following 2 aliases, which work perfectly
> except for one problem...
>
> ldiff = "!git diff `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
> ldifft = "!git difftool `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
>
> The problem is the limitation that shell commands are always executed
> at the top-level directory of the repository.
Hmmm, it'd be cool if git exported an environment variable containing
the CWD when it invoked external aliases like this...!
-Miles
--
Love is the difficult realization that something other than oneself is real.
[Iris Murdoch]
^ permalink raw reply
* [PATCH] Add MYMETA.json to perl/.gitignore
From: Jack Nagel @ 2011-12-29 4:42 UTC (permalink / raw)
To: git, gitster; +Cc: jacknagel
ExtUtils::MakeMaker generates MYMETA.json in addition to MYMETA.yml
since version 6.57_07. As it suggests, it is just meta information about
the build and is cleaned up with 'make clean', so it should be ignored.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
---
perl/.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/perl/.gitignore b/perl/.gitignore
index 9235e73..d5c6e22 100644
--- a/perl/.gitignore
+++ b/perl/.gitignore
@@ -1,5 +1,6 @@
perl.mak
perl.mak.old
+MYMETA.json
MYMETA.yml
blib
blibdirs
--
1.7.8.2.302.g17b4
^ permalink raw reply related
* Re: git alias question
From: Junio C Hamano @ 2011-12-29 5:32 UTC (permalink / raw)
To: Miles Bader; +Cc: Michael Horowitz, git
In-Reply-To: <87wr9g2hcd.fsf@catnip.gol.com>
Miles Bader <miles@gnu.org> writes:
> Michael Horowitz <michael.horowitz@ieee.org> writes:
>> I was able to make the following 2 aliases, which work perfectly
>> except for one problem...
>>
>> ldiff = "!git diff `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
>> ldifft = "!git difftool `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
>>
>> The problem is the limitation that shell commands are always executed
>> at the top-level directory of the repository.
>
> Hmmm, it'd be cool if git exported an environment variable containing
> the CWD when it invoked external aliases like this...!
Yeah, something like GIT_PREFIX environment variable, I guess.
^ permalink raw reply
* Re: [PATCH] Add MYMETA.json to perl/.gitignore
From: Junio C Hamano @ 2011-12-29 5:34 UTC (permalink / raw)
To: Jack Nagel; +Cc: git
In-Reply-To: <1325133725-20671-1-git-send-email-jacknagel@gmail.com>
Jack Nagel <jacknagel@gmail.com> writes:
> ExtUtils::MakeMaker generates MYMETA.json in addition to MYMETA.yml
> since version 6.57_07. As it suggests, it is just meta information about
Are we better off ignoring MYMETA.* instead, so that we won't get affected
when they start dropping new cruft with the same information in yet more
different formats?
> the build and is cleaned up with 'make clean', so it should be ignored.
>
> Signed-off-by: Jack Nagel <jacknagel@gmail.com>
> ---
> perl/.gitignore | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/perl/.gitignore b/perl/.gitignore
> index 9235e73..d5c6e22 100644
> --- a/perl/.gitignore
> +++ b/perl/.gitignore
> @@ -1,5 +1,6 @@
> perl.mak
> perl.mak.old
> +MYMETA.json
> MYMETA.yml
> blib
> blibdirs
^ permalink raw reply
* how can i read git repository information.
From: sp @ 2011-12-29 6:16 UTC (permalink / raw)
To: git
hi all,
i new to git.i have git repository folder of one existing project. i want to
read git repository files from that folder but when i open that file in
notepad ++ it shows some encoded information,,
pleas help...
--
View this message in context: http://git.661346.n2.nabble.com/how-can-i-read-git-repository-information-tp7134908p7134908.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Add MYMETA.json to perl/.gitignore
From: Junio C Hamano @ 2011-12-29 6:58 UTC (permalink / raw)
To: git; +Cc: Jack Nagel
In-Reply-To: <7vty4kx7ol.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jack Nagel <jacknagel@gmail.com> writes:
>
>> ExtUtils::MakeMaker generates MYMETA.json in addition to MYMETA.yml
>> since version 6.57_07. As it suggests, it is just meta information about
>
> Are we better off ignoring MYMETA.* instead, so that we won't get affected
> when they start dropping new cruft with the same information in yet more
> different formats?
Just to make sure there is no misunderstanding. The above is _not_ a
rhetorical question that implies that I _think_ the patch should instead
change the existing "MYMETA.yml" to "MYMETA.*" without adding a new entry
to ignore "MYMETA.json". It is a pure question, and a valid answer could
be "I checked with Perl people and they promise they won't be adding any
more MYMETA.foo left and right with new MakeMaker releases", in which case
the original patch is absolutely the right thing to do.
I am simply asking because I do not know.
>
>> the build and is cleaned up with 'make clean', so it should be ignored.
>>
>> Signed-off-by: Jack Nagel <jacknagel@gmail.com>
>> ---
>> perl/.gitignore | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/perl/.gitignore b/perl/.gitignore
>> index 9235e73..d5c6e22 100644
>> --- a/perl/.gitignore
>> +++ b/perl/.gitignore
>> @@ -1,5 +1,6 @@
>> perl.mak
>> perl.mak.old
>> +MYMETA.json
>> MYMETA.yml
>> blib
>> blibdirs
^ permalink raw reply
* Re: how can i read git repository information.
From: Magnus Bäck @ 2011-12-29 8:21 UTC (permalink / raw)
To: sp; +Cc: git
In-Reply-To: <1325139370841-7134908.post@n2.nabble.com>
On Thursday, December 29, 2011 at 07:16 CET,
sp <sonali.treewalker@gmail.com> wrote:
> i new to git.i have git repository folder of one existing project.
> i want to read git repository files from that folder but when i
> open that file in notepad ++ it shows some encoded information,,
Which file are you attempting to open? What is it that you
want to do?
A non-bare git repository consists of the working tree files
(i.e. the files you keep under version control) and the files
in the .git directory. Most of the latter files aren't meant
for human consumption but are used internally by Git for
bookkeeping purposes. Opening them in a text editor won't be
useful.
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
^ 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